Moving from Java to Scala

Functional programming was nowhere to be seen during my time at University, nor in my professional career, that is up until the point Scala came out of its shell. Object oriented programming had ruled and the only time I had heard much about functional languages were stories from more experienced engineers, most of which usually started with “back in the day”. But in my mind “back in the day” translated to an era of floppy disk drives, ASM programming and low-level hackery, naturally I took no notice.


I remember sitting in a SkillsMatter training course with a Typesafe representative, we had just finished a chapter on the fundamental basics of Scala, I was completely bamboozled by the notion of a lambda, what had happened to the safe haven of verbose imperative code?

In the beginning

Coming from a team of solid Java developers I was initially quite apprehensive, early proof of concept work had been frustrating and getting setup was cumbersome. IntelliJ was tripping over its own heels, traversing Scala documentation that spanned multiple versions of libraries was a battle, compile times seemed sluggish and SBT was another build/dependency management tool to add to the ever-growing list. All this on top of pressures to deliver project features, it felt like we had jumped out of the frying pan and into the fire.

Diving into a full new technology stack and language can be rather daunting, especially when there is no prior expertise in your team.  Although most good developers are able to pickup Scala through self learning, having some formal training or even better, some short-term experienced Scala contractors (with the primary purpose to knowledge share) fast tracked the team to getting their skills off the ground.

Rather than move to a full Scala stack in one swoop we opted to take a more methodical approach.  First we replaced our Java based integration tests with Scala ones, this allowed the developers to learn the fundamentals of Scala without compromising any production projects or code.  Once the team was comfortable with the fundamentals of the language we decided to build our next production project in Scala.

Reaping the rewards

Although the surrounding landscape had initially left much to desire, the advantages of the language itself were soon apparent, to name but a few:

scala-codemore concise code – the syntax and features of Scala strip away a lot of the unnecessary boiler plate that Java enforces while native language features provide solutions to common engineering patterns. Case classes, traits, type inference, optional braces, partial functions, pattern matching, implicit conversions, lazy val and more, it all plays a part.


let’s get functional – Scala treats functions as first class citizens, the ability to compose functions, create anonymous functions and pass them around really makes the language much more powerful when designing your code architecture.

less time coding – Once the team became proficient with Scala, the productivity of our team improved, this is something I observed as a general improvement in my own velocity and my colleagues.

the JVM ecosystem – Scala is a JVM language which meant we still had all of the Java libraries at our disposable, this was particularly important for us as it reduced some of the pressure during the transition period. Familiar technologies such as Apache HTTP Commons, Camel, Spring, Apache CXF and many more could still be used which reduced risk and allowed a more methodical transition to a full Scala stack.

collecting like a boss – Scala collections are immutable by default and it’s not until we really started to use Scala that a majority of problems can be solved without the use of mutable ones. Immutable collections are much easier to reason about, there is less variables and branching statements to consider. On top of this all collections support the holy grail of the functional world, map.

a reduction in bugs…perhaps – this is quite a subjective statement and comes from my personal experience working on multiple commercial Java projects.  Logic bugs that we have seen being raised seemed reduced compared to similar past projects. By logic bugs I mean things like null pointer exceptions, undesired results due to errors in branching logic and just plain business logic mistakes.

I suspect this comes from the ability to write more concise and expressive code with focus on the “happy path” using the functional paradigm. On top of this Scala collections are immutable by default, immutably reduces complexity and makes testing easier, along with the ability to compose behaviour using higher order functions and traits.  All these factors seem to contribute to the quality of our systems which I believe had a direct impact on the types and quantity of bugs. Of course some of this reduction may be attributed to more focus on automated testing, better testing frameworks and engineering practices……or maybe it’s all just placebo, I’ll let you decide.

The landscape now

The landscape for Scala development has improved greatly over the past few years, Scala 2.11 seems to have stabilised, SBT continuous compile mode offsets the longer compilation time allowing you to get feedback fast, there have been major improvements in IntelliJ support, and we also have the Typesafe Activator, which is arguably the easiest way to get started with a Scala application. On top of this we still have the full JVM eco-system at our disposable.

I would like to stress that for the same reasons Scala allows you to write succulent and elegant code, it’s versatility can be a double-edged sword.

with great power comes great responsability

There are a lot of programmers out there who are incredibly smart, sometimes too smart. In the few short years I have been working with Scala, I have seen several examples where Engineers have been lulled into writing unnecessarily complex solutions at the expense of readability and maintainability. I think Scala is a language which can be more susceptible to abuse in this area but as with any language, code quality reviews and established coding standards can mitigate these issues. My advice to those adopting Scala is to carefully choose the patterns and features you adopt, make sure your engineers are comfortable and just take it slow.

A great starting point on providing style and implementation advice is the Twitter Effective Scala guide by Marius Eriksen, I couldn’t recommend it enough.  In my opinion, the best Scala learning resource on the web is The Neophyte’s Guide to Scala by Daniel Westheide, this blog series is excellent and I would highly recommend it to anybody currently learning Scala.

As a final note, I would like to leave you with a point I feel is rarely mentioned.   Programming in Scala is FUN. The language is powerful, flexible and versatile giving you the opportunity to solve problems in the most elegant way, this really does make coding fun again. I’m sure you will all agree, happier engineers are always a good thing in any tech organisation, who can argue with that?!

3 thoughts on “Moving from Java to Scala

    • Haha I saw that when looking into it, I think there has been many references/variations of that quote by lots of different people, the first time I heard it was watching Spiderman the movie as a teenager 🙂

      Maybe I should change it to read Uncle Ben, for comedy value if anything.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s