Live data from Hacker News

Go: Support for Generic Methods

github.com

281–288 of 288 posts

Re: Go: Support for Generic Methods

#281
post #66

Earlier quoted context omitted.

D literally can't even maintain backwards compatibility between minor version updates not to mention a big part of the D community left when D reinvented itself with D2. Among languages it's probably the one that is constantly in a state of flux.

what's a big project built with D? I feel it gets mentioned a lot on hackernews but I've never run into any project using it in the wild.

Flutter

Re: Go: Support for Generic Methods

#282
post #66
post #13

Earlier quoted context omitted.

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

D literally can't even maintain backwards compatibility between minor version updates not to mention a big part of the D community left when D reinvented itself with D2. Among languages it's probably the one that is constantly in a state of flux.

Really? Wow, this is like Zig and I love Zig!

Re: Go: Support for Generic Methods

#283
post #271
post #254

Earlier quoted context omitted.

You added the word "want", the OP said "need". "We don't ever expect to add X" implies "we don't think we need X."

Clearly we don’t need this feature. Just because the Go team decides to implement a feature doesn’t imply that they must think that the language needs the feature. You’re searching for contradictions where none exist.

Ah, then they’re implementing needless features! What’s worse! lol

Re: Go: Support for Generic Methods

#284
post #283
post #271

Earlier quoted context omitted.

Clearly we don’t need this feature. Just because the Go team decides to implement a feature doesn’t imply that they must think that the language needs the feature. You’re searching for contradictions where none exist.

Ah, then they’re implementing needless features! What’s worse! lol

Most programming language features are not strictly needed. They’re just quality of life improvements that are on balance a good addition to the language.

Re: Go: Support for Generic Methods

#285
post #272
post #183

Earlier quoted context omitted.

Thankfully we already have Java, so using Go is really for the scenarios where it cannot be avoided.

Thankfully some of us have taste.

Which is why we use platforms and languages that offer superior GCs, optimization, speed, and observability, like the JVM and Java.

Re: Go: Support for Generic Methods

#286
post #284
post #283

Earlier quoted context omitted.

Ah, then they’re implementing needless features! What’s worse! lol

Most programming language features are not strictly needed. They’re just quality of life improvements that are on balance a good addition to the language.

Sure, but if you take that view, everything above assembly is a QOL improvement and we really don't need anything. That definition is pretty useless though.

Re: Go: Support for Generic Methods

#287
post #286
post #284

Earlier quoted context omitted.

Most programming language features are not strictly needed. They’re just quality of life improvements that are on balance a good addition to the language.

Sure, but if you take that view, everything above assembly is a QOL improvement and we really don't need anything. That definition is pretty useless though.

[deleted]

Re: Go: Support for Generic Methods

#288
post #286
post #284

Earlier quoted context omitted.

Most programming language features are not strictly needed. They’re just quality of life improvements that are on balance a good addition to the language.

Sure, but if you take that view, everything above assembly is a QOL improvement and we really don't need anything. That definition is pretty useless though.

Hmm, I don't think so. Go needs a string type to be a usable high-level programming language, but it doesn't need, say, the 'any' alias for 'interface{}'. Some features are more central than others. Perhaps none are 100% essential or inessential, but some features are clearly closer to one end of the spectrum than the other.
Post reply on HN