By the way, are there any projects underway to produce a library of the most common basic template functions? I'm very much looking forward to unifying some of my most copy-pasted functions when 1.18 is out, but I would like to unify on a central library right away.
How generics are implemented in Go 1.18
61–70 of 228 posts
Re: How generics are implemented in Go 1.18
#62By the way, are there any projects underway to produce a library of the most common basic template functions? I'm very much looking forward to unifying some of my most copy-pasted functions when 1.18 is out, but I would like to unify on a central library right away.
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
Re: How generics are implemented in Go 1.18
#63Earlier quoted context omitted.
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.
Increased compile time compared to doing polymorphism with an extra layer of indirection, I’m guessing
Re: How generics are implemented in Go 1.18
#64Re: How generics are implemented in Go 1.18
#65Programming 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…
[deleted]
Re: How generics are implemented in Go 1.18
#66Does 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?
There are "shared" and "c-shared" build modes[1], if that's what you mean. The latter is fairly obvious. The former is so rarely used that there was a proposal to remove it, but it turned out that some people did actually use it, but almost exclusively because of license terms.
Re: How generics are implemented in Go 1.18
#67Programming 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)
Re: How generics are implemented in Go 1.18
#68Earlier 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…
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.
That's not true, Rust doesn't have those headers and has the same compile time issues as C++.
Re: How generics are implemented in Go 1.18
#69Earlier quoted context omitted.
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…
> Although monomorphization takes a significant chunk of a typical Rust compilation, it pales in comparison to LLVM codegen
It's not the monomorphization itself that takes a long time, it's the LLVM codegen due to all the extra code being generated from duplicated function implementations. I've heard macros slow for largely the same reason, it's not the macro execution itself that's slow, it's compiling all the generated code.
Re: How generics are implemented in Go 1.18
#70I 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…
These "GC shapes" a lot like GHC's "runtime reps": https://hackage.haskell.org/package/base-4.16.0.0/docs/GHC-E...
GHC allows recursion that is "polymorphic in the types" but "monomorphic in the runtime reps". There is no reason why Go shouldn't allow polymorphic recursion that is "monomorphic in the gc shapes" either, though they might not have bothered to allow it yet.