I'm not sure "C didn't have it" is a good litmus test for determining the value of features... C is called a portable assembler for a reason.

> Yes, they are convenient, but they also add a lot of complexity to the language and toolchain.

Conversely, proponents of generics would argue that not having them creates complexity for software developers who have to come up with alternative design patterns where generics would be a better fit.

> Personally, the proposal I was most excited about was to make ints be arbitrary precision by default.

Why would you want that? C doesn't have it... ;)

What I always found hard to swallow is that Go's build in functions sometimes did have generics. Just you as a library/application writer were not allowed to create APIs with generics yourself.

If generics were unnecessary, why did the stdlib/language need them? Couldn't they just have lived with, e.g., make_map, make_slice, make_chan, etc?

But then Go is not a public place: it's private domain of Google.

I decided long time ago I dont want to learn a private tool without being paid.

Anyway, yeah, no argument there at all.

I'll be honest, as an outsider that's somewhat familiar with Pike's obsession with simplicity in Go, I'm actually a bit surprised this is getting in. It does seem like the kind of high-complexity feature that was deliberately excluded from the language as part of its overall design ethos.

But it really comes down to a weighing of pros and cons. Generics have the potential (though definitely not the guarantee!) to trade off developer complexity for compiler and toolchain complexity, and the preference on that choice is a personal one.

It can be a good test.

One reason why C is so ubiquitous is the simple binary interface. This makes it easy to reuse code since the libraries can be imported by every other language out there. C code is relatively simple and the compiled objects follow simple binary interfaces.

Adding features to languages almost always increases the complexity of these binary interfaces. Eventually they become so complicated that nothing will ever interoperate with software written in these languages. The increased language complexity reduces the reusability of software produced in that language.

C++ had this problem and Rust is following in its footsteps. Rust libraries are really only reused within the Rust ecosystem. Those that are meant to be universally reusable will no doubt offer a simple ABI that lacks all the benefits of the Rust language.

It might not be used much in the stdlib (which is relatively small!), but libraries and applications rely on void * heavily in my experience.

Personally I'm a huge fan of generics but I can understand how the keepers of Go might be reluctant to go down the path of C++, Java and C#.

The FAQ is still accurate.

-rob"

"The time has come to change Go, given what we have learned over the past decade of using it in production. -rob"

the reason this proposal was accepted is because rob and others liked this plan and said over a decade of production taught them it is an important thing to have, in fact rob asked wadler and company to help get things right for go.. so i would say you'd bet wrong

And many C programs just emulate them using crazy macros, that are harder to write and are less typesafe than proper generics.

I do not remember him being against generics. He is the one who contacted his former colleague Phil Wadler to help with the theoretical validation of the type parameters proposal. In his talk about the Go 2 draft specifications (back then the proposal was still based on contracts) he was positive that a good design can be found. (*) https://www.youtube.com/watch?v=RIvL2ONhFBI

Rob Pike has nothing against generics and never expressed criticism of them. His concern was always fairly practical; among the numerous forms of generics that exist among different languages, and the significant variation and rapid evolution of them, how can such a feature be safely added to the language?

Apparently he's nervous but can think of useful applications of generics: https://old.reddit.com/r/golang/comments/jditu9/what_do_gene...

Robert Griesemer was a coauthor on the Featherweight Go paper so I'm assuming he supports it. I would assume Ken Thompson doesn't care for generics but I think he's retired so he wouldn't vote on it anyway.

The bottom line is that generics allows the production of safer, more robust, more evolvable, more documented, more performant, code.

Along with static typing, generics are simply a feature that no language created recently should be without.

I can read generic code in multiple languages even when I'm not fluent in these languages.

Once you get used to generic code, it actually becomes easier to read and understand than code where everything is type cast or Object typed all over the place.

Simple generic code is fine, but generics can be abused to over engineer things.

IMO Golang needed sum types and match statements, but it didn't need generics.