Scala: The Adventure Begins!

I’ve been enthusiastic about the Scala programming language for a few months now, and this week’s been very exciting for the Scala community. A new Scala book from the Pragmatic Programmers was announced today, and Alex Payne from Twitter gave a presentation at C4 that strongly indicates Twitter’s writing part of their platform in Scala. Given this week’s news, I thought I’d explain why I’m using Scala, and what that means for the Lab.

I first discovered Scala while I was using JRuby. I was flipping through a list of languages for the Java Virtual Machine, and the example of Scala code really intrigued me. I couldn’t tell if it was statically typed or dynamically typed at first, and when I looked closer and found its type inference, I was hooked. I’ve got a wide background in many languages, but almost all of them, outside of C, are dynamic languages, and so I hadn’t seen type inference before. I chose Scala to be my language to learn this year.

Being busy with awesome work projects, “learning Scala” quickly became “kind of playing with it and subscribing to a lot of RSS feeds.” It wasn’t until I had a class on concurrency using Java this summer that I picked Scala up for real again. Trying to design a multi-threaded program in Java is sort of like knee-boarding with a cat, and I remembered that Scala had a better way. Its Erlang-esque actors and message passing system made writing concurrent programs dead simple. If you’d like to see an example, check out these two classes I wrote for a concurrent program moving passengers on and off elevators.

It’s not a completely fair comparison, as the Java program only keeps counts of people waiting while the Scala program keeps a list of the people, but the general idea is the same. Note that every method in is synchronized, blocking access to it while another thread is in the method, and there’s a fairly complex set of states, preconditions, and postconditions to prevent race conditions and deadlock. In Floor.scala, we have one private method that waits for messages, deals with the message through pattern matching, and then sends a message back to the original sender. It’s a cleaner, easier to read model, and it’s less likely to contain a hidden race condition.

Concurrency’s not the only reason I’m excited about Scala, of course. Even the most die-hard Ruby enthusiast - I include myself in that description - knows there are some tasks that would perform much better in a compiled language. For MRI, you can always write a C extension; for JRuby, you can write a Java class. Scala’s completely compatible with Java, and it’s possible (although not always completely easy) to call Scala classes from Java, which means you can access them from JRuby. Java’s a fine language, but as someone from a scripting language and functional language background, I’d prefer the first-class functions and type inference of Scala any day.

So what does this mean for the Lab? It doesn’t mean we’re going to use Scala any time soon. This is a personal project of mine. However, we encourage all developers to keep learning and bring those lessons back to the group. We originally switched from PHP to Rails because of Ben Scofield’s interest in and enthusiasm for Ruby. I recently presented on Scala at our monthly developer meeting, and I’m keeping it in mind for the right project where we have to integrate with Java. We know that Rails will not always be the answer. My bet is that the answer might well someday be Scala.

Clinton R. Dreisbach

Posted in Article Category: #Code