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.
Re:Elixir RAM and the Template of Doom
by rubyn00bie on Saturday August 08, 2020 @06:31PM
(#24095767)
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!
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