[knucklesandwich]

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.

[stcredzero]

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.

http://anomaly.org/wade/blog/2013/07/coding_style_terse_vs_v...

[catnaroek]

> 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.

[stcredzero]

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.)

[premium-concern]

> 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.

[catnaroek]

> 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.

[stcredzero]

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.

[catnaroek]

> In VisualWorks, there were different two ways of writing a short script to verify this in a matter of seconds.

This doesn't scale to either large programs or programs not entirely written by yourself.

In ML, there's no need to search anything: the only admissible operations on a value are those sanctioned by its type.

> You could also sometimes achieve this with a few cascaded searches through the Refactoring Browser.

As a library author, you can't search code written by users of your library.

In ML, I can prove things not only about my own code, but also about how others may use it.