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

AstonJ
As the title says, please share what you’ve been up to with Elixir. Whether that’s been learning it, looking into it, making stuff with i...
2977 92995 915
New
AstonJ
The obligatory hello world thread! Who are you and where are you from? :stuck_out_tongue:
4616 55835 594
New
caslu
I want to open this thread for you all to discuss and help those who really like Ash but are still hesitant to use it in a real project. ...
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
Herve37
We’re evaluating API mocking tools for OpenAPI-based projects and would love to hear what other teams are using. We’re particularly inte...
New
GES233
I’m posting this in response to Jose’s recent tweet (Cr. link) : People are sleeping on Elixir for a coding harness: Hot-code swappi...
New
nseaSeb
AcmeScript — Writing JS hooks as if I were still using Elixir I’ve been having fun building a little something over the last few days: Ac...
New

Other Trending Topics Top

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
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve. They are GUI (Emerge) and State management (S...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
wintermeyer
There are three potential reasons for members of this forum to have a look at https://vutuv.de You are tired or annoyed of LinkedIn. Yo...
New
webofbits
Aludel - LLM Evaluation Workbench Aludel is an embeddable Phoenix LiveView dashboard for evaluating and comparing LLM prompts across mult...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews