4 ms·

So… use generics the same way they’re used in other languages? I’m trying so hard to watch this evolution in Go with an assumption there’s careful consideration

So… use generics the same way they’re used in other languages? I’m trying so hard to watch this evolution in Go with an assumption there’s careful consideration of something other languages have gotten wrong and it seems like the whole result is… use generics within the language constraints in ways that aren’t problematic. I mean, Go already isn’t TypeScript (which does this great despite complaints). Go on, Go folks. Use generics. If you’re using them wrong you’re gonna get much more direct criticism than general guidelines to use the platform.

GeneralMayhem 5y ago
Some of it is definitely trying to walk back the refrain that Go is simple and simple is good, which implies that anything that isn't currently in Go is complicated and therefore bad. If you repeat that too many times, and people buy into it, it becomes hard to roll out any new feature without being a heretic. But - there are some things about Go generics that are particularly weird. The biggest one is that, in a lot of cases, they can actually just be another way to write runtime polymorphism, not static polymorphism as in languages like C++ (https://planetscale.com/blog/generics-can-make-your-go-code-slower https://planetscale.com/blog/generics-can-make-your-go-code-...).
- paskozdilar 5y ago
  > But - there are some things about Go generics that are particularly weird. The biggest one is that, in a lot of cases, they can actually just be another way to write runtime polymorphism, not static polymorphism as in languages like C++. Isn't static polymorphism the whole point of generics? Runtime polymorphism was already possible through interfaces and type switches. Also you can't type switch a generic variable, so runtime polymorphism with generics seems literally impossible.
  - excuses_ 5y ago
    I wouldn't say it's the whole point but very important one. For simple types the current Go implementation does produce monomorphic functions but for others, for example interfaces and other pointer types, it does pass around a dict with metadata in runtime. Check out this excellent blog post: https://planetscale.com/blog/generics-can-make-your-go-code-slower https://planetscale.com/blog/generics-can-make-your-go-code-....
    - gpderetta 5y ago
      As far as I understand it is still compile time checked, hence it is a form of static polymorphism. The fact it is still runtime dispatched it is just an implementation choice.
      - excuses_ 5y ago
        I think you’re right. It’s just not exactly what many people coming from other languages expect from generics. It’s seems like a static polymorphism but not monomorphism, which also is implemented in Go generics but for simple types.
        gpderetta 5y ago
        Actually historically most generic implementations do not monomorphize either except as an optimisation: Java, C# (at least for complex types), most functional languages use some sort of type erasure. C++ and, I think, ADA were the exceptions, although it has proven more popular with newer languages.
B-Con 5y ago
This guidance is specific and explicitly calls out some dos and don'ts. Your comment implies that there is one flavor of utilizing generics that applies across all languages and that is most certainly not true. Other languages don't tend to be as prescriptive about best practice as Go is trying to be here. Just because it's syntactically valid doesn't mean you should type it often. (Most language standard libraries are several contrasting styles shoehorned together. Although, to be fair, even Go suffers from this a bit.) This guidance isn't heralding in a new age of programming, it's explaining the right way to think about a new feature within the language.
tarkin2 5y ago
Haven't the initial designers of Go stepped back? I was under the assumption that Rob Pike, for example, wasn't overly convinced, but was happy to watch what happens.

GeneralMayhem 5y ago

Some of it is definitely trying to walk back the refrain that Go is simple and simple is good, which implies that anything that isn't currently in Go is complicated and therefore bad. If you repeat that too many times, and people buy into it, it becomes hard to roll out any new feature without being a heretic. But - there are some things about Go generics that are particularly weird. The biggest one is that, in a lot of cases, they can actually just be another way to write runtime polymorphism, not static polymorphism as in languages like C++ (https://planetscale.com/blog/generics-can-make-your-go-code-slower https://planetscale.com/blog/generics-can-make-your-go-code-...).

paskozdilar 5y ago
> But - there are some things about Go generics that are particularly weird. The biggest one is that, in a lot of cases, they can actually just be another way to write runtime polymorphism, not static polymorphism as in languages like C++. Isn't static polymorphism the whole point of generics? Runtime polymorphism was already possible through interfaces and type switches. Also you can't type switch a generic variable, so runtime polymorphism with generics seems literally impossible.
- excuses_ 5y ago
  I wouldn't say it's the whole point but very important one. For simple types the current Go implementation does produce monomorphic functions but for others, for example interfaces and other pointer types, it does pass around a dict with metadata in runtime. Check out this excellent blog post: https://planetscale.com/blog/generics-can-make-your-go-code-slower https://planetscale.com/blog/generics-can-make-your-go-code-....
  - gpderetta 5y ago
    As far as I understand it is still compile time checked, hence it is a form of static polymorphism. The fact it is still runtime dispatched it is just an implementation choice.
    - excuses_ 5y ago
      I think you’re right. It’s just not exactly what many people coming from other languages expect from generics. It’s seems like a static polymorphism but not monomorphism, which also is implemented in Go generics but for simple types.
      - gpderetta 5y ago
        Actually historically most generic implementations do not monomorphize either except as an optimisation: Java, C# (at least for complex types), most functional languages use some sort of type erasure. C++ and, I think, ADA were the exceptions, although it has proven more popular with newer languages.

B-Con 5y ago

This guidance is specific and explicitly calls out some dos and don'ts. Your comment implies that there is one flavor of utilizing generics that applies across all languages and that is most certainly not true. Other languages don't tend to be as prescriptive about best practice as Go is trying to be here. Just because it's syntactically valid doesn't mean you should type it often. (Most language standard libraries are several contrasting styles shoehorned together. Although, to be fair, even Go suffers from this a bit.) This guidance isn't heralding in a new age of programming, it's explaining the right way to think about a new feature within the language.

tarkin2 5y ago

Haven't the initial designers of Go stepped back? I was under the assumption that Rob Pike, for example, wasn't overly convinced, but was happy to watch what happens.