4 ms·

This is actually an argument against the syntactic changes. Because now if you have the common `if err == nil { return ... }` pattern, then you have _that_ "lit

This is actually an argument against the syntactic changes. Because now if you have the common `if err == nil { return ... }` pattern, then you have _that_ "littering" your code, instead of the syntax. The current solution is fine, and it seems to be only junior/new to golang people who hate it. Everyone I know loves the explicit, clear, easy to read "verbose" error handling.

scubbo 1y ago
> then you have _that_ "littering" your code, instead of the syntax. Yes, exactly. The unusual thing _should_ look unusual.
- 9rx 1y ago
  The unusual case does look unusual. == and != are visually very different. I suspect the real problem here is that the parent commenter forgot (read: purposefully avoided) to write tests and is blaming the tools to drown his sorrow.
  - scubbo 1y ago
    https://news.ycombinator.com/item?id=44172285 https://news.ycombinator.com/item?id=44172285 > [I] was apparently so desensitized to the latter construct that it actually took me ages to debug, because my brain simply did not consider that `if err != nil` was not supposed to be there. Clearly not different enough. Tests are just one tool among many that we use to build and evaluate mental models of behaviour. It's equally possible that the parent commenter noticed unusual behaviour _via_ their tests, and took "ages to debug" precisely _because_ they were misreading the code while trying to understand _why_ the tests were failing. A hypothetical syntax highlighter that flagged up to them "hey, you're doing something unusual here - is that intended?" would have helped them in debugging _alongside_ tests.
    - 9rx 1y ago
      > Clearly not different enough. If you take the word as gospel, but why should we? It is hard to believe. As shocking as it may be, not everything you read on the internet is true. Either way, the fact of the matter is that discussion about code is silly without code. Since I have no knowledge of the actual code in question, which has suspiciously been kept a secret for some reason, I'll open the bidding with this: https://go.dev/play/p/xEnGTmJ_57g https://go.dev/play/p/xEnGTmJ_57g — From the output alone, you don't think you'd be able to gain a pretty good idea of what the problem might be? Feel free to update the code with something more real-worldy if you think the contrivedness of it masks what you are trying to talk about. We had to start somewhere.

scubbo 1y ago

> then you have _that_ "littering" your code, instead of the syntax. Yes, exactly. The unusual thing _should_ look unusual.

9rx 1y ago
The unusual case does look unusual. == and != are visually very different. I suspect the real problem here is that the parent commenter forgot (read: purposefully avoided) to write tests and is blaming the tools to drown his sorrow.
- scubbo 1y ago
  https://news.ycombinator.com/item?id=44172285 https://news.ycombinator.com/item?id=44172285 > [I] was apparently so desensitized to the latter construct that it actually took me ages to debug, because my brain simply did not consider that `if err != nil` was not supposed to be there. Clearly not different enough. Tests are just one tool among many that we use to build and evaluate mental models of behaviour. It's equally possible that the parent commenter noticed unusual behaviour _via_ their tests, and took "ages to debug" precisely _because_ they were misreading the code while trying to understand _why_ the tests were failing. A hypothetical syntax highlighter that flagged up to them "hey, you're doing something unusual here - is that intended?" would have helped them in debugging _alongside_ tests.
  - 9rx 1y ago
    > Clearly not different enough. If you take the word as gospel, but why should we? It is hard to believe. As shocking as it may be, not everything you read on the internet is true. Either way, the fact of the matter is that discussion about code is silly without code. Since I have no knowledge of the actual code in question, which has suspiciously been kept a secret for some reason, I'll open the bidding with this: https://go.dev/play/p/xEnGTmJ_57g https://go.dev/play/p/xEnGTmJ_57g — From the output alone, you don't think you'd be able to gain a pretty good idea of what the problem might be? Feel free to update the code with something more real-worldy if you think the contrivedness of it masks what you are trying to talk about. We had to start somewhere.