On: Rustler – Safe Elixir and Erlang NIFs in Rust

[im_down_w_otp]

Mostly the Erlang mailing list. http://erlang.org/mailman/listinfo

As an Erlanger, and maker of a NIF -> Rust library I wasn't allowed to open source (sadly), I can tell you I think this is excellent. My current science project is trying to rebuild some small components of BEAM and the Erlang Runtime System in Rust that are currently in C.

Mostly the above is an exercise in understanding the internals of BEAM better, because my ideal end state is to figure out what it would take to make an Erlang/OTP-like library for Rust (with task/thread/process/whatever preemption)... which is actually what originally drew me to Rust 3-4 years ago back when it was shaped more like a systems-Erlang (task supervision hierarchies, etc) and less like a renovated-safe-C/C++.

[tormeh → im_down_w_otp]

>Rust 3-4 years ago back when it was shaped more like a systems-Erlang (task supervision hierarchies, etc) and less like a renovated-safe-C/C++

Wow, any chance Erlang-like supervision and actor model in general might make a comeback in Rust? I'm sure the Erlang guys has thought about this, but no static type checking makes me a bit nervous. Erlang can be surprisingly strict (a good thing) in some ways, but as far as I can tell, you only discover any failures at runtime.

[im_down_w_otp → tormeh]

You can mostly get the shapes of type-safety you'd typically expect to save you from yourself by being diligent about type specs and enabling:

  -Wunderspecs
  -Wunknown
  -Wunmatched_returns
  -Woverspecs
  -Wspecdiffs

And depending on a whole slew of things that may or may not make this useful, or more likely tractable for your codebase, you can enable this to track down some shapes of race conditions:

  -Wrace_conditions

The part where there's still a hole (now that most of the hole around Maps has been plugged) is in the message passing semantics. You can be conventional about how you write an API around the message passing to alleviate this, but there's still nothing stopping any random process from sending any shape of data to any other random process and thus essentially breaks Dialyzer's ability to enable static type checking through all paths. But as long as you have a catch-all matching clause implemented that dumps anything that doesn't explicitly match one of your types you're mostly fine.

[moosingin3space → tormeh]

> any chance Erlang-like supervision and actor model in general might make a comeback in Rust?

As a library, sure, but like green threads, actors aren't ideal for a systems language.

[pjmlp → moosingin3space]

The guys at ETHZ thought otherwise with Active Oberon.

[moosingin3space → pjmlp]

Interesting. Were actors available at the kernel level? If so, how?

[pjmlp → moosingin3space]

Not actors. I should have been more explicit, as I was referring to green threads.

[yellowapple → tormeh]

One could probably discover failures at compile-time with Erlang/Elixir as well, especially if one is diligent with typespecs and/or pattern matching / destructuring.

For example, if I have the following Elixir function definitions:

    def foo({:bar, bell}), do: IO.puts("got a barbell: #{bell}")
    def foo({:baz, bell}), do: IO.puts("got a bazbell: #{bell}")

Subsequently calling `foo({:bat, "some value for bell"})` should be detectable by the compiler and thus generate at least a warning. We can luckily catch it relatively easily and painlessly at runtime with Erlang's normal insistence on process supervision trees, but it's still a crash that could be easily avoided without having to jump into the realm of full-blown "defensive" programming.

[fenollp → yellowapple]

Dyalizer solves your example already.

But finding race conditions is another problem entirely. Have a look at Concuerror and PropEr.

[kibwen → im_down_w_otp]

> As an Erlanger, and maker of a NIF -> Rust library I wasn't allowed to open source (sadly)

Presuming that this happened on company time, I'm curious to know if there's a company using Erlang+Rust in production or if this was just a fun side project. :)

[im_down_w_otp → kibwen]

You are correct on the first count. On the latter...

I've always been a fan of Twitter's mutual opt-in requirement for DM chatting. You're being followed. Which feels really weird and funny to write. But it'll be reasonably obvious.