Well, the reason why I'm using a high-level programming language is there are a bunch of mechanical things that the computer will do better and more reliably than me. Otherwise I'd just write assembly.
What sorts of things fall into this category, and what tradeoffs you're willing to make to have the computer do things for you, is a matter of application (and taste), and so we reasonably have many different programming languages. But it's entirely defensible to want, in the abstract, your language to do repetitive and important work for you. That's what computers are good at.
There's not one reliable, or a set of reliable, way to handle errors. A high level language could handle it for you reliably in the sense of throwing exceptions and hoping you'll catch it. That'd work, you'd get Java software that throws exceptions all the time during normal operations.
Errors are valid values, handling them is as normal as handling other values you get from functions.
let foo = try!(something_that_might_error())
// or soon...
let foo = something_that_might_error()?
The try!() macro or the ? operator unwrap a Result<T, E> value, which is basically "either the return value or an error value". If it's a return value (T), the macro/operator just gets the value out of it - but if it's an error (E), it will convert the error into your own function's Result<T, E> return type using the From trait, and return that from your own function immediately.
The practical result? When I'm parsing input or doing other things that are heavy on errors, I can split it out into another function, wrap every call that might fail in try!(), and only have to actually handle the error once. This allows me to see my code clearer - I can see the success case very clearly, but I'm still forced to decide whether to handle or return errors by the compiler, because there's no other way to get the T out of a Result<T, E>.
There's a few other languages which implement this, though they lean towards the functional side a lot more than Rust does.
Experience: I'm writing a small internal certificate authority in Go because it has x.509 and signing support in the standard library. I'm no safer by having roughly 3/5 of my lines be if err != nil { return err; }.
Honestly... you could do it as a primitive type if you wanted. The only "special" bits needed are a piece of syntax which checks if it's an error, and if so returns it, else evaluates to the private value; and a way of unwrapping the actual error value when you want to handle it.
Go already has plenty of complicated language primitives with complex behaviour.
I think people are misinterpreting support for try catch family in some high level languages as lazy approaches.
But truth is it is the programmers who are lazy, we should not blame language for providing a feature which some programmer abuse.
I have never seen a Java programmer profiling their code for Memory or CPU at work and I am here running my shitty C code under Valgrind and a profiler all the time.
I guess, it is programmers and not the language.
Go's error != nil approach though rudimentary actually forces lazy programmers to complain, since they cannot abuse it.
