Live data from Hacker News

Go: Support for Generic Methods

github.com

11–20 of 288 posts

Re: Go: Support for Generic Methods

#11
This is great. Will be useful for data access methods!

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.

Re: Go: Support for Generic Methods

#12
post #10

Earlier 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.

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

#13
post #5

Earlier 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?

That’s whataboutism - no language is perfect, but given when go released it’s fair to hold them to a higher standard than languages what were designed 25 years earlier.

As an aside - D, Zig, Rust, even typescript got most of the lessons learned from C right

Re: Go: Support for Generic Methods

#14
post #12
post #10

Earlier 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.

I wanted it 10 years ago.

Re: Go: Support for Generic Methods

#15
post #6

Earlier 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…

Type hinting seems like the worst of both. You pay the cost on refactor to go change them all, where dynamic typing or static type inference avoid that. You also don't have any of the benefits of static or dynamic typing. My strong preference is static typing with good inference and an ide that shows the inferred types everywhere when asked. Dynamic typing can make some tasks dramatically easier, I'm just not capable of using them without making hideous mistakes.

Re: Go: Support for Generic Methods

#16
post #2

slowly implementing all the things they said we didn't need

Of course, if you go back and watch the original Go announcement it said that it would need generics once they figured out how to do it. And when the first version of generics landed it was said that generic methods would be added later, once they figured out how to do it. So that isn't applicable here. The need was always recognized.

Re: Go: Support for Generic Methods

#17

Earlier 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.

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

#19
post #17

Earlier 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.

Which Scheme are we talking about? R5RS? R7RS-small? R6RS? With SRFIs? Without? Which scheme? Is it `(library...)` or `(define-module...)`?

Re: Go: Support for Generic Methods

#20

Earlier 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.

ANSI CL is such a breath of fresh air nowadays. Does what you need, doesn't get in your way, comes with batteries included. And conditions are just god-tier.
Post reply on HN