This shouldn’t be downvoted. I love Erlang, but it’s the latency that’s really fast (that is, low), not the throughput[0].
It just so happens that Erlang is frequently used as a network server and can probably saturate the network interface, so its throughput is usually judged to be Good Enough, while the latency is generating the positive headlines.
[0] There are exceptions to everything. If your problem allows you to write code in such a way that the critical path stays mostly inside the VM’s C code, rather than having to keep fetching your instructions, the throughput can impress.
And that's why he's being downvoted... Generically claiming that a language is "slow af" will mean different things to different people. Hence the interpretations. Hence the downvotes.
Erlang absolutely does have this 'in common', and it makes this faculty known every time you start up the Erlang REPL.
In fact, I think there's a case to be made that it may have the most refined implementation for scheduling M:N processes (along with more advanced thread affinity, alternative RQ dispatching, SMP awareness, etc).
Well you’re either confused or being purposefully ingenuous. The original poster, samuell, said nothing about languages which compile to native executables, he said he’s looking for “languages with light-weight threads automatically mapped (multiplexed) to physical threads, like in Go”. Hence the suggestion of Erlang, which is valid. Further, making a generic statement that Erlang is “slow af” adds nothing to the discussion.
The benchmark game's "results" peg some toy programs in Erlang an order of magnitude faster than Python 3.
Of course, you probably foresaw another classic interpreter-speed justification coming from a mile away, but.... There are very well-developed methods of interfacing with fast native code, ranging from C nodes to nifs. The documentation is circumspect about using C code, but nevertheless provides you with the good, bad and the ugly on these various different methods.
If anything, I think Crystal could crib a page from Erlang and elevate what it calls "Fibers" and "Channels". Erlang made these first-class in both design & syntax, which allowed Pids and messages to be not just building blocks of concurrent interaction patterns, but also architectural utility-knifes in consecutive Erlang code. The more Erlang you read, the more you see this really powerful method of dividing concerns "physically" rather than "structurally", in which you can be doing everything from implementing Objects (for some definition of OOP) to representing recursive data structures with lightweight threads as the "backing primitive". This may be obvious to some old-head Lisp programmers, but I about choked on my latte when I saw this demonstrated at the first Erlang shop I worked in. It's a cool and extremely powerful idea that can be implemented in any language, but is best if the spawn/message syntax is concise.
Faster than Python 3 means little and the discussion is mainly about languages which compile to native code and have certain features.
Erlang is a super cool language and were I doing an app which needs millions of concurrent connections over many cores and/or machines, I'd choose it in a second. But Crystal is more of a (potential) replacement for Java or C++.
I get where you are coming from (although, in the case mentioned above at least, an order of magnitude faster places it within 150% of the speed of Java). I think you're only scratching the surface of Erlang here though. I believe "networked services", "millions of connections" and "hot-code reloading" are a meme that hides the Erlang's real utility.
Along these lines, the most popular open-source subdivision 3d modeling software package is, outside of the shaders, written top-to-bottom in Erlang (including the engine).
"Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic." (quoted from the Erlang FAQ).
It just so happens that Erlang is frequently used as a network server and can probably saturate the network interface, so its throughput is usually judged to be Good Enough, while the latency is generating the positive headlines.
[0] There are exceptions to everything. If your problem allows you to write code in such a way that the critical path stays mostly inside the VM’s C code, rather than having to keep fetching your instructions, the throughput can impress.