>Rather its hand rolling your own every time.

So your had rolled one will not have the typing overhead we are discussing, but it will have 2 much worse issues.

  1. sync.Pool's have thread local storage, something your own pools will not have.
  2. sync.Pool's are GC aware; meaning if the allocator is having trouble it can drain "free" pool objects to gain memory. Your custom pool will not have this integration.

I have a feeling that the performance you gained not type-checking you will loose by not having #1.

I think you are missing my point. So I'll restate it. sync.Pool does not help with GC issues compared to the JVM because the JVM also has object pools, further those object pools are actually better for the low latency case because the language does not force them to make a choice between dynamic type checks and specific use abstractions.

[edit] As pcwalton points out. My whole argument is actually null and void due to type erasure...doh.

To be fair, though, aren't generics on the JVM type-erased? So you're going to have a type assertion at the JIT level either way.