|
|
|
|
|
by coldtea
2475 days ago
|
|
>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. |
|
"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%.