Patric, a former Thoughtworker, is now a technical principal at Springer where he primarily writes code and helps teams deliver software effectively. He has experience with wide range of tools, languages, and technologies. Three years ago, Springer decided to use Scala on a large, strategic project. This talk was an experience report from the journey the development teams made.
Patric highlighted the benefits that Scala brought to the table: functional programming, DSL friendly semantics, concise code, and a relatively gentle learning curve. But the teams faced some very real issues too. The compilation and build times were painfully slow. They achieved some improvement in this department by restricting themselves to using pure-interface traits and good-old object composition, but this didn’t make the problem go away. Patric asserted that Scala is not sufficiently opinionated, provides too much rope, has a surprising behavior at times, and some of its features interact in non-obvious ways, leading to much incidental complexity. The tool support has been another pain point. The IDEs are nowhere near their Java counterparts, and many common refactorings still need to be done manually.
In conclusion, he said that even though they were able to deliver successfully with Scala, they didn’t see much productivity boost. There’s a lesson to be learned from Springer’s experience - Scala might not be suitable for everyone or in all settings. You have to weigh your options carefully before you decide to switch to Scala. Java 8 could be one potential answer, smaller apps and more polyglotism could be another.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.