mareknowak

mareknowak

I’m learning Elixir and I like its ecosystem but I really miss static typing (I’ve played a bit with F# and Ocaml before). I thought about moving as much application logic as possible to Rust NIFs but it seems it is not always a good idea.

Let’s take any Elixir process. Its receive function can be split into “pure” update function and “impure” execute function. The first one changes the state of a process (model) and prepares command (cmd) to be executed/sent by Elixir runtime. The second executes/sends prepared command:

def process(model) do
  receive do
    msg ->
      {model, cmd} = update(model, msg)
      execute(cmd)
      process(model)
  end
end

This separation allows us to implement update in statically typed Rust and treat Elixir as kind of postman that sends prepared commands.

I tested this idea with a toy Elixir/Rust implementation of card game of war. One has Game (arbiter) process and two Player processes. Game sends messages to Players to add or remove cards, receives back responses and updates its state.
Players processes receive messages from Game, update their states (i.e. lists of cards) and send responses (cards added, cards removed, unable to remove cards) to Game. I tested two versions of the game - with those update functions implemented as Rust NIFs and as Elixir only functions.

What about execution time? Elixir updates take on average a few microseconds and their Rust counterparts (with serialization/deserialization) are 100x slower so Elixir’s version of the whole game runs faster than Rust’s one. If speed is the only concern then one should consider substituting Elixir function with Rust NIF
only if its execution time is greater then 500 microseconds. I hope someone will check my claims - the code is available on github. By the way, NIFs are implemented with help of rustler library and data conversion between Elixir and Rust is flawlessly done by serde_rustler crate - both libraries are great.

Conclusions for static type oriented? I’m definitely not the right person but here are my thoughts.

Most functions by default should be written in Elixir :-). Medium sized Elixir functions can be written as Rust NIFs. Sophisticated applications can separated with the use of Erlang ports into Elixir “glue” and for example Ocaml part treated as a “domain model”.

The most radical option would be to abandon Elixir in favour of Rust but for web stuff Elixir ecosystem is probably much bigger.

Showing Posts 1 to 6

NobbZ

NobbZ

I haven’t looked into your project, but when you do NIFs, they need to return in less than a millisecond or they confuse the scheduler.

You can use CPU or IO bound dirty schedulers to circumvent this requirement.

mareknowak

mareknowak OP

I should be more explicit - NIFs execution time is of order 0.1 millisecond (i. e. 100 microseconds).

sribe

sribe

If you really want speed, then you don’t want to serialize/deserialize.

mareknowak

mareknowak OP

I will prepare a serde_rustler free version to check it.

dom

dom

Small passing remark: when computing run time, you want the monotonic clock rather than utc_now:

mareknowak

mareknowak OP

@sribe suggested that serialization/deserialization makes NIF slower. I prepared three version of the game to check it: elixir (no NIFs), nif_rustler (only rustler library) and nif_serde_rustler (with serde_rustler library) and took @dom advice to properly compute time of execution of update functions.

Conclusions? @scribe was right. Serde_rustler is a very nice library but rustler explicit decoding/encoding is always faster. On my machine on average rustler update takes 60 microseconds and serde update - 160 microseconds. By the way - pure Elixir update function runs in 6 microseconds. The code is available on github:

https://github.com/mareknowak/cardsnif

— All posts loaded —

Where Next? Top

Trending in Discussions Top

cblavier
Hey there, It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
budgie
A little off-topic, but I feel like people here have a good head on their shoulders. I used to be quite good at making software. Was luc...
New
axelson
Hi there! :wave: @frigidcode and I (but mostly him) have been running an Elixir Book club, we’re almost done with Designing Elixir Syste...
New
budgie
I love Elixir. It’s one of 2 programming languages I’ve ever fallen in love with. But I don’t use it anymore. Serverless was the promis...
New
Null-logic-0
What IDE or editor are you using for Elixir development? Personally, I use Zed, and I really like it, but sometimes I wish there were a ...
New

Other Trending Topics Top

GenericJam
Edit: 2026 May 15 - This post is archived. Mob is alive!! Main docs: mob v0.7.11 — Documentation A bit of explanation for the slightly c...
New
JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
mcass19
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
georgeguimaraes
Just published claude-code-elixir, a plugin marketplace for Claude Code with Elixir support. These are the plugins I’ve been using for my...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews