Certain things need to be available out of the box.

The whole point of a programming language is to make the programmers life easier.

By now decades of exposure to programming languages have made try/catch the standard way of working with errors. Forcing the programmer to guess issues, when the compiler/runtime could be doing it- IMO is just plain waste of human labor. And for even medium to large applications is a pointless exercise.

    a, err := foo() // oops, unhandled error
    err = bar()
    if err != nil { ... }

or

    fmt.Println("...") // oops, unhandled error

or more insidiously

    err1 := foo()
    if err1 != nil { ... }
    err2 := bar()
    if err2 != nil { return err1 } // oops

In the first and the last case, it seems obvious to me where the error is. An obvious code smell caught in review. The second error, yeah, but lots of languages don't enforce error handling around printing to stdout, and even though Rust does in theory, in practice everyone just unwraps it and moves on with their day.

> but lots of languages don't enforce error handling around printing to stdout

They do, they throw exceptions.

> In the first and the last case, it seems obvious to me where the error is

The last case is especially insidious. I've seen it in production several times now. Very easy to miss. Particularly when refactoring/copy pasting code (which you have to do a lot of in golang).