[zmanian]

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

[cshenton]

It’s weird to see complaints about code generation causing a too big code base at compile time when code generation is exactly what a compiler will do behind the scenes for generics.

[grumpyprole]

Not necessarily, specialisation is only argubly required for unboxed types. Java actually implements "Generics" without any specialisation at all, it boxes all the primitive types (rather controversially).

[IshKebab]

Nope. The draft explicitly states that the design allows the compiler to use a run-time implementation.

[prattmic]

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

[zmanian]

Thanks! This is actually useful information.

[dnomad]

Exactly. Like all ideological arguments it completely ignores actual real-world evidence. Somebody should sit down and analyze real codebases and understand and quantify how much these projects would be improved by real generics and proper exception handling. My (anecdotal) experience and speculation suggests that you'd see massive reduction in complexity and lines of code (especially when you consider code-gen).

But then this is part of a larger problem of the community which isn't motivated by evidence or basic pragmatism but rather strict adherence to a philosophy.

[frankietwenty9]

Changing the language specifically requires experience reports. If that's not real world evidence i'm not sure what is.

The problem with the wider go community is they are usually not driven by evidence, but adherence to a philosophy. eg, its not possible to write large programs without generics.

[baby]

> Somebody should sit down and analyze real codebases and understand and quantify how much these projects would be improved by real generics and proper exception handling

And also how most codebases would be worsen.