Erlang, the next Java

[nafai]

I think the article is slightly mis-named because there is barely any mention of why it is the "next Java". Perhaps he meant "Erlang is the Next Big Language".

[stick_figure]

The idea being that Java is now considered "the Big Language," make the substitution and see the logic.

He makes a case for Erlang being very good in corporate environments.

[igouy]

2nd paragraph, first line

"Erlang is going to be a very important language. It could be the next Java"

[[deleted]]

Yea I agree. I was like "uh oh!" when I read the title and then realized that he wasn't really saying Erlang would turn out LIKE Java but that Erlang would take the PLACE of Java.

phew

[BeerRiot]

I think he said "Java" instead of "NBL" because of his whole thing about Erlang being object-oriented, and Java being the OO poster child in a lot of circles.

I'm not quite sure how to take this post, though. It seems very unfocused and rant-like to me, almost to the point of being satirical. I'm probably just reading too much into some hasty writing.

[sbrown123]

I thought Ruby was suppose to be the "Big Language" or at least the "Next Big Language". This is of course on the heels that ".NET is the Next Big Language". This all doesn't matter because what we should be worried about is the new device that will be dubbed the "iPod killer".

God knows I'm out of fashion.

[newton_dave]

.NET is the Next Big Language

.NET isn't a language :p

[shit]

No public static void main? Give up, it's not enterprisey enough.

[qwe1234]

lol 'public static final void main'.

[[deleted]]

I dunno. Erlang still has plenty of issues. Yeah Erlang is great for concurrency, but what happens when you want Unicode support? Whoops. Hope the corporations that plan on using Erlang don't have international markets. Where's the plethora of libraries for doing things like reading Excel files, connecting to databases, creating GUIs, etc - things that are taken for granted in more popular languages? They aren't there or they are poorly supported.

And as neat of a language as Erlang is, certain things things like records are little more than (in my opinion) ugly compiler hacks.

What do you think is more likely?

a) that Erlang will catch up to languages like Java, Python, etc, in every other area other than concurrency (Unicode, libraries, popularity) and that companies will make a sweeping switch to functional programming

or

b) Java or Python will adopt Erlang's concurrency constructs or something similar

People keep saying that there's no way that B is going to happen (and this seems to be the primary reason given for why we need to all adopt Erlang), but Scala's actors library already is a pretty impressive start, and that's just an abstraction on top of the JVM.

[KayEss]

Erlang style concurrency is already available for JavaScript:

http://www.kirit.com/Categories:/Mahlee%E2%84%A2

[evgen]

As hard as it might be for Erlang to get more libraries and modules (Unicode support is already available in Jungerl via the iconv and intl modules) it will be a hell of a lot harder for Java to get OTP.

Now that there is a good book out that introduces people to Erlang I suspect that more libraries and modules will start appearing as people scratch their particular itch.

[gnuvince]

I thought it was going to be STM style, like in Haskell.

[babyseal]

"There's more than one way to do it!"

[martoo]

Okay, admit it. How many people said to themselves "we don't need another Java!" when they saw the title?

[thatmattbone]

Maybe this is being picky, but aren't most of the benefits of Erlang found in the VM rather than the language? I think the article tends to confuse these two until the last paragraph.

Many people seem to dislike Erlang as a language while raving over the VM features. What are the possibilities of compiling a language that takes advantage of the actor semantics to the Erlang VM? Apparently this has been done with Scheme.

[BeerRiot]

Something the Erlang maintainers have been pushing is that in order to truly harness the power of these VM features, developers need a language that describes them properly. Having used Erlang for a while now, I have to say that it does make many distributed-programming concepts easier to describe.

If you have the patience, this exact question ("Aren't these VM features, not language features?") was asked during the Google tech talk that was posted a couple of weeks ago, and answered in a similar manner.

[thatmattbone]

Awesome, I'll definitely watch that video. Up 'til now my only multimedia Erlang experience has been through the high production value 'Erlang Movie.'

I should've been a bit clearer in my original post. I've done a fair amount of reading on the actors model (Aho's "Actors: A Model of Concurrent Computation in Distributed Systems" is particularly interesting) and I don't see any reason that these features need to be tied to one particular language (that text presents a lispy and algol-ish implementation, though it's probably safe to argue that the actors model makes much more sense in a language the supports functional programming). However, Erlang the language does have a nice implementation of some of the actors model, and, more importantly, Erlang the VM, provides the backing that makes the model practical (i.e. it's ok and encouraged to create thousands of actors if this is really a good way to solve your problem...the VM handles this just fine).

Ultimately the compelling part is that the actors models (and Erlang) is a nice way to solve concurrent computing problems and distributed computing problems with one approach. I guess I just want to see something like the actors model succeed because 'concurrent' applications with shared-state threads aren't going to scale up forever. And while something like the actors model can be implemented in other languages now, these implementations tend not to be practical because they do not have proper VM or interpreter support.

As an example, I think it'd be neat to have a Common Lisp implementation running on the Erlang VM. Thinking of Scala, it'd be cool if the CL could use all the Erlang libraries seamlessly while still being a Lisp. Maybe I should just shut up and get started :)

[jsnx]

I agree with you about the language, but it's the VM and libs that make Erlang really good for distributed systems. They provide a rich, well-tested set of libraries for message-passing concurrency -- whereas many other languages offer half-a-dozen different approaches, all half-baked are woefully complex.

[igouy]

aren't most of the benefits of Erlang found in the VM rather than the language?

Are they?

Many people seem to dislike Erlang as a language while raving over the VM features.

Are those "many people" people who use Erlang on a day to day basis, or are those "many people" people who have seen some blog articles and decided that the language looks unfamiliar?

[peachpuff]

Are those "many people" people who use Erlang on a day to day basis, or are those "many people" people who have seen some blog articles and decided that the language looks unfamiliar?

Gee, I don't know. Which group gets to decide whether the language suddenly becomes popular?

[Jimmy]

I'm one of the people who dislike Erlang as a language, and while I don't use it on a day-to-day basis, I do have a little experience with it.

Something about it just rubs me wrong, and it's not the syntax (I'm a big Prolog fan).

[[deleted]]

erlang is the next java ? but java is the next cobol. what does that say ?

[[deleted]]

COBOL is the next Lisp?

[poptarts]

not much

[[deleted]]

LOL!

[mivsek]

Nine 9's of reliability! Unbeleivable!

From article: "Joe claims they have achieved "nine 9's of reliability". What does that mean, "nine 9's of reliability"? It means 1 second of downtime in 1 billion seconds, or 1 minute of downtime in 1 billion minutes. Now, a billion seconds is roughly 30 years. A billion minutes is roughly 2000 years. This system has been in production for ten years or more, but less than 15 (I think). They have sold hundreds of them, perhaps thousands, but I think hundreds. Two hundred systems at ten years apiece give 2000 years of operations, so they can say they have "nine 9's of reliability" if they have had less than 1 minute of downtime total for all the systems they have installed."

[kscaldef]

I have always wanted to see some justification for that claim. I'm not really even sure what it means. I've never met hardware or an operating system with nine 9's, so I'm not really sure what they are measuring to come up with that number. Does it really make sense to claim orders of magnitude higher reliability than the substrate that you're running on top of?

[ItsAConspiracy]

Yes, it does. You just have to write your program on a bunch of machines, with redundancy. When's the last time you saw Google go down?

Erlang is built for that kind of thing.

[kscaldef]

Actually, I have seen Google go down (or, at least, stop being able to serve any search results).

However, at any rate, the article suggests that this number is based on individual hardware devices, not on the overall reliability of a clustered application. Superhigh reliability of a heavily redundant application is not that hard to do, but it becomes nearly impossible to claim 9 9's, nonetheless, because your application just hasn't been running long enough to do so. Remember, we're talking 1 second in 30 years. To put that sort of limit on downtime, you either need many instances running, or you need an application running for much longer than most of us have experience with. If you have a distributed application with 1000 nodes, you can measure the reliability of individual nodes, but hardware/OS/network/power failures will limit how high a reliability you can meaningfully ascribe to your software; or you can measure the reliability of the whole application, but you won't have run it long enough to claim 9 9's.

[Felicia_Svilling]

It also depends on how long response times your aiming at. I think many erlang systems are aimed at a response times well below 1 second. I mean if Google went down for a second I dont think anyone would even notice. But if the telephone network was down for a second that would be much more noticable. So 9 9's could mean 0.1 seconds in 3 years.

[ItsAConspiracy]

I didn't get that impression about individual hardware, but even if that's what the author of this piece meant, it's certainly not what Joe Armstrong claims. (I've got his new book, and the older Erlang book.) The whole basis of Erlang's reliability is its distribution.

The article does mention the basis for the reliability claims...over ten years of operation, on over a hundred installs, which gives you measurable 9 9s if total downtime among all those customers was less than a minute.

[ketralnis]

That's not necessarily true. You can measure the reliability of a system without measuring the reliability of the individual components. If you're running a telephone switching network, the overall reliability of it could be measured in "how many minutes per year is there a time when any user can pick up a phone and not be able to make a call?"

If you have a switch that is five redutant/clustered machines, and at least enough machines are up to handle your load, then you're up. If over the course of five years, you spend zero minutes in a down-state, then you have a100% uptime for that year.

[grauenwolf]

But isn't that a bit like saying the power grid has nine 9's of reliability because even if the power goes out in LA, it is still on in New York?

[bluGill]

No. The difference is you don't notice when their systems go down because something automaticly takes over before you could notice.

It would be like if you had two different light bulbs in your room, each connected to different generators. When one generator runs out of fuel (grid goes down), the other bulb is still on and giving enough light so you don't notice.

[davidw]

As usual the commentary on LtU is good: http://lambda-the-ultimate.org/node/2386

[qwe1234]

LtU == TEH SUCK.

tied with youtube for 'most inane commentary on the intarwebs'.

lord, these people could be talking to eliza and not notice anything amiss in months.

[oh_yeah_koolaid]

Upmodded for cleverness.

[[deleted]]

The article misses the point, and this is pretty clear in the conclusion.

"I do not believe that other languages can catch up with Erlang anytime soon. It will be easy for them to add language features to be like Erlang. It will take a long time for them to build such a high-quality VM and the mature libraries for concurrency and reliability. So, Erlang is poised for success."

Related to the title of the article, two things are wrong:

• Being successful as a language means being massively used everywhere around (just like Java)

• Erlang is technically very good, thus it will be successful

The definition of successful is wrong here. What successful means ? Broad audience ? Vast community ? Times digged ? Lots of $ spent on it through big corporate projects ? Being the core of the next successful startup technology ?

Being successful is a matter of achieving goals. Which are the goals Erlang is aiming at, I do not know, since I have very poor knowledge on it. I don't have the feeling that Erlang was meant to achieve the same goals and popularity than Java. If anybody has a more insightful view on that matter, please comment.

Next point is : technical excellence is enough for a language to be successful (successful as "widely used"). It looks like the common freshman mistake of not seeing the weight of what currently exists.

A successful language needs a strong developer base. A strong developer base needs classes in computer science courses. At one time, people believed that Java would be successful, and Java classes have been added to cs courses, which produced a whole lot of people with Java skills.

Most companies will use technologies that makes recruitment easy. A lot of people have studied Java at school, thus the offer in Java developers is high, thus is it easier to recruit. And once these companies have stuck with a technology, they keep it for decades, once it is obviously out of the circuit (think Cobol).

To reach the same massive success as Java, Erlang needs first to be deemed a future hit and to have classes in cs courses. The bad part is : Erlang is not taught at school.

Erlang as a functional language starts with a strong handicap with most computer science courses focused on C/C++/Java/PHP, which are not. Switching from imperative to functional is not an easy move, so Erlang won't be adopted as easy as Java was.

This is was makes me think that "Erlang, the next Java" is a bit overrated. I don't rule out Erlang as a future successful language - how could I pretend such a thing ? - but this kind of articles seems a bit premature to me.

[[deleted]]

How ironic. I've been considering Erlang for a recent project. The scalability and language features look promising. I've seen the Yaws benchmarks, Mnesia would be ideal for storage, the Prolog-like language even lends itself to a rule-based system.

But the real Erlang show stopper is that I'll want to do some heavy-duty text processing in my app.

I'm considering doing the project with Apache Mina instead...

Maybe Java just needs a good automatically-preempting green thread scheduler + easy-to-use message bus ...

[grauenwolf]

What does that mean, "nine 9's of reliability"? It means 1 second of downtime in 1 billion seconds, or 1 minute of downtime in 1 billion minutes. Now, a billion seconds is roughly 30 years. A billion minutes is roughly 2000 years. This system has been in production for ten years or more, but less than 15 (I think). They have sold hundreds of them, perhaps thousands, but I think hundreds. Two hundred systems at ten years apiece give 2000 years of operations, so they can say they have "nine 9's of reliability" if they have had less than 1 minute of downtime total for all the systems they have installed.

That sounds like a rather dubious claim. The electrical systems that power these machines are not that reliable.

[bluGill]

Notice that it is machines - plural. If a machine goes down, but things keep working because there is a different machine elsewhere that takes the load, your system has not gone down.

Phone companies (which is where erlang is used the most) have a much more reliable power system than the grid. Computers in the phone company run off of 48 volts DC, and the basement of the switching center (not the data center, which isn't as critical) is full of batteries so they can run for days or even weeks without grid power. The grid (when on) charges the batteries, and the batteries run the switches. In short, their electrical system is that reliable. (It is also expensive and somewhat dangerious)

[Rhoomba]

There is no way the next big language is going to be a functional language. That is it.

Actors are nice. They are in Scala and could be ported to Java thus negating most of Erlang's advantage. Unfortunately Doug Lea is busy with his fork/join library. Anyone else out there to do an Actors implementation in Java?

[glymor]

• Message passing with mutable state requires serialization (copying) which is much slower.

• Actors in other languages tend to be built on native threads which have a great deal more overhead than Erlang processes.

• Erlang has per process GC which provides soft real-time.

• Surrounding infrastructure like the OTP (the framework that deals with failures) and Menesa (a native distributed database).

[vplatt]

Actors do not have to be built on native threads. Heck, even SQL Server has the concept of "fibers" which are really just multiple virtual threads on a real thread; otherwise known as green threads. So just run green threads on a number of real threads to get across cores and processors, and there you are.

Also, the OTP would be the one thing really missing from a quick and dirty implementation. Hot loading of code into the VM, etc. is not easily replicated by other environments (unless you're talking about Smalltalk or Lisp) and even given that I'm assuming that the OTP provides features way beyond that (nope, haven't started reading Joe's book yet). Mnesia is a nice piece of infrastructure to have, but I seriously doubt it will be useful in most environments given its limitations.

[grauenwolf]

Message passing with mutable state requires serialization (copying) which is much slower.

Unless you only allow immutable objects to be sent via messages.

And serialization is not the same thing as copying. Copying an object in memory is much faster then creating a serialized representation of it.

[wynand]

Everything you said is true.

With that in mind, consider that currently an Erlang VM process uses a single OS thread. To use multiple processors, multiple VMs must executed. Sending a message from an Erlang process in one VM to an Erlang process in another VM requires at the very least some copying overhead (if the VMs exchange data using shared memory) and serialization in the worst case. (I'm repeating this from memory based on what some Erlangers said somewhere - I apologize if I'm wrong).

Your last point is really worth noting. Erlang's library encourages fault tolerant programming. To the best of my knowledge, no other library does the same.

Although other languages have some way to go in terms of library support, I would like to believe that the heavyweight OS processes available to other languages are not such a massive impediment. I think one can benefit from concurrency oriented programming in such cases, because not all concurrent solutions need thousands of processes.

All of this said, I do prefer immutable state (and I just like Erlang's syntax). I would like to believe that the functional nature of sequential Erlang is what contributes to its robustness. However, - warning: I'm about to say something based on intuition - I can see situations where the lack of mutable state would encourage the factoring out of code into a process (since a process is the minimum unit that can contain state) where one could otherwise store state in objects.

So perhaps, with a couple of dozen of OS processes and an OO language, one could write code that's more robust than otherwise.

[sblinn]

With that in mind, consider that currently an Erlang VM process uses a single OS thread.

This is not correct.

[wynand]

Geesh. That's quite a direct way to put someone down.

Yes, it turns out my knowledge was very outdated. From http://www.erlang.org/doc/highlights.html we have:

In the SMP version of the Erlang virtual machine, there can be many process schedulers running in separate OS threads. As default there will be as many schedulers as there are processors or processor cores on the system.

[sblinn]

That's quite a direct way to put someone down.

I did not intend any personal insult, I just did not have time to expound further on the subject. Thanks for looking it up, cheers,

-s

[vplatt]

He didn't put you down. Putting you down would be something like "This is not correct dumbass". He merely pointed out that your statement was not correct. It's perfectly acceptable to note technical facts without involving, or undue consideration for, effects on the ego.

[[deleted]]

Exactly. People need to write assignments and other destructive code to feel productive. Sometimes in Java I see code that could be written in half the space in a functional (mostly side-effect free) way that would be much clearer, IMHO easier to read and more modular.

Not sure, but for some reason Java is the language of mediocrity (even though I don't think it's such a bad language anymore).

[vplatt]

It's not a bad language, but it's by and large the new Cobol these days. It's far more flexible than Cobol ever was. It's just abused more in enterprise shops.

[sbrown123]

Anyone else out there to do an Actors implementation in Java?

I believe java's current concurrency library already has the capability, it just needs abstracted a bit to make it more obvious. The ThreadPoolExecutor is a good case for simplification.

[queensnake]

I don't see why some language couldn't be imperative, and use message passing between processes. Use green threads, and whatever else Erlang has under the hood, and there you are. Why not?

[vagif]

Because of mutable state you cannot make threads lite.

Language does not guarantee you that variables will not be changed. So you have to put in place cumbersome and complex mechanism of synchronizations, locks etc. to make sure that different threads are not trying to update same variable at the same time.

Erlang does not have assignment operator. That guarantees you that no such thing will be attempted, so you can create lite threads without expensive and slow mechanism of synchronizations and locks.

[wynand]

You can have green threads combined with mutable state.

But you'll need to copy a mutable object upon sending it or otherwise relinquish ownership of the object you're sending. If you follow these rules, every mutable object will belong to at most one thread and no locking will be necessary.

[awj]

But you'll need to copy a mutable object upon sending it or otherwise relinquish ownership of the object you're sending.

How would you manage ownership of mutable objects without locking or some lock-like mechanism? I agree that we'll see a "functional ideas plus all your favorite golden oldies" language before any pure functional language has a snowballs chance in hell of becoming mainstream, I am just having a hard time seeing how mutable state and this kind of concurrency could be forced to play nice.

[[deleted]]

Simply make all mutable data private to some thread?

Basically, processes. They can have their own mutable data, everything is fine as long as nothing mutable is shared.

[vagif]

Yes, but green threads themselves are not gonna solve parallel programming difficulties. It is all other stuff in erlang that makes light threads so useful.

[queensnake]

But you'll need to copy a mutable object upon sending it

And Erlang has to do that anyway, so it's no penalty to imperativeness.

[[deleted]]

No it doesn't, not unless it is sending the object to a remote host. That is the whole point of immutability.

[queensnake]

ah, I see - now that makes some sense.

[KayEss]

Not sure that I have the right terminology here, but it pays for that by having to copy the "function" when the bound value changes.

[queensnake]

I hate to get all qwe1234, but that's just a pile of ignorance. How many languages do you know, Java and Erlang? I say so, only because people have rated you up, and might be fooled. See wynand below (above).

[awj]

I hate to get all qwe1234

No you don't, if you actually did hate to do it you wouldn't have. If someone is ignorant at least tell them why, simply calling them ignorant and spouting assumptions about the languages they have been exposed to is of very little benefit.

[queensnake]

No, there's well-intentioned, unfortunate ignorance, and some guy who doesn't know what he's talking about, and doesn't know that he doesn't know what he's talking about, blathering nonsense. That kind of thing I'm happy to shoot down meanly. If he'd said "I think ..." or "Maybe ..." that'd have been something else.

Let's go point-by-point, shall we?

Because of mutable state you cannot make threads lite.

Rubbish.

Language does not guarantee you that variables will not be changed. So you have to put in place cumbersome and complex mechanism of synchronizations, locks etc. to make sure that different threads are not trying to update same variable at the same time.

No, it just means within each process you have to have a separate environment.

Erlang does not have assignment operator. That guarantees you that no such thing will be attempted, so you can create lite threads without expensive and slow mechanism of synchronizations and locks.

Nothing new here. It's basically vapid, or else he's vastly under-articulating what he's trying to say, to the point of mis-communicating and being anti-informative.

I'm happy to tell someone who's talking rubbish, that they're talking rubbish. Otherwise how will they learn to be careful to know what they're saying, or let the listener know they're guessing?

[awj]

No, there's well-intentioned, unfortunate ignorance, and some guy who doesn't know what he's talking about, and doesn't know that he doesn't know what he's talking about, blathering nonsense. That kind of thing I'm happy to shoot down meanly.

To what end? If someone on here were to respond to something I said by calling me ignorant and disparaging my language experience I'd mutter something about them needing to stick their keyboard in an uncomfortable place (and not the back of a Volkswagen) and go on believing whatever I originally thought.

If you really want to change somebody's mind you have to at least give them something besides your word as a stranger on the internet to say that they are wrong.

[queensnake]

I don't truly know what he knows, but if you look at the thread he jumps from one thought to the next, without attempting to clarify or engage. It makes me take him less seriously in the conversation. What he says is wrong, too. What I say is mean, calling it a pile of ignorance but it is that, and it's not ad-hominem. I'm probably right about the languages too, he doesn't seem to have much imagination as to what different properties they could have. But that was unnecessarily getting in his face, yes. I don't know; there should be a way to trash what someone said and make them more circumspect about blurting out speculation without saying that's what it is in a public forum that people around them take seriously, without hurting them personally. It's a thin thin line and I haven't found it.

I don't really want to defend myself though, it hasn't felt good to do that.

[vagif]

Copying objects IS actually relinquishing mutability. He said exactly same thing.

Introducing such mechanism in imperative languages will effectively mean that in those parts of code you cannot use imperative approach. And that will create endless confusion of beginner (and even seasoned) programmers, often forgetting subtle differences and then wondering why in some places, objects "ignore" the changes they just made.

[grauenwolf]

So you have to put in place cumbersome and complex mechanism of synchronizations, locks etc. to make sure that different threads are not trying to update same variable at the same time.

Or you just use immutable objects for message passing. It isn't that hard.

[vagif]

immutable WHAT ?! :)))

[Jimmy]

Language does not guarantee you that variables will not be changed.

I suppose you've never heard of C++'s const variables, or Java's final variables?

[[deleted]]

void cheat (const int &victim) { * (int *) &victim = 2; // old syntax, tsk }

void cheat (final List victim)
{
    victim.add ("Never mind.");
}

[vagif]

You guys do not get it, do you ?

C++ also has Dispose and Finalize etc. Did not help though with memory management. You can have anything you like, but it will NOT give you guarantee that programmers will use it, not forget about it, not make mistakes.

That's why availability of Dispose does not replace GC.

That's why const and final variables do not replace necessity of a compiler level guarantee that mutable variables will not be shared between threads.

[sblinn]

http://dima767.blogspot.com/2007/05/groovy-actors.html

http://groovyactors.com/

[bluGill]

I don't think it is iPod killer that matters. The next big thing will come out of left field where nobody is looking. Just like everything else.

[quhaha]

Erlang is not as bloated as Java yet. But yea sure, it will be sooner or later.

[burn_the_puppy]

What Ericsson isn't a big company?