This. Behavior is much better these days but dirty schedulers and ports are still the first places to consider putting C code. Only when you know you&#x27;ve got a solid implementation should you upgrade it to a NIF.<p>A short note on how hard this is: Until recently in 18.0, there were many BIFs (built-in functions that are part of the VM) that could possibly cause the same scheduler collapses. If the VM developers don&#x27;t always get it right, the chances that some C code will, is very small. Tools like QuickCheck can help in testing the inputs and outputs but it&#x27;s hard to setup complex VM stress states and thus very hard to make guarantees about NIFs.<p>While there is definitely overhead, I&#x27;d say regular external &quot;ports&quot; (OS-level subprocessing) are quite underrated from what I see in more recent Erlang code. There&#x27;s a lot that can be done this way if port communication is carefully designed.