4 ms·
It really doesn't help that the major (perhaps only?) official resources on generics in golang are these blog posts [1][2] and the spec. And now this blog post.
by parhamn 3y ago
It really doesn't help that the major (perhaps only?) official resources on generics in golang are these blog posts [1][2] and the spec. And now this blog post.
The whole "what type am I getting"/make()ing is really tricky (as outlined in this doc) especially when its a pointer/interface/slice/etc. And a lot of feels like it doesn't need to be as much of a complex decision tree as it is. Is there any other documentation on this stuff that I'm missing?
Theres a lot of complication buried in golang people don't talk about that much. nil vs empty slices, interface{} and any behavior differences, make() and what it would do for various type scenarios, impossible to remember channel semantics (which ones panic again?). Of course, theres always a good explanation for why it is the way it is, but for a language so opinionated, stronger opinions on better DX in the deeper parts would be great.
[1] https://go.dev/blog/intro-generics https://go.dev/blog/intro-generics
[2] https://go.dev/doc/tutorial/generics https://go.dev/doc/tutorial/generics
- jrockway 3y agoPointing people at the spec is probably the best decision the Go team ever made. Why wonder about things when you can have true authority in an honestly very short piece of text? No guessing, just an exact description of what's going to happen. (I was in there recently reading about operator precedence recently and discovered an operator I didn't know existed, "bit clear (AND NOT)", &^. Amusingly, I needed to do that operation but wasn't sure if I needed parentheses for X & (^Y) or not. I still don't know why it's a dedicated operator, however. The spec rarely says WHY, just WHAT.)
- Groxx 3y agoIt does help that the spec (and memory model!) is quite good and reasonably concise. I send people there as often as possible when they start getting interested in learning things For Real, blogspam is rarely anywhere near as useful despite being multiple times longer. (Which is not meant to claim this article is blogspam - making recommendations with examples is quite different from a spec, and we definitely need recommendations)
- jrockway 3y agoYeah. Effective Go feels a little dated now. My most frequent link is to Code Review Comments: https://github.com/golang/go/wiki/CodeReviewComments https://github.com/golang/go/wiki/CodeReviewComments
- LudwigNagasena 3y ago> Why wonder about things when you can have true authority in an honestly very short piece of text? There is no such short piece of text because > The spec rarely says WHY, just WHAT.
- AlbinoDrought 3y agoThe one that got me was the implicit wrapping of structs into interface types. As an example, the below code segfaults with `fatal error: panic while printing panic value: type runtime.errorString`: package main type SomeError struct { SomeMessage string } func (se *SomeError) Error() string { return se.SomeMessage } func doSomethingSomeWay() *SomeError { return nil } func DoSomething() error { return doSomethingSomeWay() } func main() { err := DoSomething() if err != nil { panic(err) } }
- EspressoGPT 3y agoYes, this has to do with interface values and how interfaces are implemented in Go. It's a bit weird.
- lenkite 3y agonil interfaces are not equal to nil values in Golang. Interfaces are fat pointers with a type and value pair and if the type is populated then the pointer as a whole will not compare to the `nil` value as it requires both elements to be nil. Frankly, I think this was a design mistake.
- kiitos 3y agofunc doSomethingSomeWay() *SomeError { Yeah, you'd never return a concrete error like this -- clear red flag in any code review. For precisely the reason you're demonstrating here! (Among several others.)
- ithkuil 3y ago> interface{} and any behavior differences, I'm curious now. They are type aliases. In which situations there is a difference in behavior?
- mseepgood 3y agoThere are no differences. You can always substitute one for the other without change in behaviour. These two are interchangeable: func f[T any]() {} func f[T interface{}]() {} and these two are interchangeable: func f(x any) {} func f(x interface{}) {} Maybe OP means the difference between using an interface as type parameter constraint and using an interface as a function parameter / variable type.
- gabereiser 3y agoNo difference as any := interface{}
- parhamn 3y agoI was firing that list off the top of my head and I think that one was a mistake. My bad. But, I did recently have some weird typing issues around "satisfies" x vs "is" x and using new() constructors of the T in a generic functions (particularly de-alternative serialization of proto.Message types) and had quite a bit of frustration and confusion. That may have been on me, but I did open my statement with "[wish it had better docs]".
- gregwebs 3y agoGo101 is a jewel of a resource. It’s a spec written by an impartial observer not worried about trying to make golang look good but instead giving you the understanding to avoid all the edge cases https://go101.org/ https://go101.org/
- strangelove026 3y agoNever seen this before but that’s awesome!
- kiitos 3y agoEh, I can't agree. I'm sure there is useful signal in there, but the author has a highly idiosyncratic view of the language, recommends tons of "optimizations" based on benchmarks that often aren't sound, and has several bits of code that are simply incorrect. As one example, the IsClosed function in https://go101.org/article/channel-closing.html https://go101.org/article/channel-closing.html is definitely not correct. The author doesn't seem to be aware of the comma-ok form of a channel receive as documented in https://go101.org/article/channel-closing.html https://go101.org/article/channel-closing.html -- which would be the correct way. Many others. Reader beware.