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:

If you don’t already know Go, you should definitely check out The Go Programming Language. It’s not just a great Go book but a great programming book in general with a generous dollop of concurrency.

Another book to consider learning Go with is Go Programming Blueprints. It has a nearly interactive style where you write code, see it get syntax errors (or whatever,) fix it, and iterate. A useful book that shows that you don’t have to get all of your programs perfectly working on the first compile.

Posted Sat, Aug 3, 2019

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.