3 ms·

Dreading the wave of shitty badly-thought-out library "updates" to include generics (and the wave of shitty new libraries from people who never learned how to u

Dreading the wave of shitty badly-thought-out library "updates" to include generics (and the wave of shitty new libraries from people who never learned how to use interfaces and now think they know how to use generics). It's going to be a year or so before the community settles down again after this.

narraturgy 5y ago
As someone who has recently decided to learn Go, this is a rather intimidating change. What is a good way to know that I am learning from sources who are using these new tools responsibly, rather than applying them in the messy fashion which you seem concerned about?
- jerf 5y ago
  Stick close to the standard library and the extended libraries (https://pkg.go.dev/golang.org/x https://pkg.go.dev/golang.org/x ), track a community list where a lot of discussion will be occurring very quickly after release. I don't want to recommend "don't use generics", but generally think about whether or not you can solve the problem without them without immediately reaching for them. There are patterns in Go that work just fine today, which is why despite the fact that clearly some people are just flabberghasted at the idea that Go is useful without generics, it demonstrably is. Interfaces are quite a lot of what you need out of "generics". Don't just give up and copy and paste; it is necessary way less than some people who were trying to write C++ in Go claim it is.
  - marcus_holmes 5y ago
    this. Interfaces do 90% of what generics are used for in other languages. The remaining 10% had been solved by boilerplate/generation. Yes, it will be nice to have a better answer for that 10%. But we'll probably end up with generics being used (badly) for 90% of cases instead. As always in Go, follow the standard library. If they're hesitating to use generics, then that's solid advice.
- KarlKode 5y ago
  The standard library should be a good starting point.
jerf 5y ago
I'm hoping some linters get into golangci-lint quickly to curtail some of the biggest abuses. Some of them are obvious, like: func Whatever[reader io.Reader](r reader) { ... } You can tell just from the type signature that that is a useless use of generics. If it returned "reader", then that would be potentially useful, but as written that is useless. There will be some other things that can be caught too, potentially.
- masklinn 5y ago
  > You can tell just from the type signature that that is a useless use of generics. It's… not, though? In my understanding Go generics are reified, so this avoids boxing the reader, and should allow for static dispatch. How useful that is can be debated, but that's hardly useless.
  - mseepgood 5y ago
    The design does not require a specific implementation strategy (monomorphization, boxing or other approaches are possible). It can change from Go implementation to Go implementation and from Go version to Go version.
    - jerf 5y ago
      It works the other way too; the implementation is not obligated to pass an interface value to a function. The interface can be monomorphized too, if the compiler saw fit, and it would be a compliant implementation. At the language level, it's a useless use of generics. Even if generics someday used a monomorphic implementation, the compiler would be able to translate those two things back and forth trivially.
cy_hauser 5y ago
I'm on the opposite side of that fence. I'm looking forward to seeing what wonderful libraries can be created now that we have generics. It's going to be really interesting to see who's "right". Will the fear of those who think coders can't code and everything is going to get worse outweigh the concise and expressive functionality that can show up in a well crafted generic library?
kgeist 5y ago
>Dreading the wave of shitty badly-thought-out library "updates" to include generics >It's going to be a year or so before the community settles down again after this. Rob Pike doesn't want to add generics to the standard library in this release (1.18) for the same reason[0]: "<..>we have no experience with the use of the new types in Go on which to base a strong case for their design <..> For generics, we don't know what those new ways are yet. <..> I realize everyone wants to get their hands on the fun of the new language feature, and is looking forward to fixing some of the issues in the core libraries that will be less clumsy once it arrives, but I strongly believe it is best to take it slow for now." [0] https://github.com/golang/go/issues/48918 https://github.com/golang/go/issues/48918

narraturgy 5y ago

As someone who has recently decided to learn Go, this is a rather intimidating change. What is a good way to know that I am learning from sources who are using these new tools responsibly, rather than applying them in the messy fashion which you seem concerned about?

jerf 5y ago
Stick close to the standard library and the extended libraries (https://pkg.go.dev/golang.org/x https://pkg.go.dev/golang.org/x ), track a community list where a lot of discussion will be occurring very quickly after release. I don't want to recommend "don't use generics", but generally think about whether or not you can solve the problem without them without immediately reaching for them. There are patterns in Go that work just fine today, which is why despite the fact that clearly some people are just flabberghasted at the idea that Go is useful without generics, it demonstrably is. Interfaces are quite a lot of what you need out of "generics". Don't just give up and copy and paste; it is necessary way less than some people who were trying to write C++ in Go claim it is.
- marcus_holmes 5y ago
  this. Interfaces do 90% of what generics are used for in other languages. The remaining 10% had been solved by boilerplate/generation. Yes, it will be nice to have a better answer for that 10%. But we'll probably end up with generics being used (badly) for 90% of cases instead. As always in Go, follow the standard library. If they're hesitating to use generics, then that's solid advice.
KarlKode 5y ago
The standard library should be a good starting point.

jerf 5y ago

I'm hoping some linters get into golangci-lint quickly to curtail some of the biggest abuses. Some of them are obvious, like: func Whatever[reader io.Reader](r reader) { ... } You can tell just from the type signature that that is a useless use of generics. If it returned "reader", then that would be potentially useful, but as written that is useless. There will be some other things that can be caught too, potentially.

masklinn 5y ago
> You can tell just from the type signature that that is a useless use of generics. It's… not, though? In my understanding Go generics are reified, so this avoids boxing the reader, and should allow for static dispatch. How useful that is can be debated, but that's hardly useless.
- mseepgood 5y ago
  The design does not require a specific implementation strategy (monomorphization, boxing or other approaches are possible). It can change from Go implementation to Go implementation and from Go version to Go version.
  - jerf 5y ago
    It works the other way too; the implementation is not obligated to pass an interface value to a function. The interface can be monomorphized too, if the compiler saw fit, and it would be a compliant implementation. At the language level, it's a useless use of generics. Even if generics someday used a monomorphic implementation, the compiler would be able to translate those two things back and forth trivially.

cy_hauser 5y ago

I'm on the opposite side of that fence. I'm looking forward to seeing what wonderful libraries can be created now that we have generics. It's going to be really interesting to see who's "right". Will the fear of those who think coders can't code and everything is going to get worse outweigh the concise and expressive functionality that can show up in a well crafted generic library?

kgeist 5y ago

>Dreading the wave of shitty badly-thought-out library "updates" to include generics >It's going to be a year or so before the community settles down again after this. Rob Pike doesn't want to add generics to the standard library in this release (1.18) for the same reason[0]: "<..>we have no experience with the use of the new types in Go on which to base a strong case for their design <..> For generics, we don't know what those new ways are yet. <..> I realize everyone wants to get their hands on the fun of the new language feature, and is looking forward to fixing some of the issues in the core libraries that will be less clumsy once it arrives, but I strongly believe it is best to take it slow for now." [0] https://github.com/golang/go/issues/48918 https://github.com/golang/go/issues/48918