21–30 of 35 posts
While '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.
Earlier quoted context omitted.
Yes, you tell those people the software is "self healing".
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 .
Earlier quoted context omitted.
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.
> a crappy day or even a crappy week Or a crappy discovery at the end of the quarter...
Earlier quoted context omitted.
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.
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
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.
Earlier quoted context omitted.
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 a…
Earlier quoted context omitted.
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 a…
Failing silently makes sense in a language like C, where performance is a high priority and you can avoid adding assertions for performance. But JavaScript has to add an assertion to return an undefined value anyway, so you're not even getting a performance benefit from it. It's purely bad design with no benefit.
Earlier quoted context omitted.
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 a…
Maybe people who are used to js take advantage of this and do it on purpose, but from my perspective all it's done is take mistakes and move the errors farther downstream so that you can't trivially find where the problem started.
If I wanted a function to accept a variable number of parameters or have default values for a parameter that can be omitted, I would much rather have to have to define that behavior per function.
Earlier quoted context omitted.
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.
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