As for the detractors, from the first generics proposal this was called out as a "not now", not never. There were questions of implementation. They aren't a super large team, and they try to do things incrementally and do them well.
Go: Support for Generic Methods
11–20 of 288 posts
Re: Go: Support for Generic Methods
#12Earlier quoted context omitted.
It's not a bad thing to realize that one can be wrong and then strive for change.
There’s a fine line between being willing to change your mind and getting the basics wrong. Go has repeatedly gotten the basics wrong.
Re: Go: Support for Generic Methods
#13Earlier quoted context omitted.
Maybe, but personally I've become quite tired of programming languages "organically grown" as opposed to properly designed the first time. After a good decade of C then C++, I found ANSI CL (despite being a massive compromise and unfinished) much more coherent and complete than both.
So which language had it right from the start? is there a language that has a very low rewrite status?
As an aside - D, Zig, Rust, even typescript got most of the lessons learned from C right
Re: Go: Support for Generic Methods
#14Earlier quoted context omitted.
There’s a fine line between being willing to change your mind and getting the basics wrong. Go has repeatedly gotten the basics wrong.
Sounds like you want this feature, and you just got it. Not sure how that's wrong. You don't add in every feature from the start.
Re: Go: Support for Generic Methods
#15Earlier quoted context omitted.
It's not a bad thing to realize that one can be wrong and then strive for change.
I don't think anyone admitted any wrong or had any big change in philosophy. It's always a good thing to learn something along the way. But the current message seems to be that this was the plan all along, and it just took some time to design properly. Of course adding generics is not something that every language needs to do. Scripting languages like Ruby don't really need this style of generics. It doesn't fit the…
Re: Go: Support for Generic Methods
#16slowly implementing all the things they said we didn't need
Re: Go: Support for Generic Methods
#17Earlier quoted context omitted.
It's not a bad thing to realize that one can be wrong and then strive for change.
Maybe, but personally I've become quite tired of programming languages "organically grown" as opposed to properly designed the first time. After a good decade of C then C++, I found ANSI CL (despite being a massive compromise and unfinished) much more coherent and complete than both.
Re: Go: Support for Generic Methods
#18Re: Go: Support for Generic Methods
#19Earlier quoted context omitted.
Maybe, but personally I've become quite tired of programming languages "organically grown" as opposed to properly designed the first time. After a good decade of C then C++, I found ANSI CL (despite being a massive compromise and unfinished) much more coherent and complete than both.
Scheme is (or at least was) coherent. You don't need to look any further than set/setf/setq to see that Common Lisp is "organically grown" from the fertilizer of a committee. CL does its best to make every other lisp more attractive.
Re: Go: Support for Generic Methods
#20Earlier quoted context omitted.
It's not a bad thing to realize that one can be wrong and then strive for change.
Maybe, but personally I've become quite tired of programming languages "organically grown" as opposed to properly designed the first time. After a good decade of C then C++, I found ANSI CL (despite being a massive compromise and unfinished) much more coherent and complete than both.