Scala, FUD and the PCP Drug

When something new comes along the established players often spread fear, uncertainty and doubt (FUD) in an attempt to remain dominant.  But what's the opposite of FUD?  I propose praise, certainty and perfection: PCP.  Every now and then something new comes along that so enamors early adopters they uncontrollably praise its merits, the certainty of its value and its utter perfection.  Like a drug, PCP is dangerous unless carefully supervised.

Take Scala, for example. There's so much PCP surround Scala I'm about to overdose.  DZone's top link for the last two days has been a blog titled Scala is my next choice.  It's a nice entry highlighting some of Scala's strengths but the author is too generous with some of the claims.  A quick read might well lead a programmer to conclude Scala will solve all of our programming problems.  Lets look at two claims.

Efficient

Scala is an efficient language, actually due to the latest benchmarks Scala is almost as fast as Java. The JVM implementation of Scala compiles down to bytecode, but during so, the code passes through optimization phaze. An optimization example is the tail recursion optimization, to help you stick to the functional paradigm without sacrificing the performance.

While the Scala compiler (which I praised here) does do tail recursion optimization it's very limited, a performance hack if you will.  The tail call has to be within a final method or local function (and has to be to itself, hence the recursive qualifier).  Rich Dougherty has a nice post on tail calls in Scala that goes into this further.  The fundamental issue is that unlike Scheme or Haskell there's no guarantee of tail calls in Scala because the JVM doesn't support tail calls. See John Rose's post here for further information on tail call support in the JVM and the difference between soft tail calls (the Scala hack) and hard tail calls. Bottom line: recursion in Scala will affect your performance.

Concurrency

Thus Scala suggests another concurrency model called Actors, where an actor sends and receives asynchronous messages in it’s inbox instead of sharing data. This is called: shared nothing model. Once you stop thinking about shared data, you relief yourself from the headache of thinking of code synchronization and deadlocks problems.

I'm not going to argue which concurrency model is better, but it's incorrect to say that you won't get deadlocks using Actors. See James Iry's post on deadlocks in Erlang, or see Charles Leiserson's discussion of deadlocks with MPI, another message based model used by the super computer guys.  Anytime there's a cycle in the dependencies you can get deadlocks, including when you're just passing messages around. Bottom line: Scala won't stop your deadlock problems.

I don't have anything against Scala but lets not make Scala out to be this magically language that will solve all our performance, scalability and concurrency problems.

Comments

[Jordan Zimmerman]

I'm just learning Scala. But if it makes written concurrent code less error prone then it will be a winner. Do you have any thoughts on this? If it's no easier than Java then there's no point in it.

Concurrency is the "pointer", "goto" (name your evil) of programming today. We need a better solution.

[James Strachan]

So you're saying there no point Scala being lots better at lots of things in Java if it can't do a few impossible things like change the JVM from inside the Scala bytecode to support full tail calls in all circumstances or magically avoid deadlocks which noone has yet figured out a way to do?

Scala isn't trying to fool anyone; it describes how to use tail calls properly to avoid recursion (i.e. how to optimise recursion on the JVM) and how to use actors properly using immutable state.

What more do you want it to do? Make your coffee as well? Invent a perpetual motion machine? Its a programming language, that is all - just a very good one! :)

[tinou]

my point exactly, it's just a programming language, not a silver bullet!