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

81–90 of 228 posts

Re: How generics are implemented in Go 1.18

#81

Post by newuser94303 »

vlunkr wrote: post #75
ainar-g wrote: post #62

Earlier quoted context omitted.

It's partially being done in the x/exp module to prototype it thoroughly before including it into the stdlib. See: * https://pkg.go.dev/golang.org/x/exp/constraints * https://pkg.go.dev/golang.org/x/exp/maps * https://pkg.go.dev/golang.org/x/exp/slices

Cool. I'd love to see this become part of the stdlib rather than competing external packages.

If it becomes part of the stdlib, the update cycle will match the language. For now, improvements will come a lot faster as an external package

Re: How generics are implemented in Go 1.18

#82

Post by edflsafoiewq »

yakubin wrote: post #42
FooBarWidget wrote: post #7

Earlier quoted context omitted.

Rust also has (relatively) bad compile times due to generics. Not as bad as C++, but you can notice it's significantly worse than Go.

Rust does compile slower than Go, but it's not due to generics. It's mostly due to LLVM codegen and procedural macros. Go has the benefit of not relying on LLVM and not having procedural macros.

A lot of the IR comes from expanding huge stacks of generic functions. I don't think the issue can't be neatly partitioned up like that.

Re: How generics are implemented in Go 1.18

#83

Post by shadowgovt »

pjmlp wrote: post #19
shadowgovt wrote: post #6

Earlier quoted context omitted.

This summary concisely captures the key thing about generics that has kept them out of Go for so long: they weren't created in a vacuum. Go's developers had the flaws in C++ and Java's approaches to draw on in their attempt to find a better approach. Many people calling for generics to have been implemented sooner were fine with those flaws in the other languages, but the Go team wanted to do better than that.

Generics exist in languages since 1976, more than enough examples than focusing on C++ and Java.

good point! What could the Go team glean from those languages to improve Go's generics implementation?

Re: How generics are implemented in Go 1.18

#84

Post by throwaway894345 »

codeflo wrote: post #46
c-linkage wrote: post #16

I thought this was something like traits, but it goes way beyond that. Sub-dictionaries are described here: https://github.com/golang/proposal/blob/master/design/generi... It looks like the compiler needs to walk down the entire call tree from the top-level generic and then compute new dictionaries for each called function. Since the compiler may not know the entire call tree, it may have to build nested dictionaries…

From the article you linked, those subdictionaries seem to support calling a function g[T1] inside a function f[T1, T2]. There’s a concept called polymorphic recursion, supported by languages like Haskell, which goes beyond that and allows using arbitrary derived types in a function, in particular, in recursive calks. My interpretation of the section in “non-monomorphisable functions” in the original article is that…

Maybe I missed it in TFA, but what runtime type information is necessary for a generic function call?

Re: How generics are implemented in Go 1.18

#85

Post by dpatterbee »

vlunkr wrote: post #75
ainar-g wrote: post #62

Earlier quoted context omitted.

It's partially being done in the x/exp module to prototype it thoroughly before including it into the stdlib. See: * https://pkg.go.dev/golang.org/x/exp/constraints * https://pkg.go.dev/golang.org/x/exp/maps * https://pkg.go.dev/golang.org/x/exp/slices

Cool. I'd love to see this become part of the stdlib rather than competing external packages.

I believe the goal is for stdlib packages to be added with 1.19 once they have some real-world use. For now they're in x/exp to allow changes before that release.

Re: How generics are implemented in Go 1.18

#86

Post by geodel »

yakubin wrote: post #42
FooBarWidget wrote: post #7

Earlier quoted context omitted.

Rust also has (relatively) bad compile times due to generics. Not as bad as C++, but you can notice it's significantly worse than Go.

Rust does compile slower than Go, but it's not due to generics. It's mostly due to LLVM codegen and procedural macros. Go has the benefit of not relying on LLVM and not having procedural macros.

You are right of course about LLVM being source of slowness.

In general discussion I see around is that all Rust's perf optimizations are to Rust's credit (nothing about LLVM optimization) while all woes around Rust's compile time lay at step of LLVM and Rust is not be blamed.

Re: How generics are implemented in Go 1.18

#87

Post by azth »

klodolph wrote: post #60
jayd16 wrote: post #54

Earlier quoted context omitted.

>C# generics have some downright nasty interactions with other parts of the type system, like operator overloading. Operators are static methods so why is that surprising or nasty?

It affects method overloading too, I should have said “method overloading”. Just take a look at the rules for method overloading in C#, or take a look at one of the various C# compilers to see how methods are resolved.

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

Re: How generics are implemented in Go 1.18

#89

Post by shadowgovt »

kllrnohj wrote: post #80
shadowgovt wrote: post #20

Earlier quoted context omitted.

C++ still has the dubious honor of being the only language where I encountered code that I could not compile because my machine lacked enough memory. I'm sure that's possible in other languages, but the program I was trying to compile wasn't that complicated... It had just been written by someone who believed every concrete class needed an abstract interface it was implementing.

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

Computers seem to have caught up. The Java stack is the slowest one I regularly use (though it does support a certain amount of hot-recompile that other toolchains I use don't or can't), but it's never just crashed because it can't find room to store all those bytecode files.

Re: How generics are implemented in Go 1.18

#90

Post by shp0ngle »

vlunkr wrote: post #75
ainar-g wrote: post #62

Earlier quoted context omitted.

It's partially being done in the x/exp module to prototype it thoroughly before including it into the stdlib. See: * https://pkg.go.dev/golang.org/x/exp/constraints * https://pkg.go.dev/golang.org/x/exp/maps * https://pkg.go.dev/golang.org/x/exp/slices

Cool. I'd love to see this become part of the stdlib rather than competing external packages.

They want to be able to break backwards compatibility, so they can experiment more. If they put it in stdlib, they cannot break it anymore.
Post reply on HN