21–30 of 37 posts
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.
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.
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.
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 "la…
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.
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.
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.
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 "la…
> 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…
Wait wat, why do they have the C# logo in the header?
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.
So many give aways (claiming older language versions are recent meaning we deal with a cut off date, the code samples, the explanations).
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 a…
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...
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".