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

21–30 of 228 posts

Re: How generics are implemented in Go 1.18

#21

Post by klodolph »

shadowgovt wrote: post #20
klodolph wrote: post #14

Earlier quoted context omitted.

I only occasional do language design / compiler writing projects, or work with compiler internals. Most people are really bad at estimating the implementation complexity and tradeoffs inherent in various language features. I'd say that C++ serves as a warning to others... think before you add features to your language, or you'll end up a total mess, like C++. Java and C# gave us some interesting and subtle lessons ab…

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've done that in lots of languages, but it usually means I was trying to crash the compiler :-)

I remember there was some simple way to crash a Haskell compiler with an out of memory error by defining a series of types, where each successive type required twice as much memory as the previous type to represent.

Re: How generics are implemented in Go 1.18

#22

Post by jerf »

shadowgovt wrote: post #18

Something I haven't been able to pull up yet: what does the addition of generics do the `reflect` package? I assume it needs to be extended to deal with reflection through generics?

All types are concrete at run time, so, no it doesn't end up needing changes: https://go.googlesource.com/proposal/+/refs/heads/master/des...

"We do not propose to change the reflect package in any way. When a type or function is instantiated, all of the type parameters will become ordinary non-generic types. The String method of a reflect.Type value of an instantiated type will return the name with the type arguments in square brackets. For example, List[int].

"It's impossible for non-generic code to refer to generic code without instantiating it, so there is no reflection information for uninstantiated generic types or functions."

Re: How generics are implemented in Go 1.18

#23

Post by [deleted] »

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

[deleted]

Re: How generics are implemented in Go 1.18

#24

Post by kaba0 »

shadowgovt wrote: post #6
endymi0n wrote: post #3

Earlier quoted context omitted.

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…

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.

If they wanted to avoid problems they would have implemented the feature right away, instead of making it a second thought for a supposedly modern language.

Re: How generics are implemented in Go 1.18

#26

Post by nosefrog »

shadowgovt wrote: post #20
klodolph wrote: post #14

Earlier quoted context omitted.

I only occasional do language design / compiler writing projects, or work with compiler internals. Most people are really bad at estimating the implementation complexity and tradeoffs inherent in various language features. I'd say that C++ serves as a warning to others... think before you add features to your language, or you'll end up a total mess, like C++. Java and C# gave us some interesting and subtle lessons ab…

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 wasn't able to run the Clojure compiler in 2012 on a $150 dollar chromebook because it would OOM... but I blame myself for that one :P

Re: How generics are implemented in Go 1.18

#28

Post by layer8 »

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?

Re: How generics are implemented in Go 1.18

#30

Post by xigoi »

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

Increases compared to what? If you don't use generics and write the code for each type manually, you'll end up with exactly the same thing.
Post reply on HN