>decided generics is not needed
>went on for a decade
The FAQ on the official site already back in 2013 (I couldn't find an earlier snapshot on webarchive) stated they were open to adding generics but weren't sure how to properly design/implement them without overcomplicating the language, citing also other priorities.
>implemented a version of it that is not performance-sensitive
It's less performant than the ideal but it's a tradeoff to avoid exponential code bloat found in C++. In our large C++ project which extensively used templated boost.signals the code bloat from using templates alone added a whopping 200 MB of machine code which we were able to shed off by switching to our in-house library. IIRC C# uses an approach similar to Go to share generated code with some type-specific conditions at runtime (at least Mono I remember shared generic code for all reference types)
The Go authors have never said #1: they said their waiting to decide how to best do it, and they want experience with the language to determine what problem needs to be solved before solving it
#3: they’ve clearly said that they’re doing “get it right before you make it fast”.
They demonstrably decided generics are not needed for Go at release, or for the following 5+ years, I don't know how that could be seen as false. If they had thought generics are required for Go, they wouldn't have released the language before they had them.
What is often claimed instead, and is indeed false, is that they believed generics should not exist in Go. This is a position that many Go proponents take, but the designers of the language never did.
