7 ms·
When in Go, do as Gophers do
- sanswork 12y agoI've never known a language with so much discussion on why what you are doing isn't idiomatic as Go. I'm enjoying using Go for the few small services I'm using it for but it seems that a language which has to constantly fight it's users to reinforce what it considers idiomatic has some core issues.
- bsaul 12y agothis is especially true for everything related to error handling. I've never had to deal with a java codebase where exception were causing problems, but golang made me feel worrying about it from day 1. I really think they made the language a little bit too small.
- brian_herman 12y agoI think small is a good thing in languages for example the C programming language is very simple in the language but very powerful. Simplify Simplify Simplify.
- mratzloff 12y agoIf you have only worked in languages with exceptions, it's not surprising that you would struggle with Go's C-style error handling. I've grown to prefer it, as exception handling typically boils down to "not my problem" in most code bases. Go forces you to think through each error condition, which is an unusual amount of effort for people who may not be accustomed to it.
- masklinn 12y agoGo's error handling remains verbose, unsafe and error-prone compared to more modern languages which use return values for error signaling (Erlang, MLs, Haskell, Rust). The problem is not that Go's error handling requires more thinking or efforts, it's that it is bad, and while that's an improvement from C's terrible error handling it's still nowhere near good enough, let alone good (unless you consider C's error handling to be good enough in the first place).
- gorhill 12y ago> more modern languages which use return values for error signaling I must be missing something.. Returning a value in Go for error signaling is the way to signal errors in Go.
- masklinn 12y ago> I must be missing something.. Returning a value in Go for error signaling is the way to signal errors in Go. Yes? That's the point, I'm comparing it to more modern languages which signal error "the same way", by opposition to languages implementing different high-level methods of error signaling. The clause is there to explicitly point out that I'm not considering or talking about exceptions and conditions-based error signaling. Maybe it'd have been clearer if I'd written "languages which also use return values"?
- lazzlazzlazz 12y agoYeah, I parsed this incorrectly as well. It was an ambiguous statement. You posted a while back that "scope inference (in Python) sucks". Could you expand on that. I know it's totally unrelated to this thread but I was really hoping to understand what you meant. Thanks!
- 4ydx 12y agoFeel free to enlighten us specifically about how they are better.
- myg204 12y ago> I've never known a language with so much discussion on why what you are doing isn't idiomatic as Go. Python is another language where there is a lot of talk about idiomatic code ('Pythonic'). C++11 and C++14 also have a lot of idiomatic discussion since the community's trying to move to a different style with the latest enhancements. Not sure if this is a signal of core issues.
- steveklabnik 12y agoWe Ruby programmers also obsess over style, especially with regards to tests. There's even a full, printed book about it: "Eloquent Ruby."
- Tomte 12y agoAn exceptionally well written book, I'd like to add. Many authors try to unite casual style with technical writing. Russ Olsen does it beautifully. He never treats you as a child or an idiot. He never lets you feel his master status. He's like the good-natured old-timer who sits next to you with a cup of coffee, teaching you more than you realize.
- userbinator 12y agoPython is another language where there is a lot of talk about idiomatic code ('Pythonic'). I wonder what an appropriate adjective could be for idiomatic Go code. Gonic? Gonian?
- StevePerkins 12y agoHeh... I had a similar thought back when I was using Python. In both cases, I don't think it's a matter of the language "fighting" you. You can write Go however you like, so long as it compiles and runs. However, it IS a matter of people on the Internet mocking you for not being "pythonic".
- eternalban 12y agoYou must, truly, channel the minds from planet 9 to enjoy the experience of Go. (This statement is not considered 'polite' in certain circles, but darn it, I can't help myself ;) That said, I've tried channeling Rob and it is an interesting and informative experience ..
- skrebbel 12y agoI think that's a good thing. If Scala had a better commonly accepted idea of what's "idiomatic Scala", then maybe the "there's more than 6497492 ways to do it" stigma that Scala's recently gotten might've been avoided. You need discussion about what's considered "good" before you can arrive at a relatively common opinion about that.
- mostafah 12y agoOr, it could be a result of Go making use of some novel approaches that a lot of programmers are not used to.
- frowaway001 12y agoNo, certainly not.
- wwweston 12y agoDon't forget the constant reminder that leaving <language feature X> out is just simplicity, even if it means you're writing a lot of if statements and extra code.
- pjmlp 12y agoSad that this is still the way to test for interface implementations. http://talks.golang.org/2014/readability.slide#17 http://talks.golang.org/2014/readability.slide#17
- webtopaz 12y agoIt is a perfectly reasonable way to test for interfaces. A single struct may satisfy a hundred interfaces which it doesn't even know about, this is actually one of the best traits of go.
- bsaul 12y agoI looked at this slide for a while and couldn't understand it. Could you explain the detail a bit ? It seems like relying on dynamic type casting over a nil variable, is that correct ? But then what would the following "if" look like ?
- webtopaz 12y agoThis is how you can make sure that a struct implements an interface. The line 'var _ scan.Writer = (*ColumnWriter)(nil)' assigns a nil pointer of the struct to a scan.Writer interface reference which would fail if ColumnWriter doesn't implement the interface. And the casting always works.
- bsaul 12y agoSo it's a static typing check ? the code won't even compile if the ColumnWriter struct doesn't implement the interface ?
- webtopaz 12y agoYes. It won't compile. This check is not really needed as the code would fail when a function which accepts scan.Writer would fail (compilation) if ColumnWriter is sent and if it doesn't satisfy the interface. However, this is easier to debug.
- mratzloff 12y agoI found that I already do all of these as a result of reading through a lot of the Go standard library when I was learning it. One of the best ways to really learn a language is to read the standard library (the parts implemented in that language, anyway). That way you get a sense of the idioms used, but also understand the sometimes subtle trade-offs of common functions.
- steveklabnik 12y agoThis can be both good and bad. Two examples: The Rust standard library has/had lots of awkward bits, from when certain language features didn't yet exist, or before there was a convergence on how to accomplish something idiomatically. The Ruby standard library has tons of Ruby code in it that's 20 years old, that nobody has touched for various reasons. I certainly wouldn't write Ruby in the same way.
- mratzloff 12y agoYeah. When I learned Ruby I read the Rails code base, which comes with its own set of issues, but which was more modern and was a better representation of the current state of Ruby.
- minhajuddin 12y agoUnrelated to the core presentation. I wrote http://readcode.in/ http://readcode.in/ to help with reading source code in a simple single page format. It really fits go code repositories as they are usually small. e.g. http://readcode.in/github.com/gorilla/mux http://readcode.in/github.com/gorilla/mux
- jdkanani 12y agoAs I go from normal Go style to idiomatic Go style, I find more error checks. That is annoying when your code grows. http://talks.golang.org/2014/readability.slide#11 http://talks.golang.org/2014/readability.slide#11 In this example, have to check error 3 times to write 4 lines of code.
- libria 12y agoIn Java, I'd have to write 3 catch blocks. It's possible to write a blanket catch, toss it up to higher levels and make it someone else's problem. I vaguely recall this being against Pike's vision of what "exceptional" means and he wanted a language that forces developers to think of disk/network failure as a very common case.
- lclarkmichalek 12y agoGiven that every single error check there is just passing up the error, is it really that different from having exceptions that propagate along with RAII style resource cleanup? The vast vast vast majority of Go code simply propagates errors.
- sagichmal 12y ago> Given that every single error check there is just > passing up the error, is it really that different from > having exceptions that propagate along with RAII style > resource cleanup? Yes, it's fundamentally different. The whole point is to make those error blocks visible, so future maintainers are forced to deal with the reality that those invocations are fallible. Maybe there's a way to make the error handling less verbose, but hiding it altogether would subvert that explicit language design goal.
- lclarkmichalek 12y agoExcept, you know, just mindlessly typing out "if err != nil { return }" does not somehow force enlightenment upon the user. The error blocks are so uniform in their banality that future maintainers treat them the same way that error handling is treated in every other language.
- kremlin 12y agoI'm on Chrome on Mac and it's not entirely obvious how to navigate these slides. Going to the link only shows me the first 3 slides by scrolling right. Playing around a bit, I discovered that the arrow keys bring you to the next slides. Perhaps there could be a way to make that more obvious, or provide buttons onscreen.
- vegabook 12y agoWhere's the gopher?! Idiomatic Golang presentations should include a non-broken link to the gopher.
- dyadic 12y agoI've only been using Go for less than a week and my impressions are less than good. I'm still waiting and hoping to understand what it is that people like about Go, but I'm starting to suspect that won't happen. The biggest problem I have had most so far is when reading other code, finding the meaning amongst all of the error nil checks and the sprawling if conditions that they bring. Another thing that makes it difficult is the preference for scattering returns everywhere and avoiding `else if`s, I read code structurally so code like this from slide 29 (http://talks.golang.org/2014/readability.slide#29 http://talks.golang.org/2014/readability.slide#29) is really difficult to parse. func finishStatus(r Result, complete bool) int { if !complete { return http.StatusAccepted } if stat, ok := r.Object.(*api.Status); ok && stat.Code != 0 { return stat.Code } if r.Created { return http.StatusCreated } return http.StatusOK }
- wolf550e 12y agoThat is the way it is done in C: avoid indentation if you can fail out. It is very readable.
- deleted 12y ago[deleted]
- dyadic 12y agoI disagree, and saying "That is the way it is done in C" doesn't mean that it's the right way. When I see code like this I will assume that it's going to check every condition: if !complete { // do something } if stat, ok := r.Object.(*api.Status); ok && stat.Code != 0 { // do something } if r.Created { // do something } If the first condition matching causes the second, third, nth condition to not be checked then why not make it clear in the code by adding an `else`? The recommended way means that I can't trust my assumption and that I'll have to read the entire function and examine the `//do something`s instead
- tptacek 12y ago
- lukasm 12y agoI don't get where is the bug in this code: http://talks.golang.org/2014/readability.slide#10 http://talks.golang.org/2014/readability.slide#10
- _blob 12y agoIn the original code if out.Close() returns an error, run() will return nil. The revised code sets `err` to the returned error from out.Close(), in case the error from os.Create(*output) is nil. Simply spoken, the original code will suppress the error from out.Close().
- justinsb 12y agoWhat if the out.Write (which is presumably in "some code") has already set err? Then we lose _that_ error, if out.Close returns error. I think this is tricky in any language.
- zerr 12y agoAm I the only one who associates "Gopher" with Gopher (protocol)? Or is Golang so much prevalent nowadays? :)