4 ms·

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.
- troupo 2y ago
  It would be "perfectly legible" if it was just the logic. As it is, it's more `if err return err` than actual logic. And there's high chance the layer above is doing the same thing, and the layer above, until you actually get to actual error handling. Rust at least recognized this and first provided try? and then the ? operator as a shortcut to this boilerplate
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.

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.
troupo 2y ago
It would be "perfectly legible" if it was just the logic. As it is, it's more `if err return err` than actual logic. And there's high chance the layer above is doing the same thing, and the layer above, until you actually get to actual error handling. Rust at least recognized this and first provided try? and then the ? operator as a shortcut to this boilerplate

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.