Hacker News Reader

Comment by revskill | Hacker News Reader

Why did people reinvent the wheel with JVM while there's already Erlang VM ? Java did poisionate so much generations of people.

View on HN

Performance is certainly one reason. BEAM is middle-of-the-road at best.

You also have to buy in to BEAM's data model pretty hard, which would be a big ask even today, let alone twenty years ago.

Also they were roughly contemporaneous anyhow. Asking "why not Lisp?" makes some chronological sense, "why not BEAM?" doesn't.

I love Erlang but the performance of BEAM has become a bit of a bottleneck for me lately. I thought I could get away with some fairly advanced audio reencoding stuff in pure Erlang, and at least my naive implementation (which admittedly is not nearly as optimized as it could be) is going like 50-100x slower than a roughly equivalent C version.

No doubt that if I went through the code and rewrote large chunks of it, I could almost certainly eliminate a few copies and avoid a few unnecessary computations, but I figured at that point I might as well write it in Rust and use a NIF or port where even a naive implementation is likely to be fast enough. At some point I might see if I can create good NIFs around existing GMP and DCT libraries so that they can be easily used by other people more generally, but not today.

I am pretty sure that if I had written similar code in Java (or even Clojure), it would have been fast enough out of the box, probably around 2-5x slower than the C version, which would have been in my tolerance.

You might try and see what happens if you get everything into a single compilation unit and enable aggressive inlining.

Depending on what you're doing / where it gets slow, it's possible you could get a significant speedup if the stars align. If your whole processing chain gets inlined into a single function, there's likely to be code that can be eliminated: maybe things calculated and returned but not used or redundant type tests or ???

But, you'll probably be better served with a NIF.

Yeah, I considered a lot of that, and I haven't completely ruled it out, but I'm kind of setting a few artificial deadlines for this just to make sure I actually make a little progress. I am nearly 100% sure that if I hacked at this long enough (e.g. increased inlining, get rid of an extra loops, maybe abuse concurrency a bit more), it could go considerably faster, and maybe it would be fast enough to do what I need.

Or I just do it in Rust, where even a shitty version I hack up in a day or two will almost certainly be more than fast enough.

This isn't to shit on Erlang at all. Erlang is great, and for the most part it is generally pretty fast for most stuff I want to do (generally more network-heavy stuff), and I'm not really going to complain about it not being able to do something it wasn't designed to do.

Though upon typing this, I am wondering if I could get NIFs working with GraalVM so I could do it in Clojure....

Unless you are encoding very, very small snippets of audio, you are almost certainly better off writing your encoding in a best-of-breed language and shelling out to that program. NIFs aren't for "things that Erlang is slow at", it's for "things that Erlang is slow at that you need in the same process". You don't need your audio encoding to be in the same process, and you really don't want to try to write audio encoding to the restrictions of NIFs.

I ended up having some trouble getting the NIF stuff working so I ended up using ports with Rust. The amount of overhead for something like that is basically nothing, and you are right, I do not need this to be in-process.

Erlang was proprietary and under the radar until 1998. The Erlang VM has a different focus than JVM.

JVM predates BEAM.

Bytecode based runtimes and compiler toolchains predate both, and Erlang came to life in 1986, a couple of years until Oak.

Java is ten years younger than Erlang. When Java was marketed into the new hot thing in 1996-1997 Erlang was widely used within Ericsson, and in 1997-1998 someone in Ericsson had swallowed the Sun bait and forced the start of a transition to Java. Joe Armstrong and others went to management and convinced them that since Erlang was now useless it should be released as free software, and it surprisingly was.

Which meant that some of them promptly resigned from their jobs and started a company doing freedom Erlang. It took until 2005 or so for Ericsson to confess that they had made a mistake in trying to Java all the things and got around to using Erlang again.

> it took until 2005 or so for Ericsson to confess that they had made a mistake

Impressive that someone was able to make that call and accept the situation, after investing half a decade moving to Java. Also says something about the staying power of Erlang and its paradigm, that the company was able to re-adopt it again.

Well, the IT bubble had burst and Sun was basically two thirds down the sewer at the time. Re-adopting something you had built and proven in the early days of cell phones probably looked like very reasonable risk management.

They kept using Java for some things, of course.

Reply on news.ycombinator.com