Also, was the Erlang VM written in Erlang? Probably not. So I'm skeptical about the universality claims of the language.
To the programmer, messages are immutable. There are, however, optimizations to reduce the performance impact, particularly for binary data. When you send a binary message that is longer than 64 bytes, it is actually stored in a shared heap and effectively only a reference is passed as a message. Similarly, when you extract a small piece out of a larger binary, you might actually get a reference to the larger data stored on the binary heap. The Erlang VM has had more than 30 years of development, and there are a lot of subtle optimizations like this which were needed to solve real world performance and scaling issues.
Lack of serialization is one thing that makes e.g. the ETS key/value store built into the VM nice compared to Redis. You can just use raw data structures as keys and values. Reads and writes are under 1 microsecond.
As for universality, not sure where you’re getting that. No one’s saying you should use Erlang for writing device drivers or OS kernels, or the lowest-level parts of the VM. Erlang is a medium- to high-level language, and should be evaluated as such.
https://erlang.org/doc/man/erl_eval.html
https://github.com/erlang/otp/blob/master/lib/stdlib/src/erl...
It's not lisp levels of concise, but the language was not designed for that.
the trade off is that every thread has its own gc arena that can be freely and quickly cleaned, and even better, often simply dropped entirely when the thread ends
there's never a stop the world moment, only the specific greenthread that's used up all its space.
OTP setup for managing processes in a standard way is also a big boon to developing in the language.
if you need to mangle some giant datastructure concurrently, sure, erlang is likely to not be what you need. but if you're just trying to toss out a cluster of interconnected nodes that can handle tons of concurrency and your interprocess messages are largely queries to threads dedicated to managing some resource or lump of data, it's a great setup.
This particular optimization can backfire if you're not careful. If you generate short binaries that trigger this optimization and then store them in ets, it references the existing binary which has a lot of extra space. If you hit that binary:copy/1 will return a perfectly sized binary you should store in ets instead. This same kind of thing can happen if you make a sub binary from some large binary (like a service response) and store it.
[1] http://erlang.org/doc/efficiency_guide/binaryhandling.html#c...
The article states the opposite opinion: that you should use the right tool for the right job.
Change the requirements... and the spectrum-of-ridiculousness for any option changes drastically. The language matters, deeply.
This copying isn't memory efficient and may not be CPU efficient, but along with immutability, it makes garbage collection simple, fast, and independent per process.
I suppose crashing is a kind of GC