Scala is Unfit for Serious Development

Updates: 1. I do love Scala as proven by this blog 2. I’m critical of the things I love 3. I’m ok with a language that is marketed as a research language, I’m not ok if this language markets itself as post functional, the next big thing and a Java successor.

Update 2: Community response as expected: Everything is fine, personal attacks, move on. How sad. Sorry, shouldn’t have written this as pk11 pointed out.

Scala is Unfit for Serious Development (where serious means you want to make money from it, compared to a hobby). Fact. Because it’s object oriented? No. Because it’s functional? No. Because of the complex type system? No. Because of the love of symbols over words? No. It’s unfit because the developers and the community are unwilling. Since one week I haven’t written one productive line of code, but have been stuck in 2.8 version hell. One little upgrade due to a bug in a library put me into this hell trying to get the code running again. The major points are:

  1. The developers are interested in language research and writing papers, not in making a language for real development
  2. The version hell that is 2.8 – calling this version 2.8.0 is deceptive. As Python (3000) or Ruby (2.0) this should have been a major version called 3.0
  3. The developers do not care about binary compatibility, deprecated, soft migration or API compatibility. Things are changed on a whim – from one RC to the next, and they change major parts of the language/libraries in point releases
  4. They remove and add classes just as they see fit
  5. The community loves cutting edge. Instead of fixing bugs they upgrade to all new released RCs – so have you. It’s called cutting edge for a reason: You’ll cut yourself. And it’s called bleeding edge because you will bleed.

In 15 years of Java I never had those problems. I could focus on writing production code.

The sad thing is: There is no alternative. No statically typed, functional, object oriented language with enough libraries to get going. Would love to use C# if it’s not from MS. Due to no other options I will stay with Scala (Clojure with static types would be heaven [edit] or with x:String instead of #^String x). A sad day.

Thanks to @pk11 and @debasishg for their help and patience.

From Martin Odersky – see comment below:

Wow, what a controversial posting, and what an avalanche of reposes. Let me just
clarify some points.

1. 2.8 is a difficult release, on the order of Python 3 vs the 2.x series. We are almost there.

2. RCs are by definition bleeding edge, and unfit for serious development. Wait until 2.8 final is out — I expect that to happen within the week.

3. “Scala’s developers are interested in language research and writing papers, not in making a language for real development.” That one you got totally wrong. In fact I am about to take a leave from university and found a startup to do commercial Scala support. I am taking some of the key Scala developers with me.

4. Binary compatibility: Yes, it’s a tricky issue. I have said in the past that we will address this issue for releases from 2.8 onwards. And that’s still the plan.

Scala vs.Clojure, part 3 – the similarities

There is some more discussion of Scala vs. Clojure. With the Oracle deal, and some discussions about the slow Java 7 release, it looks like Java is detoriating faster not slower. So discussions about Java succession increase. I’ve discussed Scala vs. Clojure here, here and here. Greg Osuri now adds his take in “Scala Vs Clojure”, What the market thinks and compares job numbers for Clojure and Scala.

What I found interesting was a comment to that post:

I’m not really sure why Scala and Clojure are always discussed side-by-side. Sure, they’re both relatively new languages and they are both on the JVM, but Scala and Clojure have vastly different philosophies.

Scala and Clojure are indeed very different, so why compare them? I’ve wondered the same in the past, because, hey, they just don’t look alike. And nothing less than “different philosophies”. As Jesper on Stack Overflow writes:

Note that Clojure and Scala are two totally different types of programming languages – Clojure is a functional Lisp-like language, it is not object oriented. Scala is an object oriented language which has functional programming features.

But then why are they compared and mentioned together? To some, Java looks to need a successor – see my Is Java dead? analysis – both languages have enough momentum to be discussed as one (contrary to Fan for example). Both are functional languages, both support objects, both favor concurrency. So they are remarkly alike. Only on the first look are they quite different, as Scala favors C style syntax for OO and FP while Clojure favors Lisp style syntax. But that’s only lipstick.


In detail, Scala and Clojure look quite similar:

  1. Scala and Clojure are more alike than different
  2. Both have a strong focus on functional programming
  3. Both favor tight Java integration and basing apps on Java libraries (with wrappers) – with Clojure having a little bit more autarky tendencies
  4. Clojure more Lisp style, but with objects (see protocols)
  5. Scala more C style, but with functions
  6. Both favor persistent collections (immutable)
  7. Both favor new ways of concurrency, STM (Clojure) vs. actors (Scala), but both support the other mechanism with agents in Clojure and STM in Scala or Scala CCSTM


So you might wonder, with all those similarities, is it only a syntax thing? I might concur yes. You can think the same way in both languages, what you perhaps choose are differently thinking communities. The major difference is that Scala has very powerful type system – if you’re into that type of thing – Clojure is loosly typed, but can have type hints – also see here. There is a strong type focus in the Scala community, influenced by early adopters.

Hope this helped to clear some things up.

If you liked this post, might also be interested in some other post I wrote about the topic:

Scala Goodness: Structural Typing

Structural typing in Scala is the way to describe types by their structure, not by their name as with other typing. Structural typing reduces coupling and the need for inheritance. In Java you would mainly use interfaces instead of structural typing.

I go with the same examples as in “Scala Goodness: Compound types” so it’s easier to compare both solutions.

c:{ def call():Unit } describes a type which has a call method that returns nothing – like void in Java. The method does take all objects of types that satisfies this constraint. We can now use call on both classes:

You can also give your structural type a name with type aliasing:

With the same classes from above we get:

Both ways work with more than one method:

Calling with a new dog results in:

Structural typing is very useful if you are not able to modify classes to make them implement a trait or interface or if you want to reduce coupling and increase reuse. How does this relate to interfaces? The benefit of interfaces instead of structural typing is how they describe the roles of a class.

instead of

Scala glory!

See also: