5 ms·
This is great news. I really like how errors are handled in Go and I hated this proposal. The current implementation forces you to constantly think about erro
by unixsheikh 7y ago
This is great news.
I really like how errors are handled in Go and I hated this proposal.
The current implementation forces you to constantly think about errors at each single point and it is extremely good at standing out. This is something very valuable, not something that requires or needs to be hidden behind syntactic sugar. It improves the readability of the code and the quality of the software.
If it ain't broke, don't fix it.
- pcwalton 7y agoGo does not force you to think about errors at every single point. If a function returns only an error (such as, for example, os.Mkdir), the language will happily let you drop the error on the floor.
- gjs278 7y agoyou still had to think about it when you decided to drop it to the floor by putting the _ saying "I acknowledge there was an error, but I don't care"
- matthewbauer 7y agoThis is underappreciated! I suppose you are less likely to care about errors if you aren't getting values from a function, but not always. I wonder if there is a proposal to force this case to be handled, like Haskell's -Wunused-do-bind?
- matthewbauer 7y agoFound it: https://github.com/golang/go/issues/20803 https://github.com/golang/go/issues/20803
- pcwalton 7y agoThere's go vet. But it's inconsistent with the Go warnings-are-errors philosophy. Ignoring the return value of os.Mkdir() is far more likely to be a bug than an unused import is.
- bmurphy1976 7y agoAnd that's totally fine. I don't always want to be fighting with monads. If I did I'd write Haskell code. Go is the quick and dirty git-er-done tool that provides quite a bit more performance and type safety than Python, but maintains some of the development speed/ergonomics. Here's the thing, some of us don't want Rust. It looks great! It's perfectly awesome for it's primary domain (i.e. re-implementing critical portions of a modern browser). But it's not what I want to use as my daily driver. I'm writing stupid shit that's munging CSV files and transforming json documents. I want a language that mostly gets out of my way, but performs well and can scale beyond a couple thousand lines of code. Go fits that space nicely, even with its (or maybe because of) conceptually imperfect error handling.
- UK-AL 7y agoIn rust though, you dont have to handle errors all the time. You can just unwrap them, and crash when there's an error.
- bmurphy1976 7y agoIt's not just that though, GC is also a big part of the equation. I stopped manually managing memory 20 years ago. I'm not interested in going back to that. I get that certain aspects of Rust make that easier (and certainly safer) but I'm not working in a domain where the performance gains of ditching GC matter.
- jzoch 7y agoYou are hardly managing memory in rust...reference allocation is practically garbage collection and feels as such in rust.
- 0815test 7y agoReference allocation _is_ essentially equivalent to garbage collection, the one thing it doesn't deal with correctly is reference cycles. Which are inherently unlikely if you spend the time and effort to organize your code properly. (The Rust community is also working on cycle-aware reference collection, e.g. https://github.com/lopopolo/ferrocarril/blob/master/cactusref/README.md https://github.com/lopopolo/ferrocarril/blob/master/cactusre... but this will always come with some drawbacks.)
- closeparen 7y agoTyping “if err != nil { return nil, err }” a million times is not thought.
- ummonk 7y agoYes, this is exactly what I've observed in practice with Go.
- AsyncAwait 7y agoTo be fair, any decent editor will expand 'er' to that, no need to type it manually.
- deleted 7y ago[deleted]
- pjmlp 7y agoSo a typical criticism of Java and IDE dependency becomes a non-issue when talking about Go's shortcomings.
- AsyncAwait 7y agoEh, if you consider optional macro expansion an 'IDE' feature, (even gedit can do it), I guess.