Go and Simplicity Debt Redux
&gt;<i>Right now, to understand how io.Reader works you need to know how slices work, how interfaces work, and know how nil works. If the if err != nil { return err } idiom was replaced by an option type or maybe monad, then everyone who wanted to do basic things like read input or write output would have to understand how option types or maybe monads work in addition to discussion of what templated types are, and how they are implemented in Go.</i><p>God forbid we&#x27;d all have to learn such a simple concept (in a language with several non-orthogonal concepts and special cases and all the channels coordination nuance that lack of generics prevents of abstracting in a standard library to boot).<p>&gt;<i>Obviously it’s not impossible to learn, but it is more complex than what we have today.</i><p>Well, adding a feature we&#x27;ll always be more complex than not adding it. In the end, simple assembly style instructions are the simplest both for implementation and for learning fewer concepts as a developer. But abstractions make things easier to write and read <i>after</i> one has learned their concepts. And it&#x27;s 2017, even &quot;lowly&quot; JS developers understand such functional concepts today...<p>&gt;<i>What began as the simple request to create the ability to write a templated maybe or option type has ballooned into a set of question that would affect every single Go package ever written.</i><p>This is more similar to how some molehills grow into mountains. People have been asking for generics as a standalone feature  first and foremost -- orthogonal from replacing error handling. Now suddenly we can&#x27;t discuss adding Generics without taking into consideration the big burden of changing the error handling too?<p>&gt;<i>On the surface this sounds like a grand idea, especially as these types are leaking into the standard library anyway. But that leaves the question of what to do with the built in slice and map types. Should slices and maps co-exist with user defined collections, or should they be removed in favour of defining everything as a generic type?</i><p>Whether the answer, the mere addition of the ability to have standard user defined generic collections and collection libraries sounds awesome in itself, regardless of what would happen to the ill-thought maps and slices that specialcased genericity in the backend.<p>This doesn&#x27;t seem like a discussion of how to best add generics, but more like analysis paralysis.<p>&gt;<i>David Symonds argued years ago that there would be no benefit in adding generics to Go if they were not used heavily in the stdlib. The question, and concern, I have is; would the result be more complex than what we have today with our quaint built in slice, map, and error types?</i><p>A better question is: would some more complexity hurt us, especially beginning with in an overly simplistic language, and even more so, when said complexity actually unifies and harmonizes ugly special cases.