The Let It Crash Philosophy Outside Erlang
stratus3d.com
The Let It Crash Philosophy Outside Erlang
1–10 of 35 posts
Re: The Let It Crash Philosophy Outside Erlang
#2This 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.
Re: The Let It Crash Philosophy Outside Erlang
#3This 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.
[deleted]
Re: The Let It Crash Philosophy Outside Erlang
#4While 'Let It Crash' is a philosophy, it is greatly aided in Erlang by extremely lightweight threads that communicate with each other via mailboxes.
Re: The Let It Crash Philosophy Outside Erlang
#5"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...
Re: The Let It Crash Philosophy Outside Erlang
#6While 'Let It Crash' is a philosophy, it is greatly aided in Erlang by extremely lightweight threads that communicate with each other via mailboxes.
It's also viable because it's the convention. Library calls are likely to return {error, {the bad data you sent}} so it's easy to write receive {error, _) -> {missiles, {launch false}} end.
Re: The Let It Crash Philosophy Outside Erlang
#7While 'Let It Crash' is a philosophy, it is greatly aided in Erlang by extremely lightweight threads that communicate with each other via mailboxes.
And the supervisory tree that each process sits within.
Re: The Let It Crash Philosophy Outside Erlang
#8This 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.
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.
Re: The Let It Crash Philosophy Outside Erlang
#9This 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.
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.
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.
Re: The Let It Crash Philosophy Outside Erlang
#10While 'Let It Crash' is a philosophy, it is greatly aided in Erlang by extremely lightweight threads that communicate with each other via mailboxes.
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.