Erlang, the next Java | Hacker News Reader

Erlang, the next Java

cincomsmalltalk.com

20 pointsb-man15 comments

I had the fortune of doing a lot of work with Erlang over the last 3 years, even helping to ship a product that relied on it for some middleware. Erlang is great for some tasks, and if you don't know it (and you're of a programming discipline) you should learn it, if only to get comfortable with Actor concurrency.

My newest job requires interoperability with a lot of Java code, so I've been working with Akka, using Scala. While I haven't yet been able to examine if it really can scale the same way that Erlang does, so far its been off to a fairly good start so long as you are disciplined.

Is the ending of this paragraph a typo or a joke?

"One way that Erlang differs from OO languages is its emphasis on failure. Any message can fail. Processes don't raise an exception, they fail. Systems are structured as worker processes at the bottom that are likely to fail, with manager processes above them that restart the failed processes. Because programmers expect processes to fail, they"

It's likely that the idea was either misunderstood or not expressed properly. That paragraph is kind of true... just written in a very weird way that doesn't really show this process in a good light.

Yes, Erlang embraces failure and provides ways do deal with it by design. No, it's not a replacement for exceptions. Especially that Erlang does have exceptions to deal with the typical "could fail, so we'll just `try` it" programming.

No, not a typo or a joke, the mentality of an Erlang programmer is to (and this gets beaten to death in books) "Let it crash." It is ok to let processes fail, you build restart strategies for certain processes so that when they do fail, your supervisors know: how often to try to restart, how many times and of course which module.

The point is that the paragrah ends with ",they". Not the idea of fail often fail quickly :)

Based on the fact that two other people here apparently didn't finish reading the paragraph either before commenting: if it was a joke, it was a bad one. :)

Yeah... probably a very bad one. I finished the paragraph, but thought the typo was so obvious that OP was asking about the contents really, not the silly silly typo.

hah if it wasnt an intentional joke then its a very good accident.

It helped me tremendously to understand error handling in erlang when I realised every line of code was a point of failure

Java forces you to handle things like FileNotFound even if you fully expect the file to be there, erlang you would not handle file not found at all, but you would manage all errors at a higher level for the entire unit of code that expected the file to be there.

If your program gets into a funky state, it's much simpler to trash it and start over, than to try to work backwards to a safe state. Sysadmins know this at the os-process and machine level, Erlang brings it to the language level. Erlang was designed for robustness, concurrency was just a happy side-effect of that focus.

Also, this is a 3yo talk. At what point do we say, no, no it's not (and I'm a Java guy who really likes Erlang).

I wonder what is the "next Java" then? JavaScript?

(NB I used Java a lot from 1995 to 2002 and I'm now a big fan of JavaScript - the appeal of being able to do client side, server side and DB coding in one language).

Why does everyone insist that there will be a next Java? Maybe the programming language ecosystem is getting less homogenous.

How long did it take Java to reach its niche?

I like the article's emphasis that it is the lack of shared state that is more important than the fact that the language is functional. Also it is the "mystical view" of objects that contains all the value. Unfortunately its also the baby that some people fail to see when they want to throw out the object bathwater.

I like Erlang, but it is not going to be the next Java in terms of ever ranking at the top of something like LangPop.com.

Reply on news.ycombinator.com