4 ms·
While 'Let It Crash' is a philosophy, it is greatly aided in Erlang by extremely lightweight threads that communicate with each other via mailboxes.
by aprao 7y ago
While 'Let It Crash' is a philosophy, it is greatly aided in Erlang by extremely lightweight threads that communicate with each other via mailboxes.
- brudgers 7y agoIt'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.
- timClicks 7y agoAnd the supervisory tree that each process sits within.
- corysama 7y agoAnd, the fact that an Erlang server is explicitly intended for handling zillions of tiny, independent requests. A request fails? Meh. They'll call again if it's important. What matters now is the next tiny, independent request.
- mumblemumble 7y agoIt'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 7y agoJust 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
- rozap 7y agoOr ETL approach is all based on elixir (erlang) and it has some drawbacks, but ease of debugging is not one of them. No libraries, just code.
- mumblemumble 7y agoWe 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.
- tonyarkles 7y ago> a crappy day or even a crappy week Or a crappy discovery at the end of the quarter...
- dllthomas 7y agoOr crappy decisions.
- hopia 7y agoYeah and most importantly the OTP supervisors.