Hacker News Reader

Comment by marcus_holmes | Hacker News Reader

Honestly, you don't notice it once you get into the Go mindset.

The exception handling looks onerous, and is a pain at the start. But it doesn't take long to get used to it, and then (for me anyway) it becomes second-nature. Everything returns an error, and you have to handle that error (even if only passing it up again).

Static typing is more "fun" when you're exploring new concepts, but interfaces are the key. Defining the interface at the beginning ("what do I need this thing to do?") and then implementing it with a struct/whatever, feels like the right way to do this.

View on HN

> But it doesn't take long to get used to it

I did get used to it, but all the

  if err != nil {
    return nil, err
  }

sometimes taking up half or more of the vertical space of a function is still an eyesore to me, even after writing a quite substantial amount of Go.

This exactly. I haven't written enough Go to be really annoyed by the more subtle things in the post, but it'd really be nice if they could come up with some syntax sugar for that kind of like Rust's ? helper.

Maybe the Go ? is allowed within any function whose last return value is an error on any function call whose last return value is also an error. Call it with ? at the end and accept all but the last return value. At runtime, if the err is not nil, then it returns from the function, supplying the err value and nil for any other return values.

https://go.googlesource.com/proposal/+/master/design/go2draf...

I don’t think it went anywhere, unless I missed it.

iferr is one of the worst warts of the language. I recently converted a Pulumi project from golang to Typescript. Code size dropped by 30% just by removing all the iferr checks. The other thing is the compiler doesn’t complain if you forget to check error returns - so it’s easy to make mistakes. This and lack of generics make golang incredibly verbose at times.

Error handling being explicit isn't an eyesore. It lifts what is with exceptions a hidden control flow to the foreground.

Explicit error handling isn't the complaint—3 vertical lines of error handling after every function call is. Rust, for instance, started this way and eventually introduced the `try!` macro and finally the `?` operator. It's still explicit, it just doesn't fill your screen with unuseful boilerplate.

> unuseful boilerplate

First,

    ..., err := process(...)
    if err != nil {
        return nil, err
    }

is an unfortunately common antipattern. Errors should always be annotated, e.g.

    ..., err := process(...)
    if err != nil {
        return nil, fmt.Errorf("process: %w", err)
    }

The extra lines carry no significant cost -- it's not like reading them imposes a burden versus parsing a single line dense with semantic information. They expose the `return` keyword, which clearly signals a control flow point that is hidden by method chaining and `?`. And it doesn't grant the error control flow special status! These are virtues. I don't see this as unuseful at all. It's fine if you do, of course! But there's not an objective ruling, here.

So are you manually building a stack trace?

In a sense, yes. But the outcome of this process is deliberate rather than mechanical. You choose how much information to expose to callers at each layer. You can display it to users, in a pinch.

Not noticing it is exactly my fear.

Passing an error manually up several levels when it may only be a theoretical concern is a ton of expressive duplication. If I'm in the mindset, that would feel like valuable work, even though it isn't actually making things better for users.

It reminds me of one team I dealt with years ago. They were Java experts used to doing enterprise stuff; their overlords had put them on a scrappy, startup-like thing that was intended to be open source. As was in fashion for Java at the time, they had written things in many layers, the goal of which was to provide scaling cut-points. However valuable in theory, the project ever needing to scale was uncertain. What really mattered was finding something that served user needs. But the layer-by-layer duplication increased the cost of change significantly, lowering the odds we'd find the right product.

What you call "expressive duplication" I call "explicit intent". The error control flow is not subordinate to the happy path.

I'm not following. I can be explicit without being duplicative. The more I repeat an expression of a single concept, the harder I make refactoring when I discover the concept needs to change. That's why, e.g., copy-paste programming is such a bad idea for most projects.

I'm not sure how this would apply. You'll never refactor away the error handling idioms of the language itself.

Exactly. If the error-handling idioms of the language force me to be duplicative in ways that make useful work harder, then it sounds like it's not the right language for the project in question.

Reply on news.ycombinator.com