This one has been around for a good chunk of years. Recent bonus activity as it is seeing more exploration by the Elixir community right now as a wasm target.
GRiSP serms to typically hit inbetween Nerves and AtomVM. Grisp have explored some really constrained hardware compared to the typical Nerves device.
AtomVM is to my knowledge a lot of steps further down since they run a much lighter VM than the BEAM. It is also much less proven though.
Nerves, Grisp and AtomVM all do some of the same things. They make some different trade-offs. Heck, Kry10 (proprietary but targets critical infra) even sort of approaches the same thing. Running Erlang/Elixir for resilient embedded systems.
I am on the Nerves team so you can guess my preference. But all are cool. And we all talk to each other. AtomVM is the most obvious complement to Nerves since they target different device classes.
Considering that Erlang originated in the telecom world, I find it a bit odd that mobile development options are lacking. Anything to be expected in that space?
Erlang's use in the telecom sphere has primarily been focused on switching, routing, and real time voice processing on the backend. Beyond just handling cellular traffic, many internet switches are written in Erlang too. It's only recently that Erlang has been used for more of the type of code that could run on the frontend. (The niceness of writing Elixir is a big part of that too.)
The primary blocker to running Erlang on mobile has been the lack of portability of the BEAM VM itself, which is why this project is so exciting!
The massive concurrency and fault isolation properties are very nice for telephony switches (and web servers etc.) but not usually super relevant for phone apps.
Why would a programing language built around accepting and dealing with millions of connections, and used in base stations, routing, and switching be useful for a mobile device?
Buzz Aldrin would have killed the Apollo 11 crew if Margaret Hamilton had been a worse developer. He pulled up an optional display during the landing that was overloading the computer due to a bug, and the scheduler kept killing optional tasks to keep the control and guidance systems all running.
There’s the same sort of realtime system in the BEAM. When you run nice to have and mission critical software together life is much less exciting if you have something handling such things.
because it was designed as a general purpose programming language that has robust affordances for weird shit like connections dropping due to a backhoe severing your copper into a PBX.
luckily, mobile devices never encounter problems like a backhoe cutting it off from the network.
The programming model of message passing between processes lends itself well to certain types of apps even if you don't need to handle millions of connections.
For example Elixir/Erlang are currently used in certain IoT applications.
That's taking it to its extreme (unnecessary as your carrier is a different company), but consider building an application like Telegram or WhatsApp, then it would certainly be nice to use one language for everything, from front-end, back-end to distributed computing stuff.
> then it would certainly be nice to use one language for everything, from front-end, back-end to distributed computing stuff.
People say this, but it's not that helpful, IMHO. Front end and backend have different concerns, usually different teams, and using anything other than the preferred language for a client platform tends towards clunky UX.
You can do some sort of core networking library that's shared between clients, and I guess there's reasons you might want that to be Erlang, but integration feels like a lot of work when you can just deal with it in another language. Client side concurrency is so much less than server side concurrency, it'll be fine.
It's not a reason to use a different language, but if you let each team choose an effective language for their work, they may well choose different languages.
That's simply not true. The best language for a front end is the language that's preferred by the platform. Firefox famously rewrote their UI with Java on Firefox because the XUL version was miserable. You don't build iOS apps with Java. You don't build Android apps with Go.
You can't actually build a mobile app entirely in JavaScript, but if your used React Native the parts that actually deal with materially interfacing between the client and the server aren't in JavaScript. At best you can share some typescript definitions.
Java on the server is extremely different from Java on client, and the same can be said for Swift. What do you get to share? Maybe the code that serializes and deserializes messages? But even then that's thanks to a library, not the language (and if you're using a feature of the stdlib, it's almost certainly just as easy to use in any other reasonable language).
Pyodide and PyScrpt exist and you could certainly build a full stack web app with them. Why doesn't anyone, then? It's because doing so doesn't solve any serious problems or make anything much better.
Why though? Why would you want your UI code in Python, as an example? Python has nothing in its standard library to help make websites. Tools like PyScript might give you the DOM, but suddenly you'll be using shims for all the other stuff you need, like resize handlers or fetch() or Intl.NumberFormat or anything else you care about.
Web apps are JavaScript. Android apps run on a JVM. iOS apps are whatever can compile to native code and use Apple's APIs. When you avoid the runtime of the language that you're expected to build for on a platform, you'll inevitably spent most of your time working just to get a handful of features that you need from the runtime into the language you're choosing to use.
i see ok. well, erlang is more suited to program gateway nodes in the core of 3g/4g networks.
these nodes handle tasks such as handling mobility (managing handovers as cell phones moves from one location to another etc), data transfer f.e providing ip addresses to your phones etc etc.
as you can imagine, this sort of gear lives deep within service providers network, and each entity handles hundreds of thousands of sessions f.e serving an entire state etc etc.
and these nodes cannot go down taking services/sessions with them.
gui is single(immediate mode) or two(graph based) threaded. with some async going to backend or some app defined compute bounded.
there is no need for actors nor green threads. no need for erlang nor go. languages were not designed for gui(unlike js or csharp), will need a lot of boilerplate for trivial patterns.
What's a usecase for this that actually makes sense? Why does Erlang need to run on IoT devices? The main usecases of Erlang I know of are suitable for beefy machines.
Why not? Erlang encourages the same kind of really flexible actor-driven architecture that Smalltalk did. It's a nice programming paradigm that's more general than you think, and the hornclause syntax is really, really nice. Very pleasant to use like this.
The actor and supervisor system is really, really nice when you want reliability even with only one core (at least in theory, nothing against Atom but I would probably want a more battle-tested VM for shipping a production device).
There's a why page in their docs, but basically it's cheaper than a multitasking OS for doing the same thing. The valueprop of Erlang is lightweight threads and message-passing.
My knowledge of microcontrollers is dated, but the frameworks for Arduino etc. seemed limited on their ability to do event or message-based programming; most example apps at least were a polling loop. The classic architecture of setting up interrupt/event handlers and going to sleep was not there.
before they went under IIRC bowery farms was using BEAM for a fleet of vertical farm in their automated farming robotics, i imagine the no-nonsense networking and clustering was an advantage (i don't know for sure)
imagine youre automating your home, with an rpi here and a gpu node here etc. wouldn't it be nice to immediately have dev access to any node in your home just by connecting to any node?
A lot of optimization has happened to that VM, yeah. However, it has likely gotten a lot more complex. One source of complexity that comes to mind is SMP support.
(Do I have any idea how the VM would run on a 200 MHz machine? Hell no. I'm just mentioning that the thing has also gotten more complex as time has gone by.)
Multi-core support and clustering was early requirements, hence the OS-like structures organised around the process implementation where the VM starts a scheduler as part of it booting.
Could you be more explicit about what you think has become more complex?
Erlang's first release was in 1986. Experimental SMP support was added to the Erlang VM in OTP R11B in mid 2006[0]. That's twenty years.
If you were to go back to the time of R11B's release and asked the folks who were aware of it "Has SMP support been added early in the life of the Erlang project?", I expect you would be hard-pressed to find anyone who would answer that question with a "yes". Twenty years after a software project's first release is a pretty damn long time.
If we want to be maximally charitable to you, then we can knock that date back to when the master's thesis work was started (and abandoned) in 1998. That's still more than a decade after the initial release.
It is my understanding that SMP support was a substantial change to the VM, and has gotten more complex as it has been made to perform better and better on larger systems and workloads.
> ...clustering was early requirements...
You are apparently unaware that the way operators who used Erlang handled multi-processor machines was to run multiple independent instances of the Erlang VM and -if desired- use local-machine clustering for intra-instance communications. SMP support is not the same as UP support with local-machine clustering of otherwise-independent program instances.
> Could you be more explicit about what you think has become more complex?
A great many things. The ones that immediately come to mind are SMP, HiPE [1], BeamAsm, dirty schedulers, multi time warp, and Unicode support. You may argue that surely some of the additional complications that have been added since 1986 are not much complication. I would counter that surely some of the optimizations that have been made since 1986 have not been much optimization.
[1] Unless I'm confused about HiPE... and the native code it produces was already a thing that the Erlang VM could consume. If that's the case, than the obvious complexity of HiPE is all outside Erlang. But the caveats on section 4.1 and 4.2 and acknowledgements in section 6 of [2] make me fairly confident that HiPE was not using already-existing functionality in the Erlang VM.
This is really incredible, the esp32 examples are really straightforward compared to the C versions of the same. The Erlang actor model makes this much easier!
... if they can nail the OTA updates and hot-loading of code!
We have most of the groundwork done for OTA updates. We should have some APIs together in the near future. Hot-loading will be more work, but that should be possible after OTA is ready.
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 ???
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.
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.
AtomVM is super fun to prototype MCU projects with. It’s what I tend to reach for over micropython etc.
For beefier machines that have SoCs it’s Nerves usually.
And recently a project called Popcorn uses the AtomVM to run BEAM VM code in the browser! Super neat seeing more places to deploy Elixir and Erlang :)
Really incredible to see the proliferation of micro-VM tools lately. Here's one from just yesterday: https://news.ycombinator.com/item?id=44135977
This one has been around for a good chunk of years. Recent bonus activity as it is seeing more exploration by the Elixir community right now as a wasm target.
Does this target smaller devices than nerves? Or just an alternative?
Smaller devices.
There's also https://www.grisp.org which looks quite similar if a bit more mature
GRiSP serms to typically hit inbetween Nerves and AtomVM. Grisp have explored some really constrained hardware compared to the typical Nerves device.
AtomVM is to my knowledge a lot of steps further down since they run a much lighter VM than the BEAM. It is also much less proven though.
Nerves, Grisp and AtomVM all do some of the same things. They make some different trade-offs. Heck, Kry10 (proprietary but targets critical infra) even sort of approaches the same thing. Running Erlang/Elixir for resilient embedded systems.
I am on the Nerves team so you can guess my preference. But all are cool. And we all talk to each other. AtomVM is the most obvious complement to Nerves since they target different device classes.
This is the VM behind Popcorn https://github.com/software-mansion/popcorn, a project aiming to run OTP and Elixir in WASM:
> Popcorn is a library that allows you to run client-side Elixir in browsers, with Javascript interoperability
Recent ElixirConf keynote introducing it: https://youtu.be/ep--rQO1FRI
Considering that Erlang originated in the telecom world, I find it a bit odd that mobile development options are lacking. Anything to be expected in that space?
Erlang's use in the telecom sphere has primarily been focused on switching, routing, and real time voice processing on the backend. Beyond just handling cellular traffic, many internet switches are written in Erlang too. It's only recently that Erlang has been used for more of the type of code that could run on the frontend. (The niceness of writing Elixir is a big part of that too.)
The primary blocker to running Erlang on mobile has been the lack of portability of the BEAM VM itself, which is why this project is so exciting!
The massive concurrency and fault isolation properties are very nice for telephony switches (and web servers etc.) but not usually super relevant for phone apps.
Why would a programing language built around accepting and dealing with millions of connections, and used in base stations, routing, and switching be useful for a mobile device?
Buzz Aldrin would have killed the Apollo 11 crew if Margaret Hamilton had been a worse developer. He pulled up an optional display during the landing that was overloading the computer due to a bug, and the scheduler kept killing optional tasks to keep the control and guidance systems all running.
There’s the same sort of realtime system in the BEAM. When you run nice to have and mission critical software together life is much less exciting if you have something handling such things.
because it was designed as a general purpose programming language that has robust affordances for weird shit like connections dropping due to a backhoe severing your copper into a PBX.
luckily, mobile devices never encounter problems like a backhoe cutting it off from the network.
The programming model of message passing between processes lends itself well to certain types of apps even if you don't need to handle millions of connections.
For example Elixir/Erlang are currently used in certain IoT applications.
At the end of the day many IOT devices are just providing or receiving messages.
Lights, fridges, washing machines.
Uniformity of language between back and front-end, and communication layers?
Because the apps on my phone need to be written in the same language as the network devices my carrier runs? What?
That's taking it to its extreme (unnecessary as your carrier is a different company), but consider building an application like Telegram or WhatsApp, then it would certainly be nice to use one language for everything, from front-end, back-end to distributed computing stuff.
> then it would certainly be nice to use one language for everything, from front-end, back-end to distributed computing stuff.
People say this, but it's not that helpful, IMHO. Front end and backend have different concerns, usually different teams, and using anything other than the preferred language for a client platform tends towards clunky UX.
You can do some sort of core networking library that's shared between clients, and I guess there's reasons you might want that to be Erlang, but integration feels like a lot of work when you can just deal with it in another language. Client side concurrency is so much less than server side concurrency, it'll be fine.
> usually different teams
Is this a reason to use a different language? Or sometimes an effect if doing so?
It's not a reason to use a different language, but if you let each team choose an effective language for their work, they may well choose different languages.
That's simply not true. The best language for a front end is the language that's preferred by the platform. Firefox famously rewrote their UI with Java on Firefox because the XUL version was miserable. You don't build iOS apps with Java. You don't build Android apps with Go.
You can't actually build a mobile app entirely in JavaScript, but if your used React Native the parts that actually deal with materially interfacing between the client and the server aren't in JavaScript. At best you can share some typescript definitions.
Java on the server is extremely different from Java on client, and the same can be said for Swift. What do you get to share? Maybe the code that serializes and deserializes messages? But even then that's thanks to a library, not the language (and if you're using a feature of the stdlib, it's almost certainly just as easy to use in any other reasonable language).
Pyodide and PyScrpt exist and you could certainly build a full stack web app with them. Why doesn't anyone, then? It's because doing so doesn't solve any serious problems or make anything much better.
Why? For a small one person team? Sure it would be nice to write everything in one language in one repo.
For a large company with lots of developers? Makes less sense. Better use the best tools for the tasks.
Why though? Why would you want your UI code in Python, as an example? Python has nothing in its standard library to help make websites. Tools like PyScript might give you the DOM, but suddenly you'll be using shims for all the other stuff you need, like resize handlers or fetch() or Intl.NumberFormat or anything else you care about.
Web apps are JavaScript. Android apps run on a JVM. iOS apps are whatever can compile to native code and use Apple's APIs. When you avoid the runtime of the language that you're expected to build for on a platform, you'll inevitably spent most of your time working just to get a handful of features that you need from the runtime into the language you're choosing to use.
The compiler and the binaries it produces run fine on Android and Linux phones.
> … bit odd that mobile development options are lacking
what do you mean by that? can you please elaborate ? thanks !
I mean tools to run Erlang apps on iOS and Android, for example.
It has been done.
https://github.com/elixir-desktop/desktop
And a different variant driven by the server typically:
https://github.com/liveview-native/live_view_native
Not to say it is particularly ideal. But it exists.
i see ok. well, erlang is more suited to program gateway nodes in the core of 3g/4g networks.
these nodes handle tasks such as handling mobility (managing handovers as cell phones moves from one location to another etc), data transfer f.e providing ip addresses to your phones etc etc.
as you can imagine, this sort of gear lives deep within service providers network, and each entity handles hundreds of thousands of sessions f.e serving an entire state etc etc.
and these nodes cannot go down taking services/sessions with them.
gui is single(immediate mode) or two(graph based) threaded. with some async going to backend or some app defined compute bounded.
there is no need for actors nor green threads. no need for erlang nor go. languages were not designed for gui(unlike js or csharp), will need a lot of boilerplate for trivial patterns.
On the contrary, GUIs are basically event driven systems that benefit a lot from concurrency
X11 is a distributed systems protocol that outputs GUI as a side effect :P
Erlang (and Elixir and so on) run fine under Termux. Just slap on Phoenix or something and have your GUI in the phone browser if that's your thing.
People that have succumbed to Apple tell me they have facilities at least as good as Termux so you can probably do something similar there.
What's a usecase for this that actually makes sense? Why does Erlang need to run on IoT devices? The main usecases of Erlang I know of are suitable for beefy machines.
Source: former Erlang engineer
Why not? Erlang encourages the same kind of really flexible actor-driven architecture that Smalltalk did. It's a nice programming paradigm that's more general than you think, and the hornclause syntax is really, really nice. Very pleasant to use like this.
Smalltalk had nothing to do with actors. It was largely a single core system.
I don’t know about small talk but a single core system is orthogonal to a highly concurrent system which actors represent.
Doesn’t change the fact that Smalltalk wasn’t actor-based nor highly concurrent, which is what we are talking about here.
https://news.ycombinator.com/item?id=18333234
The actor and supervisor system is really, really nice when you want reliability even with only one core (at least in theory, nothing against Atom but I would probably want a more battle-tested VM for shipping a production device).
There's a why page in their docs, but basically it's cheaper than a multitasking OS for doing the same thing. The valueprop of Erlang is lightweight threads and message-passing.
My knowledge of microcontrollers is dated, but the frameworks for Arduino etc. seemed limited on their ability to do event or message-based programming; most example apps at least were a polling loop. The classic architecture of setting up interrupt/event handlers and going to sleep was not there.
before they went under IIRC bowery farms was using BEAM for a fleet of vertical farm in their automated farming robotics, i imagine the no-nonsense networking and clustering was an advantage (i don't know for sure)
imagine youre automating your home, with an rpi here and a gpu node here etc. wouldn't it be nice to immediately have dev access to any node in your home just by connecting to any node?
The renowned AXD301 ran on 68k and UltraSPARC II processors. An ESP32 isn't that far off with its 240-ish MHz.
Initially Erlang was developed on VAX, at what, 3 MHz or so? Since then decades of optimisations have gone into the BEAM.
A lot of optimization has happened to that VM, yeah. However, it has likely gotten a lot more complex. One source of complexity that comes to mind is SMP support.
(Do I have any idea how the VM would run on a 200 MHz machine? Hell no. I'm just mentioning that the thing has also gotten more complex as time has gone by.)
Multi-core support and clustering was early requirements, hence the OS-like structures organised around the process implementation where the VM starts a scheduler as part of it booting.
Could you be more explicit about what you think has become more complex?
> Multi-core support... was early requirements...
Erlang's first release was in 1986. Experimental SMP support was added to the Erlang VM in OTP R11B in mid 2006[0]. That's twenty years.
If you were to go back to the time of R11B's release and asked the folks who were aware of it "Has SMP support been added early in the life of the Erlang project?", I expect you would be hard-pressed to find anyone who would answer that question with a "yes". Twenty years after a software project's first release is a pretty damn long time.
If we want to be maximally charitable to you, then we can knock that date back to when the master's thesis work was started (and abandoned) in 1998. That's still more than a decade after the initial release.
It is my understanding that SMP support was a substantial change to the VM, and has gotten more complex as it has been made to perform better and better on larger systems and workloads.
> ...clustering was early requirements...
You are apparently unaware that the way operators who used Erlang handled multi-processor machines was to run multiple independent instances of the Erlang VM and -if desired- use local-machine clustering for intra-instance communications. SMP support is not the same as UP support with local-machine clustering of otherwise-independent program instances.
> Could you be more explicit about what you think has become more complex?
A great many things. The ones that immediately come to mind are SMP, HiPE [1], BeamAsm, dirty schedulers, multi time warp, and Unicode support. You may argue that surely some of the additional complications that have been added since 1986 are not much complication. I would counter that surely some of the optimizations that have been made since 1986 have not been much optimization.
[0] <https://erlang.org/euc/08/euc_smp.pdf>
[1] Unless I'm confused about HiPE... and the native code it produces was already a thing that the Erlang VM could consume. If that's the case, than the obvious complexity of HiPE is all outside Erlang. But the caveats on section 4.1 and 4.2 and acknowledgements in section 6 of [2] make me fairly confident that HiPE was not using already-existing functionality in the Erlang VM.
[2] <https://user.it.uu.se/~kostis/Papers/erlang03.pdf>
It was originally built for phone switching hardware.
This is really incredible, the esp32 examples are really straightforward compared to the C versions of the same. The Erlang actor model makes this much easier!
... if they can nail the OTA updates and hot-loading of code!
We have most of the groundwork done for OTA updates. We should have some APIs together in the near future. Hot-loading will be more work, but that should be possible after OTA is ready.
Any chance of a port to the Raspberry Pi Pico 2? It has 520K of ram iirc. The original Pico had half that.
Why did people reinvent the wheel with JVM while there's already Erlang VM ? Java did poisionate so much generations of people.
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.
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.
[dead]