Not really. Erlang's VM is actually surprisingly slow, and in the era of c10k it was still using select/poll, which were getting to be bottlenecks.
What Erlang excels at is "no programming mistake ever should the whole system permanently down". As in components will reboot to recover. It's not a magic fix for anything outside of that.
I mean, yes and no. It was a software challenge to hit the hardware limit, but the hardware limits were also much lower. My team stopped optimizing when we maxed out the PCI bus in ~2001.
JITs are a great magic trick but it's nowhere near guaranteed you'll get good steady performance out of one, especially when the workload is wide not narrow.
Magical thinking, like Mullvad burning large amounts of engineering effort to make sure their infrastructure never stores anything worth a subpoena. Their VPN servers don't have hard drives. Mullvad is one of the rare examples of doing more than marketing.
And my wife's Macbook Air wakes itself up again if it tries to suspend when connected to a Dell monitor. Apple has plenty of bugs too, and only Apple can fix them.
reply