from Hacker News

We Tested 7 Languages Under Extreme Load and Only One Didn't Crash

by nnx on 5/28/25, 8:43 AM with 35 comments

• by gizmo on 5/28/25, 9:15 AM

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

• by gommm on 5/28/25, 9:40 AM

  This looks like LLM blog spam. To be taken seriously, they'd need to publish the implementation in each language of each benchmark which they didn't.

  Instead they show pseudocode with very vague descriptions of failure mode that do not really make sense: "Under our error cascade simulation, some low-level failures in unsafe code regions propagated in ways that eventually caused deadlocks in resource management." That doesn't give any details nor does it sound like a realistic failure case to have "failures in unsafe code regions".

• by gspr on 5/28/25, 9:15 AM

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

• by tomtomtom777 on 5/28/25, 9:22 AM

  If I understand it correctly, all programs were coded for unbounded growth; just accept more jobs/connections until it fails.

  Obviously this is a bad idea. Even in Erlang's case because while some processes may continue to function, the behavior becomes utterly unpredictable.

  In the real world, we would gracefully reject jobs/connections above a certain threshold.

• by on_the_train on 5/28/25, 9:15 AM

  I'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

• by iLoveOncall on 5/28/25, 9:13 AM

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

• by benterix on 5/28/25, 11:12 AM

  Although as a fan of Elixir I agree somewhat with some of the conclusions of the article, it deserves flagging as a HN submission because of flawed methodology, lack of numbers and clickbaity title (yes, clickbaiting is passe).

• by mrweasel on 5/28/25, 9:14 AM

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

• by rvz on 5/28/25, 9:28 AM

  > Remarkably, the lone survivor wasn't Rust or Go, as many of us had predicted. It was Erlang.

  This is what the Erlang VM was exactly designed for, yet these "programmers" claim to be surprised that it didn't crash under heavy load, unlike the rest?

  The language runtime is what was under test rather than the language itself.

  Mediocrity and hype are once again celebrated.

• by lifthrasiir on 5/28/25, 9:22 AM

  I'm starting to realize that this article was probably written by generative AI. The evidence is the rate of new articles by this particular Medium account [1]. The author has posted whooping eight articles within last 24 hours, and about 80 articles within a week. Is it humanly possible? Yes, but only with multiple authors and there is no indication of the existence of such authors. This is also possibly why the "latest" versions were not actually latest at the presumed time point. Not only a bs, but probably a generative bs.

  [1] https://medium.com/@codeperfect

• by aredox on 5/28/25, 9:27 AM

  I would be vey interested with the same test with Ada - another langage used in high-reliability situations.

• by skinkestek on 5/28/25, 9:12 AM

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

• by superchris on 5/28/25, 1:40 PM

  The only thing surprising about the result was that they found it surprising :)

• by xanth on 5/28/25, 9:15 AM

  Wait wat, why do they have the C# logo in the header?