4 ms·

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

by gamache 10y ago

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

aaron-lebo 10y ago
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?