Sunday, April 25, 2010

What does Scala have to offer the workplace?

Update: Phil Bagwell of the Scala team has done a far better job than me with writing this up over at :

I posted very briefly a little while back on our experiences with Scala. The positive results of our experiences were duly noted. I thought it was time to give a little more back to the community, and those considering this move. This post attempts to put some thoughts together on:

- who are we and what do we do ?
- why Scala ?
- what do we do with Scala ?
- how to transition ?
- what benefits will you see ?

Of course this commentary is subjective, it is what we as a team have found, and we had a particular scenario in place at our company 'Thatcham Motor Insurance Repair Research Centre'. Furthermore the management have been very open minded and supportive of the technical team's decisions regarding technology stack options.

At Thatcham we conduct research and produce data based on that research. We research efficient, safe, cost effective repair of vehicles, and work with manufacturers to influence the design of new vehicles. If you want to know more, you can visit our site: (please note this is an old site currently under redesign by our team on a new Scala powered platform).

Our team is small, but over the last year we have been tasked to rewrite the entire suite of research software within the company, and to create a new publishing platform to disseminate the data gathered by the research software. These two parallel projects are long running, comprising many mostly web services based modules. The need to rewrite our software stems from a transition to a more web services oriented technical world, and a desire to architect a more coherent extensible platform. A small team needs to avoid firefighting, and must think things through clearly in order to not just survive, but evolve.

Why Scala? In all honesty our first concern was the sheer bloat involved in creating such a large architecture with Java. We initially had a split down the middle of the team between JVM land and .NET land. It is noticeable these days how far plain old Java is lagging behind. Why not use something better than both, with all the choice and power of the venerable Java ecosystem on tap?

We use Scala exclusively across the server side, and these days, that is where the majority of the action is. We have traditional ORM oriented modules, distributed modules, publishing modules and traditional webapp modules. The question in fact is what can't we do with Scala? Perhaps the most crucial of our modules or layers, are the distributed modules, here we make use of Scala's excellent concurrency ready concepts, and in particular actors / message passing. Our chosen implementation of actors is, mainly for the very capable integration capabilities it offers. Effectively Scala and in particular Akka have made us cloud ready, scalable and confident that we are flexible.

How do you get started with Scala, and more importantly bring it in to the enterprise ? Start slowly, Java and C# devs can all get fairly proficient quickly. Ensure the management understand the different ways Scala can be put into use. You can write Scala in a Java style, then harness it's power to a greater level over time. Finally, don't be afraid to ask your questions on the mail lists, both the Scala and Akka list members are very helpful.

How has using Scala benefited Thatcham ?

- the power of functional programming, more choice than just OOP
- collapsing the inheritance hierarchy, alternatives to inheritance, reducing coupling
- expressive syntax, express your intention, solve problems cleanly
- everything is a library, make the language do what you want, how you want it to do things
- enriching the toolset, upgrade your tools, 'pimp my library'
- dropping heavy, cumbersome dependencies, Scala does what Java needs many libraries and frameworks to do
- simple lightweight compile time checked composability and dependency injection
- feature rich actors / message passing, 'free your domain' from pollution, be flexible, scalable

Of note, we have measured a reduction in lines of code by approximately one third thanks to Scala's expressive syntax, and the concise nature of functional programming. Our reduction in dependency baggage has lead to our deployable artifact's more than halving in size where we are not hooked up to ORM. Perhaps more importantly we have more options at an architectural level, thanks to the capabilities of a more evolved language, and developing and architecting are just more fun, which is an often overlooked side effect of the transition.

All of this, and we can still leverage the undeniably rich JVM ecosystem, all those well implemented frameworks. In short we can do more with less code, and we can do it better.

If you want to know more, post a comment, I will be happy to give any help I can.


Rishi said...


Thanks for a really informative & useful post! We're evaluating making a similar move to Scala as well (and are using Akka as well in one of our components). However, we have a few Java/Spring/Hibernate libraries and I am interested in learning how you transitioned your ORM layer, etc.

Also, how has using Scala affected your packaging/artifact structure?


Ross McDonald said...

Hi Rishi.

I hope you get the opportunity to make the move!

Transitioning your ORM layer is definitely easier if you can use Scala 2.8.0 as it fixes several bugs with annotations and interop with Hibernate, most notably nested annotations. Spring integration has in our experience been seamless. Java interop has been very tight for us, with no problems experienced.

Generally speaking if you must remain in the ORM paradigm, you will find you mainly benefit from more expressive syntax, thus writing less code.

Scala has certainly flattened our packaging structure, no more massively nested folders, just a structure over which we now have more control. Our artifact structure has remained largely unchanged.