2 ms·
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. Ru
by brightball 4y 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.
- jacquesm 4y agoI'm aware of all of that but none of that answers the question.
- brightball 4y agoIt’s suggesting that there’s probably not much of a point to it.
- jacquesm 4y agoNot 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.