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

Notes on the Go2 Generics Draft

jmoiron.net

Post reply on HN
Print view View original

101–110 of 116 posts

Re: Notes on the Go2 Generics Draft

#101

Post by steveklabnik »

civility wrote: post #93
zimbatm wrote: post #86

Earlier quoted context omitted.

Maybe that's the issue. From what I have seen, the lack of generics mainly becomes painful when working in the numerical space. If I work on mapping JSON, doing APIs and CLIs I don't really need generics. If I work on algorithms and data bags then it starts to be annoying re-implementing the same thing over and over again. So in these discussion you have devops-type people mainly dealing with APIs that are perfectly…

I think you're exactly right: People who live and breathe JSON and strings don't (and probably shouldn't) care about use cases where the choice between float or double matters... I also see this with graphics people who live and breathe small (2x2, 3x3, and 4x4) matrices don't care about "type level integers" (as Rust calls them) to make 6x9 matrices efficiently live on the stack or in an array. > Is it possible that…

Graphics people are one of the groups most often requesting type level integers. I’m sure many are fine without them, but many want them too.

Re: Notes on the Go2 Generics Draft

#102

Post by baby »

vmchale wrote: post #99
baby wrote: post #68

Earlier quoted context omitted.

Same here, as a security consultant reading Golang is always a pleasure. I'm pretty sure that the strongest codebases I've seen were in Golang just because of how easy it is for everyone to read the code and actually spend time looking for logic bugs instead of trying to understand what is happening. Developers love to be able to write their magical code and their clever abstractions and often forget that their code…

> Developers love to be able to write their magical code and their clever abstractions and often forget that their code is paying the price by becoming less clear and less readable. Clearly, that justifies the fact that you can't sort an array of doubles and an array of floats with the same function.

Does it not? That’s the entire point of my comment. Some stuff are going to be painful but overall the lack of generics is a blessing.

Re: Notes on the Go2 Generics Draft

#103

Post by ainar-g »

everybodyknows wrote: post #94
bww wrote: post #29

I’m a fellow generics pessimist. Having come to Go from Java some 6 years ago I initially found the lack of generics a curious, sometimes frustrating omission. After years of using Go daily and reading a long succession of posts on the go-nuts mailing list wherein Rob Pike, et al, repeatedly and staunchly defended the lack of generics as necessary – even beneficial – in the pursuit of designing a small, readable, coh…

Speaking of Rob Pike, don't see his name on any of the Go2 proposals. His lucidity and circumspection are sorely missed. Could we be witnessing the psychological phenomenon of a "second-system effect" -- as described in The Mythical Man-Month -- writ very large?

The only person from the original three creators who still actively takes part in the language's evolution seems to be Robert Griesemer. Ken Thompson is retired, and Rob Pike seems to have moved to other projects (Upspin?). Robert Griesemer is still active, but mostly "debugging" the language specification.

The impression I get is that Russ Cox is pretty much the Chief Designer right now (pardon the Sergey Korolyov reference). The original three authors have said that they would not add a feature to the language if one of them opposed it, which is how they kept it simple. I wonder if rsc has anyone to say "no" to him.

Re: Notes on the Go2 Generics Draft

#104

Post by slavik81 »

cdoxsey wrote: post #59
civility wrote: post #57

Earlier quoted context omitted.

Writing the exact same code for float and double (and possibly complex float and/or complex double) sucks. You've created some straw man about dopamine junky programmers because you don't need generics for whatever it is you do. If you wrote numerical algorithms you'd be annoyed at any language which lacks generics.

Ironically generics don't necessarily solve this. C# requires multiple implementations of numeric methods because int/float/etc don't sit in a type hierarchy. It also doesn't really work in Java either because you have to use the Object types. Even in rust this looks pretty complicated: https://travisf.net/rust-generic-numbers Maybe it's easy in c++? I've seem a similar comment made on almost every discussion of this…

The complexity in that rust example comes from the indirection of requiring you to declare what operations you require via traits. C++ is much simpler: whatever operation you use is required.

Re: Notes on the Go2 Generics Draft

#106

Post by prattmic »

zmanian wrote: post #30

It's impossible to defend the lack of generics in golang in the face of the fact that two of the larger open source projects both invented their own generics implementations. https://medium.com/@arschles/go-experience-report-generics-i... https://github.com/google/gvisor/blob/master/tools/go_generi...

As someone that works on gVisor, I disagree with this w.r.t. our project. i.e., the existence of our go_generics tool is not an obvious indication that we need generics in the language.

A bit of history: this tool was originally created specifically for two packages, a linked list package, and a tree-based data-structure package. Both of these used an interface for the entry types, but this had two main drawbacks:

1. Interface assertions and conversions are (often) not free. These packages are used heavily in our critical system call handling path and this was costing on the order of a couple hundred nanoseconds in the critical path (total cost of the critical path is ~1500-4000ns depending on the syscall).

2. Escape analysis does not work across interface methods, requiring heap allocation of pointer arguments. This was less of an immediate problem for the initial creation of go_generics, but annoying to work around in the critical code where it mattered.

The go_generics tool solves both of these problems by generating versions of these data structures with concrete types. However, neither of these problems require generics to solve. General compiler and toolchain improvements could solve both. In fact, I imagine that (1) is greatly improved already (we were solving this problem in the Go 1.5 timeframe).

To this day, our code base has a grand total of 5 generic templates:

segment [1], ilist [2]: These are the two packages referenced above.

seqatomic [3]: Synchronization primitive for sequence count protected values. Not safe to use interfaces.

bits [4]: This is the typical "multiple integer types" problems. IMO, this use is overkill, there are only ~20 lines of code to copy.

pagetables Walker [5]: Used in critical //go:nosplit //go:noescape context, where most runtime calls are unsafe.

Given our experience with, and very narrow use of our go_generics tool, I'd actually rather Go not add generics and continue to use specialized code generation in the places we really need it.

I do recognize that there are a lot of other cases where people legitimately want generics and I am not fundamentally opposed to the draft proposal, but this was my long-winded way of saying that our go_generics are not an obvious argument in favor.

[1] https://github.com/google/gvisor/blob/f3060cb1a4ed61199688b5...

[2] https://github.com/google/gvisor/blob/8fee8f4dd5f7257a7eb77c...

[3] https://github.com/google/gvisor/blob/d1bbaf8b2caba906484d5e...

[4] https://github.com/google/gvisor/blob/d1bbaf8b2caba906484d5e...

[5] https://github.com/google/gvisor/blob/d1bbaf8b2caba906484d5e...

Re: Notes on the Go2 Generics Draft

#107

Post by zmanian »

prattmic wrote: post #106
zmanian wrote: post #30

It's impossible to defend the lack of generics in golang in the face of the fact that two of the larger open source projects both invented their own generics implementations. https://medium.com/@arschles/go-experience-report-generics-i... https://github.com/google/gvisor/blob/master/tools/go_generi...

As someone that works on gVisor, I disagree with this w.r.t. our project. i.e., the existence of our go_generics tool is not an obvious indication that we need generics in the language. A bit of history: this tool was originally created specifically for two packages, a linked list package, and a tree-based data-structure package. Both of these used an interface for the entry types, but this had two main drawbacks: 1.…

Thanks! This is actually useful information.

Re: Notes on the Go2 Generics Draft

#108

Post by jy3 »

civility wrote: post #90
jy3 wrote: post #60

Earlier quoted context omitted.

That means Go is not the right tool for you. Don't use it. It's so sad to see people pushing to radically alter a language that they will probably never use because it will never be suitable for their needs.

No, Go is not currently the right tool for me, but it's close, and it would be much closer with (usable) generics. What's "so sad" is you think this Reddit style "Don't use it" imperative is an acceptable way to talk to people. You're rightfully afraid of complexity creeping into an otherwise clean language, but it would suck less if you said it better.

I'm taken aback. I didn't mean to sound condescending.

I won't argue with you my use of the imperative mood as I'm not a native speaker. I'll take note of it.

Re: Notes on the Go2 Generics Draft

#109

Post by vorg »

atsjie wrote: post #105

The proposal reads like an attempt to add generics to a language that was not conceived to include it in the first place. It looks complex.

I agree. The real problem is they're trying to add generics to Go and make Go 2 backwards-compatible with Go 1. Doing both generates the complexity, just like with Java 5. Generics in a language are good, but Go will cross the line from simple to bloated as soon as these generics are added. To remain a simple language with generics, Go 2 would need to give up backwards compatibility with Go 1, something which the suits at Google would veto if any techies there actually tried it.

Re: Notes on the Go2 Generics Draft

#110

Post by zimbatm »

phamilton wrote: post #88
zimbatm wrote: post #86

Earlier quoted context omitted.

Maybe that's the issue. From what I have seen, the lack of generics mainly becomes painful when working in the numerical space. If I work on mapping JSON, doing APIs and CLIs I don't really need generics. If I work on algorithms and data bags then it starts to be annoying re-implementing the same thing over and over again. So in these discussion you have devops-type people mainly dealing with APIs that are perfectly…

> mapping JSON I find that an ideal set of tools allow us to describe our task and write our code using the same idioms. The fact that "mapping JSON" doesn't actually involve calling "map" on JSON data is a great example of why not having generics in golang is frustrating for me.

I forgot the 3rd category, those who see the world exclusively through the functional programmer lens :-D

Mapping functionally it worth it if the transformation between A and B is regular enough. But things are dirty. Some irregularities appear and now the perfect higher-order function doesn't work nicely anymore. With the imperative approach it just means adding 1 -3 more lines.

Post reply on HN