That's not a crazy instinct, and maybe if OSs were better you would even be right, but there's not really another way to get a skrillion communicating processes that can all crash/fail independently. Without a dedicated VM, all the other approaches are either less safe or too inefficient.
I consider BEAM an indication of a direction that OSs could and maybe should move. It's even possible to run BEAM on bare metal, (almost?) entirely in place of the normal OS.
> It's even possible to run BEAM on bare metal, (almost?) entirely in place of the normal OS.
How? With a unikernel?
Using GRiSP Metal, not exactly without an OS, but using a real time OS designed for embedded devices.
https://www.grisp.org/software
It's been a while, but I believe so. I think I'm remembering the "Erlang on Xen" project, which seems to be defunct now.
i would think so, no other option afaik.
I've built a hobby OS around BEAM... BEAM doesn't require a whole lot from the OS, I built a minimal kernel that runs a single process, which you could consider a unikernel or at least very close. I had originally wanted BEAM in ring 0, but I had a lot of trouble getting started. This way, I can just use a pre-compiled BEAM for FreeBSD and don't have to fight with weird compilation options. Anyway, with x86-32 at least, I can give my Ring 3 process access to all the ioports and let it request a mmap of any address, so the only drivers I need in the kernel are IRQ controllers, timers, and pre-beam console. Once beam is up, console i/o and networking is managed from erlang code (with a couple nifs)