4 ms·
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 programm
by 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 agoThanks 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.
- jub0bs 2y agoOne data point showing that Pike's views can be and sometimes are controverted: https://www.youtube.com/watch?v=5uM6z7RnReE&t=18m https://www.youtube.com/watch?v=5uM6z7RnReE&t=18m
- 9rx 2y ago> 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. What makes you think that? The Go team is clearly working on trying to crack the nut. There is, as of about a month ago, even now an exploratory implementation: https://github.com/golang/go/discussions/71460 https://github.com/golang/go/discussions/71460 It is not an easy nut to crack. Many serious proposals have failed for good reasons. But it is abundantly apparent that the effort is there and ongoing. The "golang detractors" aren't acting rationally. If you watch carefully you will see that most of the time they don't even understand their detraction points, indicating that they are simply repeating what they saw elsewhere. The unfortunate reality is that they aren't looking to contribute anything meaningful, they are simply trying to be funny and they will continue to believe it is funny until "You idiot, Go already has that" can be said and manages to wear them down. > three lines of mostly-identical error handling around every function call is optimal To be fair, while I am sure we could do better, I am not sure we have found it yet. I do my programming in various languages with all these fanciful error handling semantics and it is not good. I regularly wish those languages' idioms had settled on something like if err != nil over what they ended up with. It is not great, but better than the rest. But it is encouraging that smart minds are working hard trying to find better.
- stouset 2y agoThe golang core team may be working to crack that nut, but right up until that happens the community mantra will be: what we have right now is perfect. When it’s released, this will shortly become: we always wanted something better, it was just a matter of finding what that would be. I’ve seen this happen enough times I’m quite confident that’s the case. The one exception to this trend has been generics. I think it was an inevitable addition to the language, but there are still a lot of holdouts who argue it wasn’t necessary. I think this is probably because it’s more important for library authors than app developers. But it does remain by far the most divisive update to the language. > The "golang detractors" aren't acting rationally. If you watch carefully you will see that most of the time they don't even understand their detraction points, indicating that they are simply repeating what they saw elsewhere. I personally don’t think I’ve seen a lot of that. At this point it’s endemic enough that there’s a small and shrinking number of engineers each year who haven’t spent time in it. > To be fair, while I am sure we could do better, I am not sure we have found it yet. Everything below here is a more or less reasonable take (even if I have mild disagreements), and I think a lot of people would feel less likely to snipe at the language if more people expressed opinions like this.