6 ms·

I'm sure your software is great, and I don't mean this personally, but I just find this philosophy really strange. You don't write defensive code, and you don't

I'm sure your software is great, and I don't mean this personally, but I just find this philosophy really strange. You don't write defensive code, and you don't often check for errors. You just let pieces of your application fail, and feel that this is OK because the overall application continues on. IMHO, Elixir isn't "saving" you from "transient heisenbugs", it's encouraging you not worry about them, which means that they will proliferate.

sph 3y ago
How can I ever defend my position of lead engineer responsible for these systems, when someone on the Internet, that has never seen my code running, is adamant my systems are unstable and lousy with bugs. Trying to continue this conversation is a waste of our time. Feel free not to use Elixir.
- munchler 3y ago
  Again, I'm sure your code is great, and I'm not asking you to defend anything. I'm simply responding to the stated philosophy in the linked article.
  - sph 3y ago
    The "let it crash" is a sound and proven design philosophy, but it would be easier to grok if you were to spend time learning the platform, rather than comparing it in a vacuum with the things you already know. It is quite frustrating when someone has already decided something they don't know is dumb or makes no sense. It is more plausible the unknown unknowns are blinding your judgement, than Erlang and Elixir developers worldwide suffering a collective hallucination, is it not?
    - langfan 3y ago
      Yes. munchler, see: Empty your cup. https://wiki.c2.com/?EmptyYourCup https://wiki.c2.com/?EmptyYourCup
sb8244 3y ago
I'm an Elixirist, love the idea of "let it crash", and I still code defensively. To me these phrases are more about the guarantees—if it does crash it recovers—and less about dogmatic advice that everyone follows. But there's time and place for different levels of defensive programs. I get to pick and choose based on where I see risk, but I know the whole app isn't going to blow up if I missed something.
linkdd 3y ago
The "let it crash" philosophy has a misleading name. It's not "don't handle errors", but it's "delegate the error handling to a component dedicated to this". With OTP, you have what we call a "supervision tree". Your software is divided into components (erlang processes) and organized in a tree where the leafs are your components, and the nodes are the "supervisors" which will catch the error, and restart/retry the operation. What's the result? Imagine you have a component that is polling data from the database and then sending a message to another component based on that data. For a split second: - there is a network error - you lose the connection to the database - the component crashes - its supervisor notice the crash, restart the process If the network error was temporary, everything goes back to normal, and your system did not stop for a temporary network error. And your component does not need to have "retry code" (it is delegated to the parent supervisor). If the network error was not temporary, the parent supervisor will notice that the component crashes far too often, and will decide to crash as a result. Letting the parent supervisor of the supervisor deal with the problem. In Erlang/Elixir, processes can "monitor" other processes. They will receive a message when the target processes dies (normally, or abnormally). This allows you to delegate the error handling so yes, you write less defensive code, because that code is located in a dedicated component that will be notified automatically.
throwawaymaths 3y ago
> You don't write defensive code, and you don't often check for errors. There is a limit to how defensive you can make your code. As soon as you call out to another service for data, the universe of errorinf situations they can create goes to infinity. For example they could happily send you a 200 but return mistyped JSON. What do you do in that case? Are you genuinely going to write that as a test condition to make sure the transactional chain in your system handles this and rolls back the db inserts that preceded it? I can tell you that in 99% of cases idiomatically written elixir will "do the right thing" if this happens, and that is a consequence of "let it fail" philosophy. Moreover, if you try to write error handling code in the traditional sense, you will probably get it wrong, it will be hard to understand, and it will be hard to debug if your implementation is not quite right.

sph 3y ago

How can I ever defend my position of lead engineer responsible for these systems, when someone on the Internet, that has never seen my code running, is adamant my systems are unstable and lousy with bugs. Trying to continue this conversation is a waste of our time. Feel free not to use Elixir.

munchler 3y ago
Again, I'm sure your code is great, and I'm not asking you to defend anything. I'm simply responding to the stated philosophy in the linked article.
- sph 3y ago
  The "let it crash" is a sound and proven design philosophy, but it would be easier to grok if you were to spend time learning the platform, rather than comparing it in a vacuum with the things you already know. It is quite frustrating when someone has already decided something they don't know is dumb or makes no sense. It is more plausible the unknown unknowns are blinding your judgement, than Erlang and Elixir developers worldwide suffering a collective hallucination, is it not?
  - langfan 3y ago
    Yes. munchler, see: Empty your cup. https://wiki.c2.com/?EmptyYourCup https://wiki.c2.com/?EmptyYourCup

sb8244 3y ago

I'm an Elixirist, love the idea of "let it crash", and I still code defensively. To me these phrases are more about the guarantees—if it does crash it recovers—and less about dogmatic advice that everyone follows. But there's time and place for different levels of defensive programs. I get to pick and choose based on where I see risk, but I know the whole app isn't going to blow up if I missed something.

linkdd 3y ago

The "let it crash" philosophy has a misleading name. It's not "don't handle errors", but it's "delegate the error handling to a component dedicated to this". With OTP, you have what we call a "supervision tree". Your software is divided into components (erlang processes) and organized in a tree where the leafs are your components, and the nodes are the "supervisors" which will catch the error, and restart/retry the operation. What's the result? Imagine you have a component that is polling data from the database and then sending a message to another component based on that data. For a split second: - there is a network error - you lose the connection to the database - the component crashes - its supervisor notice the crash, restart the process If the network error was temporary, everything goes back to normal, and your system did not stop for a temporary network error. And your component does not need to have "retry code" (it is delegated to the parent supervisor). If the network error was not temporary, the parent supervisor will notice that the component crashes far too often, and will decide to crash as a result. Letting the parent supervisor of the supervisor deal with the problem. In Erlang/Elixir, processes can "monitor" other processes. They will receive a message when the target processes dies (normally, or abnormally). This allows you to delegate the error handling so yes, you write less defensive code, because that code is located in a dedicated component that will be notified automatically.

throwawaymaths 3y ago

> You don't write defensive code, and you don't often check for errors. There is a limit to how defensive you can make your code. As soon as you call out to another service for data, the universe of errorinf situations they can create goes to infinity. For example they could happily send you a 200 but return mistyped JSON. What do you do in that case? Are you genuinely going to write that as a test condition to make sure the transactional chain in your system handles this and rolls back the db inserts that preceded it? I can tell you that in 99% of cases idiomatically written elixir will "do the right thing" if this happens, and that is a consequence of "let it fail" philosophy. Moreover, if you try to write error handling code in the traditional sense, you will probably get it wrong, it will be hard to understand, and it will be hard to debug if your implementation is not quite right.