{ tinou bao }

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.

The von Neumann Bottleneck

In high school English literature was my favourite class because it was the one class where I could be creative and develop new ideas, not just memorize equations.  But then it dawned on me that all my novel ideas and perspectives were just hackneyed, recycled ideas some guy from 1625 already wrote at length on.  This made me depress.  Today, more than a decade after high school, I find myself in the same predicament.  All these "new" things that seem so fascinating and exciting--well, they're just the same old ideas with a few refinements here and there.  It's pretty damn depressing.  Is there nothing truly original left in this world?

Take functional programming, for example.  It's all the rage these days.  I first wrote about it in January of 2007 in an entry titled "The Rise of Functional Programming".  Two and half years later FP is still going strong.  Just search DZone, Artima, InfoQ.  Countless articles and presentation of how imperative programming no longer meets the challenges of today's complex, concurrent world--and how functional programming can.  This gets me excited.  Have we reached a new stage of enlightenment, ready to move beyond for loops?  Are we at a tipping point?

Then I read this paper entitled "Can Programming Be Liberated from the von Neumann Style?  A Functional Style and Its Algebra of Programs" by John Backus, dated August 1978.  WTF, 1978.  In 1978 Backus was already telling us what so many experts are just telling us today, that mainstream programming languages suck.  It really is true, everything interesting in computer science was done between 1950-1980.

When I first saw the paper I asked myself, "who's this John Backus guy anyway?"  Well, he's the B in BNF and lead the invention of FORTRAN.  Hmm, OK, maybe I better read his paper, even if it's so old that all the PDFs on the web are bad scans from an ACM reprint.  Here's the elevator summary of the paper.

All the computers we work with are von Neumann computers, named after the Hungarian bad-ass mathematician John von Neumann.  There's a CPU, a store that holds both data and instruction (memory), and a connecting tube that can transmits a single word (think 16, 32, 64-bit) between the CPU and store.  As the great Senator Ted Stevens from Alaska astutely observed, tubes get clogged.  Backus called this tube the von Neumann bottleneck.  The adverse effect of the von Neumann model is "we have grown up with a style of programming that concerns itself with this word-at-a-time traffic through the bottleneck rather than with the larger conceptual units of our problems."

More than 30 years ago Backus was bitching about the things we're bitching about today.  And many of us are only bitching about it because of the "multi-core revolution" and our desire for immutablity.  It really is depressing, to think about it.  We're still writing a bunch of statements to manipulate memory via this clogged tube.  Half the time we're not even dealing with the data, we're just assigning variables that point to the data.  Tomorrow, when I come into work bright and early, I know I'll be excited to spend the day thinking of ways to best clog this von Neumann tube.

Scala's Dirty Little Scalability Secret

The other week, while shooting the shit about programming languages, a colleague mentioned the Twitter Ruby v. Scala debate, how Twitter had switched to Scala to meet their scaling needs. I wasn't following the ruckus that closely (no dog in the fight), but that sounded really odd, to say that one language is more scalable than the another.

For one, different people give different meanings to scalability so any discussion on scalability is bound to be problematic unless the participants all agree on a single definition. I personally like to use Amazon CTO Werner Vogel's description.  Haven't given much more thought to the debate since then; until yesterday, when an article on Twitter's evolving architecture appeared on InfoQ.   Most of the commotion stems from Twitters messaging queue problem:

The first implementation of the MQ was using Starling, written in Ruby, and did not scale well especially because Ruby’s GC which is not generational. That lead to MQ crashes because at some point the entire queue processing stopped for the GC to finish its job. A decision was made to port the MQ to Scala which is using the more mature JVM GC. The current MQ is only 1,200 lines and it runs on 3 servers.

Now I see the problem. We're muddling the language with the platform.  The sentence "a decision was made to port the MQ to Scala which is using the more mature JVM GC" should have read "a decision was made to move to the more mature JVM GC and Scala was chosen as the language".  The move to Scala was dictated by the performance and reliability of the Java VM and its garbage collector, not Scala the programming language.  Twitter is giving Scala the programming language too much credit.  I don't think they are doing this intentionally and they do always note the JVM aspect, but with slides like this

 

and focusing more on Scala the programming language than the VM platform it's not entirely surprising that some folks took issue and were confused by Scala's magical scaling abilities.  And the bit about only 1,200 lines of code omits their dependency on Apache Mina (plain old Java).  In essence Twitter moved to Java and the Java platform--it just so happens that Scala is a cool language that can co-exist on the platform.

And that's Scala's dirty little secret. Scala is only scalable in the sense that it runs on the reliable, high-performing JVM platform. This is why people say that Java the programming language is dead, but long live the virtual machine. Rich Hickey has a good, succinct take on languages and platforms in his rationale for Clojure.  In this sense Ruby is doing it the "old way" whereas languages like Clojure and Scala are doing it the "new way" by leveraging the platform.  If Scala only ran on the 1.4 JVM no one probably would even be talking about Scala, because while some of the language constructs are neat, lets face it, they are not revolutionary or entirely novel.  What's the saying, everything interesting in computer science was between 1950-1980. 

So, in addition to

• languages don't scale, architecture scale
• frameworks don't scale, solutions scale

I will add the following

• languages don't scale, platforms scale  

Incidentally, it should be noted that the creator of Scala refers to Scala's scalability not with respect to the platform but because Scala can be applied to a "wide range of programming tasks, from writing small scripts to building large systems." But since scalability means different things to different people we're bound for disconnect.