The performance work in Erlang at the moment is really exciting. It's easy to get sniffy about it and say the JVM/CLR/whatever has has JITing for years. True. But then performance has never been the Erlang standout: that would be concurrency and robustness.

The JIT is bringing BEAM languages up the rankings on performance. It may have a way to go to get to JVM level, and might not ever get there. But it's on a really encouraging trajectory.

And none of that compromises the concurrency and robustness story, where it still stands at the forefront of production-quality capability with a single, well-designed approach that's well-implemented and impressively scalable.

The care that has gone into Erlang's evolution (including the BEAM VM) is nicely illustrated by this para in the blog:

> The embedded type information is versioned so that we can continue to improve the type-based optimizations in every OTP release. The loader will ignore versions it does not recognize so that the module can still be loaded without the type-based optimizations.

I'm not claiming that's unique among VMs (don't know, probably not) but it does nicely illustrate diligence on the part of the core team.

With Elixir adding some sparkle as an alternative BEAM language, it's a great time to be part of the Erlang community. Chapeau to the core team and community.

I don't want this to come across as snarky or unappreciative but note that JIT work on Erlang has been under active develop since at least 2014 (8 years) [0] if not earlier.

The current JIT provides about 25% improvement while other languages like PHP have sen a near 200% improvement during that same timeframe.

I also realize that Erlang is extremely difficult to increase performance of due to the very nature of it vs other languages.

[0] https://llvm.org/devmtg/2014-04/PDFs/Talks/drejhammar.pdf

Adding to that, wouldn’t adding Erlang’s unique features to the JVM be easier than the other way around? Especially with GraalVM’s unique approach that manages to elevate Ruby’s performance far higher than any other runtime?

Erjang exists, but it seems pretty dormant. JVM and BEAM have pretty different philosophies, so while you could probably add messaging and distribution to JVM, I don't think it would be the same. I think it would be hard to get one thread-like thing per connection and millions of connections per OS process to work on the JVM, unless you can get OS threads to scale that high (which seems unlikely?).

> but it seems pretty dormant.

It’s been getting an RC for the newest version like monthly?