Did anyone find this blog post helpful? I feel like it is vibe written, no technical details whatsoever.
Also, how do you put languages under load? Does the author confuse languages and runtimes?
bstsb · 5h ago
yeah from the way the article is written ("Erlang's victory wasn't about speed — it was about architecture"), and the awkwardly commented code, i'm pretty sure the aforementioned "test" never happened and this was hallucinated by an LLM
> Remarkably, the lone survivor wasn't Rust or Go, as many of us had predicted. It was Erlang.
It was totally the one I predicted after reading the list ;)
> Erlang wasn't the fastest in any single category
It is a tradeoff you have to consider for sure.
sebstefan · 5h ago
> Rust 1.78
> Primary failure mode: Under our error cascade simulation, some low-level failures in unsafe code regions propagated in ways that eventually caused deadlocks in resource management.
What was the point of using Rust if you're going to benchmark it with unsafe code and it crashes there? Or was it code from the standard library, like the unsafe part of the Arc implementation? In which case, why would you not include details
dwattttt · 5h ago
> Remarkably, the lone survivor wasn't Rust or Go, as many of us had predicted. It was Erlang.
Rust is _more_ likely to crash than C, or I assume go. Well, more likely to panic, assert, stop, and unless you're distinguishing those cases, it's all a crash.
juliangmp · 5h ago
> Erlang's architecture allowed failing processes to be isolated and restarted without affecting the entire system.
Wait does that mean the erlang program actually spawned child processes as opposed to a thread pool of some kind?
voidUpdate · 5h ago
> (It Wasn't What We Expected)
I mean, that's exactly what erlang was designed for. I was expecting the surprising conclusion that erlang was a failure, but it was exactly what I expected
Also, how do you put languages under load? Does the author confuse languages and runtimes?
edit: the original article on Medium was deleted (https://medium.com/@codeperfect/we-tested-7-languages-under-...)
It was totally the one I predicted after reading the list ;)
> Erlang wasn't the fastest in any single category
It is a tradeoff you have to consider for sure.
> Primary failure mode: Under our error cascade simulation, some low-level failures in unsafe code regions propagated in ways that eventually caused deadlocks in resource management.
What was the point of using Rust if you're going to benchmark it with unsafe code and it crashes there? Or was it code from the standard library, like the unsafe part of the Arc implementation? In which case, why would you not include details
Rust is _more_ likely to crash than C, or I assume go. Well, more likely to panic, assert, stop, and unless you're distinguishing those cases, it's all a crash.
Wait does that mean the erlang program actually spawned child processes as opposed to a thread pool of some kind?
I mean, that's exactly what erlang was designed for. I was expecting the surprising conclusion that erlang was a failure, but it was exactly what I expected