We Tested 7 Languages Under Extreme Load and Only One Didn't Crash
1–10 of 37 posts
Re: We Tested 7 Languages Under Extreme Load and Only One Didn't Crash
#2Either they ran widely different tasks in each program or the article is very misleading about what they did.
Go seems to have been tested with http handling, Rust with sequential computation heavy jobs, C++ with parallel processing and so on.
Maybe this is just one example from each language but this is just confusing.
Re: We Tested 7 Languages Under Extreme Load and Only One Didn't Crash
#3> Erlang's architecture allowed failing processes to be isolated and restarted without affecting the entire system. Even when large portions of the system were under duress, other parts continued functioning independently.
Disclaimer that I know absolutely nothing about Erlang except that I'd rather program in hieroglyphs, but how is a process crashing and restarting an acceptable failure mode?
The title says a single language didn't crash, but it literally does crash and restart if I understand correctly.
In any case this seems to be an extremely narrow test on an extremely specific use-case, where it might be fine to indeed crash and restart, but it's definitely not indicative of the performance of the languages as a whole.
Re: We Tested 7 Languages Under Extreme Load and Only One Didn't Crash
#4Not really sure why Erlang wasn't the predictable survivor? That's kinda Erlangs whole claim to fame.
The various error/failure modes are interesting, but not unexpected in retrospect.
I'm still not a fan of the Erlang syntax, it's so hard to read. It's probably just because I've mostly used C inspired language.
Re: We Tested 7 Languages Under Extreme Load and Only One Didn't Crash
#5Ignoring for a sec the silly idea of a "language crashing":
> … using the latest stable versions as of May 2025:
> Go 1.23
Go 1.24 was released in February 2025.
> Rust 1.78
Rustc 1.86 was released in April 2025.
> C++ (using GCC 14.1 with C++23 features)
GCC 15.1 was released in April 2025.
Re: We Tested 7 Languages Under Extreme Load and Only One Didn't Crash
#6All systems crash "under memory pressure" but there are no details provided that show what the actual issues are? You can write software that is very robust under memory pressure in a low level language, for instance by forking into multiple worker processes. If a process dies because of OOM this would then not affect any of the other processes. The kernel will do all necessary cleanup and do so nearly instantly.
I also don't understand why under "extreme load" there would be excessive memory pressure in the first place. When a server can't keep up with incoming requests it doesn't need to continue spawning new workers/goroutines. You don't need to .accept() when you don't have the resources to process the incoming request.
Very strange article.
Re: We Tested 7 Languages Under Extreme Load and Only One Didn't Crash
#7Wait wat, why do they have the C# logo in the header?
Re: We Tested 7 Languages Under Extreme Load and Only One Didn't Crash
#8I'm calling bs. That article is way too vague on what those " error cascade simulation" actually is supposed to be. The results sound exactly what an LLM think it would happen, but wouldn't actually happen in practice. Rust doesn't magically get "failures in unsafe code regions" when under load. And those few lines of c++ don't have "memory management issues". It's just the first bullshit LLMs come up with
Re: We Tested 7 Languages Under Extreme Load and Only One Didn't Crash
#9> Erlang's architecture allowed failing processes to be isolated and restarted without affecting the entire system. Even when large portions of the system were under duress, other parts continued functioning independently. Disclaimer that I know absolutely nothing about Erlang except that I'd rather program in hieroglyphs, but how is a process crashing and restarting an acceptable failure mode? The title says a singl…
Processes are in Erlang terms are lightweight threads. So when a "process" crashes, that's not the whole system crashing.
Re: We Tested 7 Languages Under Extreme Load and Only One Didn't Crash
#10> Erlang's architecture allowed failing processes to be isolated and restarted without affecting the entire system. Even when large portions of the system were under duress, other parts continued functioning independently. Disclaimer that I know absolutely nothing about Erlang except that I'd rather program in hieroglyphs, but how is a process crashing and restarting an acceptable failure mode? The title says a singl…
Erlang has its own notion of process — the comment should be understood as equivalent to “when running Typescript, some Promises could error and be restarted without the software crashing”.