The parent implied that in exception based languages you can save all the boilerplate since exceptions just propagate. My statement here was that I don’t think this is true, since you still need to do error handling (and have error awareness), eg for resource cleanup during those.

I am very aware about try with resources. It works however only if the lifetime of objects are tied to a scope.

* The overwhelming vast majority of functions do not allocate resources that need to be explicitly cleaned up.

* Cleanup is no more painful with exceptions - try/finally is not materially different from defer.

* In any language, a healthy pattern is "if you allocate it, you clean it up". This pattern in Go and Java looks basically the same.

* Go's lack of exceptions mean that you pay the penalty of error handling on every function call, not just in the tiny fraction of a fraction of a percentage of function calls that allocate resources.

* For business processing... this is just a non-issue, full stop. There's generally only one resource that gets allocated - a transaction - and it gets cleaned up automatically on exceptions. All that noise in Go is an utter waste of time.