Live data from Hacker News

Go: Support for Generic Methods

github.com

21–30 of 288 posts

Re: Go: Support for Generic Methods

#21
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.

Declaring a highly successful language as having the basics wrong means that you are not correct about the basics that were needed.

Re: Go: Support for Generic Methods

#23
post #17

Earlier quoted context omitted.

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...)`?

Heh, I'd probably take R4RS with define-syntax :-)

Re: Go: Support for Generic Methods

#24
post #2

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

It's not a bad thing to realize that one can be wrong and then strive for change.

It’s still annoying ~20 years after Java did the same mistake of not including generics, which was already clear to many people with C++ experience back then.

Re: Go: Support for Generic Methods

#25
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.

Declaring a highly successful language as having the basics wrong means that you are not correct about the basics that were needed.

An engineer, of course, understands that there is no such thing as "wrong", only different tradeoffs, but with the rise of "vibe coding" you don't need to be an engineer to play in the world of programming anymore.

Re: Go: Support for Generic Methods

#26

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.

Gophers are usually quite fast, perhaps an elderly turtle would be a better mascot?

Re: Go: Support for Generic Methods

#27
This resolves a big gap in generics for most people coming from other languages to go so I completely approve this direction. Not saying use it everywhere but if you must use it, it’s better to have it on the struct than call a module level generic func.

Re: Go: Support for Generic Methods

#28
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.

Declaring a highly successful language as having the basics wrong means that you are not correct about the basics that were needed.

It's a highly successful language because (1) it was backed by Google, and (2) created by Robert Griesemer, Rob Pike, and Ken Thompson.

If it came out of anywhere else, it might have struggled even to hit the homepage here.

Re: Go: Support for Generic Methods

#29
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.

Declaring a highly successful language as having the basics wrong means that you are not correct about the basics that were needed.

Something can be highly succesful in spite of having glaring design flaws. Nobody is claiming go isn't wildly succesful, but it's _in spite_ of these issues. It was clear over a decade ago that iota, gopath, and lack of generics were massive kneecaps to the language; go changing it's mind on those things isn't progress it's just getting the fundamentals wrong.

A good example of where they're kind of stuck is date formatting - it's stupid, unclear, and likely a mistake, but it's not a fundamental flaw; it's just a quirk.

Re: Go: Support for Generic Methods

#30
post #9
post #5

Earlier quoted context omitted.

So which language had it right from the start? is there a language that has a very low rewrite status?

I'd particularly like examples of statically typed languages that "got it right" (since I love me my types)

Ocaml maybe? Multi threading didn't seem necessary and introduced the possibility of data races.
Post reply on HN