AFter writing a few non-trivial projects (only thousands-ten-of thousands of lines), I'm starting to really understand every gripe about Go.<p>The standard library is very nice, but the language constantly feels like it's working against me or I'm having to circumvent some intended feature (no generics, while not a problem in the beginning, has continually worn down on me). Besides that, reason 9 is a huge nuisance which needs to be resolved,
One thing I'd like to see in Go, is the possibility to ask the compiler to not bother me for defined-but-not-used and/or imported when doing prototypes.<p>You know, "I just changed this little thing and I want to see what happens".
The Go authors and contributors probably know a lot of those issues and how the community feels in general. However, they made a strong point not to change v1 to accomodate for changes like generics. We'll see what happens with v2... one day.
1. Unlike the author, I think using capitalization for exported identifiers is great. It's hard to believe that having to name unexported constants "entirely in lower case" can be a "recurring source of discomfort".<p>2. This is called "structural typing" and it's one of Go's greatest features. It looks like the author prefers "nominal typing". Both approaches have their pros and cons. See <a href="https://golang.org/doc/faq#implements_interface" rel="nofollow">https://golang.org/doc/faq#implements_interface</a>.<p>3. Go by design doesn't have exceptions. See <a href="https://golang.org/doc/faq#exceptions" rel="nofollow">https://golang.org/doc/faq#exceptions</a>. github.com/kisielk/errcheck can be used to make sure errors are checked everywhere (but I agree this is not ideal).<p>4. I don't get that part. Sounds like nitpicking to me.<p>5. I don't get it either. If there is a "collision", you can use an alias. And I personally don't like having to repeat fully qualified package names everywhere. On this topic, I prefer Go's approach to Java.<p>6. Go has been designed to automatically generate code! A lot of tools do that all the time, the best example being gofmt. The compiler being strict is more an advantage than a liability for this purpose. But I agree with author about the issues created by packages sharing the same default name. Would be curious to know the advice of the Go team on this.<p>7. I mostly agree about missing the ternary operator, sometimes. But I don't miss the code I read in other languages that abuse it. I'm 50/50 on that.<p>8. I agree about sorting being "clumsy". This is being worked on at <a href="https://github.com/golang/go/issues/16721" rel="nofollow">https://github.com/golang/go/issues/16721</a>.<p>9. I agree about Go not providing anything builtin or well-known for dependency versioning, but I completely disagree about vendoring. See <a href="https://golang.org/cmd/go/#hdr-Vendor_Directories" rel="nofollow">https://golang.org/cmd/go/#hdr-Vendor_Directories</a>.<p>10. Missing generics is probably the most talked topic about Go. I miss them sometimes. I keep hoping Go solves this one day. Here is Russ Cox explaining why Go doesn't have generics today: <a href="https://news.ycombinator.com/item?id=9622417" rel="nofollow">https://news.ycombinator.com/item?id=9622417</a>.
> but its import system is actively hostile to vendoring<p>? It literally has built-in support for a vendor directory.<p>Great cover image though, I lol'd.
#2 maybe, #7 for sure...<p>But the rest are either (A) it doesn't work the way I want it to work or (B) I haven't read the manual and it's your fault.
# 4 "This is all part of the “convention over configuration” movement. It’s fine for small projects but bites you on large ones, and Go was meant to address the problem of “programming in the large”."<p>Isn't that the opposite? conventions (even ugly ones, or annoying ones) help with consistency across many developers or large projects.
The only problem that makes me angry with Golang is that a pointer to a struct and a struct member can both be referenced with the dot '.'. For me it makes the code unacceptably non readable.