Rust has manual memory management. Most applications where you'd use Go don't need nor want the added complexity of managing memory, ownership, learning curve, etc. It's not really a reasonable exchange.
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.
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.
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.
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.
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.
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.
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.
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.)