[kasey_junk]

For certain classes of problems the JVM just cannot be beat. Its a phenomenal bit of tech that laps the competition, especially with regard to large data sets, concurrency support, and instrumentation. Unfortunately, Java the language is fairly painful to work in (less so every release but still). Kotlin makes that particular problem less of an issue.

Even in plain Java though, your description of "the vast, lumbering Java engine cranking slowly and chugging and masses of XML configuration up the wazoo for everything" is largely only applicable in Enterprise software. Modern Java shops tend to eschew all those things and have for quite some time.

[xiaoma]

Could you dig in a bit more into how the JVM laps the Erlang VM in terms of concurrency support and instrumentation?

[kasey_junk]

Erlang is probably the closest competitor to the JVM and is a fine VM in its own right (especially for classes of concurrency problems that can operate independently).

But if you are dealing with a big interconnected data set that also needs to be concurrently accessed the Erlang memory model doesn't work as well as the JVM one.

For the kind of concurrency model that Erlang is offering it is great, but the JVM offers more variety, so that you can craft your concurrency to your problem instead of being shoe horned into 1 model.

I'd add that the commercial offerings for the JVM (and alternative JVMs like Zing) make the ecosystem more rich than the Erlang one as well.

Finally, I'd say that Erlang suffers from a similar problem to Java, that is, the VM is without peer for certain classes of problem but the ergonomics of the language make people choose other solutions. I think that is a shame as I'd like to see more solutions built on top of BEAM.

I should note, I've not programmed on BEAM for production purposes, only for small projects, but the reason for that is largely those that I mention above.