> I don't want early abort. Don't know how else to say it. If I have 5 operations, each of which can fail, I want them to be 5 visually distinct stanzas in my source, and I want to be able to manipulate the errors from each independently.

Sure you do, in 95% of cases. That's why the whole

    if res, err := fn(...); err != nil {
        return nil, err
    }

stanza exists in the first place. And if you don't want it (in Rust), Result being a first-class value means you don't have to early-abort. You just don't type `?` and you operate on the Result directly.

I have to say I'm pretty certain at this point that you haven't actually used Rust, because your points here just... aren't how things work in the language. `?` desugars to the golang error stanza almost verbatim, and if you don't want that you have plenty of other options for how to specifically handle your errors.

> I'm sorry, but I just don't agree. You call looping, bounds-checking, index, etc. minutia, but I don't see it that way.

Wild. It's incomprehensible to me that

    foo
        .filter(|v| v % 2 == 0 )
        .map(|a| a + 1);

is somehow less clear to anyone, or that anyone could think there's less room for unintended bugs than

    res := make([]int, len(items))
    for _, v := range items {
        if (v % 2 == 0) {
            res = append(res, v + 1)
        }
    }

when literally 95% of that code is boilerplate. It's immediately clear in the first example that we're incrementing every even number. In the second example, you have to visually parse significantly more code to get the gist, you have to remember to allocate an slice of the right capacity to avoid multiple reallocations for large slices, and you even end up with a slice that's too large for the data it contains in the end.

There's no argument for the go loop being "better" than the Rust equivalent that doesn't also argue that the C version with the additional hassle of bounds-checking and manual incrementing is better still.