6 ms·
The claim that Go 'forces people to be pragmatic' applies a pretty strong value judgement to the way things Go does. You could say "Go forces people do things t
by vgatherps 5y ago
The claim that Go 'forces people to be pragmatic' applies a pretty strong value judgement to the way things Go does. You could say "Go forces people do things the way Go wants and this way is wonderful for many use cases" (I don't disagree), but whether that way is pragmatic or not depends on the use case.
- threeseed 5y agoThere is nothing pragmatic about Go's approach to error handling. It's the equivalent of putting your head in the sand and pretending nothing else in the world exists.
- politician 5y agoProgramming is much more about understanding guarantees and curating the error path than it is about pulling a ticket from Jira and cranking out a happy path as agilely as you can. Error handling in other languages is like confetti. “Pop! Surprise!” A disorganized game of “52 pickup” using an under designed grab bag of control structures. No thanks.
- rsj_hn 5y agoLack of adequate control structures, or for that matter, programming language support, is almost never the reason why code has inadequate error handling. The main reason is that developers often leave error handling as an afterthought because it distracts them from thinking about the main flow, and it's hard to program when you are constantly distracted. That's why you have overbroad exception handling and the consequent improper handling. The problem is with the brain, not with the programming language.
- preseinger 5y ago> developers often leave error handling as an afterthought because it distracts them from thinking about the main flow Go asserts that "error handling" and "main flow" (a.k.a. "happy path") code paths are equivalent, and that you can't ignore the bad stuff as you program against the good stuff. Error handling _cannot be_ an afterthought -- this is the path to fragile, even broken, code. If a programmer can't adapt to this model, then they're gonna have a bad time with Go, because with Go it's non-optional!
- plorkyeran 5y agoNo, it really doesn't do that. Result types which force you to check for an error to get the non-error return value from a function, or Swift `try` which doesn't even let you call a function which may fail without writing some sort of error handling do that. Go leaves it up to the programmer to remember to check for errors, and lets you silently discard the error result.
- preseinger 5y ago> No, it really doesn't do that. Result types which force you to check for an error to get the non-error return value from a function, or Swift `try` which doesn't even let you call a function which may fail without writing some sort of error handling do that. Go leaves it up to the programmer to remember to check for errors, and lets you silently discard the error result. The compiler is one way that language invariants can be expressed and enforced. But it's not the only one -- another "layer" is convention and code review. Concretely, something like v, _ := f(...) would _never_ pass code review at any reasonable organization. If you use the compiler to express invariants like this, then the language unavoidably becomes more complex. In some contexts, that makes sense! In others, it doesn't.
- djur 5y agoRelying on "convention and code review" is still leaving it up to the programmer(s).
- preseinger 5y agoOf course! But software engineering in the large -- which is the domain that Go targets -- is ultimately not a technical domain, but a social one; the programmers who maintain the project are the ultimate authority. That's fine!
- super_flanker 5y agoDidn't you just claim: > Go asserts that "error handling" and "main flow" (a.k.a. "happy path") code paths are equivalent, and that you can't ignore the bad stuff as you program against the good stuff. But it seems the go relies on a good code reviewer for error handling.
- mcronce 5y agoIt sounds like you're referring to exceptions. While I would take exceptions over the stringly-typed nightmare that is Go errors, you should know that there are far better error handling schemes out there.
- jeremyloy_wt 5y agoGo errors are not stringly typed. You can assert that the error itself, or any error it wraps, is it a particular type through errors.Is and As. If your past experience involved people comparing error.Error() strings I’m sorry. That’s awful and I can see why that would be a nightmare
- preseinger 5y agoGo asserts that errors are the same as any other type of value, and don't deserve special accommodation at the language level. There's nothing objectively bad or wrong about this position.