The nicest things about error handling in this manner are that any function that has a error condition makes it clear in the function signature, and any time you call a function that can fail, it's visible in the source where you make the call.
This makes it very easy to tell whether code is handling potential failure conditions or ignoring them - you're either ignoring the return value (which is a compiler warning) or you're handling the failure condition. I'm reminded of Raymond Chen's post from 2005 about handling failure conditions, and recognizing code which handles all of its error conditions:
It basically feels like Java's checked exceptions without stack unwinding and with a nicer syntax - the possible errors are part of the signature, the compiler insists you do something about them, and there is a wrapping facility to cross system boundaries without leaking details.
In case my comment is taken as denigration, I'm saying this from a perspective of admiration. I think this is a fairly elegant way to solve a difficult problem, and learning Rust has been a true pleasure. I'm excited for the future of the language.
This makes it very easy to tell whether code is handling potential failure conditions or ignoring them - you're either ignoring the return value (which is a compiler warning) or you're handling the failure condition. I'm reminded of Raymond Chen's post from 2005 about handling failure conditions, and recognizing code which handles all of its error conditions:
http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/35294...
I think this approach will pay great dividends in both understandability and readability.