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

91–100 of 228 posts

Re: How generics are implemented in Go 1.18

#91

Post by kerkeslager »

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 years later we had go generate. Which I argued was a glorified C macro system to get around the lack of generics. Oh and everybody forgot about the single-pass thing, I guess.

Now in this thread there are a bunch of people commenting that they can't wait to combine all their copy pasted code using a generics which are implemented via a tree traversal that actually kind of complicated the idea of what a pass even is (I think memoization could make this linear, but at the cost of memory?).

This is a language that seemingly insists on breaking the wheel. Notice I didn't say reinventing, because in over a decade they haven't actually gotten a working version of the wheel out yet. I mean seriously, Go was released in 2009: if I'm not mistaken, C# had a pretty good generic system already, and there were a bunch of other workable options to copy from less-mainstream languages. Not that copying has helped: they copied coroutines from other languages, but failed to present a coherent memory sharing model (just copy Erlang FFS), which severely limits the usefulness of coroutines.

Every few years someone gets me to try Go out again and I discover, yet again, that it's still struggling with problems that were solved before it existed. It's a shame that this language has stolen so much mind share from more deserving languages.

Re: How generics are implemented in Go 1.18

#92

Post by vips7L »

kllrnohj wrote: post #80
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 see you haven't worked with the joy of gradle & modern Java development. By the time you stack up gradle, javac itself, proguard or for Android R8 which are basically required to fix the terrible bytecode javac produces, some annotation processors because WHY NOT, custom build plugins, etc... it gets big

I highly doubt that javac produces terrible bytecode.

Re: How generics are implemented in Go 1.18

#93

Post by Groxx »

LukeShu wrote: post #49
Groxx wrote: post #43

Earlier quoted context omitted.

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

Interesting I hadn't caught that requirement before. It both kinda makes sense and kinda doesn't... and sadly throws some cold water on a few "it'd be fun to try to do X" ideas I've had floating around in my head.

I suppose there's always RPC-like options.

Re: How generics are implemented in Go 1.18

#94

Post by EE84M3i »

LukeShu wrote: post #49
Groxx wrote: post #43

Earlier quoted context omitted.

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

Does this even include the standard library?

Re: How generics are implemented in Go 1.18

#95

Post by vips7L »

shadowgovt wrote: post #89
kllrnohj wrote: post #80

Earlier quoted context omitted.

I see you haven't worked with the joy of gradle & modern Java development. By the time you stack up gradle, javac itself, proguard or for Android R8 which are basically required to fix the terrible bytecode javac produces, some annotation processors because WHY NOT, custom build plugins, etc... it gets big

Computers seem to have caught up. The Java stack is the slowest one I regularly use (though it does support a certain amount of hot-recompile that other toolchains I use don't or can't), but it's never just crashed because it can't find room to store all those bytecode files.

I’ve compiled projects with javac, scalac, g++, gcc, and dmd. Javac is faster than all of them.

Re: How generics are implemented in Go 1.18

#96

Post by vgchh »

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…

Well let perfect not be the enemy of the good. The reality is that Go is wildly successful in practice for good reasons that have been hashed numerous times. As a result tons of Cloud software is written in Go.

There is nothing Go needs to be ashamed on. Its mindshare is a result of a good choice people made at a certain point in time. A better language will win at its own merits.

Re: How generics are implemented in Go 1.18

#97

Post by klodolph »

azth wrote: post #87
klodolph wrote: post #60

Earlier quoted context omitted.

It affects method overloading too, I should have said “method overloading”. Just take a look at the rules for method overloading in C#, or take a look at one of the various C# compilers to see how methods are resolved.

Why are they an issue in C#, but not Java, which also has similar method overloading? Or are they related to default arguments?

You may be inferring something that I didn’t write. I didn’t once mention method overloading in Java.

Re: How generics are implemented in Go 1.18

#98

Post by benhoyt »

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…

But the fact remains that it's a productive language with excellent tooling and fast build times, and a lot of people really like working with it (myself included).

I believe the reason it has gotten as far as it has without generics is because it did always have them -- but only for the built-in data types (slices, maps, channels). You just couldn't add your own until Go 1.18. I have several medium-sized Go projects that benefit hugely from generic slices and maps, but wouldn't benefit at all from user-defined generics.

Re: How generics are implemented in Go 1.18

#99

Post by joshsyn »

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…

No post body was provided.

Re: How generics are implemented in Go 1.18

#100

Post by throwaway34241 »

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…

I’m not going to defend what random internet commenters may have said, but in my view the core team has been fairly consistent and their design decisions (to me) make sense.

The first thing to understand is that Go occupies a space lower level than Java but higher level than C. It includes things like explicit pointers and more control of memory layout.

Many of the design decisions make no sense without that context. Go can’t simply copy generics from Java or memory sharing from Erlang, since the design decisions made by those languages would introduce too much overhead in a language intended to be lower level. In a lower level language more aspects of how a program executes are specified explicitly, rather than accepting more overhead or guessing what a complex optimizer will do.

On generics, I think the team’s position has mostly been that it’s a big project and there’s been other priorities like rewriting the compiler in Go, improving the GC, etc. And that in the spectrum of trade-offs for generics systems they didn’t want to go all the way to Java or C++.

I feel like a lot of HN commenters compare Go to higher level languages and find it lacking, which may be a fair assessment for certain problems but isn’t really understanding the niche it tries to occupy.

Post reply on HN