5 ms·

There is a reason why Rust, Go and Zig don't have exceptions and it isn't because the language designers didn't understand them. While you can achieve the same

There is a reason why Rust, Go and Zig don't have exceptions and it isn't because the language designers didn't understand them. While you can achieve the same thing using both approaches, errors as return values is generally simpler to reason about. Even in C# for example, exceptions are going to start taking a back seat with tagged unions which will be much better for expected failures. I agree that Go's approach is a little cumbersome however. Suggest checking out Zig's approach which I personally think really nails it.

win311fwg 1mo ago
> Go [...] don't have exceptions What do you mean? Go has exceptions. Their use with errors is generally discouraged because exceptions, as the name literally implies, are technically designed for exceptional circumstances (programmer fault), not errors (environmental fault), but just like in every other language with exceptions you can do it, and even Go's own standard library uses exceptions for errors in some cases. The Go creators have even expressed openly that you should be pragmatic about it: use them for errors if it makes your code better. They are there to use.
- osigurdson 1mo ago
  If you mean panic, it isn't really the same thing.
  - win311fwg 1mo ago
    An exception is a data structure, usually comprised of a stack trace and some kind of related data, so that's true. panic produces an exception, though, just like throw, raise, etc. as found in some other popular languages do.
    - wfn 1mo ago
      I'd strongly disagree, Go panic mechanism (but not just in the runtime sense but also in language feature sense) is quite distinct from what we typically understand "exceptions" to mean (which - esp. depending on language - are not at all just about handling programmer error). I think this is a decent article on exactly this: https://medium.com/@AlexanderObregon/why-go-panics-are-different-from-exceptions-bdf43a3957c0 https://medium.com/@AlexanderObregon/why-go-panics-are-diffe... But just imagine how exceptions typically have a whole propagation mechanism and type (=> catch) structure. Not so in Go. (Not implying some one model is better here, just flagging that panic vs exception are sufficiently distinct in meaningful (and deliberate) ways such that we can say they are "different", imho). edit p.s. s/panic/panic+defer+recover p.p.s. On exception control flow - good comment upstream by 'wannabe44, imho: https://news.ycombinator.com/item?id=49270430 https://news.ycombinator.com/item?id=49270430
      - win311fwg 1mo ago
        > I think this is a decent article Debatable. It correctly identifies that an exception is data structure (object), but claims that Go doesn't create one, even though it clearly does as it will plain print the contents of that "object" if you don't catch the exception. I will grant you that it doesn't pass the exception by value, which is different than in some other languages, but that's an implementation detail. Furthermore it seems to claim that Go using basic stack unwinding precludes it from it having exception handlers, but that's an implementation detail too. Javascript also uses basic stack unwinding. Would you also say Javascript doesn't have exceptions or exception handlers? Funnily enough, it is Javascript, not Go, that doesn't create the exception object automatically. You have to manually initialize the poorly named Error type manually (`new Error(...)`) in your code in order to create an exception. But that also is just an implementation detail. > But just imagine how exceptions typically have a whole propagation mechanism and type (=> catch) structure. What's typical? We do see some more advanced exception handling systems out there, but Javascript's is just as simple as Go's (in some cases even simpler), yet nobody that I have ever met claims that Javascript doesn't have exceptions/exception handlers. The one thing Javascript does have that Go doesn't is try/throw/catch syntax, but, of course, you can easily emulate that if you're really hung up on trivial appearances: https://go.dev/play/p/aXS5WEziLzS https://go.dev/play/p/aXS5WEziLzS Exception handlers aren't defined by any particular syntax. That, again, is an implementation detail. Go does have syntax for exception handling even if its syntax is unique.
        wfn 28d ago
        Hey, I forgot to reply, but still wanted to quickly respond and to say - thank you for the detailed response, I concede your points are valid, and your perspective seems to be more accurate (with regards to incorporating nuance + reality fit) :) > Javascript also uses basic stack unwinding. Would you also say Javascript doesn't have exceptions or exception handlers? No, I wouldn't, so re: that - fair point; For me, Go's error+panic lack of propagation + lack of exception type hierarchy are what stick out and seem vastly different to "typical"; and this does impact development, especially propagation mechanism / lack thereof. But I also haven't written lots of Go code, and could be possibly lacking experience, and am just looking from "typical" language lens (Java (not JS), Python, from my PoV)?

win311fwg 1mo ago

> Go [...] don't have exceptions What do you mean? Go has exceptions. Their use with errors is generally discouraged because exceptions, as the name literally implies, are technically designed for exceptional circumstances (programmer fault), not errors (environmental fault), but just like in every other language with exceptions you can do it, and even Go's own standard library uses exceptions for errors in some cases. The Go creators have even expressed openly that you should be pragmatic about it: use them for errors if it makes your code better. They are there to use.

osigurdson 1mo ago
If you mean panic, it isn't really the same thing.
- win311fwg 1mo ago
  An exception is a data structure, usually comprised of a stack trace and some kind of related data, so that's true. panic produces an exception, though, just like throw, raise, etc. as found in some other popular languages do.
  - wfn 1mo ago
    I'd strongly disagree, Go panic mechanism (but not just in the runtime sense but also in language feature sense) is quite distinct from what we typically understand "exceptions" to mean (which - esp. depending on language - are not at all just about handling programmer error). I think this is a decent article on exactly this: https://medium.com/@AlexanderObregon/why-go-panics-are-different-from-exceptions-bdf43a3957c0 https://medium.com/@AlexanderObregon/why-go-panics-are-diffe... But just imagine how exceptions typically have a whole propagation mechanism and type (=> catch) structure. Not so in Go. (Not implying some one model is better here, just flagging that panic vs exception are sufficiently distinct in meaningful (and deliberate) ways such that we can say they are "different", imho). edit p.s. s/panic/panic+defer+recover p.p.s. On exception control flow - good comment upstream by 'wannabe44, imho: https://news.ycombinator.com/item?id=49270430 https://news.ycombinator.com/item?id=49270430
    - win311fwg 1mo ago
      > I think this is a decent article Debatable. It correctly identifies that an exception is data structure (object), but claims that Go doesn't create one, even though it clearly does as it will plain print the contents of that "object" if you don't catch the exception. I will grant you that it doesn't pass the exception by value, which is different than in some other languages, but that's an implementation detail. Furthermore it seems to claim that Go using basic stack unwinding precludes it from it having exception handlers, but that's an implementation detail too. Javascript also uses basic stack unwinding. Would you also say Javascript doesn't have exceptions or exception handlers? Funnily enough, it is Javascript, not Go, that doesn't create the exception object automatically. You have to manually initialize the poorly named Error type manually (`new Error(...)`) in your code in order to create an exception. But that also is just an implementation detail. > But just imagine how exceptions typically have a whole propagation mechanism and type (=> catch) structure. What's typical? We do see some more advanced exception handling systems out there, but Javascript's is just as simple as Go's (in some cases even simpler), yet nobody that I have ever met claims that Javascript doesn't have exceptions/exception handlers. The one thing Javascript does have that Go doesn't is try/throw/catch syntax, but, of course, you can easily emulate that if you're really hung up on trivial appearances: https://go.dev/play/p/aXS5WEziLzS https://go.dev/play/p/aXS5WEziLzS Exception handlers aren't defined by any particular syntax. That, again, is an implementation detail. Go does have syntax for exception handling even if its syntax is unique.
      - wfn 28d ago
        Hey, I forgot to reply, but still wanted to quickly respond and to say - thank you for the detailed response, I concede your points are valid, and your perspective seems to be more accurate (with regards to incorporating nuance + reality fit) :) > Javascript also uses basic stack unwinding. Would you also say Javascript doesn't have exceptions or exception handlers? No, I wouldn't, so re: that - fair point; For me, Go's error+panic lack of propagation + lack of exception type hierarchy are what stick out and seem vastly different to "typical"; and this does impact development, especially propagation mechanism / lack thereof. But I also haven't written lots of Go code, and could be possibly lacking experience, and am just looking from "typical" language lens (Java (not JS), Python, from my PoV)?