There's a bit of back-story here, the gist of which is: the book initially was supposed to come out from O'Reilly and Associates, but periodically the release date would get pushed back by 3 months or so.
Then they cancelled it.
It was then picked up by Pragmatic Programmers, but they wound up cancelling it too.
In any case, Erik told me a couple of weeks ago at Erlang & Elixir Factory that he'd be looking to get it out himself online by -- or around, I forget -- summertime, so it's nice to see he did this now, even if it means I lose the betting pool (I kid).
I am curious if you or anyone else knows why this book might have been cancelled by both Oreilly and Prgagmatic, given they have other Erlang/OTP titles. It seems odd.
At any rate I'm glad to see it's going to have a life independently. This looks great.
Agreed! Just like people admire at a beautifully engineered ship, plane or nice building, I think BEAM VM is marvel of software engineering.
It got so many things right, it was ahead of its time. Is already stable and is serving critical pieces of infrastructure around the world for many years.
It is also worth pointing out that the BEAM was designed with one purpose and that is to run Erlang. Other languages can be implemented on it, but they sort of have to adapt to the Erlang way. The downside there is that the BEAM official specification is its ... implementation. And reasons for implementation were written down. You can catch Joe Armstrong or Robert Virding at one of the events like Erlang Factory and they'll happily tell you why things works the way they do.
Things I like about this VM:
* Process isolation : sounds like magic but it's true you can have millions of processes _and_ all having isolated heaps.
* Dynamic tracing : connect to a node and start tracing any function
* Hot code loading : don't feel like stopping a critical production server to add an extra log statement or upgrade it, don't have to. Can just load the code.
* Like you mentioned, GC. It will never "stop the world". When process ran and exited, the whole block can be reclaimed quickly and efficiently.
Anyway using BEAM with Erlang, Elixir, LFE or other languages, feels a bit like using a secret weapon that very few know about.
And the very nice 1-2 between the Erlang compiler and BEAM that ensures the system keeps on ticking by limiting the amount of work done in a single reduction.
That's a very elegant solution to various CPU hogging problems that would otherwise be extremely hard to solve in userland.
EDIT: too late to edit but it should have been "... reasons for implementation were NOT written down...". So yes do track Robert and Joe down and ask them why
This is amazing. I've started to learn Elixir recently, and as a result my interest in Erlang and BEAM has been piqued. I'm sure a lot of this will be over my head for now, but looking forward to digging in.
This is awesome. Unlike the JVM, its really hard to find anything describing how the Erlang VM works in detail. I tried reading through the source a while back but it was still hard to get a gist of what was going on because of the shear size of the project.
This will be a very valuable resource. Thanks so much to Erik!
Not to be confused with Apache Beam which is looking to become a survivor in the big data space with it's abstractions over whatever is the hottest new streaming or batch processing technology.
https://github.com/cloudozer/ling
An impressively done book on BEAM instruction sets:
https://github.com/cloudozer/ling/tree/master/doc
There is even a handy dandy online instruction set completion search:
http://erlangonxen.org/more/beam