Simplicity Debt Redux

In Go, a common complaint is the lack of generics, among other things. This article demonstrates that there are a lot of challenges to be solved if Go would get generics, and most of them is not about generics, but about the implications of having them.

These are some of the knock on effects that I see of adding generics or immutability to Go. To be clear, I’m not saying that it should not be done, in fact in my previous post I argued the opposite.

What I want to make clear is adding generics or immutability has nothing to do with the syntax of those features, little to do with their underlying implementation, and everything to do with the impact on the overall complexity budget of the language and its libraries, that these features would unlock.

(Emphasis mine.)

(This article is a follow-up to an earlier article about the concept of “Simplicity debt”, which is somewhat similar to technical debt, but occurs because something was implemented for the sake of simplicity, and later it turns out that things weren’t as simple. Another example of this is the GIL in python, as mentioned in the article.)