[nickpsecurity]

What you're saying is a VM with tons of R&D, tons of corporate investment, and a focus on speed was faster than a new one that was Ericsson's side project focused on stuff other than speed? Little surprise. Meanwhile, BEAM and its language have been doing exactly what they're designed for with enough success that it's mainstreamed naturally. Which Java didn't.

Truth be told, most of the crowd using BEAM doesn't care if it's a bit slower than Java. They just want easy scaling, distribution, and fault-tolerance. A different code-base than Java's is a plus in terms of increasing implementation diversity and avoiding the bullseye currently on Java.

[pron]

> avoiding the bullseye currently on Java.

That bullseye exists only in the minds of some HNers. Here is a very (very!) partial list of companies running primarily or largely on the JVM: Google, Twitter, Netflix, LinkedIn, Box, IBM, SAP, Amazon, eBay.

> They just want easy scaling, distribution, and fault-tolerance.

... So they write chunks of their code in C. That would be completely unnecessary if they'd just run Erlang on the JVM.

[nickpsecurity]

Oh no, it exists in the form of CVE's and actual compromises. Java compromises were coming into my news feed at a higher rate than Windows despite all its native code. Got bad enough that Krebs on Security simply recommended taking Java off one's machine unless they absolutely need it. Nice that you named many top tech firms with smart, well-funded NOC's and security teams as the counter-example. Harder for individuals and smaller firms than simply installing what works and hardly anyone is attacking. ;)

On second point, Erlang on the JVM currently gives same scaling, real-time properties, easy distributed apps, and availability as BEAM? And without one of the commercial VM's you seem to be assuming (but not stating) for eg real-time? If so, you might have a strong argument on that end. You just need to demonstrate each with examples of real-world apps running in Erlang on each. More people would accept your claim if you demonstrated it.

[pron]

> Java compromises

99% of those are Java browser plugin compromises and have nothing to do with server-side Java.

> Erlang on the JVM currently gives same scaling, real-time properties, easy distributed apps, and availability as BEAM?

As currently there is no "Erlang on the JVM" (other than a little-maintained experiment), the answer is no. If you're asking whether an Erlang implementation on current JVM would do that, the answer is no, either; it's not the same, but much better (otherwise I wouldn't have suggested it).

> And without one of the commercial VM's you seem to be assuming (but not stating) for eg real-time?

Yes, of course. Azul would be much, much, much better. Stock HotSpot would just be much better.

> More people would accept your claim if you demonstrated it.

Obviously, demonstrating it would require some effort, and as the Erlang ecosystem is so small, there is little reason for the JVM ecosystem to prove it (growing the ecosystem by another 0.1% doesn't justify the effort, no matter how small). In the meantime, you can look at the Erjang, bearing in mind that it doesn't use the new JIT, new GCs (although you can try), and new scheduler.

OTOH, if Erlang wanted to expand its reach by orders of magnitude, someone in that community should give it a try. Obviously, the fact that the world's largest, most technically-savvy companies rely on the JVM means that it's a good choice. If the Erlang community doesn't want to try -- hey, it's their loss... If they want to convince themselves they're making the right choice, that's fine by me, too. But if they want to do that by believing (and perpetuating) false notions regarding HotSpot, I'm just correcting their errors.

[nickpsecurity]

Exactly. Erlang + BEAM vs Erlang + Java is all speculation at this point. I already told you I think HotSpot would perform better than current BEAM minus determinism. Latest updates might or might not help on that. Meanwhile, they can use what they have with diversity benefit or ride along with Oracle's I.P. with associated benefits and risks. Either is a valid choice with me favoring diversity and trying new designs.

[the_why_of_y]

How many end users have an Erlang runtime installed that is invoked with untrusted code by way of a browser plugin? If there are no potential targets, don't be surprised about a lack of published Erlang VM exploits.

I'd guess that the number of JVM CVEs is in the same ball park as the other sandboxing platforms, Web browsers (JavaScript) and Flash.

In 2015 it's good advice to uninstall JVM (and Flash!) browser plugins, since they provide negligible value with current browsers. But generalizing that to the server side, where all code that runs is trusted, is dubious.

[nickpsecurity]

It's a benefit I call security by economics. The bad guys focus limited energy to produce attacks with maximum ROI. Makes them aim at most popular stuff. Simply choosing less mainstream, yet high quality, tech avoids many attacks as a side effect. Erlang is currently benefiting from this. So, I list it as a side benefit over Java.

It's not a high assurance system designed from ground up for security. It's a commercial system designed for availability. It will have plenty of flaws for malware writers to find. Meanwhile, they ignore it and smash Java instead. Gotta be a weight off Erlang crowd's mind.

Truth be told, I'd be getting my codebase in secure shape during such a time. Would look higher quality when attacks appear.