←back to thread

Go Optimization Guide

(goperf.dev)
480 points jedeusus | 3 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 #
1. jlouis ◴[01 Apr 25 13:39 UTC] No.43546668[source]▶
It is fairly common your type system ends up with escape hatches allowing you to violate the type rules in practice. See e.g., OCaml and the function "magic" in the Obj module.

It serves as a way around a limitation in the type system which you don't want to deal with.

You can still have the rest of the code base be safe, as long as you create a wrapper which is.

The same can be said about having imperative implementations with functional interfaces wrapping said implementation. From the outside, you have a view of a system which is functionally sound. Internally, it might break the rules and use imperative code (usually for the case of efficiency).

replies(1): >>43548185 #
2. stouset ◴[01 Apr 25 15:45 UTC] No.43548185[source]▶
Obviously every type system in practice has escape hatches. But I’ve never seen another staticly-typed language where you need to break out of the type system so regularly.

Go’s type system has your back when you’re writing easy stuff.

But it throws up its hands and leaves you to fend for yourself when you need to do nearly anything interesting or complex, which is precisely when I want the type system to have my back.

I should not have to worry (or worse, not worry and be caught off guard) that my pool of database connections suddenly starts handing back strings.

replies(1): >>43552022 #
3. int_19h ◴[01 Apr 25 22:39 UTC] No.43552022[source]▶
> But I’ve never seen another staticly-typed language where you need to break out of the type system so regularly.

It's about the same as Java and C# prior to their adoption of generics, and largely for the same reasons.