Golang Diaries: Generics

https://www.tbray.org/ongoing/When/202x/2022/05/14/Golang-Generics

by ciprian_craciun • 4 years ago

147 107 4 years ago

tbray.org

svnpenn• 4 years ago

func (c *container>[S]) size() int {

This is not valid code.

jallasprit• 4 years ago

This is one of the first things I remarked about the Go generics implementation. It is not yet possible to use Generics on struct methods.

fsdjkflsjfsoij4• 4 years ago

The restriction of not introducing new generic types on methods has nothing to do with why that code doesn't compile. Remove the '>' in the method signature and it works fine.

morelisp11• 4 years ago

No, it's not valid because there's a trivial typo probably caused by bad HTMLification. Remove the > and it's fine.

Strum355• 4 years ago

Thats a separate issue from the one being shown here. The syntax here is just invalid

Philip-J-Fry• 4 years ago

You can use generics, you just can't introduce new type parameters in the method. You're free to use the type parameters defined on the type you're writing the method for.

tapirl5• 4 years ago

It is obviously a typo.

timbray5• 4 years ago

Yep, fixed, thanks.

morelisp11• 4 years ago

Two thoughts:

1) The failure of

    func (t *fishTank) fishCount() string {
      return fmt.Sprintf("How many fishies? %d!", t.size())
    }

to work has nothing to do with generics; methods are always "removed" from types defined this way. If you want you can cast `t` to a `*container[fish]` and call it, but this is also where I would ask why "extend" rather than compose - are you gaining anything by ensuring identical layouts?

2) The bigger issue, that interfaces cannot require their implementations to be comparable, is https://github.com/golang/go/issues/52614 and linked tickets.

hiptobecubic2• 4 years ago

But why (1)? If a `fishTank` is a `container[fish]` what is the benefit of requiring it to be cast again?

morelisp11• 4 years ago

When people say Go is not an OO language, this is what they mean. Concrete type declarations define storage, not is-a hierarchies. A fishTank is not a container[fish], any more or less than it is any other `{ string, []fish }`.

masklinn4• 4 years ago

But why (1)? If a `fishTank` is a `container[fish]`

But a `fishTank` is not a `container[fish]`.

In common parlance

    type T Thing

is newtyping. T has the same implementation as the underlying type, and Go allows conversions back and forth, but they are otherwise unrelated, and the new type does not share the interface (method set) of the original.

It is, in a way, a shorthand for

    type T struct { _0 Thing }

tapirl5• 4 years ago

The answer is complete. I just make some additional explanations here.

1) is totally generics unrelated.

    package main
    
    type T1 int

    func (T1) M() {}
    
    type T2 T1
    
    func main() {
        var t2 T2
        t2.M() // t2.M undefined
    }

The fishTank should be defined as

    type fishTank struct {
        container[fish]
    }

instead.

2) is a temporary restriction, among many in the Go 1.18. Some of the restrictions will be removed from future Go versions.

ref:

* https://go101.org/generics/101.html

* https://github.com/golang/go/issues/50646#issuecomment-10237...

* https://github.com/golang/go/issues/51257

* https://github.com/golang/go/issues/51338

* https://github.com/golang/go/issues/52474

* https://github.com/golang/go/issues/52509

* https://github.com/golang/go/issues/52531

* https://github.com/golang/go/issues/52614

morelisp11• 4 years ago

Re. "temporary restriction": Although there's agreement something should improve around `comparable`, there's no concrete design approved to solve it. It may persist for many versions, or indefinitely.

(Vs. e.g re-enabling better type inference where the goal is known and it's "just" implementation work.)

timbray5• 4 years ago

Thanks. But why are methods removed from types defined this way? Is there a good discussion about this somewhere?

masklinn4• 4 years ago

I think Tim got confused between typedef (`type T Thing`, aka newtyping) and aliasing (`type T = Thing`).

deeptote2• 4 years ago

Go is my main language but it keeps disappointing me in it's lack of implementation tuning detail. Generics are just a code generator that, given it's poor performance for things like functional programming, makes it surprisingly of little use.

Go is a kitchen full of dull knives. It is good for layers of communication where you call other microservices to perform the heavy lifting, but not much else.

fsdjkflsjfsoij4• 4 years ago

given it's poor performance for things like functional programming, makes it surprisingly of little use.

In most cases it doesn't have "poor" performance and if you're going for optimal performance you are almost never going to be using generic data structures anyways because there's almost always type specific optimizations that can be done.

The intended use case is, and always has been, decently performing type safe data structures and Go generics are sufficient in most cases for that. Go is never going to be a functional programming language.

Gadiguibou• 4 years ago

Monomorphization is one of the ways generics are implemented in other languages and it definitely allows for type-specific optimizations.

I imagine there's a rationale for not implementing generics this way, like keeping binaries small, but it seems like a weird tradeoff considering it increases overall memory consumption and decreases performance quite a lot...

throwaway8943459• 4 years ago

I think the parent believes that code which allocates a lot and puts function calls in tight loops is an end unto itself, and he’s quite correct that Go isn’t going to perform well in those cases. Go’s memory management chooses expensive allocations and low latency over cheap allocations and high latency, which is appropriate because idiomatic Go doesn’t allocate often but as with anything, people who want to deviate from Go’s opinions experience a lot of friction and express frustration by characterizing Go as a bad language or in this case “a drawer full of dull knives”. One wonders if the parent gets frustrated that his blender is no good for driving nails or that his sink is too small to bathe in.

Thaxll2• 4 years ago

Go is on part with Java and C# and sometime as fast as C++, it's plenty fast for most usecases.

deeptote2• 4 years ago

Again, just one engineer's opinion, but that's because most use cases for engineers are CRUD. If you don't have a CRUD problem, which is probably less than 10% of modern software engineering, Go falls on it's face.

cpurdy• 4 years ago

Adding a type system to an existing language that was never intended to have that type system is not simple. And in Go, the language seems designed to largely eject its type system at the earliest opportunity that doesn't negatively impact the compiler. This will naturally constrain the capabilities of the generic programming constructs, much as it did in Josh Bloch's Java generics implementation.

Go is going to be torn between the minimalism of its creators, and the desires for modern capabilities expressed by its vocal user base. If this were a movie, it would be "A Beautiful Mind".

skybrian2• 4 years ago

There are vocal critics and sometimes they’re not wrong about some of the flaws, though often they make too big a deal of them.

But I think there are also people who appreciate stability? It’s a language people complain about in part because it’s popular.

In this case, Tim Bray tripped over “Go doesn’t have inheritance, but it does have embedding” and ran into a couple limitations in the first version of generics, but he’s not making any wider claims.

xyzzy_plugh2• 4 years ago

Luckily for us the Go core maintainers do not capitulate easily to the complaints from the vocal minority.

cy_hauser• 4 years ago

I thought the genericists were the majority? It was the top most requested feature in the Go surveys for years.

cube22226• 4 years ago

Frankly, having used Go for years, I started using generics right after they were released and I'm very happy with them so far.

Sure, the performance characteristics could be improved, but other than that they solve all my main pain points I wanted them to solve while being constrained enough to not result in ivory towers on every corner.

My main pain points having been duplicated functions for each type as well as data structures.

haolez3• 4 years ago

Where you see "modern", I see complicated type systems that solve the least interesting pains when programming. What they do provide is a feeling of "solving a puzzle" when all your type signatures are matching your usage patterns, but then again it's easy to mistake the puzzle solving with actual productivity.

Rich Hickey's talks can be very insightful in this regard. He surely convinced me :)

throwaway8943459• 4 years ago

I think type systems have diminishing returns. I’ve used Python professionally for 15 years and a whole lot of time is wasted trying to figure out exactly what properties a given parameter must have. In the best case, you have stuff like “file like object” which doesn’t tell you if it just needs a “read()” method or also write, seek, close, etc. In the common cases you have annotations that are incorrect or outdated.

On the other extreme, you have Rust and Haskell type systems where you spend gratuitous time on pacifying the type checker for negligible quality gains (arguably negative gains).

I always felt Go hit the sweet spot.

sanderjd6• 4 years ago

My counterpoint: I find it very hard to mistake writing a bunch of tedious repetitive code with productivity.

bitwize• 4 years ago

When programming in the small, I can see where a robust type system might feel like it's adding complexity and "getting in the way".

When programming in the large, type systems are flat out an unmitigated win. The more you can confidently assert about your program before run time, the more time and money your team will save. If you are programming a large system and not using strong static typing, optimally with higher-level features like parametric types, then you are doing it wrong.

LAC-Tech3• 4 years ago

I think my sweet spot is gradual typing.

In the early stages of developing something complex you often want to play fast and loose with the type system - get some code running, and some tests set up, and go from there. But later on you want to refine it and start catching some more errors statically.

The pendulum has swung really far to static typing - and I get why. But if it swings back I hope we don't forget about gradual typing.

Winsaucerer2• 4 years ago

With Go, I use a decent amount of generated code to create repetitive bits of code that only have small variations (e.g., the type!). Most of this code seems to not be possible for me to replace with generics yet, so I'm still finding myself using generated code. For example, a bunch of structs may share a field, but Go generics don't yet support accessing a field that is shared by types accepted by the interface.

xyzzyz3• 4 years ago

For example, a bunch of structs may share a field, but Go generics don't yet support accessing a field that is shared by types accepted by the interface.

You can easily and cleanly work around this by exposing getter and setter method in your interface.

Groxx7• 4 years ago

I was recently thinking that I would really like "field references" in go, e.g. via type.Field, like you can do for methods to get unbound methods. Partly because it might enable generics over "contains field(s)" instead of just "contains method(s)".

In the meantime I guess there's always anonymous functions (to use as accessors). They're not hard to be generic over.

swid• 4 years ago

Here's the way you can solve the first problem with generics in go, almost exactly as he described:

https://go.dev/play/p/GrLYBj3N0jr

The trick is to define the fish tank like so:

    type fishTank struct {
      container[fish]
    }

timbray5• 4 years ago

Thanks, yep, that works. Updated the blog piece and will improve the Quamina code a bit too.

masklinn4• 4 years ago

FWIW the original works as well, but because you're using a typedef (not an alias) you have to convert from your own type to the underlying:

    func (t *fishTank) fishCount() string {
        return fmt.Sprintf("How many fishies? %d!", (*container[fish])(t).size())
    }

that's because

    type fishTank container[fish]

creates a completely new and independent type with container[fish] as the underlying implementation.

An alternative is to just alias:

    type fishTank = container[fish]

however in that case you can't define methods on fishTank, because it's literally just a shorthand for container[fish].

CraigJPerry2• 4 years ago

Not a Go developer but i've been playing with Go for a toy project, really just to learn it. I had a tiny play with generics in Go when i needed a "min(int, ...int) int" func

    // --- There's no int min() in stdlib -----------------------------------------

    // Option 1. use math.Min() which is defined for float64, benchmarks comparing this with Option 2 & 3:
    //     BenchmarkMinImplementations/math.Min-8          261596238                4.282 ns/op
    //     BenchmarkMinImplementations/minGeneric-8        588252955                2.037 ns/op
    //     BenchmarkMinImplementations/minVariadic-8       413756245                2.827 ns/op

    // Option 2. Generics in Go 1.18, this is generic over int and float but can't support a variadic "b"
    func minGeneric[T constraints.Ordered](a, b T) T {
        if a < b {
            return a
        }
        return b
    }

    // Option 3. I was aiming for a lisp-style (min 1 2.3 -4) and this is variadic but it can't also be generic in 1.18
    func minIntVariadic(a int, bs ...int) int {
        for _, b := range bs {
            if b < a {
                a = b
            }
        }
        return a
    }

Coming from Java there's less to get your head around, e.g. super vs. extends isn't a thing here but otherwise similar.

Groxx7• 4 years ago

You can do variadic args, you just have to explicitly label the type in both arguments for some reason, like you did for the non-generic version: https://go.dev/play/p/L6psz_WdETM

(I'm aware it's not actually using the varargs reasonably, typing code on a phone is a pain)

CraigJPerry2• 4 years ago

Ha! This is awesome, thank you

gambler• 4 years ago

When I started using Go generics, they turned out to be completely useless for the use case I wanted to solve the most: functions to use in Go templates. Something is basic as adding two numbers is not solved by the core library and becomes a challenge with about a dozen numeric types. You can use a type switch and cast interface{}/any to float64 (which is a hack, but one that works in practice). What you can't do is use generics, because they require instantiation at compile time, which cannot happen in templates, because those are dynamic. Extremely disappointing.

Another disappointing thing is the fact that Go type inference is not good enough to have syntactically compact lambda functions. So now, even though it's possible to write code that does filter-map-reduce kind of stuff, it's verbose, slow to write and hard to read.

yazaddaruvala• 4 years ago

Hey Tim, a long time ago I came to your office in Vancouver to talk about Ruler. Quamina seems very similar.

Are you learning Go with a familiar project? or is there another motivation for Quamina?

timbray5• 4 years ago

See the piece about Quamina on my blog, it's the one before this one.

Golang Diaries: Generics

Related Stories