Was that what you are thinking I'm advocating for? To be clear I agree that the initial lack of generics did weaken original goals. (Even more so because I wrote Rust much more than Go anyway.) I don't agree that such lack is a major deficiency for original goals however, because built-in parametrized types do cover the majority of use cases and higher-level programming envisioned by Go designers needs less generics in general [1].
[1] Assuming that you are not going all in specific design patterns from functional programming, of course.
> Was that what you are thinking I'm advocating for?
No, I'm just pointing out that even a "fair" analysis of Go is going to catch some pretty serious design mistakes.
> Assuming that you are not going all in specific design patterns from functional programming, of course.
Eh, Java cerca 2008 (before Go was released) lacked most of the functional programming features it has today, and it was abundantly clear that generics were a critical feature for Java then--I was writing Java professionally at the time, albeit as a paid intern. While template types aren't exactly the same thing, they fulfill many of the same needs and were pretty obviously a critical feature for C++ before that. Go's developers were abundantly familiar with C++, and likely abandoned templates because they're slow to compile, but they literally could have Googled "how to compile template types faster" and found generics pretty easily.
At a high level, my big criticism of Go is that they simply did not stand on the shoulders of the giants before them. Their goals make a lot of sense. But they pretty much only tried ideas from C++ and Python which indicates to me that they didn't know any other languages, and where C++ and Python have problems, they reinvented the wheel, mostly badly. I guess garbage collection was one exception as it's in neither C++ nor Python, but that's sort of a surface-level feature of a ton of languages. If they had any deeper experience with other languages I think they'd have stolen a lot more ideas, and better ideas. There are a dozen textbooks on comparative programming languages that would have easily given better solutions to some of Go's problems.
The one thing they did right initially was trying to keep few features, but if you do that you need to choose more powerful features than they did, otherwise "simple" just means the simple language results in complex code to work around the language's neutered feature set. Now they're filling in those gaps with the features they needed initially, and I'd predict that within a few years Go will no longer be a simple language--arguably it already isn't.
[1] Assuming that you are not going all in specific design patterns from functional programming, of course.