What's all this fuss about Erlang? (2007)
pragprog.com
What's all this fuss about Erlang? (2007)
1–10 of 193 posts
Re: What's all this fuss about Erlang? (2007)
#2I think the "more cores == faster" benefit is overstated.
Without jit Erlang is so slow that languages without concurrency support will kill it. It's even more overstated when something like Go can mostly scale as well over multiple cores but be x times faster while doing so. Not to mention it's 10 years later and we haven't seen massively parallel architectures take off.
I suspect other languages are going to fold the good parts of Erlang/BEAM into them and limit its long-term adoption.
Re: What's all this fuss about Erlang? (2007)
#3This was back in a brief period when Erlang was being hyped by people as a potential Next Big Thing. Unfortunately it never really got that much momentum though, until Elixir and Phoenix came along.
Re: What's all this fuss about Erlang? (2007)
#4Dave Thomas has described Elixir as follows: "Elixir took the Erlang virtual machine, BEAM, and put a sensible face on it. It gives you all the power of Erlang plus a powerful macro system."[1]
Re: What's all this fuss about Erlang? (2007)
#5I think the "more cores == faster" benefit is overstated. Without jit Erlang is so slow that languages without concurrency support will kill it. It's even more overstated when something like Go can mostly scale as well over multiple cores but be x times faster while doing so. Not to mention it's 10 years later and we haven't seen massively parallel architectures take off. I suspect other languages are going to fold t…
The ways that massively parallel architectures have taken off are in GPU programming and they interact with them using the languages that they would have already done. C/C++ libraries that either use them directly or provide an interface to Python / Lua / Java etc...
Re: What's all this fuss about Erlang? (2007)
#6I think the "more cores == faster" benefit is overstated. Without jit Erlang is so slow that languages without concurrency support will kill it. It's even more overstated when something like Go can mostly scale as well over multiple cores but be x times faster while doing so. Not to mention it's 10 years later and we haven't seen massively parallel architectures take off. I suspect other languages are going to fold t…
> fold the good parts of Erlang/BEAM into them
A lot easier said than done, because there are a lot of really fundamental decisions about Erlang that make it what it is. You can't just slap on a scheduler for instance, or Erlang style processes.
Go is probably the closest thing, and it's still lacking some things like the supervision tree.
Erlang is certainly not 'the answer' in terms of computationally intensive anything, for the foreseeable future.
Re: What's all this fuss about Erlang? (2007)
#7I think the "more cores == faster" benefit is overstated. Without jit Erlang is so slow that languages without concurrency support will kill it. It's even more overstated when something like Go can mostly scale as well over multiple cores but be x times faster while doing so. Not to mention it's 10 years later and we haven't seen massively parallel architectures take off. I suspect other languages are going to fold t…
Agreed. I don't think there is a big fuss about Erlang anymore. Still it's an interesting language from an acidemic perspective if not from a practical one.
Re: What's all this fuss about Erlang? (2007)
#8I think the "more cores == faster" benefit is overstated. Without jit Erlang is so slow that languages without concurrency support will kill it. It's even more overstated when something like Go can mostly scale as well over multiple cores but be x times faster while doing so. Not to mention it's 10 years later and we haven't seen massively parallel architectures take off. I suspect other languages are going to fold t…
Unfortunately, I think you're correct.
Anecdote: I used Erlang, over the course of several years, for very-high-level bot behavior and multi-player mission control, where performance was much less important than the things Erlang provides, but I still had issues with it. Nonetheless, I felt it had given me great leverage, and I thanked Joe Armstrong profusely, when I met him at a conference. Later at the con, I asked a panel whether there were active efforts at improving performance, perhaps with a JIT. They seemed to take it as an attack, and suggested that if I need performance, I should use another language. I mostly write in Clojure now.
Re: What's all this fuss about Erlang? (2007)
#9> Your Erlang program should just run N times faster on an N core processor
But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever.
If your program has sequential or less parallel phases or needs to communicate then you are subject to Amdahl's law like you always were.
Armstrong has that claim in the Erlang book and I was gobsmacked to see it written down with no caveat or mention of the limits from Amdahl's law whatsoever. I was sure it was a joke and it would be followed by 'ha ha ha of course not - nobody knows how to achieve that despite decades of intensive research', but no it's a serious claim made with a straight face. Erlang's solved it!
Erlang helps you write parallel programs... but only if you program is entirely parallel in the first place.
Re: What's all this fuss about Erlang? (2007)
#10I think the "more cores == faster" benefit is overstated. Without jit Erlang is so slow that languages without concurrency support will kill it. It's even more overstated when something like Go can mostly scale as well over multiple cores but be x times faster while doing so. Not to mention it's 10 years later and we haven't seen massively parallel architectures take off. I suspect other languages are going to fold t…
> fold the good parts of Erlang/BEAM into them A lot easier said than done, because there are a lot of really fundamental decisions about Erlang that make it what it is. You can't just slap on a scheduler for instance, or Erlang style processes. Go is probably the closest thing, and it's still lacking some things like the supervision tree. Erlang is certainly not 'the answer' in terms of computationally intensive any…
so many people (including me from time to time) misunderstand "computaionally expensive" that I think Elixir/erlang/beam will serve a lot of systems/apps well for a long time until they really see a need for "intense" computation