Comment by hnlmorg

That's a theoretical problem that almost never surfaces in practice.

Using `defer...recover` is computationally expensive within hot paths. And since Go encourages errors to be surfaced via the `error` type, when writing idomatic Go you don't actually need to raise exceptions all that often.

So panics are reserved for instances where your code reaches a point that it cannot reasonably continue.

This means you want to catch panics at boundary points in your code.

Given that global state is an anti-pattern in any language, you'd want to wrap your mutex, file, whatever operations in a `struct` or its own package and instantiate it there. So you can have a destructor on that which is still caught by panic and not overly reliant on `defer` to achieve it.

This actually leads to my biggest pet peeve in Go. It's not `x, err := someFunction()` and nor is it `defer/panic`, these are all just ugly syntax that doesn't actually slow you down. My biggest complaint is the lack of creator and destructor methods for structs.

the `NewClass`-style way of initialising types is an ugly workaround and it constantly requires checking if libraries require manual initilisation before use. Not a massive time sink but it's not something the IDE can easily hint to you so you do get pulled from your flow to then either Google that library or check what `New...` functions are defined in the IDEs syntax completion. Either way, it's a distraction.

The lack of a destructor, though, does really show up all the other weaknesses in Go. It then makes `defer` so much more important than it otherwise should be. It means the language then needs runtime hacks for you to add your own dereference hooks[0][1] (this is a problem I run into often with CGO where I do need to deallocate, for example, texture data from the GPU). And it means you need to check each struct to see if it includes a `Close()` method.

I've heard the argument against destructors is that they don't catch errors. But the counterargument to that is the `defer x.Close()` idiom, where errors are ignored anyway.

I think that change, and tuples too so `err` doesn't always have to be its own variable, would transform Go significantly into something that feels just as ergonomic as it is simple to learn, and without harming the readability of Go code.

[0] https://medium.com/@ksandeeptech07/improved-finalizers-in-go...

[1] eg https://github.com/lmorg/ttyphoon/blob/main/window/backend/r...