"What Go 1.0 didn't have was user-defined generics." If you sit down and carefully write out the use cases for generics, which extend well beyond "parameterize

"What Go 1.0 didn't have was user-defined generics." If you sit down and carefully write out the use cases for generics, which extend well beyond "parameterized data types", you'll note that Go interfaces cover a lot of them reasonably well, which is how it has been a viable language for versions 1.0 - 1.17. While this is an unpopular opinion, I don't really consider 1.18 to have "added" generics so much as completed them. (As evidence, consider how important "interfaces" still are in generics, and I can attest from personal experience with helping people that there's a lot of people who try to fire "generics" at a problem when they just need interfaces.) I say this in support of the original post. Otherwise one must reconcile how Go could be successful "without generics"; my suggested resolution is that it shipped with "bad" or "incomplete" (more charitably) generics rather than no generics. Compare programming in Go with programming in C and the differences become very clear. There's a reason so many people were able to smoothly transition their code bases from Python to Go, for instance, which a view of Go in which it literally has "no" generics finds hard to account for. You need more than just "maps" and "slices" to do that successfully.