Lee’s “BEAM 2.0” project
* Lee provided an ad-hoc update on his “safe BEAM” built in Rust
* Along with a project that emerged from it, called Silica
* Further information, discussion and possible collaboration in EEF Slack’s Security WG channel
Any public pointers or information that can be shared, without the need to be part of the EEF Slack? This could be of interest to a wider audience if shared, with more people involved then?
I’ve been waiting for someone to post about this. I was incredibly excited to hear about the project, and unfortunately quite let down to hear that NIFs would not be supported. IMHO, without the ability to “just use a new compiler with close the zero changes” it’s effectively DOA.
The idea of having to re-implement any/all NIFs and/or external C based components such as Open SSL is a huge blocker.
Don’t get me wrong, I’m still hugely excited about this effort, but IMHO, it needs to be seamless. There are many components in production use that cannot easily be replaced with re-writing in Sicla at without significant cost.
If I could just a command to compile a project with zero changes I’d be 100% in to test, without it …
Will still follow what’s happening and excited to see what it brings to the table
Sorry, this is going to be long.
I’m not ready to go public with the repo yet. Some things are still in design others are in progress. I can’t see a way to add the specification files to a post here, and they are large being specification files. These files are well on their way to being ‘fixed’ for an initial release. I will add them to the general slack channel and they can be distributed by people there. The files are open to useful and thoughtful suggestions and modifications.
I will say this directly here, there are several design decisions driving the development of Silica;
Being familiar with BEAM languages means you are well on your way to being familiar with Silica but don’t expect to find syntactic sugar in Silica.
So where does development sit as of today?
The bootstrap compiler, written in Rust, is ‘done.’ It has support for all the items listed below, lightweight processes, cases, traits, effects, safe, direct access to memory including buffers, etc.
The phase2 compiler, written in Silica is in progress. This is what exists in the phase2 compiler right now.
main functions with returns to the OS (several types).
atoms with comparison and print_atom/1
int8 with arithmetic and print functions.
int16 with arithmetic and print functions.
int32 with arithmetic and print functions.
int64 with arithmetic and print functions.
uint8 with arithmetic and print functions.
uint16 with arithmetic and print functions.
uint32 with arithmetic and print functions.
uint64 with arithmetic and print functions.
float16 with arithmetic and print functions.
float32 with arithmetic and print functions.
float64 with arithmetic and print functions.
string with concatenate, substring (multiple), and print functions.
tuple composition and decomposition.
My external target for a usable first release is the beginning of September, 2026 (this year). My internal, personal target is the end of June. If things keep going as well as they have and life doesn’t interfere, It may be ready by the end of April 2026. In two months. Don’t hold me to my internal goal dates.
@LeeB Is silicia also going to be an actor based concurrency focused language a la Erlang or Pony? Or is it just meant for implementing something like Erlang
Sorry to hear you feel this way.
Thanks LeeB for this update and the sharing of your goals. Good luck for your target dates, both internal and external ones then!
About the specification files, they could be shared on their own repository to get public reading and suggestions / PR, whatever tool / service is easier for you. Using a slack channel doesn’t seem the most effective way of sharing such documents with the wider BEAM-language community.
Good idea. I’ll do that today.
Actors are focus based like Erlang, Kotlin, Swift.
To the original poster: you are a hero for doing this and I look forward to seeing it. The one issue I see is that it is in Rust rather than say SPARK/Ada or Frama-C, because Rust is available for so few platforms as yet. Is it the intention that Silica will be more portable than Rust?
The bootstrap compiler is in rust. The silica compiler is written in silica. The initial target is AArch64 this will be followed by x86-64. After that support can grow in any direction.
Here is the link to the current state of theSilica specifications and a ‘Why Silica?’ README.md. Remember these are undergoing revisions as the compiler is built.
Is this unrelated to the OTP teams plans?
I update members of the OTP team when they are in meetings. I don’t know what their plans are specifically.
Thanks for the link. In fact the model (which is still followed x86-64 and everything the BEAM runs on) is not the PDP-11 but the IBM System/360. Flat address space, byte addressed, multiple general registers, sizes of 8 16 32 and 64 bits are “natural”. Unlike the machine I used as an undergraduate: tree-structured address space, word addressed (with byte pointers sort of hacked in), no general registers (three ISA-invisible top-of-stack registers), sizes of 6 48 and 96 bits natural, and designed for multiple tightly coupled CPUs back in the 1870s. All supported programming languages were memory safe and several of them were concurrent, in the 1970s; I am of course talking about the Burroughs B6700 family. The model that won was the System/360.
The argument against C is half valid but mostly not. C all by itself is not memory-safe. But there are verification tools for C (such as Frama-C) which can enforce memory safety. Thinking back to my time at Quintus, the WAM, our analogue of the BEAM, was written in a sort of high level macro assembler called PROGOL that was at a lower level than. It was thus even less memory safe than C. But while we had our share of bugs, memory safety in the emulator was just never an issue. I have no idea why. when we ported the system to InterLisp-D on the Xerox 1108 and I had to rewrite the emulator in Lisp (as a model and fall-back for the microcode version), then I did make mistakes using (\GETBYTE object offset) or whatever it was, but the pain of having to reboot the machine by feeding it 24 floppies ensured that I learned to write memory-safe low-level Lisp fast .
Having someone independent write a BEAM emulator is an excellent way to smoke out problems in the current BEAM and all of us stand to benefit from it. I repeat, you hero!
Thanks for the history. It reinforces my belief that the BEAM is a work of genius and inspiration.
the pain of having to reboot the machine by feeding it 24 floppies ensured that I learned to write memory-safe low-level Lisp fast .
Ah, the good old days…
. I remember them well. I remember my first armored floppy when I went back to college. I wondered how I would ever fill it. How naive. 
when I got my first job in industry, being the new guy, one of my jobs was to split the product across floppies. What a hoot. 