Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's all this fuss about Erlang? (2007)

pragprog.com

Post reply on HN
Print view View original

11–20 of 193 posts

Re: What's all this fuss about Erlang? (2007)

#11

Post by tormeh »

aaron-lebo wrote: post #2

I 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 slowness of Erlang was a conscious decision. You're supposed to offload all the computationally intensive things to native code. That may not be ideal for your use case and a PITA, but it's how the language and runtime was designed. I would guess Erlang would do (if it isn't already doing) well in HPC as the thing that coordinates all the Fortran code.

Re: What's all this fuss about Erlang? (2007)

#12

Post by derefr »

davidw wrote: post #3

This 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.

I've always thought that Erlang would be more successful if it had a better deployment story, along the lines of Go or Rust: e.g. if you had the option of baking an Erlang runtime into a static binary. As it stands, software like ejabberd and rabbitmq are pretty ugly in OS package form (because distro maintainers think such packages need to rely on a common, usually very old, Erlang runtime, instead of allowing them to vendor it in as you're supposed to.)

Now that I think of it, Canonical's push toward "snaps" (sandboxed and vendored—but not fully containerized—software bundles, as a package format) might bring a flourishing of Erlang-based application software, given that it's much more compatible with Erlang's style of release-management.

Re: What's all this fuss about Erlang? (2007)

#13

Post by hota_mazi »

> How do programmers fix these problems? They don’t. They pray.

Ah! No, Joe, that's what you do.

Most of developers have figured out how to do concurrency and parallelism with mutable state and locks. It's not as hard as you make it sound and it's supported in a lot of languages which, as opposed to Erlang, are statically typed, hence much more suitable to the kind of large scale software you describe.

And yes, that was already true in 2007.

Re: What's all this fuss about Erlang? (2007)

#14

Post by stcredzero »

aaron-lebo wrote: post #2

I 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…

I think the "more cores == faster" benefit is overstated.

I've tried to create servers for massively multiplayer games in Clojure and Go. What I've found is that it "takes some doing" to be able to efficiently use many processors in parallel. You can't just slap on a pmap call in Clojure or do the equivalent cheesy channel trick in Golang and have good utilization of all your cores in parallel.

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.

For what value of "mostly scale as well?" For me, that means doing a little extra design/architecting to break out your Golang server process into multiple worker processes.

it's 10 years later and we haven't seen massively parallel architectures take off.

Because there are still barriers that are a bit too large. You either wind up having to do weird things to do what amounts to efficiently passing data between cores, or you end up using a slower language that's a bit far from the computing mainstream.

Re: What's all this fuss about Erlang? (2007)

#15

Post by gamache »

aaron-lebo wrote: post #2

I 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…

> ...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... > I suspect other languages are going to fold the good parts of Erlang/BEAM into them and limit its long-term adoption.

Comparing a bare-metal-but-with-GC language like Go to a miniature operating system like Erlang isn't quite fair -- in comparison, Go is missing an actor model, buffered CSP, crash supervision, hot upgrades, remote console/tracing/debugging, and built-in clustering (to name a few).

Once other languages adopt "enough" of the BEAM featureset, they'll have similar performance.

Re: What's all this fuss about Erlang? (2007)

#16

Post by douche »

hota_mazi wrote: post #13

> How do programmers fix these problems? They don’t. They pray. Ah! No, Joe, that's what you do. Most of developers have figured out how to do concurrency and parallelism with mutable state and locks. It's not as hard as you make it sound and it's supported in a lot of languages which, as opposed to Erlang, are statically typed, hence much more suitable to the kind of large scale software you describe. And yes, that…

You have a more optimistic view of the average level of skill and knowledge of developers than I would. Basic concurrency bugs strike all the time, and a lot of people don't know what they don't know, until they've been burned a few times.

Re: What's all this fuss about Erlang? (2007)

#17

Post by [deleted] »

stcredzero wrote: post #14
aaron-lebo wrote: post #2

I 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…

I think the "more cores == faster" benefit is overstated. I've tried to create servers for massively multiplayer games in Clojure and Go. What I've found is that it "takes some doing" to be able to efficiently use many processors in parallel. You can't just slap on a pmap call in Clojure or do the equivalent cheesy channel trick in Golang and have good utilization of all your cores in parallel. It's even more oversta…

[deleted]

Re: What's all this fuss about Erlang? (2007)

#18

Post by zazibar »

stcredzero wrote: post #14
aaron-lebo wrote: post #2

I 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…

I think the "more cores == faster" benefit is overstated. I've tried to create servers for massively multiplayer games in Clojure and Go. What I've found is that it "takes some doing" to be able to efficiently use many processors in parallel. You can't just slap on a pmap call in Clojure or do the equivalent cheesy channel trick in Golang and have good utilization of all your cores in parallel. It's even more oversta…

Can you elaborate on how you implemented those servers? Would you still use Clojure or Go for them now? If not, what alternative do you suggest?

Re: What's all this fuss about Erlang? (2007)

#19

Post by zaphar »

hota_mazi wrote: post #13

> How do programmers fix these problems? They don’t. They pray. Ah! No, Joe, that's what you do. Most of developers have figured out how to do concurrency and parallelism with mutable state and locks. It's not as hard as you make it sound and it's supported in a lot of languages which, as opposed to Erlang, are statically typed, hence much more suitable to the kind of large scale software you describe. And yes, that…

If I am totally honest. Most of the code where I was pretty sure I had figured out the whole mutable states and locks thing has another developer looking at it right now and cursing me under his breath.

Re: What's all this fuss about Erlang? (2007)

#20

Post by aaron-lebo »

gamache wrote: post #15
aaron-lebo wrote: post #2

I 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…

> ...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... > I suspect other languages are going to fold the good parts of Erlang/BEAM into them and limit its long-term adoption. Comparing a bare-metal-but-with-GC language like Go to a miniature operating system like Erlang isn't quite fair -- in comparison, Go is missing an actor model,…

Hot upgrades and remote debugging are front in center in lisp and it has excellent performance. Even so, there's no general consensus among programmers about whether hot code reloading is preferred to static binaries.

The actor model is a choice of implementation. Crash supervision stands out, but that's not necessary and is part of the Erlang culture - let it crash. It's not as important in other languages with a different underlying belief about errors.

What features mean BEAM must necessarily be slow?

Just to be clear: I really like Erlang. It obviously has different features than a lot of languages and most are aimed towards a certain goal: uptime. But if you can give just a little on that (and you might not have to at all), you can get most of those advantages with a different feature set.

I wonder out of the Erlang experiment which are the objectively better features and which are just really cool?

Post reply on HN