[pcwalton]

Exceptions don't have any runtime costs beyond those which Go is already paying by mandating unwinding.

In fact, C++-style exceptions are strictly less expensive in the non-exceptional case than defer, because of defer's dynamic semantics. Go's semantics require a slower exceptional control flow scheme than almost any other language I'm aware of, including dynamic ones like JavaScript.

[duaneb]

IIRC the idea is that the conceptual overhead of exceptions is much larger than the runtime cost, hence the minimal syntax/runtime support beyond defer (which is easy to follow, if hard to implement efficiently).

I am not so sure I would agree with this, but I don't use go enough to have a firm opinion myself.

[pcwalton]

Try/catch/finally is simpler than panic/recover/defer both conceptually and in implementation, due to the statically, lexically-scoped semantics.

[enneff]

As you probably already know, panic/recover/defer are not supposed to be used in the same way as try/catch/finally. They're different features for different purposes.

If you want error handling in Go, use error values.

[pcwalton]

Sure. Panic, recover, and defer are in the language, though, and are more complex than exceptions regardless of how they're intended to be used.

[duaneb]

If recover is used in a file you never read, is its complexity relevant?

[enneff]

I think what's happening here is pcwalton is a language implementer, so when you talk about 'conceptual complexity' he thinks about how the feature is specified, whereas you or I think about how the users of the feature think about and use it. We're all talking past each other a bit, I think.

[duaneb]

Well he answered me as if he understood me, so I am going to go ahead with that assumption. This thread is not at all difficult to follow. Anyone who uses rescue should be shot on sight--it takes a masochist to introduce panic as a stack unwind mechanism intended to be caught. The process should stop. I have never seen rescue used in the wild, so it seems as if the only thing this has in common with exceptions is stack unwinding. It is apples and oranges and the performance difference is meaningless unless you try to use them as the same.

To be fair, pcwalton was not advocating this. He was pointing out that defer is already more costly runtime wise than exceptions, correcting another person.

[the_mitsuhiko]

A big problem with both Rust and Go is that the marketing says there are no exceptions, and because we all know exceptions are bad/slow/hard to understand that the languages are superior. I strongly object to this idea because from an implementation POV both Go and Rust are 90% there for all the complexities that exceptions cause but now nobody is aware of it.

(This is also why I'm a huge proponent of Results in Rust and disabling unwinding altogether)

[fauigerzigerk]

I disagree completely. We're talking about a feature that can affect the execution path of your code even if you're not using it yourself. For such a feature, you have to work under the assumption that someone will be using it somewhere and you have to deal with it.

The whole reasoning behind not supporting a ton of features in Go is that excuses like "don't need it? Don't use it!" are invalid when it comes to programming language features. And nowhere is this more relevant than for a feature that can unwind the stack without warning.