Learn You Some Erlang renamed Learn You Some Scala

I'm excited to announce that Frederic Trottier-Hebert has decided to change the name of Learn You Some Erlang to Learn You Some Scala! This should come as no surprise to most of us. As I demonstrated here Scala and Erlang are really the same language. With the growing popularity of Scala it only makes sense to target the Scala audience (whom we can thank for Erlang's actors). I got the chance to talk to Frederic about the change. When asked what finally prompted the change he said:

<MononcQc> Well yeah, I mean I was there when you first were talking with Virding about the migration of Erlang to the JVM. I'm quoted in that blog post

<MononcQc> that discovery was pretty much a shock to me too, and so it's why I've pondered this and discussed the whole issue over #erlang on the course of the last few weeks

<MononcQc> I picked up one of the many great books about Scala and realized that 'damn, they're the same stuff!'

<MononcQc> Scala being bigger with the JVM being stress tested in production environment (sometimes claiming 9 nines of uptime)

<MononcQc> I decided to do the switch.

<MononcQc> So LYSE becomes LYSS

<MononcQc> It's much more marketable anyway

Some of the changes he has told me are upcoming:

• OTP In Scala - How to work with some of the Scala specific OTP libraries to get better soft real time guarantees and performance


• Mnesia and Scala - Mnesia is written in Erlang/Scala so moving your databases should Just Work. There should be a pretty big performance increase due to the JIT too (performance improvements have been shown to be about 20%-25.4%) I'm pretty excited about this one.


• JVM Performance tuning - When to use -client and when to use -server will play a big part in this chapter. Frederic plans on really covering the nitty details of JVM tuning. Frederic admits that he hasn't done much work with the JVM but given the similarity to beam doesn't forsee that being a problem


• Java interop - No more need to use jinterface, Java interop is much easier when running on the JVM!

What does Frederic have to say about possible backlash from the Erlang community about the name change? "I see none. I'm moving for the best". There you have it folks. Frederic said the rebranding is still a work in progress but he hopes to have the entire book moved over to Scala terminology in a few weeks.

How Much Has Scala Influenced Erlang?

This question was recently overheard at qcon. On the surface it seems like a rather silly question but after some digging I think the answer might surprise you.

Scala and Erlang have actually gone back and forth, sharing ideas, for quite awhile now. While many people don't realize it, Erlang was first implemented on the JVM. This is back in the 1.x days when Java was using green threads. Joe had seen that this was a great platform for distributed, low latency, high throughput, concurrent applications and wrote a quick language implementation that quickly grew into Erlang. Martin Odersky has stated several times that Erlang was his influence for implementing Scala on the JVM. It was at this point that Scala introduced actors. While not a new concept, Scala was one of the first major implementations of actors. Erlang originally used a dataflow concept similar to what Mozart/Oz would later implement.

Why, you may ask, did Erlang finally move off the JVM? Such a great platform, you would expect them to stay. The answer is tail calls. The JVM has always lacked tail call optimization and Erlang needed it. Trampolining just was not sufficient for how Joe wanted to structure programs. So they ditched the JVM and implemented their own VM (known as beam). At this point, since Erlang was off the JVM, Sun (now Oracle) decided to drop the green threads for a more traditional threading implementation. While this transition may seem weird, it actually gave birth to what many people consider the most powerful part of Erlang: fault tolerance. Because Joe wanted to move off the JVM as quickly as possible he had people use his unfinished VM, which was very buggy. A lot of the fault tolerance aspects of Erlang come from people trying to work around Joe's buggy VM, which thankfully is quite stable now.

Richard Virding was nice enough to give us a little rundown on what it was like in the early days of moving from the JVM to beam (from #erlang on freenode):

< MononcQc> Did the need for distribution have anything to do with your move from the JVM?

< rvirding> No not at all, Terracotta implemented everything we wanted, and better, it was really the tail calls that pushed it.

< rvirding> I can remember one night late with Joe we were trying to get our own distribution layer worker and we were having trouble with the security model.

< rvirding> Joe had just happened to be playing with Netscape that day and saw this idea they introduced called 'cookies' and he said "Richard, I've got it!"

All of this makes a lot of sense when you think about it though. Given the popularity of Scala and that it was a forerunner to Erlang's style of programming you can see why there are so few Erlang books. It also becomes clear why Erlang has such a hard time penetrating the market. You can pretty much pick up Erlang just from a Scala book and at that point, why not just use Scala?