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

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

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

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.

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.

That profile picture appears on dozens of websites under different names lol.

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.

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?

LLMs have knowledge cutoffs...

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.

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.

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.

Processes are in Erlang terms are lightweight threads. So when a "process" crashes, that's not the whole system crashing.

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.

[0]https://en.m.wikipedia.org/wiki/Erlang_(programming_language...

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.

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.

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

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