Scala in practice


Published on

While the Java platform has gained notoriety in the last 15 years as a robust application platform with a thriving ecosystem and well-established practices, the Java language has had its share of criticism. Highly verbose, overly didactic, limited feature set; whichever flavor of criticism you prefer, it's patently obvious that Java is playing catch up to more modern languages with a less rigid evolution path.

The language landscape today is vastly different than it had been five or ten years ago; a wide array of languages are available, designed to suit a variety of flavors: Groovy, Clojure, Scala, Gosu, Kotlin... which should you choose? This lecture focuses on one company's decision to focus on Scala, and presents a case study based on our experiences using Scala in practice, in the hope of providing much-needed real world context to assist your decision.

This presentation was used for the Scala In Practice lecture at the Botzia Israeli Java User Group meeting, May 3rd 2012.

Published in: Technology
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Evolve codebase (in other words, keep existing infrastructure and fix/extend as needed):Frustrating, legacy codebase written under tight time constraints is a maintenance nightmareNew engineering team needs a fresh start; keeping the team in maintenance mode is hazardous to team’s mental healthRefactor and extend (break down into smaller pieces; replace infrastructure incrementally, build extension points where needed):A highly practical solution. Existing code will continue to serve existing customers;Problematic bits can be replaced piecemeal, complex new functionality built separately and integrated at the lowest possible level (usually the database);A good compromise between risk mitigation and engineering sanitySupplant with new architecture (keep existing codebase in place and fix critical bugs only; where new functionality is required, interoperate with existing architecture):Impractical. Existing codebase had too many issues;In practice this is the same as evolving the codebase, because of the prohibitively high maintenance cost on the existing architecture.Complete rewrite: too risky, too slow. ‘nuff said.
  • Scala in practice

    1. 1. Scala In Practice: A Case StudyTomer Gabel, newBrandAnalytics April 2012
    2. 2. Some context circa 2011:• Startup with limited budget• Cloud hosted, Linux based• Complex prototype codebase – Lots of Java code – Serving paying customers
    3. 3. Strategy 101 Supplant Evolve Refactor Complete with newcodebase and extend rewrite architecture
    4. 4. Data points• Complete system rewrite impractical – Too much code – Business continuity a priority – Cannot afford product stagnation• Team comfortable with Java platform• … but want a better language
    5. 5. Why Scala?• JVM-targeted, statically typed• Success stories (Twitter, Foursquare, LinkedIn)• Active community• Good (not perfect) tool ecosystem• Reasonable learning curve
    6. 6. Alternatives • Dynamic • LISP dialect • Dynamic • Java-like syntax • Script-oriented • Static • Java-like syntax • In its infancy
    7. 7. Scala in a nutshell• Pervasive type inference
    8. 8. Scala in a nutshell• Type aliases, closures, first class functions and comprehensions Output:
    9. 9. Scala in a nutshell• Imperative with functional-style constructs
    10. 10. Scala in a nutshell• Traits: static mixins
    11. 11. Scala in a nutshell• Pattern matching FTW!
    12. 12. Scala in a nutshell• Other goodies – Option wrappers (no more NPEs!) – Powerful collection framework – Implicit conversions – Concurrent, immutable maps (HAMT) – Built in actors
    13. 13. Caveat emptor• Scala is bleeding edge• You will get cut – Learning curve – Rough edges – Partial/outdated documentation• It’s well worth it, if you’re prepared!
    14. 14. Focal points• Learning curve• Tooling• In production
    15. 15. Learning curve• Risks: – Functional constructs need getting used to – Few best practices: • Coding conventions • Patterns • “Dangerous” features
    16. 16. Learning curve• Mitigations: – Relatively familiar syntax – Seamless Java integration • Evolve your codebase to include Scala • Reuse existing components and libraries – Lots of wow moments!
    17. 17. Lessons learned“New techniques are easy to explain.Old techniques are hard to maintain.” - an old Vulcan proverb• Encourage experimentation• Encourage rapid iteration• Document and share new techniques
    18. 18. Lessons learned• Get a good grasp of the basics: – Functions and closures – Option wrappers – Pattern matching – Traits, traits and traits• Each of these is immensely powerful• Together, they make ponies!
    19. 19. Lessons learned• Avoid wacky syntax! – Some common Scala libraries have atrocious syntax (scalaz) – Does this make sense to you? val p2c = ((_: Int) * (_: Int)).curried some(5) <*> (some(3) <*> p2c.pure[Option]) should equal(Some(15))
    20. 20. Lessons learned• Promote functional constructs: – Intent over implementation – Massive code savings – Immutability, correct code by design• Mentor junior developers!
    21. 21. Lessons learned• Don’t go overboard – Use implicits sparingly – Avoid tuple overload • x._1._2 * x._2 orElse x._3 == yuck • Use case classes and partial functions instead – Path-dependent types are scary!
    22. 22. Focal points• Learning curve• Tooling• In production
    23. 23. IDE Support• Eclipse support via TypeSafe’s own ScalaIDE• IntelliJ IDEA support via plugin
    24. 24. IDE support• Lower your expectations• Don’t skimp on dev hardware!• Use latest IDE/plugin builds• Take your time – Grok the tool-chain – Assign a “go-to guy” (or gal)
    25. 25. IDE support• Wonky debugging – Java debuggers work… – … with some caveats • Step into synthetic stack frames • Do not step over closures – TypeSafe are focusing on debugging – JetBrains will likely follow
    26. 26. IDE support• Except the unexpected – Spurious error highlighting • Especially with implicit conversions • Double-check with your build tool- chain – Rebuild the project occasionally – The situation is improving daily
    27. 27. Build tools• Native Scala build tool is sbt – Ivy2 (-> Maven repositories) – Scala syntax – Very powerful, sharp learning curve• Stay away from ant• Maven and buildr should work fine
    28. 28. Library ecosystem• Surprisingly mature landscape!• We use: – ScalaTest + ScalaMock – Squeryl – Scalatra• Use your favorite Java libraries natively!
    29. 29. Focal points• Learning curve• Tooling• In production
    30. 30. GC considerations• Lots of generated classes – Higher PermGen utilization – Increase -XX:MaxPermSize• Lots of intermediate objects – High eden space churn (normally OK) – Tune with –XX:NewRatio
    31. 31. Other considerations• Scalac emits lots of synthetic code – Deep call graph – Intermediate stack frames• Default stack often too small – -Xss=2m should do
    32. 32. Nasty surprises• Different compiler, different edge- cases – Stack overflow may segfault – Crash log may fail to generate (JDK 1.6.0_x) – Logs and thread dumps are your friends
    33. 33. Codebase evolution Import Java codebase Refactoring Tipping point Slow growth Initial Scala experimentation
    34. 34. Conclusion• I would recommend Scala for: – Startups willing to take the plunge – Small teams of senior developers – Large enterprises with tech advisory/leadership teams• But not (yet) for: – Contractors – Traditional enterprises
    35. 35. Questions?… answers may be forthcoming
    36. 36. Afterword• newBrandAnalytics for allowing the use of the company name and R&D evidence• TypeSafe and the amazing Scala community for making Scala what it is• … and for the PowerPoint template• Get in touch! – –