codegen: Use Go generics for stream types about grpc-go

[dfawley]

Something like this could be really interesting. Unfortunately this is a very niche kind of thing and we likely won't have the bandwidth to work on it in the foreseeable future. If you are interested in fleshing this out and sending PRs, we can review them.

As for an implementation plan, I'd propose something like:

1. Add these generic interfaces and implementations in the experimental package.
2. Have the codegen produce them only if a flag is set.
3. Give some time for users to try them out. If they prove to be good, move the definitions to the grpc package with type aliases in experimental for several releases.

Not being backward compatible would be the biggest problem with changing how the codegen works. We'd either need to generate both together with different names (the non-generic implementation could even call the generic one), or we'd need a flag to decide which one to generate. If we generated both, we'd need to choose good names to be ergonomic and to avoid conflicts.

I'm not concerned about supporting versions of Go older than 1.18, as this kind of thing is necessary from time to time anyway (e.g. we will soon be making changes to the codegen that will require the most recent release of grpc-go, which doesn't support 1.18 already).

[aarongable]

Thanks for taking the time to read! I'd be happy to contribute implementation, but of course also have a lot of other things on my plate so no guarantees.

Would you also be willing to accept an implementation plan like this:

1. Add generic interfaces and implementations to the grpc package. Modify codegen to produce the same exact exported type names as today, but with (e.g.) GreeterReadOnly_SayHelloServer being a type alias for grpc.ServerStreamServer[HelloReply].
2. Add a flag to codegen to stop producing and using the type aliases, and instead use the underlying generic types directly.
3. Give some time for users to try them out. If people like it, flip the default value of the flag and eventually remove it entirely.

To my mind, the big change here is in the publicly-exposed interface, and that's the thing worth protecting behind a flag. But I definitely don't have insight into all of the things the gRPC team might be concerned about (do Go generics have meaningfully different runtime performance? I don't think so, but maybe) so I'm not sure if swapping out the underlying implementation is too risky to not put in experimental first.

Thanks for the note about go 1.18; I'll keep an eye on other compatibility stuff and just make sure any reliance on generics lands after the other changes you mentioned.

[dfawley]

I definitely would like to put the interfaces in experimental first, to prevent anyone from relying upon them until all of the work is done and we're sure they are going to work. The other option is to put them in the permanent location with an "experimental" tag on them in doc strings, but unfortunately, lots of our users don't heed those sorts of warnings and changing them later can be a major problem.

Does the type aliases prevent any backward compatibility breakage problems? If so, that might be the ideal final state? I really don't want to be in a situation where users have to choose between two different forms of codegen that are incompatible. Otherwise no old generated code library can ever migrate to the new style (without a v2 since it's a breaking change), and users of that generated code would be stuck implementing it that way forever.