
The Let It Crash Philosophy Outside Erlang - Stratus3D
https://stratus3d.com/blog/2020/01/20/applying-the-let-it-crash-philosophy-outside-erlang/
======
kerkeslager
This is my biggest criticism of JavaScript: it fails silently quite often.
`{}.foo` returning `undefined` is the most common culprit, but there are many
other possible causes.

Django templates also do this, which causes all sorts of debugging problems.

~~~
whatsmyusername
The worst part about javascript failing is a lot of time it doesn't do it at
the thing that is the problem.

I've run into a lot of cases in node where I passed something not quite right
to a crypt library but didn't find out until like 2 pages later. Usually for
things that in python would throw an exception immediately.

~~~
Jtsummers
That's not really a Javascript problem. That's a dynamically typed language
problem. Unless you add some kind of assertion/test at the entry point to a
library, the failure will always be postponed to the point of use (or silent
if it's never used, until the day someone turns a feature on). If the same
sort of issue works differently in Python, the Python library has asserts or
other tests, or is using the value at an earlier point so it's more easily
discovered.

~~~
dahfizz
JavaScript is absolutely the problem.

As pointed out, {}.foo will not cause an error. In Python and any good dynamic
language, that will generate an error.

Another problem is all the implicit (silent) type conversions. JavaScript will
happily add an Object and an integer, then multiply that by a string. Any
sensible type system would not allow that, but JavaScript silently produces a
NaN.

The problem isn't that its a dynamic type system, but that the type system
ignores things which are clearly problems.

------
aprao
While 'Let It Crash' is a philosophy, it is greatly aided in Erlang by
extremely lightweight threads that communicate with each other via mailboxes.

~~~
mumblemumble
It's helpful in other domains, too.

For example, in ETL pipelines, I would greatly prefer to have an entire DAG go
down quickly and noisily than to risk having it generate incorrect data. It's
the difference between a crappy morning, and a crappy day or even a crappy
week.

~~~
alexchantavy
Just curious since a lot of my work is on an ETL - what are your favorite DAG
libraries/approaches? Some of my ETL workflows can run in parallel with each
other because there aren't data dependencies between them, and others should
definitely crash loudly

~~~
mumblemumble
We use a home-grown solution, and try to keep it pretty minimal. For example,
we can run all our pipeline steps serially and still get all the work done
plenty fast, so, for now, we're keeping that parallelism can of worms firmly
shut.

------
gpderetta
"I don’t think Let It Crash is a good name for the philosophy Erlang has about
handling faults"

This is also known as "Crash-Only software" [1]. I'm a huge fan.

[1] [https://www.usenix.org/conference/hotos-ix/crash-only-
softwa...](https://www.usenix.org/conference/hotos-ix/crash-only-software)

~~~
davidw
What he might be getting at, that others have certainly discussed, is that
things like "crash only software!" are not winning marketing slogans when
trying to sell a piece of technology to higher-ups in your company.

~~~
echlebek
Yes, you tell those people the software is "self healing".

~~~
perl4ever
It reminds me of how people _love_ , for marketing purposes, to have
technology, say in vehicles, that is "adaptive". In software in general, but
particularly in cars, there is nothing I hate more. Because "adaptive" makes
people think of a partner that anticipates your needs, but it can't do that,
_not being intelligent_ so adaptive ends up being the _opposite of
responsive_.

~~~
NortySpock
"unexpected acceleration" in cars comes to mind.

~~~
perl4ever
I was more in mind of steering and transmission algorithms.

------
waynesonfire
i'm a huge fan of erlang and i'm familiar w/ this philosophy and tend to have
a hard time w/ applying it. when i develop software, i read man pages for the
functions i call. i intently study their return values and do my best to
address whatever conditions i can at that moment. if i'm unable to handle the
fault, i generate a message with the intent to add context to the error and
let it bubble up. that context is important. it's _very_ beneficial when a
failure does occur because i can quickly ascertain the root cause due to my
diligence in annotating the _BAD_ path with context--all the way to the top of
the function stack.

i've noticed that when erlang programs crash, the error message and stack
trace is a WTF moment. i hate that. so yes, there are all these benefits when
focusing on the happy path, but there are down sides, can we explorer those?
once software is written, it's how the _BAD_ path is presented to maintainers
that matters. this philosophy, in my current understanding, throws those
people under the bus.

------
mlatu
I like the Let-the-user-handle-it approach from CL.

