I'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.<p>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.<p>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 (<a href="http://talks.golang.org/2014/readability.slide#29" rel="nofollow">http://talks.golang.org/2014/readability.slide#29</a>) is really difficult to parse.<p><pre><code> 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
}</code></pre>
I've never known a language with so much discussion on why what you are doing isn't idiomatic as Go.<p>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.
As I go from normal Go style to idiomatic Go style, I find more error checks. That is annoying when your code grows.<p><a href="http://talks.golang.org/2014/readability.slide#11" rel="nofollow">http://talks.golang.org/2014/readability.slide#11</a><p>In this example, have to check error 3 times to write 4 lines of code.
Sad that this is still the way to test for interface implementations.<p><a href="http://talks.golang.org/2014/readability.slide#17" rel="nofollow">http://talks.golang.org/2014/readability.slide#17</a>
I'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.<p>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.
I 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.
I don't get where is the bug in this code:<p><a href="http://talks.golang.org/2014/readability.slide#10" rel="nofollow">http://talks.golang.org/2014/readability.slide#10</a>
Unrelated to the core presentation. I wrote <a href="http://readcode.in/" rel="nofollow">http://readcode.in/</a> 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. <a href="http://readcode.in/github.com/gorilla/mux" rel="nofollow">http://readcode.in/github.com/gorilla/mux</a>