Home » JVM Languages » Scala » I Don’t Like Scala

About Bozhidar Bozhanov

Bozhidar Bozhanov
Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE, as well as Android, Scala and any framework you throw at him. creator of Computoser - an algorithmic music composer. Worked on telecom projects, e-government and large-scale online recruitment and navigation platforms.

I Don’t Like Scala

Yes, it is my opinion, and yes, it might seem like a hate-post. But I’ll try to address the issues I have with Scala and its surroundings. I have used Scala in a single, relatively small project (currently working in production), so I guess I’m somewhere between “n00b” and “intermediate”.

  • there are multiple right ways to do the same thing – there are a lot of tasks that you can achieve with one or two lines in Scala. But often there is more than one way to do it, and there’s no obvious winner. The options vary on the brevity-readability scale, on the functional-imperative scale, and in many other ways. I know what currying, partial functions, partially applied functions, folding, collect, map, apply, etc. do, but given a simple task I can use all of them I don’t know which one. Probably because I’m a beginner – true, and over time I guess I’ll build a preferred set of approaches. Which will likely differ from those of any other co-worker, and the projects will me “messy”. It would be something like having half the project with curly brackets on same line, and the other half – on the next line.
  • it’s cryptic – you can probably be ok with all the symbols flying around after some coding, but I find it plain ugly. It is a high-level language and the use of so many symbols is troublesome. Take a look at this stackoverflow question to see what I mean.
  • binary incompatibilities – I have an error that in a Scala 2.10 project I can’t use a library compiled with Scala 2.9. There are reasons for that, and it will probably be improved or completely fixed in the future, but for now it’s making life harder.
  • not smoothly integrating with existing java frameworks and tools – this is partly due to the different mode of thinking (e.g. you may not need a DI framework in Scala), and there are already a couple of viable Scala alternatives (e.g. ORMs), but sometimes you would prefer to use proven technologies that you are familiar with. And it’s not only frameworks, but tools as well – I found it a nightmare to serialize JSON 6 months ago. All options had at least one thing that isn’t working as I need it, or lack a feature I need (both the java ones, the Java-Scala bridges, and the native Scala ones). I ended up using an abandoned project (jerkson). Luckily, the jackson support is now fixed (at least for my use-cases) and I switched to it. The same probably goes for other libraries as well.
  • random failures – the time I’ve wasted in random things that break during compilation is significant. I only remember the last example, where I extended some Java class and I got an “AssertionError”, with some extra information that I don’t think makes sense to anyone, other than the author of the compiler. This particular example is related to the previous point (as I extended a Java class), but there are some more that I don’t remember, because they were random.
  • irrelevant compiler errors – this isn’t universal, but sometimes you get a compiler errors that are not at all related to the actual problem.
  • slow compilation – I haven’t really experienced that to a significant extent, since the project was small, but worth mentioning – see here
  • IDEs used to be terrible. The scala-ide I’m using is from 6 months ago, and it is practically unusable – refactoring doesn’t work, inspection in debugging doesn’t work, sometimes compilation doesn’t work (while at the same time the maven build runs fine and classes are compiled). I tried IntelliJ back then, and it was slightly better, but I somehow didn’t always compile on save. Now the newest IntelliJ plugin works way better, and I’d say is actually usable. Probably the same goes for the eclipse-based scala-ide. So things are improving indeed, but used to be horrible at a time where you’d expect a technology to be more mature. And no, I don’t want to use vim/emacs/jedit/whatever for a statically-typed language that allows for refactoring, call hierarchies, etc.
  • annotations, enums, reflection – coming from Java, I “cherish” these things. And while if you are in a pure Scala thinking, you may not need runtime retention of annotations, I still haven’t reached that Nirvana, and I also need to use it in conjunction with Java libraries. The workaround is to define java annotations in your project, alongside the Scala classes. Enums – I just don’t like the way they are defined, it’s unnecessarily verbose. And reflection is coming to Scala, but things like @ScalaSignature(bytes) scare me a bit.
  • steep learning curve – even if you are familiar with functional programming, scala introduces a lot of stuff, including the “cryptic” symbols mentioned above. Not only that, but in order to get a full-featured scala project, you may need to learn a myriad or new frameworks and tools, like scalate, scalatest, Squeryl, etc. Partly because the Java-alternatives don’t work well with Scala, partly because the Scala alternatives are taking advantage of Scala features.

I’m not saying you shouldn’t use Scala. And obviously I haven’t listed all the good things about it. But for now I don’t like working with it – I am less productive due to the above problems that I would be in Java, and for me that trumps the productivity benefits that come from the cool language features. Things are obviously improving (both IDEs, the language, the runtime and the libraries), and I certainly don’t regret doing the project in Scala, as this is invaluable knowledge that I’ll possibly use later on.

Reference: I Don’t Like Scala from our JCG partner Bozhidar Bozhanov at the Bozho’s tech blog blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

and many more ....


  1. I was thinking about this the other day (Scala and other functional languages) and mostly your first point. It seems with functional language in general there are 100 different ways to the same thing. Some see this as a strength, but after using a different functional language (Mathematica) I’ve come to believe definitely this is not a strength. In functional languages, people are discouraged from doing things in a simple procedural loop oriented way. There needs to be more and more ‘functional helpers’ to handle special cases. Over time there comes to be 100 difference functions you can use to iterate over items in slightly different ways.

    In Mathematica for example there is Map, Thread, Select, Cases, Table, Array, NestList, Sow, Reap, Join, Partition, Scan, Split, SplitBy, Gather, GatherBy, Outer, Inner, FoldList, Apply, Riffle as a few examples of the ones whose names I can think of. All this just to avoid doing a slightly more verbose for loop. Mathematica still has For, Do and While though, because it turns out that even with all these specialized functions you still need to occasionally resort to a procedural loop to do exactly what you want. The ‘brevity’ of final code is kind of a lie because it relies on the specific functionality of one of a hundred slightly different functions under the covers. While most procedural loops are usually easy to understand, the resulting shorter code from the ‘functional-way’ is usually incredibly difficult to understand and requires visiting and going over the documentation again and again. It’s an incredible cognitive bottleneck, just to save a few characters of typing.

    • Well then you can code Assembler as well, as everything you need is just filling and reading registers. It’s true that there maybe more ways to do the same thing, which is in general not a good idea. However you will understand code a lot easier, when the functions are well named. This is IMHO the real problem, as symbolic operators are sometimes used to heavily.

      Consider the following example

      val list = List(1,2,3,4)
      val (even, odd) = list partition(_ % 2 == 0)

      where as using a while loop

      val (even, odd) = (ListBuffer(), ListBuffer())
      for(e <- list) {
      if(e % 2 == 0) {
      even += e
      } else {
      odd += e

      At some point you will start implementing this functionality itself in some kind of library (or using apache commons or guava for this). Another neat example for partition would be file handling:

      val paths = … // List of paths
      val (files, directories) = paths partition(_.isDirectory)
      val (executables, nonexecutables) = files partition(_.isExecutable)

      This is readable, understandable even with less code. Writing will be harder, but you only write once and read code a lot more.

  2. I’d like to take the time to go through several of your concerns:

    1) multiple ways of doing things – In my experience using scala at two different gigs, I’ve just not really run into this problem that much. You definitely do gain a feel for when to use what functions to use. For example, foreach vs map, you can do everything with map that you can do with foreach, but if the return type is Unit, then use foreach. And I would much rather have the scala collections framework than the java collections framework (Im speaking from a pre-java 8 standpoint, lambdas can make the collections framework in java much better, but it remains to be seen if they will).

    2) cryptic – yes, it can be cryptic but there are improvements on this being made. This isn’t purely a function of the language but also a function of the library and how the standard lib is built. I like having operators tied to functions and I think being able to define new operators gives you an expressive power that’s simply not available in java. Look at Akka’s actors. I find the ! and ? much cleaner than tell or ask. That said, a few good examples of how scala has changed wrt this is scalaz and dispatch. Both of these are moving away from using operations to traditionally named functions. Note that it’s good practice in the scala community to not use operators unless it REALLY makes sense to. e.g. it’s really well know that with Actors ! is fire and forget while ? isn’t.

    3) binary incompatibilities – this is one of the main factors in what has slowed java’s growth and made it an overly bloated API. For example, why in the world has java.util.Calender not been simply replaced with Joda Time? I havent run into many problems with this in my experience. Typesafe has specified when releases will be compatible and when they wont. Im comfortable with this tradeoff that allows the language to continue to improve. Please refer to this post for more details: http://suereth.blogspot.com/2011/12/scala-fresh-is-alive.html

    4) I havent run into any JSON serialization issues. I’ve used lift-json to great effect and haven’t found anything missing from a feature perspective. As far as wanting to integrate with java frameworks, I’ve integrated with jersey, jedis, and a few other frameworks with no issues. That said, I think its supremely important to consider scala a different lang all together. It’s not a cleaner java so let’s not limit ourselves to the JVM. I ask that you share more details on your struggles though.

    5) You’ll need to share more detail here. I havent seen random error’s though when extending java classes

    6) Can you give an example here? I havent seen any compilation errors that dont make any sense

    7) slow compile times – this is a valid complaint however it’s worth considering that the compiler is doing a lot more. there’s a great deal more of code generation and other things that the compiler does when compared to javac. It’s a trade off, but IMO worth it.

    8) You’re being critical of a language based upon the previous state of tooling. I think that’s not really valid.

    9) enums are kinda terrible in scala. annotations are available. as far as reflection, what are you looking for?

    10) you’re complaining about having to learn new frameworks for a new language? again this isn’t valid. there’s great reasons why I would say that tools like squeryl leave hibernate in the dust. I dont see the point in coding in a language that offers a bunch of new tools for expressing and proving programmatic logic and then choosing to limit yourself to a language which doesn’t take advantage of those tools. It makes no sense. You made mention of scala alternatives that don’t work as well. Can you please share? In general, my decision tree for finding a lib/tool is check for a scala way of doing something and if that’s not available fall back to the java way.

  3. Creds: Wrote Scala code for about 3 years where it both used and plugged into a large Java project.

    “there are multiple right ways to do the same thing” To some extent this is true, but I think you do a disservice throwing a bunch of names out implying they do the same thing. “currying, partial functions, partially applied functions, folding, collect, map, apply” are used for different things.

    Ian: I don’t know about Mathematica, but Scala’s List-oriented, looping functions are present in many popular, modern languages. Java 8 is supposed to get stuff like this. It certainly seems like many think these functions are nice.

    “it’s cryptic” Are high level languages typically defined as ones that don’t allow symbolic operator/methods? I wasn’t aware of that. While I do agree with the hard-to-search argument, it is easy to find the scaladoc for the cryptic symbols, which are just methods.

    “binary incompatibilities” This is painful, but how far off is the ‘Java is about the only language that doesn’t have this problem’ argument? Regardless, this is scary to someone who is very used to having a large (hundreds) of dependencies.

    “not smoothly integrating with existing java frameworks and tools” As mentioned above, my Scala project both used a huge number of Java dependencies and plugged into a huge Java project (based on Apache ServiceMix). I wouldn’t claim there was never any pain, but it never made me regret using Scala. In my case, Apache Camel caused me some pain. Do you have specific examples?

    “random failures” & “irrelevant compiler errors” Only you know how much these truly cost you. Scala, like almost all software, has some bugs. Hopefully, the Scala contributors are effectively dealing with them. During my years with Scala, the compiler has confused me, but this wasn’t the norm.

    “slow compilation” This is definitely a pain. In my case, our project had a significant amount of Scala code, and it certainly was much slower than the Java code.

    “IDEs used to be terrible.” Pointing to the past when saying something sucks is sort of silly IMO. Regardless, IntelliJ support has been pretty good for quite some time.

    “annotations, enums, reflection” I haven’t used Java annotations much, so I don’t miss them. I have wanted Java enum-like stuff. I haven’t used Scala’s reflection support, but isn’t it touted as superior to Java’s?

    “steep learning curve” You’re repeating stuff from other sections, so I won’t repeat my replies regarding ‘cryptic operators’ and Java interop.

  4. Samuel,

    Mathematica is also List-oriented. I’ve seen some pretty scary code in Mathematica. It can be very compact and almost impossible to read.

    I only played around Scala a couple of years ago and didn’t like it’s Type system. Often couldn’t do what I wanted without using some hack feature (implicit or something like that). It seemed like a total mess to me. The collection library was also incredibly confusing. Several times I tried to extend make my own special case collection. Wow, beyond painful. I decided not to pursue it further.

  5. So is the learning curve steep, or have you simply forgotten how long it took you learn to develop software in Java? I suspect your blog post would have been the reverse if you learned functional programming first rather than imperative programming.

  6. I have learned functional programming in university, so the functional aspect was not new to me :)

  7. I think you are wrongly blaming the Scala programming language. The language does not force you to write stuff in a complicated fashion. It fully supports object oriented and imperative programming. You can very well just use a subset of Scala to make it feel more like Java.

    I you would stick to Java style of programming you would of course only leverage about 1/3 of what Scala let’s you express, but that’s fine! You determine your own learning curve. At first it’s just a few syntactic differences like `def`, `val`, `var`, the ‘weird’ constructor, `trait` instead of `interface`, etc. This is all fine and not complicated at all for an experienced developer.

    One thing I have noticed though is that people tend to miss the actual thing that makes Scala feel complicated: the libraries. Libraries are written by people who tend to learn more and more of what Scala can offer. They (for example) tend return `Option[String]` instead of `String` (or `null`) and by that expose you to an unknown (or new) type. They will probably also introduce functional or type-level programming and force you to do the same! Or… you could just not use their libraries.

    About the ‘weird’ operators, enthusiastic library writers without a lot of experience tend to overuse weird method names, just because they can. There are however two parts of Scala that are legitimately using ‘weird’ names for classes or types: functional and type-level programming. A lot of concepts in those worlds are known as nothing more than a ‘weird’ symbol. Scala exposes you to those new worlds and that might be scary.

    All in all I do not think Scala itself is complicated, it allows for multiple programming paradigms and is (one of) the first languages to do that. Eager developers tend to try, learn and incorporate new knowledge into their programming and thus their libraries. Most of us programmers are well-schooled in one of those paradigms and thus at least 2/3 of the language features are alien for us.

    I personally love the fact that Scala exposes me to other ways of thinking about programming and expressing myself using the language. It pushes me to learn! If being productive is more important for you than learning, I guess Scala is not for you.

  8. ~ Bozhidar,

    I like Scala, long crazy story to follow. Yet I feel Scala will forever remain a niche language. And that’s just fine. Why wouldn’t it be? Why must Scala surpass Java or any other language to be successful?

    Your critical observations of Scala, though, are painfully spot on. Of course, that always alienates the hardcore Scala folks. Tough.

    Yet, after 12 years, Scala has failed to conquer the enterprise space, not that it initially set out to do so. At least it’s on the map, not unlike a small town in the Switzerland.;)

    And Rod Johnson’s dream of Scala dominating Java by 2018 will simply not happen. Of course, he must know that, given his deep knowledge of the Java enterprise space.

    Even more worrisome for the Scala community is Paul Phillips’ talks, which are scaring prospective developers away from Scala and making Scala newbies reconsider their decision to use Scala.

    Paul, a Typesafe founder, is a true Scala guru. As for lines of Scala written, no one can compare. Moreover, he speaks the truth, and the the Scala community knows it.

    Yet few in the Scala community want to listen to Paul. It’s even more interesting how they don’t have the technical chops, nor ethics, to challenge Paul. To me that represents a community in denial.

    The major force holding back Scala has always been its deep ties to academics and bleeding-edge uber geeks. And that just doesn’t work in the enterprise space, where making money, with the least amount risk, is absolutely paramount.

    Once again, I think that’s okay. Scala has and always will march to its own tune. So just let it be. It’s found its niche.

    ~ javawerks

  9. Thanks a lot for writing this – it’s exactly my feelings (although my experience with Scala is much smaller than yours – but whenever I approach it I hit many of the frustrations you mention here).

    I think a big difference in opinion (people saying “Scala is a solution to all your problems and more” vs people like you, saying “Scala introduces its own problems”) often comes from environment you work in. As it’s been mentioned here, Scala’s background is very academic. It probably works well where you have a small group of very talented people, communicating well with each other, working on small-to-mid-size project. It might save you a lot of time writing verbose Java code (having said that, I NEVER could get that argument as I do NOT write this code – I let my IDE generate it for me. But that’s a side note). Once you get to the point where you can actually understand the convoluted syntax it might be easier to read too (as it will be less lines expressing the same functionality).
    But in the environment where I work in, i.e. enterprisey banking, I cannot see it working on a big scale any time soon. The industry still suffers from a syndrome of “all developers are exchangeable resources” so you get a lot of not-so-good people. I can see how ugly code they can produce in Java – I dare not think what they’d produce in a much more powerful (and thus: dangerous) language as Scala. I can see how often they hit a brick wall with relatively simple Java problems and cannot work out how to fix it – with Scala I’d be on calls explaining things to them all day long.
    Also, the scale of the projects in banking is usually multi-years, multiple millions of lines projects. People change on them, people grow technically and change approach. Even with Java I can see sometimes “oh, this person was just going through a phase of Builder-ing every single class” or “they just discovered Guava functions and I get 10 lines functional programming instead of a simple 4-lines loop”… Exactly same would happen with Scala – except that in Scala the result would be even less readable than it is in Java. You often inherit projects after someone else – and Java’s verbosity is a huge help here – not hindrance. I wouldn’t want to try and work out what the previous developer (who’s obviously no longer in the firm) tried to do with a language where an awful lot is happening “magically”, behind the scenes.

    So… yeah. Especially with the little niceties that Java 8 finally brought to the table, I can’t see a good reason to attempt to migrate to Scala on a big scale (no pun intended). If I hit a problem that explicitly requires a functional approach then I’d isolate the problem into a small Scala-based library but the rest of the project would still be Java.

Leave a Reply

Your email address will not be published. Required fields are marked *


− one = 0

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Do you want to know how to develop your skillset and become a ...

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!
Get ready to Rock!
To download the books, please verify your email address by following the instructions found on the email we just sent you.