Updated Fri, Jan 6, 2023: Added comments about the new sum types as interfaces proposal.

I like programming in Go, just the way it is. I said the same thing when I first started playing with it in 2015 and now in 2023. But I have to admit every new feature that has been added has been awesome. I can’t imagine now programming in Go without things like Go Modules, built-in fuzzing, etc.

So my current contentment aside, I am looking forward to seeing these Go proposals evolve into things that we might see in the language, tooling, etc someday.

Ordered by my current level of interest.

  • #19623: change int to be arbitrary precision

    Arbitrary sized integer types built-in to Go would, I feel like, be very in-line with Go’s existing pattern of taking good things from Ruby, Python, and similar landscape. When I program in Ruby this is one of those joys that exists in that language that’s just there. When I reach for int in Go, I’m not reaching for the system’s word-size – even if that’s what it is – I’m usually reaching for the most convenient largest integer size to avoid overflow. The fact that Go has sized types too like int32 means that control is still there for those situations where I really am intentionally wanting a specific size. Go is a programming language for productivity and there’s a reason arbitrary sized integers show up in other languages known for productivity too.

  • #43557, #56413: user-defined iteration using range over func values

    I have a hard time figuring out the right way to use iterators in Go. The stdlib has a ton of them, and each time I go to use one I read the docs, look at examples, and try and craft the loop and use of values just the right way for that specific iterator. They aren’t all the same. I think this causes some people to think we need a common interface for iterators in Go. I don’t know if we need that, but I do feel like if we had a way to write functions that could be used with for, then that would go a long way to let people write iterators however they’d like, and present them in a way that anyone could use them one way.

  • #20733: redefine range loop variables in each iteration

    I’ve made this mistake too many times. It feels like something worth fixing.

  • #19412, #54685, #57644: add sum types / discriminated unions

    The proposal I am most excited about is #57644. It presents sum types as interfaces with a closed set of types. It’s simple, it integrates seamlessly with existing Go code because sum types are just interfaces. See my thoughts about the proposal here.

    I’m not very excited by either of the other proposals, as they add a lot to the language.

    I frequently work with the Stellar XDR (See RFC 4506) and XDR contains discriminated union types. In languages like Go this ends up being represented as structs with a discriminant field, then a pointer-field per type. It works, but it’s also a lot of work, easy to footgun if you aren’t diligent with checking you exhaustively addressed all types.

  • #19814: add typed enum support

    I’m regularly emulating enums using types and constants in Go. This actually works mostly fine, but if Go had enums I’d use them. The benefit I’d expect is validation on parsed values reducing runtime errors in areas of the code separate to when the value is created. It’s so easy to introduce invalid enum values in Go applications today if as the developer you aren’t diligent about validating the enum value after it exists. Unfortunately it’s so easy to think that in a static langauge that strongly typed enum must be valid, when it might not be.

  • #47487: allow explicit conversion from function to 1-method interface

    Go has a nice pattern of being able to turn functions into interfaces, but it requires a significant amount of boilerplate and it’d be convenient if that wasn’t required.