Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

freedium.cfd

Post reply on HN
Print view View original

11–20 of 37 posts

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

#11

Post by kqr »

skinkestek wrote: post #2

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.

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

#12

Post by GavinMcG »

iLoveOncall wrote: post #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 singl…

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

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

#14

Post by zweifuss »

iLoveOncall wrote: post #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 singl…

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

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

#15

Post by masklinn »

iLoveOncall wrote: post #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 singl…

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.

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

#16

Post by lifthrasiir »

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

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

#17

Post by tomtomtom777 »

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.

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

#19

Post by concerned_user »

iLoveOncall wrote: post #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 singl…

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.

Post reply on HN