Iirc beam has fixed memory constraints for its processes and a deterministic scheduler that gives even time to all processes, which help.

The BEAM is admittedly, a very interesting option for embedded systems.

http://www.rosepoint.com/ uses Nerves under the hood on its marine navigation products (so, real-world results). Garth (CEO) did a presentation a year ago or so where he said his entire industry is java-driven and was skeptical about his decision to go Nerves but after testing it on some realtime data for a month and seeing absolutely zero memory leaks or any faults (and relatively low CPU usage), he decided to go forward with it and has been pretty happy with it so far.

I assumed between that and the fault tolerant nature of the architecture that it would be ideal for a standalone device that would be harder to service. I remember doing specs for in vehicle systems in college and the "what if it crashes" question was a nightmare.

Unfortunately, BEAM is not really very easy to hack on. The community has gotten much better than it was a few years ago, but the code is pretty hard to understand.

I think the BEAM approach could be very attractive for embedded systems, given the right investment.

I'll grant you that there's not a lot of documentation for the internals, but I don't think the internal code is that hard to understand. To start with, unlike some languages I've worked with, a large amount of OTP is built in erlang, not C. Another key thing Erlang does is avoid complexity when it can. For example, the GC algorithm is just about the simplest GC you can get (caveat it is generational); because of the language constraints, a very simple GC is effective.

You certainly need to spend some time figuring out all the data types and how to access them in C, but if you're willing to spend some time, and you're capable of mucking about inside a VM; I don't see how it's that hard to understand. It feels to me to be on about the same level as the FreeBSD kernel; after chasing down surprising behavior enough times, I've got a pretty good feel for how to read the code, and whereabouts to start looking for code I'd like to read; but making changes can be a stretch, depending on where it needs to happen. OTOH, I only have to dive into the depths when my team manages to break beam or the kernel, which isn't everyday... If more things broke, I'd have more skill here. ;)

You work at WhatsApp then?

I've written a bunch of Erlang, and a bit of Linux Kernel bits.

You're right, rarely do I break BEAM because most of what I'm able to break is in Erlang. The only times when this is untrue is performance. If you spend a lot of your day hacking on BEAM, I'd love some more documentation like the BEAM handbook, if you're interested.