Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.

Scala Programming: A Guide to Scala Adoption in Your Java Organization

20-Page Tech Report + 15 pages of Q/A w/ Scala founder Martin Odersky


Scala is a language created by Martin Odersky and his desire to combine object-oriented and functional programming on the Java Virtual Machine. Odersky’s previous work on Pizza, GJ, Java generics, the javac compiler and Funnel eventually led to the creation of Scala and its first release in 2003 at EFPL. Scala is purely object-oriented as every value is an object, and functional as every function is a value. The successful mix of OOP and FP paradigms has made the language relatively popular and a “better Java” for many. It’s also a good language for those looking for Haskell-like capabilities on the JVM.

Following the language’s rise in popularity, Typesafe was founded in 2011 by the creators of Scala and the Akka middleware, to provide easy to use packaging of both in the form of the Typesafe Stack, as well as better development tools and commercial support.

In the last few years there has been some criticism of Scala; it’s mostly been accused of being too complex. In this report, we opine that the perceived complexity of Scala actually arises more from the diversity of the ecosystem rather than the language itself. We then look at a simpler subset of Scala that is perhaps a good place to start for Java teams who are considering adopting it in 2013 or later.

We also include an interview with Martin Odersky, creator of Scala, Chairman and Chief Architect at Typesafe and throughout the report we have comments from Josh Suereth, also from Typesafe, and author of Scala in Depth.


Numerous blog posts during the past year or two have accused Scala of being too complex or highlighting other issues with Scala adoption. Some of the criticism is fair, but some of it could be targeting almost any JVM language out there. Scala seems to get more of the flak because it’s more popular and possibly pulling ahead of the others. And also probably because Scala actually is rather complex, but only if you want it to be.

Think of Scala as a swimming pool – there is a deep end and a shallow end; it seems that many people who haven’t learned to swim yet jump straight into the deep end. Inevitably, after splashing about for a while are surprised to find that their legs don’t quite reach the floor, or that they sank to the bottom and are startled by not being able to breathe underwater.

“This is an important point. Scala is not just a “Java++”. There’s a lot of depth to pull out of the language, and lots you can learn. It doesn’t take a lot to start, but it can be intimidating how much is out there. You need to be prepared for it to take some time to learn things in the Scala community. Remember that Scala has been around for many years, and a good portion of its community has been around and experimenting for 5+ years. Don’t get flustered if not everything makes sense. Wade into the pool and get comfortable before going deeper.”


Why does this happen? Maybe it is hard to distinguish the deep end from the shallow end – it’s not quite as simple as having a glance and getting a clear picture of how deep the pool is. Maybe the deep end seems more exciting at first, when you haven’t gotten a true taste of it yet.

Why talk about such a dichotomy in the first place? Because the Scala community is very diverse. It can cater both to newbies and expert type- safe library designers. Some Scala users come from an object-oriented programming background (e.g. Java), some come from a functional programming background (e.g. Haskell).

Scala blends together these programming styles, but still lets you code mostly in an “impure” imperative or mostly in a “pure” functional way. And that might be the main problem – the very different coding styles enabled by Scala means that a lot of code written by people from a school outside of one’s own might seem downright illegible.

“The key here is that team productivity is important. Any language can be introduced in a crippling fashion, regardless of its merits. The same is true with Scala. When working with a team, getting everyone on board and learning is crucial.”


Each Scala team needs to find a common style that they agree upon, or the result will be a mess. The Scala Style Guide might help with this.

This piece is mostly written for those coming from the Java (object-oriented / imperative) school. Some of the suggestions are very much a matter of taste, background and so on, so we’re not expecting everyone to agree with it. But let’s get on with some thoughts, opinions and comments…


There are some things in the Scala ecosystem that will seem like a foreign language to someone coming from Java. They may be fun to mess with and may actually be useful, but if you are trying to adopt Scala in a team of Java programmers, these things might work against you; such as finding yourself inadvertently in the deep end. We think the following parts of the Scala ecosystem are better avoided when just starting out:

  1. SBT – Simple Build tool
  2. Scalaz
  3. Category theory
  4. Libraries that overuse “operator overloading”
  5. Collections of library Source code
  6. The cake Pattern
  7. The Kingdom of Verbs
  8. Too Functional or too type Safe code

Download the pdf

1 2 3 4 5 6 7 8 9Next »