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

How generics are implemented in Go 1.18

github.com

Post reply on HN
Print view View original

201–210 of 228 posts

Re: How generics are implemented in Go 1.18

#201

Post by simias »

foldr wrote: post #148
simias wrote: post #143

Earlier quoted context omitted.

I also couldn't help gloat a bit thinking about all these bad faith arguments I heard coming from the Go community over the years about how the lack of generics was not such a bit deal and generics sucked anyway. I especially remember one particular document where some Go devs claimed to make an "unbiased" study of the pros and cons of generics and it was ridiculously one sided (if somebody remembers what this docume…

Does it help to make such vague references to bad faith arguments? If you want to point to something specific that someone said, then fine, but otherwise it seems like you're just stirring up discord. No programming language is loved only by rhetorical geniuses. Of course you can find some people who've said some silly things about Go or generics. But so what? You can also find people who've said silly things about y…

I wasn't making an argument at all really, just sharing my point of view. I also didn't think that the claim that many bad faith arguments regarding the utility of generics came from the Go community would be scrutinized and needed supporting. Besides it's irrelevant and petty to bring it up now, I'm more interested to see how these new generics fare.

Re: How generics are implemented in Go 1.18

#202

Post by saturn_vk »

kerkeslager wrote: post #180
vgchh wrote: post #96

Earlier quoted context omitted.

Well let perfect not be the enemy of the good. The reality is that Go is wildly successful in practice for good reasons that have been hashed numerous times. As a result tons of Cloud software is written in Go. There is nothing Go needs to be ashamed on. Its mindshare is a result of a good choice people made at a certain point in time. A better language will win at its own merits.

I'm not letting perfect be the enemy of good, I'm saying Go isn't good . No language is perfect, but there's literally not a single use case I'd choose Go for, because there are a dozen languages that do almost everything better. > Its mindshare is a result of a good choice people made at a certain point in time. Its mindshare is a result of Google using it, and people mistakenly thinking that if Google uses it, it m…

That's OK. But saying it isn't good as a fact is a bit misleading. If it wasn't any good, it would not be used and would've faded to obscurity a long time ago. That is not the case, so there must be some redeeming qualities to is

Re: How generics are implemented in Go 1.18

#203

Post by saturn_vk »

rat9988 wrote: post #181
throwaway34241 wrote: post #100

Earlier quoted context omitted.

I’m not going to defend what random internet commenters may have said, but in my view the core team has been fairly consistent and their design decisions (to me) make sense. The first thing to understand is that Go occupies a space lower level than Java but higher level than C. It includes things like explicit pointers and more control of memory layout. Many of the design decisions make no sense without that context.…

> On generics, I think the team’s position has mostly been that it’s a big project and there’s been other priorities like rewriting the compiler in Go, improving the GC, etc. And that in the spectrum of trade-offs for generics systems they didn’t want to go all the way to Java or C++. That was not the initial team position. Their initial position was "why would you even need generics? Please provide us a usecase". Th…

This has never been the case, and stating it as a fact is a big lie

Re: How generics are implemented in Go 1.18

#204

Post by azth »

klodolph wrote: post #97
azth wrote: post #87

Earlier quoted context omitted.

Why are they an issue in C#, but not Java, which also has similar method overloading? Or are they related to default arguments?

You may be inferring something that I didn’t write. I didn’t once mention method overloading in Java.

Yes, I inferred because earlier you mentioned Java and C#, but only mentioned C# when it came to method overloading. Does Java have the same issue you were referring to when you mentioned C#?

Re: How generics are implemented in Go 1.18

#205

Post by klodolph »

azth wrote: post #204
klodolph wrote: post #97

Earlier quoted context omitted.

You may be inferring something that I didn’t write. I didn’t once mention method overloading in Java.

Yes, I inferred because earlier you mentioned Java and C#, but only mentioned C# when it came to method overloading. Does Java have the same issue you were referring to when you mentioned C#?

I don't have enough Java experience to know the answer to that question.

Re: How generics are implemented in Go 1.18

#206

Post by foldr »

simias wrote: post #201
foldr wrote: post #148

Earlier quoted context omitted.

Does it help to make such vague references to bad faith arguments? If you want to point to something specific that someone said, then fine, but otherwise it seems like you're just stirring up discord. No programming language is loved only by rhetorical geniuses. Of course you can find some people who've said some silly things about Go or generics. But so what? You can also find people who've said silly things about y…

I wasn't making an argument at all really, just sharing my point of view. I also didn't think that the claim that many bad faith arguments regarding the utility of generics came from the Go community would be scrutinized and needed supporting. Besides it's irrelevant and petty to bring it up now, I'm more interested to see how these new generics fare.

It is irrelevant and petty to bring it up now – but you have. I think you should either withdraw the comment or point to an example.

Making broad brush accusations of bad faith just doesn't help to get to the bottom of any technical issue. It's fine to express your opinion, but if you publicly say bad things about a community, you should be prepared to substantiate those claims when asked.

HN commentary on Go seems to repeatedly return to increasingly exaggerated and vitriolic claims about the supposed idiocy of the Go team or Go community in relation to generics. The factual foundation of these claims is virtually nil. It appears to be some kind of group false memory phenomenon, where vague second hand reports, endlessly repeated, become accepted as fact.

I would therefore invite you to actually try to find some examples of these bad faith arguments, for your own benefit if nothing else.

Re: How generics are implemented in Go 1.18

#207

Post by LaPingvino »

kerkeslager wrote: post #91

So maybe 7-8 years ago, I got into a bunch of arguments with people on Hacker News because I said that Go's type system was ineffective without generics. At that time, Gophers leaped to defend it, going so far as to say that it's better because it's simple. Oh and it was really important to Gophers that Go compiles in a single pass (which I argued is only relevant for truly enormous codebases like Google's). A few ye…

Generics were considered at the very release. Go just focuses on getting it right. And I love it for it, because to this day Go is the only language that got OOP right, and now Generics.

Go is a language made for the human factor.

Go generate by the way is mostly NOT used for generics. Check for example Vugu, which compiles UI documents to pure Go code. Go generate is made to incorporate any random external tool without making it complicated for the humans using it. And it makes sense because the goal was not single pass compilation, it was single pass parsing, which is exactly WHY Go generate is useful. It is still true to the exact way this has been defined. Go is simple in ways that matter.

Re: How generics are implemented in Go 1.18

#208

Post by LaPingvino »

masklinn wrote: post #107
vgchh wrote: post #96

Earlier quoted context omitted.

Well let perfect not be the enemy of the good. The reality is that Go is wildly successful in practice for good reasons that have been hashed numerous times. As a result tons of Cloud software is written in Go. There is nothing Go needs to be ashamed on. Its mindshare is a result of a good choice people made at a certain point in time. A better language will win at its own merits.

> Well let perfect not be the enemy of the good. When you have half a dozen generic builtins but reject the idea that builtins are necessary, and can’t even be arsed to provide a working vector type, you’re nowhere near “good”.

They never rejected it. In the very first post launching it they commented that they considered Generics but didn't add them because they didn't find a way that works well with Go's principles. I'm happy it took them the time it did to get to the current design. They did have a vector type before version 1 too, they intentionally removed it for similar reasons.

Re: How generics are implemented in Go 1.18

#209

Post by LaPingvino »

kerkeslager wrote: post #182
omginternets wrote: post #109

Earlier quoted context omitted.

Where does this cause problems for you in practice? Where is the usefulness of goroutines limited practically ? Where is the complex notion of a compiler pass causing problems? I’m very open to the idea that I’m suffering from a problem I don’t know I have, but right now you’re just asserting that problems exist without actually telling us how to recognize them.

I'm not saying a compiler pass is a problem: I'm pointing out that Go fanboys originally said that they needed a single compiler pass, and that was why Go couldn't have generics. But Go has abandoned single pass a long time ago, and Go still doesn't have generics, and when it does have generics, it will have an abstraction so complex that it makes adding another compiler pass look simple. If anything, I think compile…

No, the documentation stated that Go was designed for reading without backtracking. That results in single pass compilation being possible and thus being faster, but that was never a limitation that was imposed. The reading without backtracking is still valid: go generate DOESN'T work on .go files, only on any other tool that generates .go files.

About the second part, you seem to mix up goroutines and channels. In a concurrent system, you would need locks for your example, and channels fix this. Goroutines are just the representation of independent processes and can be implemented and ARE implemented differently per compiler, check e.g. how tinygo and gopherjs do this.

Your example point 2 doesn't make any sense, check fan in and fan out patterns with channels. Go supports message passing, that is what channels are. You really didn't try Go and it shows.

Re: How generics are implemented in Go 1.18

#210

Post by LaPingvino »

rat9988 wrote: post #181
throwaway34241 wrote: post #100

Earlier quoted context omitted.

I’m not going to defend what random internet commenters may have said, but in my view the core team has been fairly consistent and their design decisions (to me) make sense. The first thing to understand is that Go occupies a space lower level than Java but higher level than C. It includes things like explicit pointers and more control of memory layout. Many of the design decisions make no sense without that context.…

> On generics, I think the team’s position has mostly been that it’s a big project and there’s been other priorities like rewriting the compiler in Go, improving the GC, etc. And that in the spectrum of trade-offs for generics systems they didn’t want to go all the way to Java or C++. That was not the initial team position. Their initial position was "why would you even need generics? Please provide us a usecase". Th…

They have mentioned that you don't really need it as an explanation after they already said for a long time that they do consider it, from the start. They never strayed from that POV.
Post reply on HN