I think you're missing the point. All these languages are functional programming languages, have structural pattern matching and share the same types. The types of languages you can develop on the beam are very restrictive. For example, you'll never get Ruby or Java to work on the BEAM VM.
let's look at garbage collection.
How does tradition stop the world, Mark-and-sweep garbage collection work on the BEAM? it doesn't really.
Each process on the beam has its own garbage collection algo, because processes can't share memory, garbage collection on one process can happen without disrupting any other process.
> For example, you'll never get Ruby or Java to work on the BEAM VM
Uhm, several ways:
1. Bind the VM in as a C FFI artefact
2. Write your ruby or Java bytecode emulator to run on one Erlang process only. Since Java supports threads, each thread could live on a different process, any shared memory would live on an Ets table.
"never" is a strong word. The reason why people don't do it is that it's not worth it.
I believe riak embeds javascript in the erlang VM. You can imagine why that might be worth it.
and then you have a a kernel panic and bring down the entire VM. That doesn't work and totally defeats the whole point of having a VM, 9 9s or reliability, etc. Having a bunch of FF/NIFs in C to get around the VM is really missing the point.
Then what's the point of the beam then? you can have the beam, but you can't have concurrency?
I *could* eat soup with a paper airplane, I'm really not understanding how any of this is viable solution to implementing something like ruby on the BEAM VM. What would the performance hit be for using ETS for all your state? You'd just be better off using MRI for Ruby.
You're the one that suggested it, but I'll bite: you might want to embed say ruby in BEAM if you wanted to take advantage of hashicorp terraform. Perhaps you want to support middleware or a query system in another language but have the bulk of your architecture be BEAM. You might want to deduplicate internal libraries shared between teams. You might want to use a 3rd party library written in one of these langs. You might want to transition between lang X and a beam lang and what you need is to leakily expose BEAM modules using shim code as an intermediate. You might just be crazy and want to do weird shit for fun.
also given that it's Wasm GC performance/characteristics aren't grate so it's best suited for non GC language (for now, it's changing, also JIT doesn't work grate either as it's designed for AOT, through interpreted languages can work just fine and for such limitations wrt. how you can write GCs might be less of an problem).
let's look at garbage collection.
How does tradition stop the world, Mark-and-sweep garbage collection work on the BEAM? it doesn't really.
Each process on the beam has its own garbage collection algo, because processes can't share memory, garbage collection on one process can happen without disrupting any other process.
https://www.erlang.org/doc/apps/erts/garbagecollection