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

151–160 of 228 posts

Re: How generics are implemented in Go 1.18

#151

Post by valenterry »

tsss wrote: post #136
kerkeslager wrote: post #91

So maybe 7-8 years ago, I got into a bunch of arguments with people on Hacker News because I said that Go's type system was ineffective without generics. At that time, Gophers leaped to defend it, going so far as to say that it's better because it's simple. Oh and it was really important to Gophers that Go compiles in a single pass (which I argued is only relevant for truly enormous codebases like Google's). A few ye…

Quoted post unavailable.

It in fact reminds a bit of Angular. I'm expecting a similar revamp of Go at some point - it will share the same name but otherwise won't have to do anything with the original.

Re: How generics are implemented in Go 1.18

#152

Post by yakubin »

nicoburns wrote: post #69
yakubin wrote: post #35

Earlier quoted context omitted.

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

> 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.

If that were true, the same issue would apply to hygienic macros, yet it doesn't. It's distinctly a problem with proc macros.

Re: How generics are implemented in Go 1.18

#153

Post by FooBarWidget »

pjmlp wrote: post #17
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.

D, Ada, Eiffel, Delphi go as counter example, and C++ modules are already proving a much better experience in VC++.

Delphi didn't have generics. Not sure about more modern versions, but the power of the generics also impacts compile times. Java generics barely impact compile times at all but they're also nowhere as powerful as Rust and C++ ones.

Re: How generics are implemented in Go 1.18

#154

Post by gspr »

klodolph wrote: post #21
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'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.

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

It's a real problem.

Anecdotally: I maintain a Debian package with a large-ish (but far from huge), template-heavy C++ codebase. I had to give up on compiling on 32 bit machines long ago, simply because not enough addressable memory was available to the compiler. I know other maintainers have to heavily tune the compiler to work around the problem, too.

I was once asked by the Ubuntu folks to disable parallel builds altogether, due to even their 64 bit builders running out of memory altogether.

And this package is just large-ish – it's nowhere near truly large (like a browser or an office suite).

Re: How generics are implemented in Go 1.18

#155

Post by twic »

MobiusHorizons wrote: post #112
staticassertion wrote: post #102

Earlier quoted context omitted.

How is Go lower level than C#?

One major difference that makes Golang lower level is that it compiles to machine code for the target CPU arch/OS instead of bytecode.

I think this is a red herring - compiling to native code is orthogonal to low-levelness. Haskell compiles to native code, but is exceedingly high-level. Forth is traditionally bytecoded, or threaded-coded, but is excruciatingly low-level.

Java was originally bytecoded, but at some point gained various ahead-of-time native compilers. Did it become lower level when that happened? It did not.

Re: How generics are implemented in Go 1.18

#156

Post by kaba0 »

Cthulhu_ wrote: post #144
Guthur wrote: post #127

Earlier quoted context omitted.

Nope, as a language Go adds nothing and sometimes feels like it gives even less. Where Go has been a success is tooling. The tooling is pretty decent and helps a lot. But that could be added to pretty much any language ecosystem

Go apologist here. Go doesn't work because it adds something to existing languages, but because it keeps things away. In 30 years time, Go codebases built today will still be around, while Java, Javascript, Scala or Ruby codebases will have been rebuilt multiple times over or removed entirely, because they drowned in their own complexity and their developers' own cleverness. That said, for me it's not so much Go itse…

That’s a bit bold coming from a relatively young language, given that Java has codebases close to 25 years old.

Also, repeating the same code many times due to lack of expressiveness is not the epitome of long-lived software. Essential complexity is non-reducable, the only way we can deal with it is through abstractions.

Re: How generics are implemented in Go 1.18

#157

Post by kaba0 »

pjmlp wrote: post #128
mahesh-hegde wrote: post #122

Earlier quoted context omitted.

AOT compiler; single binary; standard library and package ecosystem well suited for a subset of programming tasks, while being much lightweight and less verbose than Java / C#. Would not pick Go to make a website. But it's probably best tool to make a simple HTTP server or command line tool that deals with files or network.

Java has AOT compilers since 2000, they just weren't free beer. .NET was released with AOT compiler, although it only did dynamic linking (NGEN). Mono always supported AOT compilation, just like the C# dialects for Singularity, Midori, and .NET Native for Windows 10 UWP.

Actually, there used to be GCJ which was a free AOT compiler for Java

Re: How generics are implemented in Go 1.18

#158

Post by kaba0 »

MobiusHorizons wrote: post #112
staticassertion wrote: post #102

Earlier quoted context omitted.

How is Go lower level than C#?

One major difference that makes Golang lower level is that it compiles to machine code for the target CPU arch/OS instead of bytecode.

By bundling a runtime. The abstraction level is pretty much the same as Java/C#/JS.

Re: How generics are implemented in Go 1.18

#159

Post by madmax96 »

kaba0 wrote: post #157
pjmlp wrote: post #128

Earlier quoted context omitted.

Java has AOT compilers since 2000, they just weren't free beer. .NET was released with AOT compiler, although it only did dynamic linking (NGEN). Mono always supported AOT compilation, just like the C# dialects for Singularity, Midori, and .NET Native for Windows 10 UWP.

Actually, there used to be GCJ which was a free AOT compiler for Java

GCJ had compatibility issues. It never supported Java 1.5. It also couldn’t handle static linking properly. For a large-scale project it usually wasn’t an option.

Re: How generics are implemented in Go 1.18

#160

Post by pjmlp »

FooBarWidget wrote: post #153
pjmlp wrote: post #17

Earlier quoted context omitted.

D, Ada, Eiffel, Delphi go as counter example, and C++ modules are already proving a much better experience in VC++.

Delphi didn't have generics. Not sure about more modern versions, but the power of the generics also impacts compile times. Java generics barely impact compile times at all but they're also nowhere as powerful as Rust and C++ ones.

You stop using Delphi long time ago, I would say.

To pick one of my examples, D templates and compile time metaprogramming are even more powerfull than Rust and C++ ones, yet it compiles just as fast.

Post reply on HN