Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Expectations for generics in Go 1.18

groups.google.com

Post reply on HN
Print view View original

171–180 of 209 posts

Re: Expectations for generics in Go 1.18

#171

Post by valenterry »

throwaway894345 wrote: post #155
valenterry wrote: post #120

Earlier quoted context omitted.

Sure, devops tools are usually more fundamental, whereas high level languages are used for things closer to the business. Twitter's backend for example is mainly powered by Scala, but you probably don't know about it, because it is not as visible to you.

Enumeration isn’t a compelling way to indicate relative frequency (in this case, frequency of usage of Go and Scala, respectively). An enumeration of size=1 is even less convincing.

That was not my intention. The example was supposed to show that not all software has the same visibility to software-developers.

Re: Expectations for generics in Go 1.18

#172

Post by Zababa »

masklinn wrote: post #169
Zababa wrote: post #148

Earlier quoted context omitted.

Don't you need sum types/sufficiently powerful enums for Result though? Which, in a way, makes it a language feature.

You’re confusing the chicken for the egg. Sum types are a powerful language feature, but they’re also a general language feature, they don’t exist for the sole purpose of creating a Result type (and indeed a number of languages have had the former and lacked the latter).

Do you mean that in contrast to affine types, that are here for borrow checking?

Re: Expectations for generics in Go 1.18

#173

Post by Zababa »

StevePerkins wrote: post #152
kubb wrote: post #137

Earlier quoted context omitted.

That's an expected pivot. From "nobody needs generics" to "we absolutely needed 10 years to figure out the best way to do parametric polymorphism, which was already known for 35 years when the language was created". And of course in addition to that, there will probably be claims that "no one claimed that generics aren't needed". I'm glad that we have the archives to show that this isn't true, and it's a good thing t…

The term "gaslighting" has become overwrought to the point where it's hard not to immediately dismiss anyone using it. It is not a "pivot" for someone to say, "X isn't necessary" , and then say, "X still isn't necessary but at least it's implementation doesn't break things" .

There's no gaslighting. The Go team position was always something like "We didn't find a good way to include generics in the language, but if we do we may add them". That's a reasonable position.

However some people, which are referred here as "apologetes and zealots", claimed that you don't need generics and that they were a bad thing, which is a very different thing and not the opinion of the Go team.

The conclusion here is that these people were wrong, just like the ones that said that it was impossible to do anything serious without generics. While those people were busy arguing with other people on the net, the Go team and community were slowly but surely refining their ideas on generics and how to make them fit into Go.

Re: Expectations for generics in Go 1.18

#174

Post by mseepgood »

Joker_vD wrote: post #162
Kranar wrote: post #14

Earlier quoted context omitted.

Yes, which I find unfortunate but I can respect that approach as it's likely the simplest way of implementing it and Go does want to avoid heavy abstraction in its type system. The downside is you can't do something like have a function pointer to the generic itself or specify generic members of a dyn trait/interface or otherwise treat the generic as a first class value (although you can treat specific instantiations…

C# mostly gets away with it because it has JIT support for it; in the end you still need to generate code for every data-size it's used with. Obviously, if all data are passed by reference you'd only need to generate code for the size of the pointer. Even in C#, generics are sort-of second class: interface IMyLovelyADT { R Accept (IMyLovelyADTVisitor visitor); } is not isomorphic to Func , R> The interface is strictl…

> Interestingly enough, upcoming Go 2's generics

It will be Go 1.18, not Go 2.

Re: Expectations for generics in Go 1.18

#175

Post by tcard »

kubb wrote: post #117

I'm glad that all the blog posts written by the apologetes and zealots, claiming that Go doesn't need generics and how they will actually be a detriment to the language, are archived somewhere in the wayback machines, so that they can't gaslight us into believing that they weren't just being silly for all this time.

Who's "they"?

Surely you don't mean the Go team, which has had this in the language FAQ since 2009 [1]:

Why does Go not have generic types?

Generics may well come at some point. We don't feel an urgency for them, although we understand some programmers do.

Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.

[1] https://github.com/golang/go/commit/dd64f86e0874804d0ec5b713...

Re: Expectations for generics in Go 1.18

#176

Post by eweise »

arp242 wrote: post #13
jimbob45 wrote: post #6

Does anyone know the impetus for using [] in generics? I know Nim opted for the same syntax and I assume it has some parsing/tokenizing benefit like the switch to using “fn” a la Zig or Rust. However, the syntax seems needlessly ambiguous with array notation sharing the same operator. I know I’m not alone because I’ve seen others mirror my concerns on Nim forums [0]. [0] https://github.com/nim-lang/Nim/issues/3502

The original implementation used ( .. ), which I found an unreadable mess of parentheses soup, but luckily that was changed. The problem with is that it's ambiguous with the greater-than and lesser-than operators. From [1] (among many other discussions on this): For ambiguities with angle brackets consider the assignment a, b = w (z) Without type information, it is impossible to decide whether the right-hand side of…

Let's face it, is just ugly. whereas [] is beautiful :)

Re: Expectations for generics in Go 1.18

#177

Post by pjmlp »

geodel wrote: post #170
pjmlp wrote: post #104

Finally catching up with modern times.

I have heard even Java is going to catch up with modern times with Valhalla and maybe even futuristic later on, where a directory tree of source files can be compiled without weird twisting of java command line.

Not paying attention to the AOT compilers available since 2000, or optimizations available on IBM J9?

I guess it is a thing, after all Go folks tend to ignore the experience from other programming communities.

Re: Expectations for generics in Go 1.18

#178

Post by dnautics »

akavel wrote: post #141
1_player wrote: post #91

Earlier quoted context omitted.

Zig disagrees. Monads are cool and all, but we can do better than Result for error handling.

AFAIR, Zig has an open issue on how to pass additional context with errors, such as e.g. row & col where a syntax error happened.

To clarify I thin parent means syntax error I'm the sense of "I'm parsing a (code) file at runtime and there's a syntax error", not a language syntax error.

I mean there's nothing stopping you in zig from creating a rich "error" struct and returning a union of the struct with whatever you would have done otherwise. You only lose the error return trace.

Re: Expectations for generics in Go 1.18

#179

Post by tored »

arp242 wrote: post #13
jimbob45 wrote: post #6

Does anyone know the impetus for using [] in generics? I know Nim opted for the same syntax and I assume it has some parsing/tokenizing benefit like the switch to using “fn” a la Zig or Rust. However, the syntax seems needlessly ambiguous with array notation sharing the same operator. I know I’m not alone because I’ve seen others mirror my concerns on Nim forums [0]. [0] https://github.com/nim-lang/Nim/issues/3502

The original implementation used ( .. ), which I found an unreadable mess of parentheses soup, but luckily that was changed. The problem with is that it's ambiguous with the greater-than and lesser-than operators. From [1] (among many other discussions on this): For ambiguities with angle brackets consider the assignment a, b = w (z) Without type information, it is impossible to decide whether the right-hand side of…

> In Go, type information is not available at compile time.

Not a compiler expert, but I got confused when reading this, when is it available?

Re: Expectations for generics in Go 1.18

#180

Post by Joker_vD »

mseepgood wrote: post #174
Joker_vD wrote: post #162

Earlier quoted context omitted.

C# mostly gets away with it because it has JIT support for it; in the end you still need to generate code for every data-size it's used with. Obviously, if all data are passed by reference you'd only need to generate code for the size of the pointer. Even in C#, generics are sort-of second class: interface IMyLovelyADT { R Accept (IMyLovelyADTVisitor visitor); } is not isomorphic to Func , R> The interface is strictl…

> Interestingly enough, upcoming Go 2's generics It will be Go 1.18, not Go 2.

They've been discussed as one of the several "feature proposals for Go 2.0" for couple of years, the playground for them is called "https://go2goplay.golang.org/", the issues with them go into "cmd/go2go" tag on Github, so that's why I called them "Go 2's generics".

And weren't they supposed to be in Go 1.17 but then got delayed?

Post reply on HN