> You seem to assume that because people disagree with you, that they must just be ignorant.
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<bar<baz>> 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.
> > You seem to assume that because people disagree with you, that they must just be ignorant.
> If people disagree with me on things that are pretty solidly proven by my experience, then yes.
I guess I just am aware that others may have had different experiences than I have, and unless their opinion is way out in left field (like, "programming in assembly is just as productive as python")... then I assume they're not ignorant. People think Ruby is fantastic and I think it's pretty horrible, but I don't think they're ignorant of other languages, they've just developed different tastes.
> So your position is that we should take away features that people overuse?
Some of them, yes. Go doesn't have the ternary operator. I consider that a good thing. I've seen critical security bugs that had been in production code for years because someone misused the ternary operator in a way that never would have happened with a boring old if/else.
> 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!
I'm saying that what makes a language good or bad is generally subjective. I don't think you can objectively say one language is better than any other except in extreme cases. Is Haskell better than Python? Is C# better than OCaml? It's like asking if minvans are better than sports cars... it depends on what you want to do with them and what you enjoy. I used to like to floor it getting on the highway and hearing the engine rev as I was pushed back into the seat of my v6-powered sedan... now I take great satisfaction in throwing a new couch in the bed of my truck and not having to wait or pay for delivery. Is my truck better than my sedan was? Would my truck be better if it had the same 0-60 time as my old car? Sure... it would also cost like $15k more. There are always tradeoffs.
You say the Go community is being blind to the benefits of generics, and we say you're being blind to the costs of generics. And I don't mean compiler complexity or speed. I don't give a fig about the compiler. I care about the complexity of the code. I care about error messages that make you open up 4 different files to try to figure out what combination of code is actually being run in a single place.
I don't think we're going to agree here, and that's fine.
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<bar<baz>> 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.
[1] http://blog.golang.org/slices