Talk: EIR: Infrastructure for working with BEAM code
This is a talk I held at Code BEAM Stockholm about the EIR project.
Posts with the tag elixir:
Juicy: Fast streaming JSON parser for Elixir
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.
Talk: Elixir FFI with Rust
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.
Rustler - Safe Elixir and Erlang NIFs in Rust
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.
I built a computer from scratch
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.
Preemptive scheduling of Erlang NIFs
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 :)