6 ms·
In most languages, the top words are self/this and function/def. On the other hand, in Go, the most common word is "err", and "if err != nil" are three of the t
by Noughmad 10y ago
In most languages, the top words are self/this and function/def. On the other hand, in Go, the most common word is "err", and "if err != nil" are three of the top four words. I really wonder how big part of the code in Go is just propagating errors.
- s_kilk 10y agoSame with many node apps. Every other statement is: if (err !== null) { return callback(err); }
- Klathmon 10y agoWith es2015+ this is no longer the case, it's back to good old try/catch statements if using async/await, and .catch(...) if using promises.
- grabcocque 10y agoOne day, maybe half a decade from now, Rob Pike will wake up from a nightmare and suddenly realise they got this one wrong. Maybe it'll occur at the same time as the generics one.
- fagnerbrack 10y ago"err". Because "error" is too hard to type, right?
- matthewmacleod 10y agoWell, `error` is the type, and `err` is the most common variable name. It's not so unusual, just convention!
- the_duke 10y agoAlso, it cuts the characters you have to type and read in halve, while not being obtuse. That's an odd thing to complain about.
- stirner 10y agoNo, because error variables have extremely limited scope and the length of a variable name should be proportional to its scope.
- kbart 10y agoHeh, I always use longer name variables for broader scope somewhat naturally, but only after reading your comment realized that.
- bryanrasmussen 10y agoI figure it's probably proportional to its importance and difficulty of understanding, as a longer more descriptive name aids in understanding, but things with broader scope tend to be more important.
- hyperpape 10y agoFrom which it follows that you should use the most terse names possible, in order to make it harder to write too-long functions. (I am only half trolling).
- deleted 10y ago[deleted]
- open-source-ux 10y agoI wonder the same thing about "elif" in Python. It's two extra characters to make it the more pleasant, readable "elseif". I don't understand why dropping those letters was felt necessary.
- uranusjr 10y agoA lot of older parts in Python inherit the naming style common in C, which always seems to me they have OCD to shorten everything, e.g. ls for list, mk for make. Newer Python parts are more “healthy” in this regard. But this also results in some wierd inconsistencies like mkdir vs makedirs.
- chei0iaV 10y agoC has else and if, not elif. I'm actually curious why in Python "else if" is a syntax error.
- deleted 10y ago[deleted]
- rebeccaskinner 10y agoThere are some was to make error handling much less annoying in go. Since error is just an interface it's pretty easy to make monadic constructs that can carry the error information and let you write pipelined code. IMHO it makes the code much cleaner and easier to read, but a lot of golang enthusiasts haven't really adopted the idea because it's quite different from the established idioms around error handling. Hard-core gophers love them some verbose and stupidly explicit code; but I'm hoping that as the language gets adoption in the wider community the voice of reason will win here.
- the_duke 10y agoInterfaces require casting and hurt performance, though. You could come up with `Either` types, but due to the lack of generic structs you'd have to have a whole lot of those. Interestingly, Rust has basically the same error handling idiom, but verbosity is considerably reduced by the '?' operator (previously the try! macro). When I was coding in Go, i would have loved that feature. The mind-numbing error checking in go is hugely annoying.
- tokenizerrr 10y ago> When I was coding in Go, i would have loved that feature. The mind-numbing error checking in go is hugely annoying. Ugh. Yes. I really want to love go. No, I really love go. But this is so annoying.
- woah 10y agoCould you link to some instructions?
- rebeccaskinner 10y agoI've been working on putting together an in-depth series of blog posts about it. I'm presenting on the topic of better error handing in go at the Agile Tech Conference this year, and I'd like to start getting everything in order soon- I'll probably post here on HN. In the short term I have a really rudimentary library I've put up here: https://github.com/asteris-llc/gofpher https://github.com/asteris-llc/gofpher and a presentation on it here https://github.com/rebeccaskinner/presentations/tree/master/golang_monads https://github.com/rebeccaskinner/presentations/tree/master/... (should build with pdflatex, I need to get an actual pdf built soon) Rob Pike has a blog post that looks at a similar, although ideologically different, approach to doing it: https://blog.golang.org/errors-are-values https://blog.golang.org/errors-are-values I think the latter is more go-ish, although also less generic than the monadic approach- it's also more in keeping with the ideology of go, but in practice I still never see it being used much in production code.
- z3t4 10y agoLetting errors surface is a good thing.
- keymone 10y agohaving 3 out of 4 lines in your codebase dedicated to letting errors surface is a bad thing.
- deleted 10y ago[deleted]
- literallycancer 10y ago3 out of 4 most common words are related to error handling. How does that imply 75% lines are error handling?
- keymone 10y agoerr := someOperation(args...) if err != nil { return err } that's 4 lines, 3 of them are error handling
- AsyncAwait 10y agoTo be honest, part of the reason for this is that in Go, 'self' is any name you see fit in the particular context, otherwise it may still be self.
- flgr 10y agoI was thinking about forking the language just so I could add a Maybe monad. I now typically deal with this via a Must() function that takes to values and return the non-err value or panics if there was an err. That means you can call it like con := Must(db.Connect(...)).(db.Connection)
- flgr 10y agoThis is not super-conventional, but some of the standard library uses panics in a similar way. I think as long as panics don't cross library boundaries you're fine. And panics can cross library functions if the function is called MustConnect(). (Which means it'd be neat to have a pre-processor that generated MustX from X if it wasn't already there...)
- oelmekki 10y agoThis made me smile as well. While I'm now used to it, I have troubles saying there's nothing wrong in having `err` a more common word than `if` :)