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

41–50 of 228 posts

Re: How generics are implemented in Go 1.18

#41

Post by belak »

_fz_ wrote: post #37
belak wrote: post #31

Earlier quoted context omitted.

The original plan was to release in February, but in the Beta 2 release [1], they said this: "Because we are taking the time to issue a second beta, we now expect that the Go 1.18 release candidate will be issued in February, with the final Go 1.18 release in March." It looks like there are still a few release blockers [2]. I'd imagine RC is fairly soon though. EDIT: as mentioned by _fz_ below, RC1 has already releas…

> I'd imagine RC is fairly soon though. RC1 was released two weeks ago.

Thanks! Good catch! I was going off blog posts and didn't see that there was a download for RC1.

Re: How generics are implemented in Go 1.18

#42

Post by yakubin »

FooBarWidget wrote: post #7
kevin_thibedeau wrote: post #5

Earlier quoted context omitted.

The compile time issues for C++ are entirely because of the creaky header mechanism that doesn't permit efficient parsing. Generics have worked fine in Ada since its inception. Any modern language can adopt the same process of tracking a formal abstract interface that is parsed once and expanded into concrete code as necessary.

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.

Re: How generics are implemented in Go 1.18

#43

Post by Groxx »

whateveracct wrote: post #36
layer8 wrote: post #28

Does Go support separate compilation? The approach sounds like a change in the implementation of a generic function (changing the gcshapes) could cause client code to break unless it is recompiled as well. What am I missing?

Go is all from source

Except for plugins. But plugins are pretty darn niche, and feel more experimental than anything: https://pkg.go.dev/plugin

Re: How generics are implemented in Go 1.18

#44

Post by Banana699 »

endymi0n wrote: post #3
elromulous wrote: post #2

Disclaimer: I only very occasionally touch Go code. Hasn't this been a very long time coming? Iirc there has been much dispute over this in the community. Can anyone weigh in on what the other options were?

In a nutshell, torn between the extreme ends of high compile-time cost and large code size of a C++ flavored implementation and the high runtime cost and dangers of boxing/unboxing (Java), Golang opted for "none of the above" and tried to limit complexity drivers / powerfulness / expressiveness / usefulness instead, keeping the impact on both compile time and run time low. About how well that decision will turn out i…

C# also made a similar tradeoff between purely generative generics of C++ and the type-erased generics of Java.

Re: How generics are implemented in Go 1.18

#46

Post by codeflo »

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 Go’s compilation strategy doesn’t handle that currently.

Re: How generics are implemented in Go 1.18

#47

Post by slx26 »

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 pieces here and there... and the system should make sense and work. We can see that it must work! But these features are trying to resolve problems from a very closely-connected but still different domain, and that's why we see so much friction when trying to use them. We try to encode system-level patterns in the implementation, and there's gonna be friction. We can see that these features give us power, and that's why we like them, but we also see the problems they cause, and that's when we get cold feet and say "yeah... maybe it's not such a great idea".

I'm actually really happy to get generics in golang, and I'm happy with the team giving it as much thought as they need, but we are only gonna get so far within the current paradigm of trying to model the universe from a few text files. Generics are nice, but we shall do better in the future!

Re: How generics are implemented in Go 1.18

#49

Post by LukeShu »

Groxx wrote: post #43
whateveracct wrote: post #36

Earlier quoted context omitted.

Go is all from source

Except for plugins. But plugins are pretty darn niche, and feel more experimental than anything: https://pkg.go.dev/plugin

Note that if a plugin and the main program have any packages in common, the build-hash (Go binaries include a hash for each included package) must be identical between the program and the plugin. If the hashes don't match, then the program's `plugin.Open(…)` call will return an error.

So if there is a package in common such that an implementation change could cause something like a cgshape change, well the cgshape change won't matter since any implementation change will change the package's build-hash. And so everything will need recompiled anyway, regardless of whether the cgshape changed or not.

Re: How generics are implemented in Go 1.18

#50

Post by geodel »

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…

Right. Basically Go team is lacking big picture thinkers like this[1]

1. https://dilbert.com/strip/1994-12-17

Post reply on HN