Python is a dynamically typed language so when you say you've never used generics, that makes sense -- the concept does not apply to dynamically typed languages. But I bet you frequently use lists and dictionaries, and perhaps occasionally use higher-order functions like map, filter, and reduce. All of those would be generics in a typical statically typed language, because with static typing you don't just have "a list" but "a list of ints" or "a list of strings".

Go has built-in generic arrays, slices, and dictionaries, but nothing else, and you can't define your own functions that work on those without specifying the type. So say you write a function that shuffles the elements of an array, like Python's random.shuffle(list). You can't make your function work for all kinds of arrays. You have to have a different function to shuffle arrays of strings, arrays of ints, arrays of FooBarClass, etc. even though the shuffling logic doesn't give a damn about what sort of thing is in the array.

I have a suspicion that this occasionally leads developers to write code inline that they previously would've extracted into a utility function. See the answers here:

https://stackoverflow.com/questions/12264789/shuffle-array-i...

Thanks. I took a year of CS ten years ago and haven't had to do statically typed development of any size since then - certainly not developing libraries.

So essentially, containers and function overloading is damned near impossible. Got it.

Python doesn't need generics because it doesn't try to statistically type your code in the first place.

    def example(a):
        return a

Would be perfectly legal python code. But in Go you would have to choose the type of A and duplicate the function under a different name if you want it to work with a different type.

So, when a language implements static typing without generics they actually mean 'lots of code and approaches legal in Python would be rejected'.

So it doesn't add a feature to the expressiveness of the code. It fixes a bug in the type system so that the expressive code is considered legal. Of course better type systems have existed since the 70's, but the set of people that know the ins and outs of how to implement those and the trade offs behind it does not include Rob Pike. His interests and skills are different (and the cause of some of the better features of Go)

When you don’t have type safety you don’t need generics. Example: in python you can call a function with any arguments (numbers, strings, whatever) and it can return anything (usually something of the same type). With go you can do this as well, but you lose compile time type safety, have to add a bunch of gross code, and incur a small performance penalty.

> Why are generics such a critical component of a programming language that every thread about Go mentions it?

Personally, I do not feel that strongly about generics; it would be nice to have them, but for my purposes, I can live without them.

But still: generic container types would be very nice. I don't need to use it very often, but Go's sort.Sort is very uncomfortable to use. If Go had proper generics, it would be easier to define a "generic" interface to iterate over things - currently, Go's builtin slice and map types are privileged over user defined types. There are probably more issues I cannot think of right now.

None of those are deal breakers for me. Go is highly compatible with the way my mind works, to such a degree I can easily forgive it all the things I do not like about it. But I also work in C# from time to time, and seeing how the .Net framework uses generics makes me wish Go had them, too.

Here's a framing I found useful: as a user of a library, you may not particularly use generics. But as an implementor of a library, on the other hand, they're extremely useful.

However, comparing to Python won't make much sense; people see generics as essential to statically typed langauges. You don't need them for dynamically typed ones!

> Here's a framing I found useful: as a user of a library, you may not particularly use generics. But as an implementor of a library, on the other hand, they're extremely useful.

Agreed. Something that's been underlined for me since picking up TypeScript in addition to JavaScript. I can take or leave TS when writing a script, but I consider it indispensable when writing a library.

In Python, duck typing provides the benefits of generics, minus the static guarantees. If you're using duck typing in python, then you should be able to understand why generics can be useful.

Go uses structural typing which feels like duck typing but it's actually checked at compile time.

That's the reason why the Go community feels generics are not the top priority (euphemism.)

Only in very specific cases (implementing data structures, for example) you can feel the need for generics. Maybe also in serialization, although that's really normal to pass a generic container (object, void *, interface{}) and use introspection.