Thursday, 24 July 2008

Scalaris Released

If you were at the Erlang Exchange in London last month, you should know that one of the hottest talks was given by Alexander Reinefeld, "Building a transactional distributed data store with Erlang"

Joe Armstrong seems to like it too:

"I might be wrong, but my gut feeling is that what Alexander Reinefeld showed us will be the first killer application in Erlang."

"So my take on this is that this is one of the sexiest applications I've seen in many a year. I've been waiting for this to happen for a long while. The work is backed by quadzillion Ph.D's and is really good believe me."

- http://armstrongonsoftware.blogspot.com/2008/06/itching-my-programming-nerve.html

Well, seems like Scalaris has been released! The link went up on the website in the last 24-48 hours. I haven't had the time to look at it yet, but you can grab it here.

Wednesday, 2 July 2008

Notes from Erlang Exchange

I was at the Erlang Exchange in London last week, which I really enjoyed. It was really great to see Joe Armstrong, and to see the faces behind the projects, e.g. Claes Wikström (Yaws, Bluetail, Kreditor, Tail-f), Steve Vinoski, Eric Merrit and Martin Logan (Erlware), Matthias Radestock (LShift & RabbitMQ), Mickaël Rémond (ejabberd) etc. etc.

Something that Joe said reminded me of a comment that Keith made about 6 months ago. I think this is something that gets lost in the hype around Erlang and multicore computing:

Erlang was designed to program fault tolerant systems.

It was not designed to program multicore computers. It was designed 15-20 years ago when multicore-everywhere was not even on the horizon. As a side-effect, it is a good language for multicore systems, since the only way to actually achieve fault tolerance is to have independant processes (read here for some more on this).

I think it's important for us as to remember to advocate this, and instead of marketing Erlang/OTP as "the application system for multicore", we should be marketing it as "the application system for fault tolerance". Oh, and by the way "this is one of the few systems that will actually use those cores that are coming your way".

The second point that I have been pondering, was brought on my Gordon Guthrie's talk about Erlang/OTP vs Google Apps as an application engine. At this moment, there aren't many application systems to choose from, Erlang/OTP, Google Apps and Amazon EC2 come to mind. In the context of the talk, an Application System (A/S) would be something that takes care of a lot of the non-functional requirements of you system, e.g. reliability, scalability (+distribution) etc.

For some businesses, using Google Apps or EC2 would be a good fit, but then you're tied into the value chain of that business, and in some instances you just cannot (for legal and other reasons) put your data on servers you don't own. If you go the OTP route you have full control over your application(s), but there's a lot of extra infrastructure that you will have to supply yourself.

If you start thinking of Erlang/OTP in this way, you realise that the terms should be reversed and it should actually be OTP/Erlang. The platform is actually the important thing. The platform is the thing that gives you the reliability, scalability, distribution and hot code swapping etc. that you require. Erlang becomes this awesome language that you use to build things on the platform. Looking at things from a different perspective can lead to some interesting insights.

If I'm standing at this vantage point, heated discussions like the recent meme-storm in the blogosphere of "Erlang vs Scala" become much less relevant. Is there a platform that gives you reliability, scalability, distribution, hot code replacement that uses Scala as a language? No? Oh. What a pity...