>The other definition of generics that _is_ satisfiable by (untyped) Python--the definition you presumably had in mind--is equally satisfiable by Go via its `interface{}` type. So regardless of which definition you adhere to, "Go lacks generics" is no more valid a criticism for Go than for Python.

Well, that's not exactly the case. Interface{} might have the same tradeoffs with Python's dynamic types (plus more ceremony), but that's not the real issue.

Python is inherently a dynamic typed language, so not having types and generics is expected and idiomatic.

For Go, you have a type system and static type checking, but you can't properly use it when you resort to interface{} to make generic algorithms.

So while for Python not having types/generics is business as usual (and that's part of the very promise of the language), for Go not having generics means losing two of it's main promises, static type checking and speed.

For whatever it's worth, I'm a proponent of generics in Go.

"Static type checking" does not mean "every conceivable program is safely expressable by the type system". Haskell doesn't make this promise and neither does Go.

Anyway, Go is as slow and as unsafe as Python in the ~1-5% of code that is generic. It's still a pretty good deal even if you were mistakenly expecting 0%.

>"Static type checking" does not mean "every conceivable program is safely expressable by the type system". Haskell doesn't make this promise and neither does Go.

No, and I didn't make this claim or demand this either.

But it should mean: "any algorithm variation where just the type changes should be expressable by the type system without me having to rewrite e.g. a sort list for int64 lists, int32 lists, float lists, etc, it's 2019 already".

That's not what static typing means. If you want it to mean that, go right ahead. I agree that Go should support that feature, but it has no bearing on the definition of static typing nor on Go's position relative to Python with respect to speed or safety.