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.
