Leon Mika

Follow @lmika on Micro.blog.

I never considered myself someone who believed that Go must’ve had generics from the start. I appreciated that the designers added them to the language, but I though I’d could be just as effective writing Go code if they chose not to.

I don’t believe that anymore.

I’ve found generics in Go to be a major improvement to the language. It now means that I can now use higher order functions that operate on collections, like “map” or “filter”, in a more natural way. I got use to these functions while working in languages that had them (Python, Ruby, JavaScript, Java 1.8) and they’ve been so useful that I wished Go had them as well.

There was no technical reason for Go not to have these functions, but they would have had to use the interface{} type to be useful, meaning that there was no type safety built-in and your code would be littered with type assertions. This was such a turn-off that most of the time I didn’t bother with considering higher order functions, and just wrote a for loop by hand to convert types in one slice to types in another slice. Trivial to write, but just so boring.

Now with generics, these higher order functions can be made type safe, and there is no longer a need for type assertions to use them. These made them viable once more, and I’ve found myself using them a fair bit recently. Not having to write yet another for lop has made coding fun again.

✍️ Reply by email