Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go: Support for Generic Methods

github.com

Post reply on HN
Print view View original

241–250 of 288 posts

Re: Go: Support for Generic Methods

#241

Post by [deleted] »

stouset wrote: post #91
skywhopper wrote: post #78

Earlier quoted context omitted.

Is anyone actually mad about this, or do people just bring it up to stir the pot? Who cares what the FAQ says? They've worked out a way to add it easily in a backwards compatible way that can solve some problems. They had not identified this solution at the time they wrote the FAQ, and Go has been perfectly usable without this feature for 16 years.

We care that time and time again, when anyone ever brings up a criticism of the language, they’re told that everything is just fine and it’s not a problem and we just don’t get the Go Philosophy. There’s not a problem, stop trying to make Go like every other language, and changing things would make the language more complicated and worse. Then when the language is inevitably changed for the better, resolving the comp…

[deleted]

Re: Go: Support for Generic Methods

#242

Post by davidatbu »

apatheticonion wrote: post #227

I wrote Go professionally for years. I don't know how many hours I've spent debugging and reviewing nil pointer bugs and race conditions. Generics were sorely needed but the initial implementation was lacking. I moved to Rust professionally 4 years ago and haven't looked back. Mutex Option Result are all phenomenal. I've written everything from web backends, frontends (hurry up wasm, seriously), to Node.js and Python…

By frontend, do you mean wasm in the browser? I'd have expected multithreading there, especially in wasm, to be extremely unergonomic.

Maybe you mean to refer to concurrency?

Re: Go: Support for Generic Methods

#243

Post by Falell »

Boxxed wrote: post #239
Merovius wrote: post #177

Earlier quoted context omitted.

> but the reason against using runtime reflection is mostly that it's slow. More specifically, it is that it would introduce surprising performance cliffs – code becoming surprisingly slow due to seemingly unrelated changes. Though BTQH I think an even more important argument is that you would need to have effectively two generics implementations, one working at runtime and one working at compile time. That's a lot o…

BTQH?

Maybe a typo for To Be Quite Honest?

Re: Go: Support for Generic Methods

#244

Post by axod »

And so the cycle will continue. Always a shame when languages cave like this and add extra unnecessary complexity and error prone hard to parse syntax.

It'll be interesting to see the next language that comes along rejecting bloat in favor of simplicity, and then we can all start again.

Re: Go: Support for Generic Methods

#245

Post by zerotolerance »

pjmlp wrote: post #173

Go becoming a proper 21st century language, is like pulling teeth. It is Apple's school of design, think different, ah, actually, there are reasons why the fence is in the middle of nowhere. Then the design ends up half way there versus being done properly from the beginning.

Your comment could have been, "I've never agreed with the design philosophy behind Go." I've always appreciated the apparent Go design philosophy and feel like it most matches my lessons learned from 20 years in software. Feature minimalism is a feature for languages targeting organizations with thousands of programmers. If by 21st century language, you mean one that has become unrecognizable through multiple generations of fashionable feature and ecosystem thrash then I'm all for Go not becoming a 21st century language. Language should be boring if the target environment is large teams with varied skill sets. Plain speak. Low jumpy behavior. No cream, no syntactic sugar. Get the job done.

Re: Go: Support for Generic Methods

#246

Post by tapirl »

jimbokun wrote: post #232
tapirl wrote: post #169

Earlier quoted context omitted.

Go's generics design is the most clunky one among popular languages.

What’s the approach they should have used instead and how would it be better? Especially in terms of keeping fast compile times and overall performance.

[dead]

Re: Go: Support for Generic Methods

#247

Post by stouset »

piekvorst wrote: post #238
jamesfinlayson wrote: post #146

Earlier quoted context omitted.

Yeah, I worked with a guy in the late 2010s - one of the most painful people I've ever worked with - who would tell anyone that would listen that Go (as it was in 2018) was the perfect programming language - it had all the features you'd ever need - no more, no less. It doesn't need generics, the package management story is fine etc. Thankfully he's been out of my life for a long time now but I believe he's still wri…

This is an outlier. The Go team and community never endorsed that. In fact, their position has always been the opposite. To give just one example, see [1]. [1]: https://research.swtch.com/dogma

I think it’s pretty clear this post was a response to the clear dogma within the community.

> But we need help from everyone. Remember that none of the decisions in Go are infallible; they’re just our best attempts at the time we made them, not wisdom received on stone tablets.

Re: Go: Support for Generic Methods

#248

Post by ethin »

MrBuddyCasino wrote: post #206
ethin wrote: post #192

Earlier quoted context omitted.

Now there's a surprise. I've generally been very disillusioned with Go after they absolutely stonewalled everybody on uint128 (and continue to do so) for absolutely no reason (and ignoring that it would make many things in the language easier to express).

> it would make many things in the language easier to express Like what?

Like IPv6 addresses, UUIDs, the list goes on. Does it mean anything that Go themselves had to invent a custom uint128 type in the standard library because they didn't want to add it to the language? There's a very long list of instances of them stonewalling it here: https://github.com/golang/go/issues/9455

Re: Go: Support for Generic Methods

#249

Post by [deleted] »

pjmlp wrote: post #190
9rx wrote: post #162

Earlier quoted context omitted.

> and averse to the idea of using other people's work. They did use someone else's work, though. If you recall, Philip Wadler (of Haskell fame) designed Go's generics. > but by so doing end up with poor reinventions of well-studied concepts. Which is funny as there is probably nobody on earth that would be more capable than Wadler to get the job done. His pedigree in that area of work is pretty astounding. If he coul…

Yes, the same guy that supported the effort to add generics to Java, a decade beforee Go came to be, talk about not getting language design history. Stop excusing them, they were the first to acknolowdge being wrong in first place, "They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. W…

[deleted]

Re: Go: Support for Generic Methods

#250

Post by 9rx »

pjmlp wrote: post #190
9rx wrote: post #162

Earlier quoted context omitted.

> and averse to the idea of using other people's work. They did use someone else's work, though. If you recall, Philip Wadler (of Haskell fame) designed Go's generics. > but by so doing end up with poor reinventions of well-studied concepts. Which is funny as there is probably nobody on earth that would be more capable than Wadler to get the job done. His pedigree in that area of work is pretty astounding. If he coul…

Yes, the same guy that supported the effort to add generics to Java, a decade beforee Go came to be, talk about not getting language design history. Stop excusing them, they were the first to acknolowdge being wrong in first place, "They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. W…

> Stop excusing them

What is there to excuse? Your quote confirms that they simply don't know what they're doing as was already established. Not that anyone should expect them to. They're just regular average humans, same as every other random Joe you encounter while walking down the street, who all equally have their own failings and shortcomings. Why HN is constantly trying to put these particular people on a pedestal, I'll never know. Jealously that regular bumbling idiots just like them accidentally stumbled into creating something popular (for some definition of popular), perhaps?

Post reply on HN