Will Node and Scala really dry up?

There’s a quite significant rise of buzz around Google’s Go programming language. Some may think that it’s just another peak of excitement coming after a period of calm because the Scala + Akka / Node plateau is over. Derek Collison says:  “The management layers and infrastructure layers of the newer technologies that provide this cloud delivery model? Within two years, a majority will be written in Go.”. Finally, we have this very interesting talk by Paul Dix, entitled bravely “Why Node and Scala will dry up: Go will drink their milkshake”. I strongly recommend watching this video, which was actually the reason why I decided to write my blog post. As a big enthusiast of Scala I want to address some of Paul’s concerns, so let’s take a look at his “allegations” (but remember to watch the talk first!):


I don’t have experience with writing backend using Node, but I code in JS and Paul’s arguments look pretty convincing to me. The performance vs coding in javascript tradeoff just doesn’t appeal to me for most cases. If I was about to write a super-performant mission-critical system then maybe I’d take a chance to investigate it deeper. Since then, EOT.

Dependencies (language / library versions)

Paul mentions that this is the thing that hurts him most in Scala. Well, I can agree that it is a bit painful and dealing with compatibility takes time and effort, sometimes we just got lead into a dead end. On the other side we have another extreme of Java where high focus on backward compatibility results in really crappy debt and yet it still has lots of quirks when it comes to deal with versions. Maybe it’s wishful thinking but I suppose that aggressive strategy of version incompatibility in Scala will pay off in long term. Early adopters have to pay the price but I hope that reward will be worthy.

No centralized home for libraries

That was never a big deal for me, neither with Scala + SBT nor with Java + Maven. The notion of repository is a decent standard and looking up the right repo to get our libraries is usually very easy. I had a few struggles with finding location of some exotic libs in the Internet but it never took much time.

Option sucks

I guess that this part of video was the moment when I decided to write my blog post 😉 Paul states that using Option requires vague and verbose handling which is pretty much comparable to handling nulls. Well, the main difference is that Option makes implicit explicit and brings null handling to a much safer level. Of course, you can always call .get() and hit a NPE but the difference is that you explicitly ignore a warning. It should be obvious since Tony Hoare explained why he calls null reference “the billion dollar mistake”. As for using map to safely work on wrapped values: it’s not Scala’s idiomatic way. Take Maybe in Haskell. However, I can agree that it may be more elegant to deal with in terms of style. Cedric shows a cool approach used in Fantom in this blog post.

Method invocation without dots or parens needs to die in a fire

Okay, I can agree with that 🙂 There are some exceptions though, like test frameworks that give a neat DSLs using this capability, but in typical codebase it’s just confusing, especially if you browse code written by different people.

Pattern matching

As for using pattern matching with Option, I already pointed out that it may look a bit clumsy. However, using pattern matching with extractors and case classes has much more power than using if/else. Some neat examples can be found on Martin Odersky’s course at Coursera.


A very good point. I was also disappointed that such a mature language as Scala requires to browse many resources over the Internet to find a decent third-party library for filesystem manipulation or network operations.

Too many concurrency options

My experience here is still weak but as all the community buzz around new Akka that I observe (especially on Twitter) always made me think that there are no other options for most cases. However, feel welcome to comment if I’m wrong 🙂

Tuples are an abomination

I agree. I always feel uncomfortable when working with tuples, the whole _.1, _.2 stuff is just hard to read in many cases. It’s often a feeling of hitting a wall when I read concise, elegant Scala code and run into a _.1. What was that? Have to go back and check again. And then bang! _.2. What was that? The whole flow of pleasant code reading gets disturbed.

Language footprint is massive

Unfortunately yes. I often get a feeling that Scala is overwhelming with too much stuff to learn, know and follow. Martin Odersky even proposed to split Scala into different language levels to make it easier but it started a controversial discussion (Sigh… I can’t find the source. Was it on Stack Overflow? Please post a comment if you know it).


I won’t comment too much on this language, because all I know now is stuff I learned from Paul’s talk and another cool introductory talk by Konrad given recently in SoftwareMill (in Polish). Just a few first impressions:

  • Controversial approach to versioning and dependencies.
  • Statements are not expressions. I got really used to expressions, imperative code looks a little stiff to me now 🙂
  • Goroutines and channels: +1, quite interesting concepts
  • Garbage collection: may be risky if it’s really too simple?
  • Compilation to native code: +1 for deployment simplicity. Cool for micro services which are actually a pretty strong trend recently.
  • No inheritance: very good!
  • Syntax: a bit too C-ish

Nature abhors a vacuum

We may observe an interesting progress of adaptation of Go language. Let’s see what future brings and never stop learning.

5 thoughts on “Will Node and Scala really dry up?

  1. andrew

    I don’t think is good idea talk about nodejs when even you have used this..personally I found nodejs really fast for develop and the performance is pretty good…obviously scala is even better but nodejs is a really good option for small teams, short time and moderate concurrent sites…

    About scala, almost everything than you hate are the same than I love (I’m functional programmer with haskell and f#) I found other weak points for scala:

    1 – Compilation time is terrible
    2 – So big, so complex..the syntax is friendly for javist, not for functional programming and many concepts tends to be a bit harder to understand cause the syntax
    3 – memory eater…you need adjust the jvm a lot but even doing this compile and run any small program with sbt are almost 500mb memory…800 mb for intellij …and that is a lot memory waste…
    4 – Some incosstencies or weakness caused for the jvm

    About Go…personally I consider it a really ugly language…with a few thing of python and a lot of c/java….for me is a big fail…rust (from mozilla) looks much more sexy, powerful and modern….

  2. @npeftw

    _1, _2 … in tuples are meh, but I always assign them to vals, just as @bartekpiech mentioned, and then it looks just fine.

  3. KajMagnus

    Here is a thread at Hacker News that kind of debunks the presentation:

    Actually, the “arguments” “against” Scala, made me like Scala *more* — if those arguments are the best reason’s not to use Scala… then Scala is a really good language?

    What bothers me a bit with Scala, is long compilation times.

  4. Jason Legler

    Yea, I wanted to like this presentation more, but as someone who uses Scala every day in a production environment, and would really like for something better to come along, I found his arguments against Scala pretty weak. It’s a complex language, but the things he went after aren’t that big of problems. They’re more like annoyances. Some of them are entirely optional, which is a strength and/or weakness of the language.

    If he doesn’t like options, he doesn’t have to use them. You don’t get a lot of those choices with Go, for better or for worse. Go is opinionated, Scala isn’t. Scala’s tuples are heinous and are a hack job, but @bartekpiech posted a good solution to that problem above. Also, you don’t have to use them. If his online post is the definitive post on why not to use Scala, which it appears to be on Google, I think Scala is going to be fine. I find myself going back and forth on it as a language. The people who pimp it are too mathy and I think that puts people just coming to it off. Also, the JVM is a shit show of ridiculous terminology and silly named abstractions. When you really start solving problems with Scala though, and you get around the warts, it’s a pretty incredible language. I love it some days, and I hate it some days. I get a lot done with it though, and I get it done quickly.

    Scala with Akka is a pretty incredible platform if you take the time to learn it and really work with it. Unfortunately for Scala, that learning period is long because the language is so complex, and there are speedbumps caused by the Java community’s inability to not make things way harder than they need to be. Go’s advantage may be that it can be mastered quicker than Scala can be, but if people stick with Scala a little bit, it can do some neat things.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s