Targeting BEAM for extreme reliability

Sometime back I got to see Reia, a Python-Ruby esque language targetting the Erlang virtual machine (BEAM) and the high performance native compiler (HiPE). Much before discovering Reia, I had exchanged a couple of tweets with Michael Feathers expressing my surprise why not many languages target BEAM as the runtime. BEAM provides an ecosystem that offers phenomenal scalability with concurrent processes and distributed programming, which is really difficult (if not impossible) to replicate in any other virtual machine being worked upon today. After all, it is much easier to dress up Erlang with a nicer syntax than implementing the guarantees of reliability and extreme concurrency in any of your favorite languages' runtime.

And Reia precisely does that! The following is from the wiki pages of Reia describing the philosophy behind the design ..

Reia combines the strengths of existing language concepts. The goal isn't to invent new ones, but to provide a mix of existing approaches which provides an easy and painless approach to writing concurrent programs. To that end, Reia feels like Python with a dash of Ruby, and the concurrent programming ideas behind Erlang added to the mix.

Reia also leverages the highly mature Erlang VM and OTP framework. These both provide a bulletproof foundation for concurrent systems which has been highly optimized over the years, particularly in regard to SMP systems. There's no need to build a new VM when an awesome one like BEAM is available.

Bunking the single assignment semantics ..

This is something I don't like about Reia. From the FAQ .. "Reia does away with many of the more obtuse semantics in Erlang, including single assignment." Single assignment in Erlang is all about extreme reliability and providing developers a lower cost of fixing bugs that may arise in highly distributed systems with hot swapping and transparent failover. The code that I write today in Reia may not be deployed in a distributed architecture right now. But it has to be safe enough to interplay with Erlang modules that already run in the same virtual machine as part of an extremely reliable architecture. This is the basic idea behind cooperative polyglotism - modules written in various languages can interplay seamlessly within the confines of the honored VM.

Erlang guarantees immutability at the language level. Once you allow destructive assignment, you are no longer playing to the strengths of the ecosystem. A similar logic holds with Scala actors built on top of the Java Virtual Machine. Because the language does not guarantee immutability, you can always send mutable data between actors, which can lead to race conditions. And as Yariv explains here, this leaves you just where you started: having to ensure synchronized access to shared memory. And because of the fact that neither Java nor Scala ensures language level immutability, you cannot really take advantage of the numerous existing Java libraries out there while implementing your actor based concurrent system in Scala. Without single assignment enforced, systems written in Reia may also have the same consequence while interoperating with Erlang modules.