logoalt Hacker News

pie_flavor • last Wednesday at 1:35 AM • 1 reply • view on HN

This code:

    foo, err := someExpr
    if err != nil {
        return nil, err
    }
Is entirely boilerplate, and a language feature could generate it (and in Rust, does). This is not the same statement as 'all error handling is boilerplate', which is obviously false, which is why I didn't say that. Condensing that particular snippet down to `?` would be less terrible than the status quo, where the status quo is every function being filled with twenty copies of it drastically reducing readability. The situation is exactly the same as with old Rust, where:

    let foo = match expr {
        Ok(val) => val,
        Err(e) => return e,
    };
Was entirely boilerplate. Rust noticed that this was a problem and solved it. Go's status quo is not better than pre-`?` Rust's status quo; it does nothing pre-`?` Rust didn't. Go just doesn't solve it.

It is not actually the original design intent of Go to make every function 50% boilerplate garbage by LoC. Go is extremely full of 'helpful' happy-path short functions that leave you reimplementing lots of stuff more verbosely the moment you step off the happy path, inclusive of happy paths that do partially the wrong thing. `?` is exactly in line with `iota`, `foo_windows.go`, `flag.Var`, `http.HandleFunc`, etc. I don't know why people respond to literally every Go mistake with 'it's actually not a mistake, you just don't understand the genius', especially since half the mistakes are reverted later and acknowledged as mistakes.

Replies

kiitos • last Wednesday at 2:24 AM

    This code:
    
        foo, err := someExpr
        if err != nil {
            return nil, err
        }

    Is entirely boilerplate
But you'd never write that, you'd write

    if err != nil {
        return nil, fmt.Errorf("some expr: %w", err)
    }
which is _not_ boilerplate, in any sense that would benefit from being mitigated with new syntax or short-cuts.

> Condensing that particular snippet down to `?` would be less terrible than the status quo

This simply isn't any kind of objective or agreed-upon truth. Many people, including myself, believe that the status quo is better than what you're suggesting here.

People who are annoyed with Go at some fundamental level, and who largely don't use the language themselves, delight in characterizing `if` blocks related to errors as "boilerplate" that serves no purpose, and needs to be addressed at a language level.

> `?` is exactly in line with `iota`, `foo_windows.go`, `flag.Var`, `http.HandleFunc`, etc.

I've thought on this at length and I have no clue as to what you think the common property between these things might be. A proposed language sigil that impacts control-flow, an existing keyword that's generally not recommended for use, a build-time filename convention, and two unrelated stdlib type definitions?

➕ show 1 reply