I'm hoping Go's error handling is improved in 2.0. I understand the objections to Java-style exceptions but I think they underestimated the actual cost of having so much boilerplate clogging up every non-trivial program, not to mention the way it actively encourages people to punt on error checking which is why so many projects are littered with `x, _ := foo()`.

The approach I'd like would be a lightweight assert-style failure mode where the compiler would treat any function which returns an error as being followed an implied `if err != nil { panic("Unhandled error") }` unless the error is checked on the next statement. That'd allow you to handle things which you expect to fail regularly while preventing the litany of bugs in C programs caused by forgetting to check return codes on things which rarely fail.

    > I get lost trying to figure what 
    > the happy path behavior is.

The happy path is idiomatically at indent level 0.

Except when it's

    if x, err := doSomething(); err != nil {
    }

...the happy path there is intend level 0?

    if err := doSomething(); err != nil {
        return fmt.Errorf("something failed: %v", err)
    }

Or,

    x, err := doSomething()
    if err != nil {
        return fmt.Errorf("something failed: %v", err)
    }
    
    log.Print(x)