Will Erlang Become the Next Java (or .NET)?

Ralph Johnson intrigued the hell out of me with his recent post about Erlang. A language geared specifically toward multi-processor/core environments; systems with reliability of nine 9’s; a number of little processes talking to each other via messages as opposed to dipping their hands into shared memory, etc—sounds too good to be true. Yet this is what Erlang promises.

On Ralph’s recommendation, I ordered a copy of the brand new book Programming Erlang by Joe Armstrong. Joe is a key figure behind Erlang. Apparently, they’ve been running an electronic switching system at Ericson for some time. Built in Erlang, the system delivers, allegedly, the wicked “nine 9’s” uptime.

I’m halfway through the book, and I’m getting a kick out of this language. It’s odd, but once you get the hang of it, it makes sense. For example, variables can be initialized only once, i.e. values are “burned” into variables upon initialization. Want to assign another value? Declare another variable.

Also, there’s no shared memory. Consequently, there are no locks or synchronization primitives. You write a set of processes and they communicate by way of messages. Those of you who ever wrote multithreaded code in C++ with semaphores, mutexes, etc, know what a nightmare it can become. Debugging that mess is, uummm, a little difficult.

Language maturity

I don’t think Erlang will become the next .NET or Java, but I do believe it’ll carve out a niche of devotees, just like Ruby and Rails did. Nothing wrong with that. I think the purity of language will be preserved better. Otherwise committees of “super stars” will inevitably spoil it.

The reason I’m saying it is this. I can’t help but notice how good manipulation of collections, lists and sets is in Ruby, Python, Erlang and similar languages. In .NET, collections are an embarrassment. A handful of primitive lists and dictionaries which only confuse people (see .NET Collection Madness part 1 and part 2). By golly, even STL kicks butt.

List<T> made life a little easier, but the “prescriptive guidance” advocates usage of the neutered Collection<T> class so you can override InsertItem, RemoveItem, etc, hoping that one developer out of a million will actually care! That always bothered me.

If we’re stealing stuff from functional languages into C# 3.x, why not clean up collections while we’re at it?

Conclusion

Anyway, keep an eye on Erlang. If it catches momentum, I think we’ll see some interesting developments.

>why not clean up collections while we’re at it?

Oh, but we couldn't possibly break backwards compatibility, could we? The world would come to an end.

Seriously, I couldn't agree more and I've voiced opinions on this in the past. An increment to the major version number of the framework should indicate backwards *incompatibility* with previous versions. Then they can go mental fixing all the APIs they need to, and developers the world over will thank them for it.

Without doing this, the .NET BCL will end up like Java's libraries. A plethora of deprecated crap and bad practices to avoid just to get the simplest of tasks done. And - as you noted - case in point: collections.

Wow that conclusion was really insightful.

Wow that conclusion was really insightful.

"Conclusion" concludes (i.e. ends) a post. It doesn't necessarily connote a decision or opinion you arrive at. ;)

Ganesha, do you have anything meaningful to add to this discussion?

very true;
its hard to judge wot gonna catch fire and what not. Just like we didn't knew that youtube gonna be success but not the other video sites launched before it.

great coverage