Earlier quoted context omitted.
> If you haven't written any Go code, how can you know what weaknesses are significant? First of all, I have written Go code, I just wouldn't call myself an expert. And lack of generics becomes a pain in the ass rather quickly. I decided to come back when they had added generics, but it turns out that isn't happening. But even if I hadn't ever written a line of Go, I don't think that would invalidate my opinion, beca…
My apologies, there didn't seem to be much to address. > the only people who would use Go are people who aren't aware of the last few decades of compiler research: people who think coroutines are a new idea and aren't sure whether generics are useful This is simply untrue. Most developers I know that like Go have written tens of thousands of lines of code in other languages that do have generics and more advanced fea…
If people disagree with me on things that are pretty solidly proven by my experience, then yes.
> How about if people disagree with you because we have different tastes in languages?
I mean, if you're argument basically comes down to, "That's just, like, your opinion, man", then I'd counter that its pretty objectively true that people are more productive in some language than others.
> ...that generics are not needed in many of the cases where they're used. That YAGNI holds true a lot more often than they think. I had actually started coming to this conclusion (about generics) before I even started writing Go - and I'd already started using them less. Not having foo> in my code simplified it a lot, and given that most of the time I only ever implemented one version... it just wasn't worth defining a whole bunch of generic logic, when really I only had one concrete implementation that I'd ever use.
So your position is that we should take away features that people overuse?
There are tons of places where you just need a few functions, not a class with a bunch of methods on it. How far are you going to take this logic?
If you want to be babysat by your language, write Java.
> You say you've written Go and the lack of generics was a problem rather quickly. I have been writing Go for almost 2 years full time and 9 months on the side before that. Generics have almost never been a problem for me.
Well, there are a few explanations for that:
1. You've worked in a very narrow domain.
2. You're willfully pretending the problem doesn't exist so you can feel good about your chosen language.
3. You're completely not seeing the numerous cases where your code has duplication which could be removed using generics.
> You have to use the language in the way it was designed.
On the contrary, if the language is designed poorly I do not have to use it at all.
> It's a matter of opinion, and opinions can't be wrong.
So, lacking justification, you just segment off what you're saying into the realm of opinion, where if you believe hard enough anything you want can be true!
EDIT: A funny thing is that the Go core project itself is apparently not one of those projects you claim exist that don't benefit from generics. See here[1] about halfway down the page:
> A weakness of Go is that any generic-type operations must be provided by the run-time. Some day that may change, but for now, to make working with slices easier, Go provides a built-in generic append function. It works the same as our int slice version, but for any slice type.
But sure, that will never come in handy in most projects.