[mattnewton]

In my case it's python, Rust has a bit more of a learning curve / productivity hit. I'm still complaining though because I like what Go is doing with concurrency and simplicity, but I think it would be almost perfect if it just trusted the user a bit more.

[woah]

You say you like the simplicity, yet you are complaining about it.

[mattnewton]

Besides the fact that I think it's less simple to have ad-hoc compiler extensions for the standard library types that can't be replicated in userspace, so the alternatives are code generation and type erasure, it doesn't have to be an absolute principal! We can have generics without sliding towards some slippery slope of abstraction! You don't allow some kind of generics one day and wake up the next day with custom operators and monads. The buck really can stop at this one pain point.

[karma_vaccum123]

Okay, that's nice, but the Go developers already picked their side in the debate many years ago. If you don't like it, use one of the many other tools available.

[stcredzero]

I think it would be almost perfect if it just trusted the user a bit more.

If it trusted the user just a bit more, it would be making many of the same mistakes other languages make, which Go is trying to avoid. You're free to go and use some of those other languages.

[mattnewton]

I don't understand this attitude. I do use other languages, and I can tell you type polymorphism is not a mistake. Complicated architectures full of abstraction are a mistake, which you can limit without sacrificing the ability for me to make a type-safe generic function.

[stcredzero]

I can tell you type polymorphism is not a mistake.

It's a particular trade-off. Some opine that it's not the right trade off. You disagree.

Complicated architectures full of abstraction are a mistake, which you can limit without sacrificing the ability for me to make a type-safe generic function.

From what I've seen, the other mechanisms for limiting over-exuberant abstraction don't work well enough over the long term, at scale.

[pcwalton]

> From what I've seen, the other mechanisms for limiting over-exuberant abstraction don't work well enough over the long term, at scale.

Can you name a specific example of people using ML-style generics (i.e. no typeclasses, no module system) to achieve "over-exuberant abstraction"?

[stcredzero]

Nope. You got me there. I'm not so sure that would be cheap to implement in Golang, though. Also, your comment prompted me to find and read this:

http://people.cs.uchicago.edu/~jacobm/pubs/templates.html

[pcwalton]

> If it trusted the user just a bit more, it would be making many of the same mistakes other languages make, which Go is trying to avoid.

Can you explain with an example that would apply to Go how introducing generics to a language was making a mistake? Be specific.

[stcredzero]

Can you explain with an example that would apply to Go how introducing generics to a language was making a mistake? Be specific.

These things are epiphenomenal, and have to do with what happens in large codebases over a long time, with lots of programmers. It's a fallacy to suppose that neat StackOverflow sized examples are some kind of a evidence gold standard. The problems I've encountered with C++ templates have to do with the interaction of several things at once, in places I'd have to dig out of version control, in codebases I can't share. So no, I'm not signing up for doing that work for you for free.

[pcwalton]

I'm not asking for examples of bad interactions between C++ templates and other features of C++--there are tons of those. I'm asking for examples of languages in which implementing simple generics was a bad idea in retrospect.

(I don't think there are any such examples, because simple ML-style generics yield a lot of power for negligible drawback, and I hope that future versions of Go add them.)

[pjmlp]

I won't happen, there was this presentation some time ago that the language design was done and their focus was improving the runtime and tooling.

Hence why I decided to stop arguing about Go's lack of generics and rather advocate it for those that search for a C + GC with improved type safety.

For the rest of us there are better options.