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.