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

141–150 of 228 posts

Re: How generics are implemented in Go 1.18

#141

Post by pjmlp »

socialdemocrat wrote: post #139
pjmlp wrote: post #129

Earlier quoted context omitted.

Never used unsafe and raw pointers in C#? They exist since version 1.0. Never used ArraySegments in C#? They exist since version 2.0 Abtracting over float/doubles is called generics.

It is not the same thing at all if you care to compare the details. C# pointers come with a long list of caveats which does not apply in Go. They feel like a bolted on escape hatch rather than a real part of the language.

Moving goal posts, so now instead of not existing, they come with caveats.

Re: How generics are implemented in Go 1.18

#142

Post by masklinn »

Guthur wrote: post #127
dgb23 wrote: post #121

Earlier quoted context omitted.

I‘m sure there are better reasons for people liking Go other than what you described. This reads like a general dismissal.

Nope, as a language Go adds nothing and sometimes feels like it gives even less. Where Go has been a success is tooling. The tooling is pretty decent and helps a lot. But that could be added to pretty much any language ecosystem

> But that could be added to pretty much any language ecosystem

Though it annoyingly is not. The profiling with integrated stack, line, and memory / alloc profiler seems especially nice.

Though it’s made progress (especially with the rise of flamegraph-type visualisation) the ecosystems I navigate seem to remain a hodge-podge of disparate tools.

Re: How generics are implemented in Go 1.18

#143

Post by simias »

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…

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 document was I'd love to read it again, especially now that Go has generics).

That being said I'm happy to see that Go now attempts to find a tradeoff between generics and compile time, if their approach proves successful hopefully it could lead to improvements for other languages as well.

Re: How generics are implemented in Go 1.18

#144

Post by Cthulhu_ »

Guthur wrote: post #127
dgb23 wrote: post #121

Earlier quoted context omitted.

I‘m sure there are better reasons for people liking Go other than what you described. This reads like a general dismissal.

Nope, as a language Go adds nothing and sometimes feels like it gives even less. Where Go has been a success is tooling. The tooling is pretty decent and helps a lot. But that could be added to pretty much any language ecosystem

Go apologist here. Go doesn't work because it adds something to existing languages, but because it keeps things away.

In 30 years time, Go codebases built today will still be around, while Java, Javascript, Scala or Ruby codebases will have been rebuilt multiple times over or removed entirely, because they drowned in their own complexity and their developers' own cleverness.

That said, for me it's not so much Go itself, but the mindset that comes with it of writing dumb and verbose but obvious code. I've reduced 15-line for loops into clever functional oneliners, but maybe all I needed was a `range` instead of a `for i = 0` style loop all along, because I need a lot more time and mental energy to understand the functional oneliner than a `for x in range` loop.

Re: How generics are implemented in Go 1.18

#145

Post by Cthulhu_ »

kaba0 wrote: post #118
throwaway894345 wrote: post #104

Earlier quoted context omitted.

> Every few years someone gets me to try Go out again and I discover, yet again, that it's still struggling with problems that were solved before it existed. It's a shame that this language has stolen so much mind share from more deserving languages. Go steals the mindshare because it focuses on the important problems that other languages neglect in part or in full: performance, tooling, ecosystem, simplicity, readab…

There is absolutely nothing mentioned in your comment that Java or C# didn’t already do better 10 years ago, let alone now. The only somewhat redeeming quality of go is virtual threads, but that is not even the reason like 90% of its user base uses it for.

It's not an either/or though. How many and what companies use Java / C# for new applications these days? They're a solid working horse, and lowkey Java is my retirement plan.

Re: How generics are implemented in Go 1.18

#146

Post by mahesh-hegde »

pjmlp wrote: post #135
mahesh-hegde wrote: post #132

Earlier quoted context omitted.

> Java has AOT compilers since 2000, they just weren't free beer. "just" Tell me how me, a student in India with a cheap plastic laptop running Linux, could get straightforward access to some AOT compiler produced by some commercial company in north pole or somewhere. Open source compilers got popular for a reason. Now we have graalvm, but getting something running with graalvm is not always straightforward. Even wit…

Like always, on a street bazaar, or are you going to tell us they don't exist?

I don't think some obscure company's compiler for Java would be being sold on streets of Bangalore, much less likely in affordable price, much less likely in smaller towns.

And, to reiterate, usability matters, defaults matter. Cannot compare 'there existed some obscure vendor who sold an obscure feature in an obscure corner of Europe or Canada', with a mainstream programming language sponsored by a big tech having a good-enough default toolchain adopted by many companies and has lot of jobs;

Re: How generics are implemented in Go 1.18

#147

Post by Cthulhu_ »

benhoyt wrote: post #98
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…

But the fact remains that it's a productive language with excellent tooling and fast build times, and a lot of people really like working with it (myself included). I believe the reason it has gotten as far as it has without generics is because it did always have them -- but only for the built-in data types (slices, maps, channels). You just couldn't add your own until Go 1.18. I have several medium-sized Go projects…

That's the main use case I think; certain specialized container data types (e.g. a linked list) will benefit from generics, but I don't see it going as crazy as e.g. Java in terms of usage.

Which is something the Go team is behind as well; they added it to the language, but they aren't telling people how to use it, and are letting the community come up with use cases over time before they iterate on it.

Re: How generics are implemented in Go 1.18

#148

Post by foldr »

simias wrote: post #143
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…

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 your favourite programming language.

Re: How generics are implemented in Go 1.18

#149

Post by Ginden »

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…

> At that time, Gophers leaped to defend it, going so far as to say that it's better because it's simple.

I'm not sure why certain things generate such fanatical community.

Eg. I remember arguing with iOS developer in my first work that smartphones bigger than 4.7" are useful. He claimed they aren't and Apple, as company focused on best experience of user, will never ever produce bigger smartphone, because it's totally useless.

Re: How generics are implemented in Go 1.18

#150

Post by pjmlp »

mahesh-hegde wrote: post #146
pjmlp wrote: post #135

Earlier quoted context omitted.

Like always, on a street bazaar, or are you going to tell us they don't exist?

I don't think some obscure company's compiler for Java would be being sold on streets of Bangalore, much less likely in affordable price, much less likely in smaller towns. And, to reiterate, usability matters, defaults matter. Cannot compare 'there existed some obscure vendor who sold an obscure feature in an obscure corner of Europe or Canada', with a mainstream programming language sponsored by a big tech having a…

My experience, the catalogues used to be quite big and it was only a matter of time to get whatever.

Then again, maybe things changed in 20 years.

The technology for doing JIT caches on OpenJDK comes from J/Rockit, while OpenJ9 comes from IBM Websphere.

From 2000 to 2009, Red-Hat used to have an Eclipse version compiled with gjc.

Hardly obscure vendors.

Post reply on HN