How “let it fail” leads to simpler code • Hacker News Board

Re: How “let it fail” leads to simpler code

#51

Post by beachy » Sun, Jul 17, 2022, 2:13 AM UTC

xdennis wrote: post #37

trav4225 wrote: post #5

I've seen a lot of new developers shocked by this approach, which surprises me a little. They seem to think that it's up to the application to handle all errors, even those of the programmer(s). This, of course, is unreasonable since it would essentially require knowing all the bugs in advance. :-)

I was on a team for a short while (Java programmers) and their frontend code was really overly "careful". For example, they would always check if a method existed, before calling it. var o = new SomeObject(); if (o.computeSomething != null && o.computeSomething != undefined) { o.computeSomething(...); } Their reasoning was that in JavaScript (with the old syntax) you just add functions to the prototype, so you could…

Sounds like hilarious passive aggressive behavior from java developers forced to interact with that devil's language JavaScript against their will.

Re: How “let it fail” leads to simpler code

#52

Post by teaearlgraycold » Sun, Jul 17, 2022, 2:17 AM UTC

anyfoo wrote: post #44

bzxcvbn wrote: post #38

Earlier quoted context omitted.

>Solutions and suggestions would be appreciated! Use a language with strong typing?

Yeah, that one is indeed obvious. That's what everyone advocating for static typing (which you mean, somebody commented already) has been shouting all the time. The problems coming from dynamic typing are just unnecessary, and the only thing that made python palpable for me again was mypy, which introduces static typing into python. But it's not the default, so it still only really works for small things.

IMO mypy is severely lacking compared to what TypeScript added to JavaScript. I'd always pick TS over Python given the choice.

Re: How “let it fail” leads to simpler code

#53

Post by glouwbug » Sun, Jul 17, 2022, 2:18 AM UTC

WalterBright wrote: post #45

I learned from working on aviation systems is that when a system enters an unknown state, it must be disabled and locked out. In software, this is known as an assertion failure. When the assert trips, the program is, by definition, in an unknown state. A program cannot reasonably be allowed to continue in an unknown state - it may launch nuclear missiles. The only thing to be done is exit directly, do not pass Go, do…

What if the plane is mid flight?

Re: How “let it fail” leads to simpler code

#54

Post by calvinmorrison » Sun, Jul 17, 2022, 2:22 AM UTC

TameAntelope wrote: post #23

smackeyacky wrote: post #12

I don't agree with this approach. Say you have a network service that relies on other network services. It is not difficult to write those such that they know to back off / retry when something disappears. It's extremely useful in a lot of situations: if you do work on a laptop that gets regularly unplugged, having running test services that know to reconnect makes your life easier. In production, having things autom…

What you're describing are "known" states; the idea behind "let it fail" is that you shouldn't write code that exhaustively handles every single potential outcome, just the ones that are part of your code's path in general use. Definitely write code to handle network issues. Don't write code to handle random bitflips, ways to handle garbage coming back from the service you're connecting to, or try to handle OOM error…

One of the best protocol family is email protocols! It says - call back later, the line is down, give me an hour. Eventual consistency is better than failed calls.

When my email went down last week, I wasn't worried. Eventually all messages would arrive.

I like that system.

Re: How “let it fail” leads to simpler code

#55

Post by winter_blue » Sun, Jul 17, 2022, 2:22 AM UTC

In a new language, I'd like to see exceptions being allowed in pure code, but prohibited in non-pure code. (Non-pure here meaning code with side effects.)

In pure code, an exception could essentially be passed up, and transformed into an error return value at the point where it's called by non-pure code.

Re: How “let it fail” leads to simpler code

#56

Post by stu2b50 » Sun, Jul 17, 2022, 2:27 AM UTC

sergiotapia wrote: post #3

For our liveview project, a lot of the bugs we find are edge cases in the pattern match. We find the bug in appsignal, build another arity match and go on with our day. It's pretty cool. I've been working in Elixir exclusively since 2016. I do think a lot of the Let It Fail is just marketing from Elixir (and BEAM) but there is a lot of truth in it. In reality you will most definitely not write everything under an exp…

> In reality you will most definitely not write everything under an explicit supervisor.

That's the point of the supervisor _tree_. Certainly not every process will have its own supervisor, but all processes should be linked to other processes, which are linked to other processors, and at some point you have a process that is quite fundamental to the application and has a supervisor.

As long as there's a supervisor somewhere on that tree, the whole subtree will be restarted, hopefully in a non-erroneous state, and the application will continue on its merry way.

Re: How “let it fail” leads to simpler code

#57

Post by bzxcvbn » Sun, Jul 17, 2022, 2:29 AM UTC

aunderscored wrote: post #40

bzxcvbn wrote: post #38

Earlier quoted context omitted.

>Solutions and suggestions would be appreciated! Use a language with strong typing?

Python is strongly typed. You want statically typed. (Instead of duck typed / dynamically typed)

Can you guess what this code does?

    class foo:
        pass
    
    obj = foo()
    obj.bar = "I thought Python was strongly typed?"
    print(obj.bar)

And even better:

    class foo:
        a = 42
    obj = foo()
    print(obj.a)
    del foo.a
    print(obj.a)

Whatever your opinion on what the imprecise sentence "strongly typed language" should mean, these are definitely not features of one.

Re: How “let it fail” leads to simpler code

#58

Post by bicx » Sun, Jul 17, 2022, 2:29 AM UTC

glouwbug wrote: post #53

WalterBright wrote: post #45

I learned from working on aviation systems is that when a system enters an unknown state, it must be disabled and locked out. In software, this is known as an assertion failure. When the assert trips, the program is, by definition, in an unknown state. A program cannot reasonably be allowed to continue in an unknown state - it may launch nuclear missiles. The only thing to be done is exit directly, do not pass Go, do…

What if the plane is mid flight?

It won’t be in mid-flight for much longer.

Re: How “let it fail” leads to simpler code

#59

Post by bee_rider » Sun, Jul 17, 2022, 2:31 AM UTC

xdennis wrote: post #37

trav4225 wrote: post #5

I've seen a lot of new developers shocked by this approach, which surprises me a little. They seem to think that it's up to the application to handle all errors, even those of the programmer(s). This, of course, is unreasonable since it would essentially require knowing all the bugs in advance. :-)

I was on a team for a short while (Java programmers) and their frontend code was really overly "careful". For example, they would always check if a method existed, before calling it. var o = new SomeObject(); if (o.computeSomething != null && o.computeSomething != undefined) { o.computeSomething(...); } Their reasoning was that in JavaScript (with the old syntax) you just add functions to the prototype, so you could…

I set tabwidth to 3 in my editor. I like the way it looks. But of course the whole point of tabs is that nobody else has to suffer for my esoteric choice.

It also helped when tutoring new python students -- when they mixed space-indented code they copied from the internet with tab-indented code they copied from the internet, they'd get all sorts of fun errors. Setting the tabwidth to an even number sometimes allows them to hide. 3, though, really makes them stick out.

Re: How “let it fail” leads to simpler code

#60

Post by bogdanoff_2 » Sun, Jul 17, 2022, 2:33 AM UTC

aunderscored wrote: post #40

bzxcvbn wrote: post #38

Earlier quoted context omitted.

>Solutions and suggestions would be appreciated! Use a language with strong typing?

Python is strongly typed. You want statically typed. (Instead of duck typed / dynamically typed)

Well, it's not very strongly typed if you use dicts with default values for everything.