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

181–190 of 228 posts

Re: How generics are implemented in Go 1.18

#181

Post by rat9988 »

throwaway34241 wrote: post #100
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’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". They actively denied there was a need for generics.

Re: How generics are implemented in Go 1.18

#182

Post by kerkeslager »

omginternets wrote: post #109
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…

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 compiler time is worth a lot less than developer time for the vast majority of projects, and if a compiler pass saves developers even a little time, I say add the compiler pass (within reason--don't keep doing this until the compiler grinds to a halt). This is fairly obvious and encoded into the compilers of almost every compiled programming language. But Go is learning this 12 years into its existence when everyone else knew this before Go existed.

As for goroutines being limited: here's a practical example:

1. Write a basic two-person p2p chat in Go and some other appropriate language. At a high level, each user client has a message log, and the other user can write messages to it. Since the arrays are single-reader, single-writer, there's no real problem, just use an array: this is a nice demo of how simple Go is! You don't need all these fancy abstractions!

2. Expand the chat to include a third person. Again, everybody gets a message log, but now more than one person can write to it. Now, your message log is multiple writer, single reader (assuming each user can maintain their own log of messages they've sent so they don't need to read other people's logs to get those--there's an implicit copy here but that's fine). In Go, start over and write a probably-buggy implementation of a SRMW queue because Go is too simple to have that already. In any reasonable language, wrap writes to your message logs in a built-in queue that's already thread-safe. Note here that "any reasonable language" in this case includes Java (LOL!). In Erlang/Elixir/Clojure, you may literally have accidentally supported a third user already and have to make no changes. There are of course other go implementations which are maybe more idiomatic, but none of them approach the simplicity of a language that supports message passing.

Re: How generics are implemented in Go 1.18

#183

Post by kerkeslager »

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…

Exactly.

Re: How generics are implemented in Go 1.18

#184

Post by kerkeslager »

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…

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

Sorry, but anyone who's been watching Go's development long enough remembers this: it's not being made up.

Dischord is good if the alternative is consensus around a backwards language that wastes huge amounts of people's time and money.

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

The problem being that in the case of Go, the people saying silly things are the primary developers of the language.

Re: How generics are implemented in Go 1.18

#185

Post by throwaway894345 »

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.

If someone cut out a bunch of features from Java and .Net (classes, inheritance, exceptions, nominally subtypes interfaces, etc), added value types (in the case of Java), simplified the build and dependency management systems, static (and ideally native) compilation by default, etc then I would be very interested.

Re: How generics are implemented in Go 1.18

#186

Post by kerkeslager »

socialdemocrat wrote: post #138
BatteryMountain wrote: post #125

Earlier quoted context omitted.

C# generics are delicious. Combined with the strong compiler and super good reflection features, you can do very well indeed with it.

Nah… if so was embracing C# style complexity I would rather do Swift of Rust. At least they have a clean solution for fixing the million-dollar-mistake. My chief attraction to Go is simplicity. I can be away from Go for years and pick it up again really fast. With simplicity, you naturally need to make some sacrifices, but I think Go team has been diligent about choosing those.

> Nah… if so was embracing C# style complexity I would rather do Swift of Rust.

Just so we're clear here, you're using the word "complexity" to describe the situation of not having to copy paste or `go generate` 30 different implementations of the same class for different types because your language lacks generics.

Re: How generics are implemented in Go 1.18

#187

Post by pjmlp »

ilovecaching wrote: post #177
pjmlp wrote: post #133

Earlier quoted context omitted.

I bet that if the Docker and Kubernetes ecosystem was born today, Rust would be used instead. We are already seeing the transition happening, e.g. Deis Labs: https://deislabs.io/posts/still-rusting-one-year-later/ > Given the team’s background in many Go projects, we often hear something like this: “Well, what about Go? Do you regret moving to Rust? What do you miss from Go?” Addressing this in the context of our dis…

You clearly have no idea what Rust is for, or who the target audience is. Application developers do not need a non-GCed language, and anyone who argues for the added complexity and noise (because Rust makes it so easy you'll say) is actually just looking for something cool to learn and push at the office. I get it, you don't want to write Go, it's too simple for the 1%er programmers. I've been a kernel developer for…

You clearly don't have any idea who I am, or my opinions on Rust.

Since I feel like educating you,

> Nothing really, Rust's killer application are domains where using a language with automatic memory management and support for value types isn't an option, trying to use it elsewhere, while possible is sacrificing productivity.

https://news.ycombinator.com/item?id=30391431

That doesn't change the fact that many relevant projects in CNCF are now adopting Rust in their reboots.

Deis Labs, which you also don't know who they are.

Linkerd2 proxy was written in Rust, despite Linkerd 2 being written in Go.

The famous rewrite from Go into Rust done by Discord for their microservices.

The Amazon Bottlerocket uses Rust for large part of the user space, as does Fuchsia nowadays.

Any language can be a systems programming language, even Go, as ARM and F-Secure do with their bare metal Go deployments for microcontrollers.

Go's future is assured, no need to panic.

Re: How generics are implemented in Go 1.18

#188

Post by pjmlp »

Kranar wrote: post #174
pjmlp wrote: post #131

Earlier quoted context omitted.

They sure do, make the most common expansions avaiable as extern templates.

That has nothing to do with modules. You can extern a template going back to C++11.

Modules make it more convinient to do so, and allow for more build speedups.

Re: How generics are implemented in Go 1.18

#189

Post by pjmlp »

throwaway894345 wrote: post #167
pjmlp wrote: post #133

Earlier quoted context omitted.

I bet that if the Docker and Kubernetes ecosystem was born today, Rust would be used instead. We are already seeing the transition happening, e.g. Deis Labs: https://deislabs.io/posts/still-rusting-one-year-later/ > Given the team’s background in many Go projects, we often hear something like this: “Well, what about Go? Do you regret moving to Rust? What do you miss from Go?” Addressing this in the context of our dis…

Of course there’s no way to know for sure, but I would be more inclined to use Rust for projects where the domain is well-understood; however, Kubernetes was (and to an extent, still is) experimental and rapidly evolving. It would be painful to have to do all of that iteration in the presence of a borrow-checker. And yeah, I understand the purported benefits of having a robust type checker protecting you in a refacto…

Naturally that was an what-if, my comment was based on what we see happening with CNCF projects evolution.

Re: How generics are implemented in Go 1.18

#190

Post by foldr »

kerkeslager wrote: post #184
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…

> 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. Sorry, but anyone who's been watching Go's development long enough remembers this: it's not being made up. Dischord is good if the alternative is consensus around a backwards language that wastes huge amounts of peopl…

Again, you're just saying that a bunch of people said some unspecified silly things. It's difficult to take that seriously as a critique of Go or any of the people involved in designing it.
Post reply on HN