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.
jiggawatts · 19h ago
It reads like an astroturf advertisement for a product, but Erlang is open source and free.
It's a worthless article anyway for the simple reason that there are no graphs, numbers, or reproducible experiments. The code snippets aren't the whole programs and the test harness setup isn't spelled out. The programs themselves look different in what they're doing, so they're not even equivalent! It's hard to tell because, for example, in some snippets the outermost loop is shown, but for C++ only the per-request "workload", but not all of it.
Even just the how of the testing can make a huge difference in my experience, especially when running synthetic workloads against garbage-collected languages. Most of them will never crash under normal workloads, but if you go out of your way to generate stupid amounts of memory allocations, practically none will be able to keep up.
The whole article is just nonsense, end-to-end, starting from the first content paragraph:
"Our test environment consisted of a cluster of 16 high-performance servers..."
Why a "cluster"? None of the workloads appear to be distributed or clustered applications! They're not testing Akka or Microsoft Orleans here, so why bother having more than one box?
What operating system was used?
What were the client systems? How many?
Were some of the languages "doing better" simply because they were slower at handling the test loads and hence failing slower?
Were the test clients correctly sending requests as fast as possible, or waiting sequentially for previous requests to complete before sending the next request?
Etc...
burnt-resistor · 17h ago
Data or it didn't happen.
It seems like an ideological shitpost.
gommm · 19h ago
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".
tomtomtom777 · 20h ago
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.
benterix · 18h ago
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).
0x000xca0xfe · 18h ago
Thank you. The article sounds like it could have been a fantastic research and even help fix some compiler/standard library bugs on the side. But in reality it probably was generated by ChatGPT. I've load tested NodeJS myself and had a different failure mode (connections getting dropped, not "cascading failures", whatever this means).
yetihehe · 15h ago
I've load tested erlang and had cascading failures in my code. While I love it, erlang is not a silver bullet. I also managed to find a one-liner that will block whole erlang vm for many minutes with 100%cpu usage on only one core, so it's not perfect here too, but it's one of those "well, don't do that in this way" cases. Joe Armstrong was intrigued :D
mrweasel · 20h ago
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.
taavi013 · 19h ago
Actually Erlang syntax is very nice. You just have to get over first confusion of language functional nature and prolog heritage.
It helps tremendously, that in Erlang functions are quite short, self contained due to functional nature. And you can grasp essence of function on one screen without need to have background knowledge of scattered mess of classes/global variables/other spaghetti.
Really pleasant for reading code.
But definitely not C inspired language.
superchris · 15h ago
The only thing surprising about the result was that they found it surprising :)
lifthrasiir · 20h ago
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.
It certainly looks like that. For such a technical article, there are just very vague descriptions of the failure modes. The code examples do not make much sense. I would expect more in depth dive into the problems, but all we got is this mostly generic stuff.
ochre-ogre · 19h ago
That profile picture appears on dozens of websites under different names lol.
skinkestek · 20h ago
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.
kqr · 20h ago
I think the intro makes clear that all languages went through the same tests.
Edit: though I agree with another top-level comment that the reported results are too vague and stereotypical to be believed.
skinkestek · 19h ago
> I think the intro makes clear that all languages went through the same tests.
I know, but then it goes on to show widely different, half baked examples with poor explanations.
After reading other top level comments I agree with the others that this is probably AI slop. The only thing I achieved ny reading it was wasting a few minutes.
gspr · 20h ago
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.
concerned_user · 19h ago
Is that just sloppiness on their part or is it LLM chat bots being used with a prompt "hey give me current versions of these languages" without verifying the result?
mkl · 19h ago
LLMs have knowledge cutoffs...
xanth · 20h ago
Wait wat, why do they have the C# logo in the header?
jiggawatts · 20h ago
Which is especially ironic since they didn't test it, even though it's near the top of the TechEmpower leaderboard for precisely this kind of workload.
skinkestek · 19h ago
Seems like they didn't actually test anything just asked an AI to write about a test.
So many give aways (claiming older language versions are recent meaning we deal with a cut off date, the code samples, the explanations).
aredox · 20h ago
I would be vey interested with the same test with Ada - another langage used in high-reliability situations.
on_the_train · 20h ago
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
benmmurphy · 18h ago
you could have failures in unsafe regions you have written yourself to handle concurrency when under load. of course this begs the question why are you writing such unsafe code. i don't think such code would be idiomatic for an engineer with 5 years of rust experience to write. of course there is no links to the full code so its impossible to check the code.
rvz · 19h ago
> 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.
iLoveOncall · 20h ago
> 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.
masklinn · 20h ago
An Erlang process is a userland construct, but unlike “green threads” (e.g. goroutine, tasks, …) they have little to no shared memory, and the language is built around immutable values. Erlang’s “let it crash” philosophy is based around supervision trees, where a system is composed of a number of (erlang) processes, with “supervisors” overseeing worker processes, and worker crashes are automatically reported to the supervisors. As such it is common to do little to no error handling in workers, instead the worker crashes and the supervisor handles the error condition.
This is nothing you couldn’t do in other languages, but because the entire thing is built into the language and the runtime, and includes tooling to make structuring an application that way easier (“behaviours”), it’s very normal to build Erlang applications that way.
This further extends to entire machines.
serbuvlad · 20h ago
Processes are in Erlang terms are lightweight threads. So when a "process" crashes, that's not the whole system crashing.
GavinMcG · 20h ago
Learning a bit more than “absolutely nothing” about Erlang would make a conversation more productive. The Wikipedia page [0] has some material relevant to your question under the “‘Let it crash’ design philosophy” heading.
I think by crash they mean program stopping execution and being unable to continue, so by that metric Erlang didn't fully crash.
Erlang is designed with a mechanism that makes it easy for external processes to monitor for crashes (or hardware failures), rather than an in-process mechanism like exception handling used in many other programming languages.
Erlang was designed with the aim of improving the development of telephony applications.
The Erlang runtime system provides strict process isolation between Erlang processes (this includes data and garbage collection, separated individually by each Erlang process) and transparent communication between processes on different Erlang nodes (on different hosts).
The "let it crash" philosophy prefers that a process be completely restarted rather than trying to recover from a serious failure. Though it still requires handling of errors, this philosophy results in less code devoted to defensive programming where error-handling code is highly contextual and specific.
alpaca128 · 19h ago
The idea behind Erlang’s error handling is that completely avoiding crashes and errors is practically impossible, so the language is designed to gracefully handle crashing "processes" (lightweight threads) and restarting them instantly without the rest of the software being affected. It doesn’t mean the entire program crashes, in fact that’s what this approach prevents.
zweifuss · 20h ago
"but it literally does crash and restart"
No, think of it not as blue screening and reboot, but as a form of automatic error detection and handling. This keeps the system up and responsive, even if unrecoverable errors happen.
zmgsabst · 20h ago
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”.
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.
It's a worthless article anyway for the simple reason that there are no graphs, numbers, or reproducible experiments. The code snippets aren't the whole programs and the test harness setup isn't spelled out. The programs themselves look different in what they're doing, so they're not even equivalent! It's hard to tell because, for example, in some snippets the outermost loop is shown, but for C++ only the per-request "workload", but not all of it.
Even just the how of the testing can make a huge difference in my experience, especially when running synthetic workloads against garbage-collected languages. Most of them will never crash under normal workloads, but if you go out of your way to generate stupid amounts of memory allocations, practically none will be able to keep up.
The whole article is just nonsense, end-to-end, starting from the first content paragraph:
"Our test environment consisted of a cluster of 16 high-performance servers..."
Why a "cluster"? None of the workloads appear to be distributed or clustered applications! They're not testing Akka or Microsoft Orleans here, so why bother having more than one box?
What operating system was used?
What were the client systems? How many?
Were some of the languages "doing better" simply because they were slower at handling the test loads and hence failing slower?
Were the test clients correctly sending requests as fast as possible, or waiting sequentially for previous requests to complete before sending the next request?
Etc...
It seems like an ideological shitpost.
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".
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.
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.
It helps tremendously, that in Erlang functions are quite short, self contained due to functional nature. And you can grasp essence of function on one screen without need to have background knowledge of scattered mess of classes/global variables/other spaghetti.
Really pleasant for reading code.
But definitely not C inspired language.
[1] https://medium.com/@codeperfect
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.
Edit: though I agree with another top-level comment that the reported results are too vague and stereotypical to be believed.
I know, but then it goes on to show widely different, half baked examples with poor explanations.
After reading other top level comments I agree with the others that this is probably AI slop. The only thing I achieved ny reading it was wasting a few minutes.
> … 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.
So many give aways (claiming older language versions are recent meaning we deal with a cut off date, the code samples, the explanations).
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.
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.
This is nothing you couldn’t do in other languages, but because the entire thing is built into the language and the runtime, and includes tooling to make structuring an application that way easier (“behaviours”), it’s very normal to build Erlang applications that way.
This further extends to entire machines.
[0]https://en.m.wikipedia.org/wiki/Erlang_(programming_language...
Erlang is designed with a mechanism that makes it easy for external processes to monitor for crashes (or hardware failures), rather than an in-process mechanism like exception handling used in many other programming languages.
Erlang was designed with the aim of improving the development of telephony applications.
The Erlang runtime system provides strict process isolation between Erlang processes (this includes data and garbage collection, separated individually by each Erlang process) and transparent communication between processes on different Erlang nodes (on different hosts).
The "let it crash" philosophy prefers that a process be completely restarted rather than trying to recover from a serious failure. Though it still requires handling of errors, this philosophy results in less code devoted to defensive programming where error-handling code is highly contextual and specific.