[Scramblejams]

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.

[rlander]

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.

[Mikeb85]

The parent of the post I replied to was about Haskell, Ada, Pony and Go. And the thread is about Crystal (with lots of mentions for Nim).

All of those share one thing in common, something which Erlang doesn't have in common with them.

[ZephyrP]

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).

[Mikeb85]

Was referring to the fact they're all languages which compile to native executables.

[rlander]

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.