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

31–40 of 228 posts

Re: How generics are implemented in Go 1.18

#31

Post by belak »

colesantiago wrote: post #27

When is generics officially coming into Go? I thought it would be in February as promised?

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 released. Seems like the full release will most likely still be in March.

[1]: https://go.dev/blog/go1.18beta2

[2]: https://github.com/golang/go/issues?q=is%3Aopen+label%3Arele...

Re: How generics are implemented in Go 1.18

#32

Post by aaronbee »

colesantiago wrote: post #27

When is generics officially coming into Go? I thought it would be in February as promised?

go1.18 is coming out soon with generics. The first release candidate came out 2 weeks ago. You can track the open issues here: https://github.com/golang/go/milestone/201

Re: How generics are implemented in Go 1.18

#33

Post by Kranar »

kenniskrag wrote: post #9
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.

Isn't that solved with c++ modules [1]? [1] https://en.cppreference.com/w/cpp/language/modules

Not really, in C++ templates still need to be instantiated in every module but modules don't have to each repeat the parsing of template definitions. The module that declares the template will do the job of parsing the template and producing some intermediate representation of it that other modules can consume. Okay that does save some amount of time but the overwhelming majority of time spent compiling templates is in instantiating them, not parsing them from literal text into an AST.

Modules don't make instantiating templates any faster, it only makes parsing them faster.

Re: How generics are implemented in Go 1.18

#35

Post by yakubin »

josephg wrote: post #11
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.

The process of expanding genetic code into concrete code based on the types (monomorphizing) can also be an expensive process. At least, people in the rust world point to it a lot as a reason why some crates compile slowly. Monomorphizing multiplicatively increase how much code LLVM needs to process (and optimize). Mind you, C/C++’s ridiculous header system is probably still a much bigger issue. Especially because C+…

Although monomorphization takes a significant chunk of a typical Rust compilation, it pales in comparison to LLVM codegen and execution of procedural macros. So although it's academically worthy of note, optimization-wise it's not where the focus should be. Personally, I'd like to see someday a Rust compiler which is not based on LLVM. Both Zig and Jai compile much faster when using their non-LLVM backends than when using LLVM, so Rust is not the odd one here either.

Re: How generics are implemented in Go 1.18

#36

Post by whateveracct »

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

Re: How generics are implemented in Go 1.18

#37

Post by _fz_ »

belak wrote: post #31
colesantiago wrote: post #27

When is generics officially coming into Go? I thought it would be in February as promised?

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.

Re: How generics are implemented in Go 1.18

#38

Post by whateveracct »

Kranar wrote: post #29
cryptos wrote: post #25

Do Go generics support covariance and contravariance?

Go does not have subtypes, so your question is not applicable.

It does have subtyping relationships via interface. It absolutely has subtypes in the co/contravariance.

In theory, a slice of structs that implement an interface should be able to be used as a slice of that interface. But due to the implementation, that requires a full copy.

Re: How generics are implemented in Go 1.18

#39

Post by lamontcg »

Kranar wrote: post #29
cryptos wrote: post #25

Do Go generics support covariance and contravariance?

Go does not have subtypes, so your question is not applicable.

Can you use generics to create a container of an interface or does it only support concrete types as generics?

Re: How generics are implemented in Go 1.18

#40

Post by Laremere »

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?

While (iirc) Go uses caching in its build system internally, it builds quickly enough that this is not a concern.
Post reply on HN