This is not "introducing BEAM VM" type of website. More like a reference for more reading for those who already tried Erlang or Elixir or LFE or another language running on it. So they should come with at least the initial knowledge what this is.

Source: I created this website.

I've never used Erlang, but have read up on it a few times over the years. I think a large reason why it's not more popular is that the concepts are so abstract and hard to grok, partially because -- as you mention -- there is a lot of overloading of terms from Unix land. e.g. a VM isn't a VM by the definition used in most colloquial contexts [0], a process isn't a Unix process, etc. And yet despite all this, you can run it on Unix systems. This is confusing.

There isn't really a solution to it, since it's not like Erlang can start from scratch and rename everything, but I really think this kind of cognitive overhead discourages people from learning new languages. The same challenges exist in languages like Haskell.

That said -- "devs are too lazy to read" is no reason to stop innovating. Erlang seems quite cool and I hope I get an excuse to use it in production one day.

[0] Yes, I know that Beam satisfies all the technical requirements to be a VM (https://en.wikipedia.org/wiki/Comparison_of_application_virt...) My point is more that, colloquially, people usually refer to a VM in the sense of a guest operating within a Hypervisor.

> My point is more that, colloquially, people usually refer to a VM in the sense of a guest operating within a Hypervisor.

Python, Ruby, Java, and JavaScript want a word with you. Bytecode VMs being called just 'VMs' colloquially is extremely common.

Yeah, I mean, ultimately my argument is that devs are too lazy to understand documentation, but of course I don't consider myself one of those, so I can't defend the claim that my biased and imaginary sample of devs understands VMs in the same way as your sample.

That said, I will stand by the argument that most people (myself included) are too lazy to understand documentation.

> When I see 'VM' I think first of a hypervisor virtual machine.

VM as a bytecode interpreter is a very well-known meaning of the term thanks to the JVM.

I guess most people that uses erlang (or apps made with erlang) know what BEAM is, just like people that uses java or java apps know what JVM is, so the author doesn't feel the need to explain it anymore.

I think the ELI5 is being used rather loosely and figuratively and in spirit here, which should be clear.

> When I see ‘VM’ I think first of a hypervisor virtual machine.

That’s kind of a strange interpretation to me. In the context of programming languages VM is quite clear ala BEAM VM, CLR, JVM, LLVM, etc.

I think the first sentence of the page explains pretty clearly that this an ELI5 of BEAM VM internals, not of what the BEAM VM is.

This is the collection of easy to read (ELI5) articles as well as in-depth knowledge such as VM internals, memory layout, opcodes etc.