I've been very excited at Rust's prospects as an alternative to C for extending all sorts of higher-level languages, but I'm most excited at the prospect of combining Rust with Erlang given the latter's focus on reliability. I'd love to figure out where Erlang programmers hang out to ask them what they think about using Rust for NIFs.
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++.
>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.
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.
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.
> 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. :)
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.
I'm using Rust in exactly that capacity (along with ports). In fact, if it weren't for Rust, I'd probably steer clear from writing my own NIFs for the sake of my own sanity; coming from the Perl 5 world, where XS is king, I'm not exactly keen on splaying open Erlang's C API unless I have a language with which to do so without slicing off my own leg.
(Ports, on the other hand, are inherently safer due to being isolated from the Erlang VM, such that even if they crash they don't bring down the whole VM. They also communicate over STDIO, meaning that I'm free to use them to interface with components written in languages with less-than-pleasant methods of achieving C ABI compatibility, like Perl 5 and Ruby when not augmented with extra packages.)
On that note, Rust also has some wonderful implications for the Perl 5 world in terms of providing some semblance of safety around native Perl extensions. Same deal for Perl 6 (though its FFI mechanisms are infinitely nicer than Perl 5's).
