4 ms·

Go never had a stance on "unrecoverable panics kill your program". Go always supported recover, but encourages (correctly IMO) error values because they are mo

Go never had a stance on "unrecoverable panics kill your program". Go always supported recover, but encourages (correctly IMO) error values because they are more performant and easier to understand. The Go standard library even uses panic/recover (aka throw/catch) style programming in specific instances.

troupo 2y ago
> they are more performant and easier to understand. They are more performant because Go decided to make them so. E.g. in Erlang crashing a process is an expected lightweight operation. As for "easier to understand"... They are not when: - your code is littered with `x, err = ...; if err != nil` - it's not easier to understand when the code errors have to be dealt with on a higher/different level. The calling code isn't always the one that needs to deal with all the errors Just a very random example (I literally just clicked through random files): https://github.com/kubernetes/kubernetes/blob/master/pkg/controlplane/controller/clusterauthenticationtrust/cluster_authentication_trust_controller.go#L143 https://github.com/kubernetes/kubernetes/blob/master/pkg/con... Oh, look, you can't even see the logic behind all the `if err`s which do nothing but return the error to be handled elsewhere.
- zmgsabst 2y ago
  I always liked Erlangs “crash until someone knows how to recover”.
- CharlieDigital 2y ago
  You aren't kidding. Line 143 - 182... You'd think they'd come up with a short form for something that gets written so often.
  - skywhopper 2y ago
    They haven’t, because it’s perfectly legible, versus languages that hide control flow with implicit assumptions. The main point of Go was to avoid magic. If you don’t care for it, that’s fine. Plenty of us prefer explicit control flow.
    - williamdclt 2y ago
      Everyone prefers explicit control flows. But there's other things in the balance (noise, code density, readability), and many people think that this is pretty bad trade-off. Rust with Optionals strikes a much nicer trade-off, and personally I'd love to see a language that offers a good checked exception mechanism which would offer a lot of explicitness with most noise removed.
    - CharlieDigital 2y ago
      How about a simple one liner like (just throwing out random ideas; I'm sure these are not idiomatic) return when err return if err return ?> err return ? err Still readable, still pretty explicit IMO.
      - vbezhenar 2y ago
        `return err` is a terrible approach. You must wrap the error with new error, include file and line information, so stacktrace is actually useful. When program spews some random garbage into its stderr and you have no idea where that message came from (imagine looking through millions of lines of kubernetes implementation), that's the good way to ensure that nobody would even care to look at it. Thousands of unsolved issues in kubernetes tracker is a perfect demonstration of it. Go is just bad at handling errors. Exceptions are superior in every way.
        CharlieDigital 2y ago
        Even that could be fixed right? return when err return if err return ?> err return ? err to: return when stackify(err) return if stackify(err) return ?> stackify(err) return ? stackify(err) I don't know; I'm just throwing ideas out there. I do agree that exceptions are just fine and it's not like you couldn't just catch and return exceptions if you wanted to like err.
        vbezhenar 2y ago
        They definitely could introduce a shorter syntax like Rust did. And they discussed that, but apparently they were not happy with ideas so far, so it's postponed. May be some day.
  - williamdclt 2y ago
    Simplicity and explicitness are really important to Go design. It's been defended hotly. Personally (using Go everyday) I think it's a terrible trade-off for devx and is mostly stockholm syndrom, but it's very difficult to argue at the "design principle" level: one side says "explicitness!", the other says "readability!", which can't be meaningfully compared.
    - CharlieDigital 2y ago
      I feel like both of these are still pretty explicit but much better DX: return when err return if err return on err
  - kevin_thibedeau 2y ago
    Fix that with m4.

troupo 2y ago

> they are more performant and easier to understand. They are more performant because Go decided to make them so. E.g. in Erlang crashing a process is an expected lightweight operation. As for "easier to understand"... They are not when: - your code is littered with `x, err = ...; if err != nil` - it's not easier to understand when the code errors have to be dealt with on a higher/different level. The calling code isn't always the one that needs to deal with all the errors Just a very random example (I literally just clicked through random files): https://github.com/kubernetes/kubernetes/blob/master/pkg/controlplane/controller/clusterauthenticationtrust/cluster_authentication_trust_controller.go#L143 https://github.com/kubernetes/kubernetes/blob/master/pkg/con... Oh, look, you can't even see the logic behind all the `if err`s which do nothing but return the error to be handled elsewhere.

zmgsabst 2y ago
I always liked Erlangs “crash until someone knows how to recover”.
CharlieDigital 2y ago
You aren't kidding. Line 143 - 182... You'd think they'd come up with a short form for something that gets written so often.
- skywhopper 2y ago
  They haven’t, because it’s perfectly legible, versus languages that hide control flow with implicit assumptions. The main point of Go was to avoid magic. If you don’t care for it, that’s fine. Plenty of us prefer explicit control flow.
  - williamdclt 2y ago
    Everyone prefers explicit control flows. But there's other things in the balance (noise, code density, readability), and many people think that this is pretty bad trade-off. Rust with Optionals strikes a much nicer trade-off, and personally I'd love to see a language that offers a good checked exception mechanism which would offer a lot of explicitness with most noise removed.
  - CharlieDigital 2y ago
    How about a simple one liner like (just throwing out random ideas; I'm sure these are not idiomatic) return when err return if err return ?> err return ? err Still readable, still pretty explicit IMO.
    - vbezhenar 2y ago
      `return err` is a terrible approach. You must wrap the error with new error, include file and line information, so stacktrace is actually useful. When program spews some random garbage into its stderr and you have no idea where that message came from (imagine looking through millions of lines of kubernetes implementation), that's the good way to ensure that nobody would even care to look at it. Thousands of unsolved issues in kubernetes tracker is a perfect demonstration of it. Go is just bad at handling errors. Exceptions are superior in every way.
      - CharlieDigital 2y ago
        Even that could be fixed right? return when err return if err return ?> err return ? err to: return when stackify(err) return if stackify(err) return ?> stackify(err) return ? stackify(err) I don't know; I'm just throwing ideas out there. I do agree that exceptions are just fine and it's not like you couldn't just catch and return exceptions if you wanted to like err.
        vbezhenar 2y ago
        They definitely could introduce a shorter syntax like Rust did. And they discussed that, but apparently they were not happy with ideas so far, so it's postponed. May be some day.
- williamdclt 2y ago
  Simplicity and explicitness are really important to Go design. It's been defended hotly. Personally (using Go everyday) I think it's a terrible trade-off for devx and is mostly stockholm syndrom, but it's very difficult to argue at the "design principle" level: one side says "explicitness!", the other says "readability!", which can't be meaningfully compared.
  - CharlieDigital 2y ago
    I feel like both of these are still pretty explicit but much better DX: return when err return if err return on err
- kevin_thibedeau 2y ago
  Fix that with m4.