Hacker News new | ask | show | jobs
by brightball 1495 days ago
BEAM is never going to win for straight line speed. This is going to be an improvement for a language optimized for resilience, concurrency and consistency.

Running millions of concurrent processes, with their own heap, with consistent response times that individually tolerate failure without negatively affecting the entire system is just a different animal with a different set of trade offs.

You’re trading some speed for those benefits.

1 comments

I'm aware of all of that but none of that answers the question.
It’s suggesting that there’s probably not much of a point to it.
Not for you. But I know quite a bit about the guts of the BEAM VM and I think this is a very interesting development and if the jump is large enough it may well obviate the need for a whole slew of situations where you now have to fall back to externally loaded functions in different languages, and that would make a bunch of stuff far more elegant. Yes, those externally loaded functions will (always) have a speed advantage, but if the advantage drops below the level of the cost of adding an external module then that would be pretty good news.