Re:The absurd cost of finalizers in Go
by selimthegrim on Saturday May 20, 2023 @03:39PM
(#36014915)
This is the post: https://crawshaw.io/blog/sharp-edged-finalizers
Thanks. So, the small useful feature is that it can be used to (unreliably, as finalizers aren’t guaranteed to run) detect resource leaks.
Such code wouldn’t have to mutate the object being finalized (or any other object, for that matter), so I think that use case would better be served by a more light-weight feature, removing finalizers edge cases such as objects that get revived.
> Java even plans to remove them from the language
The "Alternative techniques" section of the JEP suggests to use Cleaner.register, which was created as a replacement and has a similar API to Go's runtime.SetFinalizer.
https://docs.oracle.com/en/java/javase/20/docs/api/java.base...
On the contrary, the final line
> Maybe there is a way to do better, I hope there is, but I suspect not.
to me, says the writer suspects that it isn’t absurd, but as good as it can get.
I also think there’s broad agreement on the fact that finalizers almost always are a bad idea.
For golang, there’s https://crawshaw.io/blog/tragedy-of-finalizers, which says:
“So a common instinct we all have is to say "gee, it sure would be nice if the file descriptor were closed when the File is garbage collected, let's use a finalizer". This does not work.”
and
“It is a bug to depend on the GC to run before your resources are exhausted”
and
“What are finalizers good for? Nothing generally.”
It also says “I believe I have one very small use for finalizers as they exist today, which I will talk about in a followup blog post”. I couldn’t find that post, though.
Java even plans to remove them from the language (https://openjdk.org/jeps/421)