we added proper weak pointer support to the garbage collector. … we were astonished by how simple and straightforward all of it turned out to be. Astonished enough that weak pointers are now a public proposal.
Ha! I remember advocating for weak references on the golang-nuts mailing list c.2013 and getting a lecture from some of the Go developers about how weak refs are useless and a bad idea. I’m glad they’ve changed their minds.
I’m not sure who in that thread is on the Go team besides Ian Lance Taylor, but he seemed open to it.
That suggests that there is no need for it in the language proper, but
it could perhaps be added to the runtime package at some point in the
future.
To me it seems like a minor convenience. A weak reference is
effectively a cache. Having the GC manage the cache for you is handy
but on the other hand you give up the ability to control the
replacement strategy or the size of the cache.
In my opinion weak references should not be added to the language. If
Go ever has them, they should only be implemented via a runtime API.
Not a yes but also not a no. This is being added as part of the runtime API, so that part came true.
My observation of the Go issue tracker was that a) it was generally acknowledged that you could use finalizers to fake weak references/interning but b) it was a pain in the ass and very delicate work and c) no one was particularly eager to do the work. When Tailscale needed weak references for a more efficient type for IP addresses, it got added first to their internal fork and then to Go itself as an internal package, which made its becoming public semi-inevitable.
Thinking about the future, I wonder what would make Go finally add SIMD. It’s in a similar place of being obviously useful but not part of the core concerns of the Go team so priority starved.
Ha! I remember advocating for weak references on the golang-nuts mailing list c.2013 and getting a lecture from some of the Go developers about how weak refs are useless and a bad idea. I’m glad they’ve changed their minds.
Here’s that thread https://groups.google.com/g/golang-nuts/c/PYWxjT2v6ps
I’m not sure who in that thread is on the Go team besides Ian Lance Taylor, but he seemed open to it.
Not a yes but also not a no. This is being added as part of the runtime API, so that part came true.
My observation of the Go issue tracker was that a) it was generally acknowledged that you could use finalizers to fake weak references/interning but b) it was a pain in the ass and very delicate work and c) no one was particularly eager to do the work. When Tailscale needed weak references for a more efficient type for IP addresses, it got added first to their internal fork and then to Go itself as an internal package, which made its becoming public semi-inevitable.
Thinking about the future, I wonder what would make Go finally add SIMD. It’s in a similar place of being obviously useful but not part of the core concerns of the Go team so priority starved.
[Comment removed by author]