I like your list, but one thing that would be helpful for me is in the alternative languages available on the BEAM, make the distinction between those implement

I like your list, but one thing that would be helpful for me is in the alternative languages available on the BEAM, make the distinction between those implementations which are "BEAM languages" vs those that are simply implemented on the BEAM. For example, Elixir is a proper BEAM language that targets the BEAM directly in a compile step.... but Luerl is not: Luerl is basically a Lua interpreter written in Erlang. I would expect different trade-offs from Elixir vs. Luerl as such. For example, I have a project where I need a limited, embedded scripting environment inside of an otherwise Elixir project. Using a BEAM language seems to be difficult to impose the desired limitations for such scripting environment, but in Luerl it seems I can do just that... limiting the scripting to a-less-than-system-wide scope. Of course... I expect a fairly substantial performance penalty for that... but trade-offs :-).