Go Optimization Guide

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

But that's only run when the pool needs to allocate more space. What GP seems to expect is that sync.Pool() would always return a zeroed structure, just as Golang allocation does.

I think Golang's implementation does make sense, as sync.Pool() is clearly an optimization you use when performance is an issue; and in that case you almost certainly want to only initialize parts of the struct that are needed. But I can see why it would be surprising.

> [any] is a type

It's typed the way Python is typed, not the way Rust or C are typed; so loses the "if it compiles there's a good chance it's correct" property that people want from statically typed languages.

I don't use sync.Pool, but it does seem like now that we have generics, having a typed pool would be better.

If that's what people actually wanted, Coq and friends would be household names, not the obscure oddities that they are. All the languages that people actually use on any kind of regular basis require you to write tests in order to gain that sense of correctness, which also ends up validating type-correctness as a natural byproduct.

"A machine can help me refactor my code" is the property that most attracts people to the statically typed languages that are normally used. With "I can write posts about it on the internet" being the secondary property of interest.

In the case of refactoring this is incredibly useful. It doesn't say much about the correctness of your program, though.

Might be, but that's a design decision that has nothing to do with type or generics, isn't it? You seem to refer to a function to drain the pool, which is not needed, and frankly, rather unusual.

> It's typed the way Python is typed

Not in the slightest.

> "if it compiles there's a good chance it's correct"

If you want to compare it to something, it's more like Rust's unwrap(), which will panic if you apply it to the wrong result.

You know, it's this kind of comment on USENET forums which prompted the creation of StackOverflow. It's not curious and adds nothing to the discussion.

I like Go and use it extensively; and I like having the option to fall back to the `any` type. But it's simply a fact that using the `any` type means that certain properties of the program can't be checked at compile time, in the same way that Python isn't able to check certain properties of the program at compile time.

> If you want to compare it to something, it's more like Rust's unwrap(), which will panic if you apply it to the wrong result.

Rust's unwrap() is used when a type can have one of exactly two underlying types (which is why no type is specified). In this case, getting back an `any` type means the underlying type could literally be anything -- as demonstrated by the example, where they put an integer, a string, and an empty struct into the pool. That's almost certainly not what you wanted, but the compiler won't prevent you from doing it.

One could define a new "Pool[T]" type (extending sync.Pool) to get these guarantees:

  type Pool[T any] sync.Pool  // typed def

  func (p *Pool[T]) Get() T { // typed Get
      pp := (*sync.Pool)(p)
      return pp.Get().(T)
  }

  func (p *Pool[T]) Put(v T) { // typed Put
      pp := (*sync.Pool)(p)
      pp.Put(v)
  }

  intpool := Pool[int]{        // alias New
      New: func() any { var zz int; return zz },
  }

  boolpool := Pool[bool]{      // alias New
      New: func() any { var zz bool; return zz },
  }

Map/List<T> etc are erased to basically an array of Objects (or a more specific supertype) at compile-time, but you can still use the non-generic version (with a warning) if you want and put any object into a map/list, and get it out as any other type, you having to cast it as the correct type.

You might want to step off that extremely high horse for a second, buddy. It's extremely reasonable to expect a type-safe pool that only holds a single type, since that's the most common use case.

> certain properties of the program can't be checked at compile time

Neither can you check if a number is positive or negative, or if a string is empty or not at compile time, but that doesn't make Go similar to COBOL or Forth. `var v any` declares v to be of the type any, not of any arbitrary type, which is what Python does. Writing `v + 1` gives a compiler error, unlike Python, which may or may not turn it into a runtime error. It is rather different, and especially so when you look at interfacing. Even though you may declare a variable to be an integer in Python, there is no guarantee that it actually is, whereas in Go that is the case, which has significant implications for how you handle e.g. json.

> the compiler won't prevent you from doing it.

It will prevent you from using e.g. an array of strings as if it were an array ints. Python does not. They are quite different.

> You know, it's this kind of comment on USENET forums which prompted the creation of StackOverflow. It's not curious and adds nothing to the discussion.

Ffs.

So long as that one is not you? You completely forgot to address the expectation:

    type Foo struct{ V int }
    pool := Pool[*Foo]{ // Your Pool type.
        New: func() any { return new(Foo) },
    }

    a := pool.Get()
    a.V = 10
    pool.Put(a)

    b := pool.Get()
    fmt.Println(b.V) // Prints: 10; 0 was expected.

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.

> fmt.Println(b.V) // Prints: 10; 0 was expected.

Sorry, I don't get what else one expects when pooling pointers to a type? In fact, pooling *[]uint8 or *[]byte is common place; Pool.Put() or Pool.Get() then must zero its contents.

As seen in your previous comment, the expectation is that the zero value will always be returned: "What GP seems to expect is that sync.Pool() would always return a zeroed structure, just as Golang allocation does." To which you offered a guarantee.

> Pool.Put() or Pool.Get() then must zero its contents.

Right. That is the solution (as was also echoed in the top comment in this thread) if one needs that expectation to hold. But you completely forgot to do it, which questions what your code was for? It behaves exactly the same as sync.Pool itself... And, unfortunately, doesn't even get the generic constraints right, as demonstrated with the int and bool examples.

If those constraints don't hold (like you say) it should manifest as runtime panic, no?

> What GP seems to expect is that sync.Pool() would always return a zeroed structure

Ah, well. You gots to be careful when Pooling addresses.

> But you completely forgot to do it, which questions what your code was for?

OK. If anyone expects zero values for pointers, then the New func should return nil (but this is almost always useless), or if one expects values to be zeroed-out, then Pool.Get/Put must zero it out. Thanks for the code review.

Not quite that. Imagine I have a pool of buffers with a length and capacity, say when writing code to handle receiving data from the network.

When I put one of those buffers back, I would like the next user of that buffer to get it back emptied. The capacity should stay the same, but the length should be zero.

I think it’s reasonable to have a callback to do this. One, it doesn’t force every consumer of the pool to have to remember themselves; it’s now a guarantee of the system itself. Two, it’s not much work but it does prevent me from re-emptying freshly-allocated items (in this case reinitialzing is fast, but in some cases it may not be).

This also should be an optional callback since there are many cases where you don’t want any form of object reset.

No. Your int and bool pools run just fine – I can't imagine you would have posted the code if it panicked – but are not correct.

> I did not forget?

Then your guarantee is bunk: "One could define a new "Pool[T]" type (extending sync.Pool) to get these guarantees:" Why are you making claims you won't stand behind?

> but are not correct.

I don't follow what you're saying. You asserted, "And, unfortunately, doesn't even get the generic constraints right, as demonstrated with the int and bool examples." What does it even mean? I guess, this bikeshed has been so thoroughly built that the discussion points aren't even getting through.

Values are copied in Go. Your code will function, but it won't work.

You've left it up to the user of the pool to not screw things up. Which is okay to some degree, but sync.Pool already does that alone, so what is your code for?

Gotcha. Thanks for clearing it up.

> so what is your code for?

If that's not rhetorical, then the code was to demonstrate that sync.Pool could be "extended" with typedefs/embeds + custom logic. Whether it got pooling itself right was not the intended focus (as shown by the fact that it created int & bool pools).

Wherein lies the aforementioned guarantee? The code guarantees neither the ask (zero values) nor even proper usage if you somehow didn't read what you quoted and thought that some kind of type safety was the guarantee being offered.

Furthermore, who, exactly, do you think would be familiar enough with Go to get all the other things right that you left out but be unaware of that standard, widely used feature?

I think you should re-read what I wrote. You seem to be upset that I did not solve everyone's problem with sync.Pool with my 10 liner (when I claimed no such thing).

  One could define a new "Pool[T]" type (extending sync.Pool) to get these guarantees

Yes, structural typing removes the ability to check certain properties at compile-time. That doesn't make it typed like Python, though.

You "forgot" to copy the colon from the original statement. A curious exclusion given the semantic meaning it carries. Were you hoping I didn't read your original comment and wouldn't notice?

> You seem to be upset

How could one ever possibly become upset on an internet forum? Even if for some bizarre and unlikely reason you were on the path to becoming upset, you'd turn off the computer long before ever becoming upset. There is absolutely no reason to use this tool if it isn't providing joy.

> One could define / extend sync.Pool to get those guarantees [for their custom types] ...

What audience would be interested in this? Is there anyone who understands all the intricacies of sync.Pool but doesn't know how to define types or how to write functions?

You got me!

A truly typeless language (or maybe more accurately single type for everything language) is ASM, particularly for older CPU designs. You get a word - the bitfield in a register, and can do any operation on it. Is that 64 bits loaded from an array of characters and the programmer intended it to be a string? Cool you can bitwise and it with some other register. Was it a u64, a pointer, a pair of u32s? Same thing - the semantics don't change.

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

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.

The empty set is trivially satisfied by all types, but obviously can be narrowed as you see fit.