5 ms·

I remember when Rob Pike wrote an essay insisting that `if err != nil` isn’t all that common and golang programmers clearly would wrap that logic in more fluid

I remember when Rob Pike wrote an essay insisting that `if err != nil` isn’t all that common and golang programmers clearly would wrap that logic in more fluid interfaces which would prevent the redundant boilerplate.

DangitBobby 2y ago
https://go.dev/blog/errors-are-values https://go.dev/blog/errors-are-values
- the_gipsy 2y ago
  This reads like satire!
  - stouset 2y ago
    I’ll be honest, having been involved off and on with golang over 10+ years, I constantly feel like I’m being gaslit. It’s fine that golang has made missteps along the way and course corrects. Or if people realize that some hoped-for development doesn’t come to pass, but the current state of things is acceptable. But the number of times it feels like we’re just told things were always this way, or this was always the goal, or actually having 2/3s of the language being redundant boilerplate is a good thing (it’s “explicit”), or actually they always intended to have generics because it’s important for library authors, or actually systems programming always meant small network services, or actually abstraction is bad unless it’s coincidentally the exact level of abstraction that golang ended up with, or… on and on and on. It’s exhausting and it’s not a good look on the community.
    - mlvljr 2y ago
      [dead]
    - jub0bs 2y ago
      > actually they always intended to have generics There was a time when generics were not even on the table. I'm pretty sure I remember an old talk by Rob Pike where he says that much. People can change their mind as they learn more about the problem space; that should be tolerable.
  - throwaway2037 2y ago
    No trolling here: I am not a Golang programmer. Can you explain more?
    - stouset 2y ago
      This shows that ten years ago even the guy who invented the language thought error handling wasn’t in a good state and that it was expected that golang programmers would find elegant ways to build on top of the primitives provided. No such development has occurred. The state of the art remains three lines of boilerplate around most function calls in practice. And honestly, if the mindset was: hey, you know what, this isn’t great but it’s what we’ve ended up with, it isn’t the end of the world, and maybe we’ll crack the nut and improve things down the line… I think a lot of golang’s detractors would nod and everyone would move on. Instead, everyone clings to: three lines of mostly-identical error handling around every function call is optimal, I prefer it this way, all of this extra code is “explicit” so it’s an inviolable good, we’ve always been at war with Eastasia. As someone who is more than happy to point out all the things that annoy me about the languages I prefer to use, it feels at times like entire community wants to pretend that there aren’t any flaws or downsides with the language.
      - throwaway2037 2y ago
        Thanks for the detailed follow-up. I now understand very well what you meant. > it feels at times like entire community wants to pretend that there aren’t any flaws or downsides with the language. Yeah, the delusion of version 2.0 perfection is strong from Golang thought leaders. It is nauseating to read about. Like the whole resistance to generics, then finally giving in, then finally saying "Yeah, we definitely need these." So... the last 8(?) years of blogging against generics... what about that? Another comment below used the phrase "gas-lighting the users" which seems appropriate here. Deeper: This will be controversial to some readers here. I wonder if the reason why the "entire community" resists criticism so fiercely is that Rob Pike has a very public profile and "infinite Internet (reputation) points", so no one can beat that final boss. I'm not saying that Rob Pike would use his Internet boss powers to kill off any critics, but I do think it does repress some critics. Also, his style and opinions are very strong. All said, as a non-Golang writer, but avid reader, I am still very impressed by how carefully that Golang was developed. It could have gone so much worse (C++? JavaScript?), or the community been much more toxic/unwelcoming, e.g., Rust. Overall: It is a huge win for current and future programmers.
rcxdude 2y ago
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.

DangitBobby 2y ago

https://go.dev/blog/errors-are-values https://go.dev/blog/errors-are-values

the_gipsy 2y ago
This reads like satire!
- stouset 2y ago
  I’ll be honest, having been involved off and on with golang over 10+ years, I constantly feel like I’m being gaslit. It’s fine that golang has made missteps along the way and course corrects. Or if people realize that some hoped-for development doesn’t come to pass, but the current state of things is acceptable. But the number of times it feels like we’re just told things were always this way, or this was always the goal, or actually having 2/3s of the language being redundant boilerplate is a good thing (it’s “explicit”), or actually they always intended to have generics because it’s important for library authors, or actually systems programming always meant small network services, or actually abstraction is bad unless it’s coincidentally the exact level of abstraction that golang ended up with, or… on and on and on. It’s exhausting and it’s not a good look on the community.
  - mlvljr 2y ago
    [dead]
  - jub0bs 2y ago
    > actually they always intended to have generics There was a time when generics were not even on the table. I'm pretty sure I remember an old talk by Rob Pike where he says that much. People can change their mind as they learn more about the problem space; that should be tolerable.
- throwaway2037 2y ago
  No trolling here: I am not a Golang programmer. Can you explain more?
  - stouset 2y ago
    This shows that ten years ago even the guy who invented the language thought error handling wasn’t in a good state and that it was expected that golang programmers would find elegant ways to build on top of the primitives provided. No such development has occurred. The state of the art remains three lines of boilerplate around most function calls in practice. And honestly, if the mindset was: hey, you know what, this isn’t great but it’s what we’ve ended up with, it isn’t the end of the world, and maybe we’ll crack the nut and improve things down the line… I think a lot of golang’s detractors would nod and everyone would move on. Instead, everyone clings to: three lines of mostly-identical error handling around every function call is optimal, I prefer it this way, all of this extra code is “explicit” so it’s an inviolable good, we’ve always been at war with Eastasia. As someone who is more than happy to point out all the things that annoy me about the languages I prefer to use, it feels at times like entire community wants to pretend that there aren’t any flaws or downsides with the language.
    - throwaway2037 2y ago
      Thanks for the detailed follow-up. I now understand very well what you meant. > it feels at times like entire community wants to pretend that there aren’t any flaws or downsides with the language. Yeah, the delusion of version 2.0 perfection is strong from Golang thought leaders. It is nauseating to read about. Like the whole resistance to generics, then finally giving in, then finally saying "Yeah, we definitely need these." So... the last 8(?) years of blogging against generics... what about that? Another comment below used the phrase "gas-lighting the users" which seems appropriate here. Deeper: This will be controversial to some readers here. I wonder if the reason why the "entire community" resists criticism so fiercely is that Rob Pike has a very public profile and "infinite Internet (reputation) points", so no one can beat that final boss. I'm not saying that Rob Pike would use his Internet boss powers to kill off any critics, but I do think it does repress some critics. Also, his style and opinions are very strong. All said, as a non-Golang writer, but avid reader, I am still very impressed by how carefully that Golang was developed. It could have gone so much worse (C++? JavaScript?), or the community been much more toxic/unwelcoming, e.g., Rust. Overall: It is a huge win for current and future programmers.

rcxdude 2y ago

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.