This is a talk I held at Code BEAM Stockholm about the EIR project.

Early 2017 I experimented with writing a well behaved JSON parser NIF in Rust, using the Rustler project. I never wrote about it or showed it off at the time, but I recently looked back at it and realized it could do some pretty cool things.

Lately I have been spending some time at the Hackheim hackerspace in Trondheim. Although being located at the back of a bar and arcade is really cool, looking around and seeing projects like the Flaschen Taschen made us feel slightly insecure about our digital signeage situation. Things needed to be set right, and we decided to outdo them. After thinking it through, we snapped back to reality, and decided to just make a really nice LED-lit sign instead.

This is the talk I held at PolyConf 2017 in Paris.

It’s on the subject of using Rust in combination with my crate rustler for writing Erlang/Elixir NIFs in a safe way.

Newer Apple devices have a feature called Force touch. It allows the device to accurately measure the pressure that is applied to the screen by the user. This is done by a dedicated sensor located on the back of the screen.

The Xperia Z5 by Sony does not have such a sensor, and thus can not directly measure the pressure which is applied to the screen surface. However, the phone is waterproof. This has the side-effect of making the air pressure within the phone increase momentarily when there is pressure applied to the screen. As it turns out, this can be used to determine the amount of absolute pressure on the screen relatively accurately.

Natively Implemented Functions, more commonly known as NIFs, are not a new thing in Erlang. They have been around for several years, and are commonly used for speeding up simple tasks like JSON parsing. The reason why they are not more commonly used for general computation is the massive disadvantages they carry with them. While Erlang is generally built for reliability and fault tolerance, all bets are off when writing NIFs written in a language like C. Any programmer error in the NIF code can very easily take the entire Erlang VM down with it, which includes all processes, supervision trees and data contained within.

Ever since I started programming, I have been interested in how the stack works all the way down to the bottom. Although I don’t know the specifics on a lot of things, I like to think I have developed a reasonably complete understanding of how a modern computer works all the way down to the assembly level. The levels below that have always been more or less shrouded in a thick fog of mystery for me. A couple of months ago I decided to do something about that, and what better way to learn something new then to jump straight into the deep end. I decided to design and build my own computer from scratch.

In this article we look at a completely reckless and unsafe (but fun) way to work around some of the issues with running native code from Erlang. This involves allocating a new C stack and switching to it, then interrupting execution when a certain amount of time has passed and switching back to the original thread, for then to resume execution where we left off later at a later point in time.

Note that is is purely done for fun, is completely nonportable, and does quite a few things that could crash or deadlock the Erlang VM if you so much as look at it the wrong way. What’s not to love :)