1610849111.en.md (1708B)
1 +++
2 date = 2021-01-16T20:05:11-06:00
3 draft = false
4 +++
5 Reading through the [latest Go generic
6 proposal](https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md), I felt ok at the beginning, but increasingly uneasy as I scroll along to find the long list of restrictions and edge cases. It's clear that the dev team is actually painstakingly trying to fit a generics implementation (almost exactly as people have asked for) into the language. Perhaps because Go seemed like such an opinionated language, I was not actually expecting such an serious attempt at all: I would have expected Go generics to simply involve a handful of special interface types from standard library that are somehow unboxed (have one less layer of pointer redirection) and we still write for-loops instead of map-reduces.
7
8 It's one of those cases where I applaud the effort, but I'm not convinced that a suitable solution can be achieved (like *The Rise of Skywalker*). The proposed generics system eats into Go's originally quite orthogonal feature set and reading through all the caveats of how it would interact with other parts of Go already feels similar in length as the entire Go spec. On the other hand, generics and interface types obviously overlap in functionality and while there are restrictions in place to discourage a Go version of "almost always `auto`" from happening, having to think about which one to (not) use takes away some of Go's appeal for me.
9
10 Ugh, this is such an arduous yet unrewarding path to go down. Maybe Go team's `.async` moment would eventually come and we would all love the solution, but then again, I really don't mind writing generics-free Go that much.