To Scala or not to Scala?

I heard today I'm considered an advocate of Scala for a client I'm at. I came across Scala in 2006 and was at first very excite about it, but decided not to keep with it, so I thought I'd share my view of the language.


So, why should you choose to use Scala:

  • It is a type-safe functional language with nice syntax. There are languages (Ruby, Python, Javascript) that are functional, but not type safe. There's Functional Java but code becomes very cluttered with template parameters.

  • Functional programming makes some code a lot shorter. You can google for many examples. For a short example, in Scala I can write

task("foo") {

// do stuff


where the task is invoked later. In Java you'd need to write:

new Task("foo") {

public void execute() {

// do some stuff



  • Type safety is important to get IDE code completion and navigation as well as JIT optimizations (it's hard to compile 'a * b' to machine code unless you know what a and b are)

    • My experience with Ruby was that I did not miss this as code is easy to follow by reading it. In scala, things are different, see example below.

  • Scala has some cool features like operator methods ('a * b' means 'a.*(b)'), pattern matching (making switch statements a lot richer), multiple assignment, type inference, actors library, and more

  • Scala can seamlessly use Java code. So you can use all your favourite libraries and frameworks.

  • Type safety gives you some extent of code check.

  • Scala is where all the cool kids hang.


So far, so good, right? Well, not so good:

  • Scala's rich (as in a lot) syntax structures mean it is easy to get weird compilation errors. In essence, it is like being in C++ again. In dynamic-typed languages, the syntax tends to be a lot simpler (not needing to declare types), and so errors are easier to understand.

  • All the idioms Scala provides means a lot of idioms to learn and master. People may say that you need not use all of them, which is true, but you probably need all of them to read others' code and to reason about it.

  • While reading Scala code, a lot of compilation is going in your head. Granted, the code is shorter, but until you get used to the tricks done by the code to make it shorter, it is hard to understand just by glancing at it.

  • For example, you might see a bit of code like "foo ?: bar". What does it mean? You might want to know what the type of foo is, to open up its file and find the method ?:. But foo is declared as 'val foo = car'. Now car may not be in site. Why? because it is a method imported from some other package. How do you know which? If you're lucky, it is explicit (import, but in Scala, many imports are for everything in a package (or type). Now say you figure out where car is and find its return type, so now you know what foo's type is. Assume it turns out to be Foo. You try finding Foo.scala, but it doesn't exist, since scala allows to define many types in a single file and name it whatever you want. Finally you find that Foo is defined in Helpers.scala. You look for the method ?:, but it is not there. Why? well you figure that in Scala, methods ending with colon are right associative, so the method is actually invoked on bar. You go through the process again and find that Bar is defined in file Util.scala. You open up that file, and no, there's no ?: defined there. Why? because when the Scala compiler sees an object (class) does not support some method invoked on it, it looks for an implicit method that converts the object to another one which does support the method. So now you need to hunt for the implicit method. Finally you find it and there ?: is in all its glory.

  • Yes, I know, IDEs will help you find this at a click of a button. Still, IDE support is not robust enough yet (for me the Eclipse plugin provided just syntax highlighting and conflicted with the spring plugins and I had to resort to using IDEA). And also, for me, whenever I see code as in the above I need to "compile" it in my head to understand the flow.

  • For those interested, ?: is not part of Scala, but an operator that can be added with 3 lines of code to mean 'if foo is not null, use its value, otherwise, use bar' where both foo and bar can be method calls that will be evaluated only if needed.

  • Because Scala compiles to JVM bytecode, they had to do some tricks which are not easy to follow.

    • The reason I left scala can be found in this thread: basically, try to figure out the difference between:

var cond = true

for (val x<-List.range(0,10);cond){if (x>=5)cond=false; Console.println(x)}


which prints 0 to 10


var cond = true

for (val x<-List.range(0,10);{if (x>=5)cond=false;cond}) Console.println(x)



which prints 0 to 4.

What is the difference? It's hard to tell because it is all legal code. The secret (which I couldn't find then, but learned now because I had to) is that whateve is inside the parenthesis of the for statement is evaluated prior to executing the body (which is counter intuitive since it is not howregular for and while behave). So in the firs example, cond is always evaluated to true, even though in the body it is set to false.

  • It is easy for people to create unreadable code: invent operators, use functions where not needed etc.

  • Some libraries are not as robust as they are assumed to be. For example, the lift framework (a web framework) has abandoned the actors library of Scala because they found it to be hard to use due to its bugs (they created they're own actors library)

  • The language is still evolving (2.8 will add named parameters for example).

  • Compared to dynamic-typed languages, Scala still requires the compile-package-deploy cycle that Java defined.




So, should you choose Scala? You should if:

  • You like functional programming, but don't want to loose on static typing (optimization, code completion)

  • You want to keep your team on edge with the latest advancements. This is not necessarily a bad thing. It can mean that people do not stagnate into doing repeated work but stay sharp as the learn new things.

  • You are confident in your team to use the power of Scala to create readable code

  • You think that most innovations will be implemented in Scala and you want to be able to use them (while Scala can access Java code, the reverse is not always true since all the Scala features created un-intuitive JVM classes and methods).

    • Examples are specs, scalatest, lift, akka



You should stick with Java if:

  • Your team members don't want to learn new things (Scala has a steep learning curve) or they will not be able to leverage the language correctly.

  • You have a large existing code base and you don't see your existing framework changing. In this situation, you'll end up writing code in Scala that is just Java with different syntax.


You should use Jruby, Groovy or Jython if:

  • You want the agility of a dynamic-typed language with less syntactic structures

  • You are confident you'll write enough tests to cover the code

  • Your are not concerned you need to squeeze every bit of performance (note that many large sites, with lots of traffic use php/ruby/python. Erlang, a language developed as a soft-runtime environment to develop phone switchboards, is dynamic-typed)


(I left Ruby, Ptyhon out of the equation as I assume most people will want to be able to use existing Java libraries and code)


So why I decided to not keep with Scala back then: First, since I learned it for fun, I was not interested in searching for answers for the many problems I encountered trying to figure how code works. Second, for functional programming, I felt other languages  did a better job at providing functional programming (and other idioms) while keeping the syntax simple and without compile-deploy cycle. But given an enterprise environment, where existing code base is important and so is performance, and with the right team of people, I'd definitly want to use it over Java.



Thank you for your interest!

We will contact you as soon as possible.

Send us a message

Oops, something went wrong
Please try again or contact us by email at