I do wonder what he was imagining that would look like, given go has basically no ways to abstract over control flow. (rust, meanwhile, had macros, and people

I do wonder what he was imagining that would look like, given go has basically no ways to abstract over control flow. (rust, meanwhile, had macros, and people settled on the try! macro fairly quickly, which is basically just bundling up 'if err != nil' into a smaller package, and that eventually turned into '?' because try! was still a bit too unwieldy. Go doesn't have an way to do the same) addendum: Having read the blog post, it seems like it's basically arguing for interfaces which essentially buffer error reporting. I've written code that works like this before, and it doesn't really deal with control flow well at all: it's basically only a solution for the case of having a straight-line set of function calls, and some interfaces are commonly used like this, but it's only a fraction of them and you introduce more likelihood of errors if you then try to use them in more complicated situations (imagine his proposed option but you want to make a decision based on a value in the middle, or run a loop. It either stops working entirely or you have to decide on a 'safe' fake default value to return in the case of an error fall-through that doesn't break the logic, which is usually impossible.