That's a good pint! I also can say that it is a matter of perspective. From an Erlang developer point of view, the processes are executing in a preemptive manner without telling them when to yield. The important factor is the reduction limit of the actors as well as being reentrant. It guarantees that each actor will sure yield even if it is still running and have something to do, and will be selected whenever scheduler select them again for execution.
Although writing C code for NIFs is not a regular task for Erlang developers, it must be done with extreme care because not only a long-running NIF could degrade the responsiveness of the VM, but also when it crashes the whole VM will crash.
However when there is no other options except writing a NIF, there are ways to protect yourself:
1. Your NIF should return less than a millisecond.
2. If the item 1 is not possible, split it into shorter NIF calls.
3. If item 1 and 2 are not possible so you have a dirty NIF. It is a NIF that cannot be split and cannot execute in a millisecond or less. There is an experimental feature in Erlang virtual machine which is called "dirty scheduler". When it is enabled some other schedulers are ready to execute the dirty NIFs, so they won't interfere with the normal operation of schedulers.
4. If item 1 and 2 are not possible and you don't want to use dirty schedulers, the +sfwi emulator flag is available to force normal schedulers to wake up again from the collapse situation.
These items are some solutions to remain in normal scheduling state even in case of writing the native functions in C (NIF), but what the article says is about just Erlang code which is run by schedulers and are preempted with no trouble as soon as they reach the reduction limit.
There are lots of demands for making things concurrent, fault-tolerant and distributed nowadays, not only in big companies but also among startups. Erlang already has those features as well as standard tools (OTP) which lets everyone to create something simply.
However among all the languages which run on top of Erlang virtual machine (BEAM) like LFE, Elixir, Efene, Luerl, Erlog, and such the Elixir has an active and bigger community, more interesting frameworks and wider adoption. So it could be claimed that it helped to introduce Erlang values to a wider range of developers.
Thanks for reading my post and taking time to write about it.
As the title of post which emphasizes on "WHY GC matters", I tried to reason why we should understand the underlying of a system, say Erlang, Go, Java or whatever else. But unfortunately always there are few documentation around about them and sometimes it is advised not to read them.
I do agree with you that comparing languages with very different goals is totally wrong, but what I did was comparing the Go's documentation author advice with mine, which is about being clever enough to understand your system.
The Go docs don't have that because they don't want you to know, they have that because they want to be able to change it without blowing up your programs.
Erlang has had similar corners over time, such as the way it has handled large binaries, where they've needed to reserve the right to change it. (IIRC the docs promise that the large binaries won't be in your process heap, which has been true for a long time, but beyond that, the details have changed significantly.)
> The Go docs don't have that because they don't want you to know, they have that because they want to be able to change it without blowing up your programs.
That's a very charitable interpretation. If that's what they want to say, they could say that. I just don't buy it.
