Hi, I have done 2 languages on top Erlang/BEAM, public languages anyway, LFE (Lisp Flavoured Erlang) GitHub - lfe/lfe: Lisp Flavoured Erlang (LFE) · GitHub and Luerl GitHub - rvirding/luerl: Lua in Erlang · GitHub . The first is a Lisp which keeps the basic Erlang semantics as provide by the BEAM while the second is an implementation Lua implemented in Erlang. [*] Note that the BEAM is designed to run Erlang and most the of the Erlang language features are directly implemented in the BEAM.

Luerl works by compiling down to a VM for which I have then written an interpreter. This to provide the data and code handling which Lua requires but is not provided by the BEAM. Basically Lua has shared, mutable and global data which we don’t do. Yes, the resulting language is slower but the Erlang interface is fast and you get free access to Erlang’s concurrency and parallelism.

[*] I call the first “native” languages on the Erlang Ecosystem, Elixir is of course another one, while the second “non-native” languages.

What kinds of documents do you mean?

There is the BEAM book and also BEAM wisdom. Perhaps you can find even more valuable resources in Best resources on BEAM internals?.

As well as there might be some wisdom available in the OTP sourcecode or in the two RUST re-implementations ErlangRT and enigma.

You could, but if your language has a lot of mutability or objects (I do infer this from your constant mention of the JVM) or other semantics building on those, then the BEAM is probably not a suitable runtime for your language.

Still, building a compiler for your language on the BEAM is a valid choice.