You can make this argument with nearly anything we naturally accept as a feature of a programming language. The ability to name things has a long history of abuse. The ability to define types, implement programming patterns, define new syntactic features via high order functions, use concurrency primitives. Hell, simply the idea of programming is rife with potential for abuse.
This is a narrative without specifics, and unfortunately always where the conversation seems to end with gophers. We accept some amount of features that can be abused because they offer utility that outweighs their potential for misuse. So how exactly are generics a worse offender than these other features or a worse tradeoff for their utility? Because from my perspective, being able to define parametric data types and functions is a huge win for safety and terseness of code without a lot of downside.
Hell, simply the idea of programming is rife with potential for abuse.
Exactly. Everything you add has a cost/benefit for a particular context. Evidently you disagree with how the Golang team has calculated cost/benefit with regards to generics.
Because from my perspective, being able to define parametric data types and functions is a huge win for safety and terseness of code without a lot of downside.
Terseness is a good thing? Some people say terseness is bad. Is safety the only issue or always the top priority? All production code exists in a specific context. It's best to tailor to your specific context. This may well mean that you may encounter a context where you do not want to use Go.
> Terseness is a good thing? Some people say terseness is bad.
Clarity is good. Clarity comes from both including every relevant detail (which pulls away from terseness) and excluding irrelevant details (which pushes towards terseness). Clarity also comes from saying everything that has to be said exactly once and no more than that (which pushes towards terseness).
Unfortunately, when you program in Go, you often have to pay attention to irrelevant details, and you have to say what you want more than once.
> Is safety the only issue or always the top priority?
The benefits of typeful programming go beyond type safety. They also include: “economy of thought”, “fearless refactoring”, “less time wasted on fixing stupid mistakes”, etc.
The benefits of typeful programming go beyond type safety. They also include: “economy of thought”, “fearless refactoring”, “less time wasted on fixing stupid mistakes”, etc.
Funny, but that's exactly what we Smalltalkers had in Smalltalk -- with far less of the "type system" enforced by the compiler and almost all of it in our heads. (That said, back in the day, we had tooling which was more advanced while also being more responsive, years ahead of everyone else, so our viewpoint might be skewed.)
> with far less of the "type system" enforced by the compiler and almost all of it in our heads
That's why reasonable people want to have good type systems: People who think that they can keep the type system in their head are exactly the people whose opinion should be ignored.
> Funny, but that's exactly what we Smalltalkers had in Smalltalk
Smalltalk doesn't let you say “this object responds to message Foo only when used in this part of the program”. In other words, there's no separation of concerns.
> and almost all of it in our heads
What you realistically can't produce entirely in your head is a proof that your program is correct, unless the language is explicitly designed to lift part of this proof obligation. That's exactly the role of parametricity: to help you separate concerns, allowing you to prove one small thing at a time.
Smalltalk doesn't let you say “this object responds to message Foo only when used in this part of the program”.
In VisualWorks, there were different two ways of writing a short script to verify this in a matter of seconds. You could also sometimes achieve this with a few cascaded searches through the Refactoring Browser.
This doesn't scale to either large programs or programs not entirely written by yourself.
My industry experience clearly shows that you're just flat wrong -- with multiple large systems written by other people over the span of over a decade.
As a library author, you can't search code written by users of your library.
What kind of nonsense is this? The library author doesn't need to do such a search! The library users in Smalltalk would do such searches. Access to source was the norm. Decompilation in Smalltalk is trivially perfect, excluding local variable names, so closed source was fairly pointless.
> My industry experience clearly shows that you're just flat wrong
Please tell me how a code search performed by library author Foo will ensure that library user Bar won't break invariants Foo intended to enforce.
> What kind of nonsense is this?
In ML, I can prove that users my library can't use my library wrong. Maybe they won't be able to use my library at all - they type checker will reject every attempt. But it guarantees that, if they can use my library, they will use it right, in the sense that every invariant I enforce won't (and can't possibly) be broken by users.
For example, there may be multiple ways to realize the same ordered set as a red-black tree (balanced differently), but I can arrange things so that the difference can't be observed by users of the ordered set abstraction.
> The library users in Smalltalk would do such searches.
Library users shouldn't be in the business of enforcing invariants that are only relevant to the library's author. See? This is what I mean by “Smalltalk can't separate concerns”.
I'm not saying all of this to be mean. It's been known for quite a while that parametricity is the mathematics of abstraction and separation of concerns [0]. If you need to insulate users of your code from your design choices, you absolutely need parametricity. (Or “social conventions”, but those don't work in the long run.)
This is a narrative without specifics, and unfortunately always where the conversation seems to end with gophers. We accept some amount of features that can be abused because they offer utility that outweighs their potential for misuse. So how exactly are generics a worse offender than these other features or a worse tradeoff for their utility? Because from my perspective, being able to define parametric data types and functions is a huge win for safety and terseness of code without a lot of downside.