Hacker News Reader

IMO NIFs won't get you the best of both worlds as they tend to eliminiate the resilient properties of the BEAM.

See http://erlang.org/doc/tutorial/nif.html:

> As a NIF library is dynamically linked into the emulator process, this is the fastest way of calling C-code from Erlang (alongside port drivers). Calling NIFs requires no context switches. But it is also the least safe, because a crash in a NIF brings the emulator down

View on HN

In theory yes, but in practice it’s not too bad. Especially with Rust, or even Nim NIFs.

It’s only a problem if the NIFs crash (rate in my experience), or they take too long and cause the VM to hang (easier to do for big computations). Now with the newish ability to mark a nif as dirty which helps the scheduler know a nif can have longer runtimes that could block the VM.

P.S. Elixir/BEAM often also achieve resilience via connecting multiple nodes as well.

I think Rust can give the best of both, but in general I totally agree with you. IMHO, most people look to NIFs when they probably want to use IPC. Run a separate process for the computationally intensive operations (e.g. ./must-go-faster) and then let the operating system manage it. It's more reliable, probably faster, and easier to maintain that way too!

What IPC method would you recommend?

Reply on news.ycombinator.com