Generics in Go, via Contracts
The newest Contracts proposal was published just a few days ago. I read it in full and have a few thoughts.
You may want to read the proposal to form your own conclusions first; I would suggest skipping straight to the examples and then reading the rest if you are up to it. I do not intend to summarize the proposal.
Before I go into much more depth I do want to mention a conviction I have about generics in Go: I am confident that generics in almost any form will dramatically change the characteristics of Go in the wild. I think that given the ability to use a form of abstraction people are more likely to use it than not, if only because adding the use of an abstraction is easier than removing it. It’s almost like the computer form of entropy: things get complicated. I am resigned to the fact that generics will end up in Go and am a little excited to use them. On the other hand I am sure that I’ll be reading code that’s even harder to understand than before thanks to them. I’d love to be wrong though!
Ok all that said, here’s my rambling thoughts I jotted down while reading the proposal:
🔗 Values of generic types are not boxed
“Values of generic types are not boxed” first lead me to believe that generic types will get a little speed boost compared to interfaces, which automatically turn their values into pointers. Reading more though, when using generic types all values are turned into pointers to simplify method dispatch, but only within the generic code, rather than values that are returned from the generic code. All this to say: I was excited and I ended up more confused.
🔗 Function argument type inference
Go’s type inference is minor but welcome, typically reducing much of the type
duplication that’s all over the place in Java. For some reason I didn’t expect
the proposal to include type inference for generics, but it does. So for
example if you have this generic function call: Store(int)(5), type inference
allows you to simply write Store(5). The rules for inference are a little
more subtle than I am used to in normal day-to-day Go programming, so it may be
that this ends up disappointing me, but the proposal seems to imply that the
inference could be improved.
🔗 Map/Reduce/Filter
I love functional programming in the small; one of the examples given in the proposal implements all of Map, Reduce, and Filter in just a handful of lines each; all of the example calls work with type inference as well. Very attractive.
All in all, I am excited by the proposal. I doubt I’ll be able to actually try it out any time soon, but I could be wrong about that; modules were released as vgo first, maybe we’ll get a similar ggo to try?
If you are interested in learning Go, this is my recommendation:
(The following includes affiliate links.)
If you don’t already know Go, you should definitely check out
The Go Programming Language
Another book to consider learning Go with is
Go Programming Blueprints
If you're interested in being notified when new posts are published, you can subscribe here; you'll get an email once a week at the most.