Interesting. A huge part of the Erlang value proposition is that the language and runtime are designed to complement each other, and both have significant constraints imposed by the language design.
Taking half of that equation, and supporting any language, feels like you’re missing a big part of the benefit.
I read the "Erlang inspired" more narrowly. Specifically, it's about supporting large numbers of efficient, isolated processes. So there's a single, well-understood concurrency primitive: the (lunatic) process.
Having written concurrent code in Erlang, C# and Python, I'd view above as a win. A big win. Concurrency decisions in Erlang are simple: if things need to run concurrently, spawn them in different processes. If they're sequential, put them in a function. That's it.
In C# and Python it's nowhere near as straightforward. Do you use OS processes? Threads? Async/Await? Each has different strengths; each also has significant weaknesses.
So: a new runtime that aims to bring Erlang's simple, powerful and scalable concurrency model to any language that targets WebAssembly is, at the very least, interesting. It doesn't need to have all the wider benefits of OTP, or the symbiosis of Erlang and the BEAM. (Though that's great too obviously).
LFE is Virding's himself, and has been around for longer than Erlang has been popular: Robert Virding - LFE - a lisp flavour on the Erlang VM (Lambda Days 2016)
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).
Those languages have the same semantics as Erlang in many important respects. For example, there are no mutable variables in any of those languages. They all have the same concurrency model, the same memory management etc.
The other languages that work with the BEAM are all roughly equivalent. I failed to be explicit, but as weatherlight indicated, languages like Ruby will never work on it.
But your argument is “supporting any language”. Lunatic isn’t supporting any language, the language has to be compatible with WebAssembly for all the reasons you and weatherlight stated.
Erlang/Elixir+BEAM is a tightly integrated ecosystem where the sensibilities of the language(s) and the sensibilities of the runtime mesh perfectly. Both language and runtime are highly opinionated, and their opinions are identical.
WASM is the opposite of opinionated. It was designed to be a compilation target for everything. Almost every language is working on supporting WASM, and that's exactly what WASM was intended for. Because Lunatic is built around WASM, it does support any language, because that's what WASM set out to do.
On the contrary, wasm is extremely opinionated for an assembly-level language. I mean, starting with the part where it literally doesn't have goto, and "almost every language" like C++, C#, or really anything else that has such a construct on language level has to rewrite it into (sometimes much less efficient) loops, conditionals, and/or duplicated code. Or we could talk about how code and data are strictly separated in memory, so no JIT and no language features that require it.
You’re correct, and it’s entirely possible that a language that targets WebAssembly must be designed in a way that makes this a useful addition to the ecosystem.
I just get skeptical when people try to retrofit an existing language/platform to act like FP in general, or Erlang in particular.
Taking half of that equation, and supporting any language, feels like you’re missing a big part of the benefit.