4 ms·
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
by ngrilly 10y ago
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".
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 https://golang.org/doc/faq#implements_interface https://golang.org/doc/faq#implements_interface.
3. Go by design doesn't have exceptions. See https://golang.org/doc/faq#exceptions https://golang.org/doc/faq#exceptions. github.com/kisielk/errcheck can be used to make sure errors are checked everywhere (but I agree this is not ideal).
4. I don't get that part. Sounds like nitpicking to me.
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.
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.
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.
8. I agree about sorting being "clumsy". This is being worked on at https://github.com/golang/go/issues/16721 https://github.com/golang/go/issues/16721.
9. I agree about Go not providing anything builtin or well-known for dependency versioning, but I completely disagree about vendoring. See https://golang.org/cmd/go/#hdr-Vendor_Directories https://golang.org/cmd/go/#hdr-Vendor_Directories.
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: https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417.
- junke 10y agoI don't get how "great" it is to let capitalization be used for exported identifiers. What is the rationale behind this?
- ngrilly 10y agoAccording to Rob Pike: "This was not an easy design decision. We spent over a year struggling to define the notation to specify an identifier's visibility. Once we settled on using the case of the name, we soon realized it had become one of the most important properties about the language. The name is, after all, what clients of the package use; putting the visibility in the name rather than its type means that it's always clear when looking at an identifier whether it is part of the public API. After using Go for a while, it feels burdensome when going back to other languages that require looking up the declaration to discover this information." Source: https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article Must be noted that any identifier that doesn't start with an uppercase letter is not exported. This makes possible to use an underscore to mark unexported identifier and still use uppercase letters (like _Name or _SOME_CONSTANT), which is a common practice in many programming languages (like Python). This is not idiomatic in Go, but it's possible.
- ngrilly 10y agoWhy the downvote?
- tkxxx7 10y agoI didn't downvote, but I'd guess it's because you didn't answer the parent's question exactly, which was asking the OP's rationale for their opinion (not the rationale for the addition to the language). Your comment still provides valuable context so it seems unfair to me.
- junke 10y agoI didn't downvote either. I would have like to read a more convincing answer, but this always come down to "Rob Pike says so". I found an old thread about this btw: https://news.ycombinator.com/item?id=5201461 https://news.ycombinator.com/item?id=5201461.
- ngrilly 10y ago
- leshow 10y agoHe says generics "haven't had time to pass through the filter of practical experience" which is completely false. Generics have been around for decades in real programming languages, outside of a research setting. His post just makes it seem like a proper type system with good inference and generics is over all the heads of the people who work on Go.