This, IMO, is quite possibly the best instance of "best tool for the job" I've ever seen. Rust is great for writing high-performance code, and Erlang is fantastic for distributed systems.
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.
Really nice to see this linked here, I was chatting with hansihe about getting the html5ever parser from servo into a nif and he magically created it here:<p><a href="https://github.com/hansihe/html5ever_elixir" rel="nofollow">https://github.com/hansihe/html5ever_elixir</a><p>It shows how create a threadpool and avoid the 1ms maximum nif execution time too.
NIFs are the fastest method to call external code from Erlang/Elixir, as far as I understand. But I wonder how high the actual overhead is.<p>My understanding is that if I still want to ensure that the Beam VM can continue to schedule all processes efficiently, these NIFs shouldn't calculate forever, but return quickly to avoid blocking all other processes. So the straightforward way to ensure this for longer calculations would be to split the calculation in smaller, parallelizable jobs, if that is possible. But then the overhead of calling NIFs might actually matter, if you split them into chunks that are too small.<p>I've no idea how big the overhead actually is, I'd be interested in a rough estimate. Is it small enough that I can just ignore it entirely?
> This means you can write and run totally safe code in Rust, no worrying about segfaults.<p>This is not quite accurate; you can still segfault rust writing 100% safe code, for example if you have a large stack overflow ever since __morestack was killed.<p>Though these cases are fortunately rare