←back to thread

Go Optimization Guide

(goperf.dev)
480 points jedeusus | 4 comments | 31 Mar 25 20:29 UTC | HN request time: 0.001s | source
Show context
stouset ◴[01 Apr 25 06:46 UTC] No.43543575[source]▶
Checking out the first example—object pools—I was initially blown away that this is not only possible but it produces no warnings of any kind:

    pool := sync.Pool{
        New: func() any { return 42 }
    }

    a := pool.Get()

    pool.Put("hello")
    pool.Put(struct{}{})

    b := pool.Get()
    c := pool.Get()
    d := pool.Get()

    fmt.Println(a, b, c, d)
Of course, the answer is that this API existed before generics so it just takes and returns `any` (née `interface{}`). It just feels as though golang might be strongly typed in principle, but in practice there are APIs left and rigth that escape out of the type system and lose all of the actual benefits of having it in the first place.

Is a type system all that helpful if you have to keep turning it off any time you want to do something even slightly interesting?

Also I can't help but notice that there's no API to reset values to some initialized default. Shouldn't there be some sort of (perhaps optional) `Clear` callback that resets values back to a sane default, rather than forcing every caller to remember to do so themselves?

replies(5): >>43543875 #>>43544042 #>>43544109 #>>43544700 #>>43546668 #
tgv ◴[01 Apr 25 07:32 UTC] No.43543875[source]▶
You never programmed in Go, I assume? Then you have to understand that the type of `pool.Get()` is `any`, the wildcard type in Go. It is a type, and if you want the underlying value, you have to get it out by asserting the correct type. This cannot be solved with generics. There's no way in Java, Rust or C++ to express this either, unless it is a pool for a single type, in which case Go generics indeed could handle that as well. But since Go is backwards compatible, this particular construct has to stay.

> Also I can't help but notice that there's no API to reset values to some initialized default.

That's what the New function does, isn't it?

BTW, the code you posted isn't syntactically correct. It needs a comma on the second line.

replies(6): >>43543989 #>>43544008 #>>43544021 #>>43544567 #>>43545116 #>>43546665 #
1. pyrale ◴[01 Apr 25 13:39 UTC] No.43546665[source]▶
> There's no way in Java, Rust or C++ to express this either

You make it look like it's a good thing to be able to express it.

There's no way in Java, Rust or C++ to express this, praised be the language designers.

As for expressing a pool value that may be multiple things without a horrible any type and an horrible cast, you could make an union type in Rust, or an interface in Java implemented by multiple concrete objects. Both ways would force the consumer to explicitly check the value without requiring unchecked duck typing.

replies(3): >>43550823 #>>43551026 #>>43552063 #
2. sophacles ◴[01 Apr 25 20:08 UTC] No.43550823[source]▶
Rust has an Any type. It's rarely useful, but there are occasionally situations where a heterogeneous collection is the right thing to do. Casting the any type back to actual type is fairly nice though, as the operation returns an Option<T> and you're forced to deal with the case where your cast is wrong.
3. tgv ◴[01 Apr 25 20:32 UTC] No.43551026[source]▶
> You make it look like it's a good thing to be able to express it.

No, just that this pre-generics Go, and backwards compatibility is taken seriously.

4. int_19h ◴[01 Apr 25 22:45 UTC] No.43552063[source]▶
> There's no way in Java, Rust or C++ to express this, praised be the language designers.

That's not even the case. In Java, you'd just use Object, which is for all practical purposes equivalent to `interface{}` aka `any` in Go. And then you downcast. Indeed, code exactly like this was necessary in Java to work with collections before generics were added to the language.

In C++, there's no common supertype, but there std::any, which can contain a value of any type and be downcast if you know what the actual type is.