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

161–170 of 228 posts

Re: How generics are implemented in Go 1.18

#161

Post by pjmlp »

Cthulhu_ wrote: post #145
kaba0 wrote: post #118

Earlier quoted context omitted.

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.

Not only that, only .NET has tooling comparable to stuff like JFR.

Re: How generics are implemented in Go 1.18

#162

Post by pjmlp »

tsss wrote: post #136
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…

Quoted post unavailable.

Sometimes I wish that the Go advocates had not joined Kubernetes project and triggered the rewrite of the prototype from Java into Go.

Re: How generics are implemented in Go 1.18

#163

Post by pjmlp »

pkolaczk wrote: post #137
vips7L wrote: post #95

Earlier quoted context omitted.

I’ve compiled projects with javac, scalac, g++, gcc, and dmd. Javac is faster than all of them.

javac doesn't have to generate optimized machine code, which saves it a lot of time. But you pay the price incrementally in all those slow startups of java apps.

Only if stuck in Java 8, those of us in modern Java use JIT caches with PGO feedback.

Re: How generics are implemented in Go 1.18

#164

Post by pjmlp »

turminal wrote: post #67
slx26 wrote: post #47

Programming languages are lacking because they are too stuck in the "implementation plane" while trying to deal with lots of "system design" problems. Generics, traits, interfaces, union types and others are fundamentally targeted at giving developers more expressive power to describe the systems we are designing. We know there are many parts we could swap around, using different implementations, connecting some piec…

Some of the people behind go are the living example of how far you can get with a bunch of text files and a good model around them. (The answer is very far)

We don't need Go for that, Oberon already made that point, we got a full graphical workstation OS out of it, in 1992.

Re: How generics are implemented in Go 1.18

#165

Post by neilwilson »

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've had a play around with Go generics, and from what I can tell it boils down to passing the type parameter down the chain, from the concrete to the general, to the point where a function needs to create a structure, and then returning that structure back up again, modifying the structure with functions and methods as you go.

Rather than creating the structure and passing it down the chain to be modified via typecasts as previously.

Pretty much everything else ends up being limited by interface types being unable to reference structure attributes directly, but requiring method signatures. So it becomes more complicated to reference all types that have an 'ID' attribute for example.

With some types I ended up with so many getter and setter functions to enable generics, that it was better to revert back to 'go generate'.

Perhaps it works better with pure container types that can take 'any'.

Re: How generics are implemented in Go 1.18

#166

Post by kllrnohj »

vips7L wrote: post #92
kllrnohj wrote: post #80

Earlier quoted context omitted.

I see you haven't worked with the joy of gradle & modern Java development. By the time you stack up gradle, javac itself, proguard or for Android R8 which are basically required to fix the terrible bytecode javac produces, some annotation processors because WHY NOT, custom build plugins, etc... it gets big

I highly doubt that javac produces terrible bytecode.

I highly doubt you've ever looked at it then. javac more or less intentionally doesn't do any optimizations, it leaves it all for the job of the JIT at runtime. It doesn't do either class-local optimizations nor whole-program / LTO-equivalent optimizations. Things like proguard offer both, and hence why they can so easily claim things like +20% performance. There's a lot of low-hanging fruit in javac's output, at the cost of needing a map file to reconstruct source mappings of course (although Java could of course integrate this into the class files if it wanted, it would just rather invest more or less exclusively in the JIT & GC).

Here for example: https://godbolt.org/z/4nzPY3h57 javac doesn't even bother to resolve that static field at compile time, which wouldn't even have observable side effects. Nope, just blindly emits a static initializer to invoke square(2) at runtime.

Or for a real fun one, enums: https://godbolt.org/z/xjbYvc8dx

Now some of that is necessary to handle all the stuff other classes could do with the enum, but some of it is just unnecessary. Like building the values array, which invokevirtuals all the ordinals of all the enum values. Ordinals the compiler already knew, since it's literally in the same .class file further up (and these are always in the same .class file, they are in lock-step, so there's again no observable difference if the values array was defined with constants instead of invoking ordinals on each field).

And then the trivial switch statement there isn't optimized at all, either, which again wouldn't be observable (compare against what eg. gcc would produce: https://godbolt.org/z/414rGjbE1 )

Further note that these examples are both static initializers, which means the JIT never "fixes" these (and thus instead perpetually contribute to slow startup). So if javac was going to bother with any attempt to optimize at all, you'd think it'd be here.

Re: How generics are implemented in Go 1.18

#167

Post by throwaway894345 »

pjmlp wrote: post #133
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…

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

That said, Kubernetes isn’t a monolith so it doesn’t need to be all-or-nothing, and one component that would likely be well-suited to Rust is etcd.

Re: How generics are implemented in Go 1.18

#168

Post by throwaway894345 »

ctopher7 wrote: post #117
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…

Quoted post unavailable.

I gave a reasoned argument and you responded with ad hominem. I don’t think it’s the “Go fans” who are toxic. We merely disagree, and that’s okay.

Re: How generics are implemented in Go 1.18

#169

Post by throwaway894345 »

kaba0 wrote: post #156
Cthulhu_ wrote: post #144

Earlier quoted context omitted.

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 itse…

That’s a bit bold coming from a relatively young language, given that Java has codebases close to 25 years old. Also, repeating the same code many times due to lack of expressiveness is not the epitome of long-lived software. Essential complexity is non-reducable, the only way we can deal with it is through abstractions.

Some of us were around when Java was young and can compare a 5yo Go codebase with a 5yo Java codebase :)

> Also, repeating the same code many times due to lack of expressiveness is not the epitome of long-lived software. Essential complexity is non-reducable, the only way we can deal with it is through abstractions

Repetition is not a big deal in a local context (e.g., error handling or for loops), and Go is rarely repetitive in larger contexts. Gratuitous abstraction is a much greater danger than extra keystrokes IMHO.

Re: How generics are implemented in Go 1.18

#170

Post by staticassertion »

socialdemocrat wrote: post #140
jcelerier wrote: post #116

Earlier quoted context omitted.

C# also supports AOT compilation. It's definitely not a low-level / high-level language differentiator. The term generally means the abstraction level you can reach.. I'd be tempted to define it as the distance to simple lambda-calculus in the lambda-cube

C# ahead-of-time compilation has for many years come with all sorts of caveats. Early versions requires runtime system because not everything got compiled on parts. Later versions have all sorts restrictions which do no apply for Go. I think when C# and Java people compare with other languages they treat it as a checkbox exercise without caring about how good that feature actually is.

OK but Go carries around a runtime too?
Post reply on HN