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

101–110 of 228 posts

Re: How generics are implemented in Go 1.18

#101

Post by Ericson2314 »

lalaithion wrote: post #76
Ericson2314 wrote: post #70

Earlier quoted context omitted.

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.

I think they do; the problem is that Go puts way less things behind a pointer than Haskell does. Every struct is its own runtime representation. If you change the example in https://github.com/golang/go/issues/48018 to use a pointer indirection, I think it should work.

Hopefully Haskell will get some monomorphizing generics and we will make less stuff boxed too!

Re: How generics are implemented in Go 1.18

#102

Post by staticassertion »

throwaway34241 wrote: post #100
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.…

How is Go lower level than C#?

Re: How generics are implemented in Go 1.18

#103

Post by sigmaml »

I made a crude proposal for generics in 2011[1], in which I proposed a pair of concepts ("storage class" and "type class") that are somewhat similar to the concept of this "gcshape".

I proposed it as a compromise between full monomorphisation and runtime code generation.

[1] http://oneofmanyworlds.blogspot.com/2011/11/draft-2-of-propo...

Re: How generics are implemented in Go 1.18

#104

Post by throwaway894345 »

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…

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

Go steals the mindshare because it focuses on the important problems that other languages neglect in part or in full: performance, tooling, ecosystem, simplicity, readability, learning curve, etc. Much important software has been built in fully dynamic languages (never mind a 99% type-safe language like Go), but it’s a lot harder to build in a language that lacks important libraries or is prohibitively slow or for whom it is hard to find/train developers, or whose tooling is poor, or which is difficult to read/maintain, or etc.

So yes, Go is now looking at generics because it’s tackled the more important problems. Not because it was the most important problem and the developers were just too stupid to understand.

Re: How generics are implemented in Go 1.18

#105

Post by throwaway34241 »

staticassertion wrote: post #102
throwaway34241 wrote: post #100

Earlier quoted context omitted.

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

How is Go lower level than C#?

I think C# might be the closest mainstream language, but I’d say explicit pointers, interior pointers, and slices as the default list type might be things that make Go programming a little lower level.

There are also other differences that would prevent using C#’s system as is - Go doesn’t have the reference/value type dichotomy or inheritance. I think they also wanted to be able to abstract across float/doubles etc (unless C# added that recently).

Anyway I like both languages and I’m not trying claim one is better than the other, just trying to explain the design space Go seems to occupy.

Re: How generics are implemented in Go 1.18

#106

Post by masklinn »

whateveracct wrote: post #38
Kranar wrote: post #29

Earlier quoted context omitted.

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.

> a slice of structs that implement an interface should be able to be used as a slice of that interface

It absolutely should not even if it could (which it can not since the memory layouts don’t match), as that undermines the type system.

Re: How generics are implemented in Go 1.18

#107

Post by masklinn »

vgchh wrote: post #96
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.

> Well let perfect not be the enemy of the good.

When you have half a dozen generic builtins but reject the idea that builtins are necessary, and can’t even be arsed to provide a working vector type, you’re nowhere near “good”.

Re: How generics are implemented in Go 1.18

#108

Post by pjmlp »

shadowgovt wrote: post #83
pjmlp wrote: post #19

Earlier quoted context omitted.

Generics exist in languages since 1976, more than enough examples than focusing on C++ and Java.

good point! What could the Go team glean from those languages to improve Go's generics implementation?

Lots of things, here is their acknowledgement that it was a mistake to ignore them.

> we were biased too much by experience with C++ without concepts and Java generics.

https://go.googlesource.com/proposal/+/master/design/go2draf...

Re: How generics are implemented in Go 1.18

#109

Post by omginternets »

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…

Where does this cause problems for you in practice? Where is the usefulness of goroutines limited practically? Where is the complex notion of a compiler pass causing problems?

I’m very open to the idea that I’m suffering from a problem I don’t know I have, but right now you’re just asserting that problems exist without actually telling us how to recognize them.

Re: How generics are implemented in Go 1.18

#110

Post by strangeattractr »

slx26 wrote: post #79
geodel wrote: post #50

Earlier quoted context omitted.

Right. Basically Go team is lacking big picture thinkers like this[1] 1. https://dilbert.com/strip/1994-12-17

Golang is my favorite language, and I really like the approach that the team takes. A few days ago I shared here some interesting comments from Griesemer on Golang enums. But sure, let's not give any ideas or question anything ever again, someone might get offended.

Honestly, the lack of enums annoys me far more than the generics ever do. Mainly because we have interfaces.
Post reply on HN