> I mean if you have to write that match construct around every function call

Not quite.

1. you're supposed to handle errors around function calls which can fail, which is a strict subset of "every function call"

2. rust has a number of higher-order constructs to facilitate that handling[0][1][2], not just raw `match` statements or expressions.

That aside, for rust explicit error handling is considered a feature both at the language level (allows for less runtime requirements and much stronger guarantees — check out exception-safe C++ for what happens when low-level meets exceptions) and at the user level (by forcing a conscious and explicit decision, whether it's crashing the system, handling the error or passing the ball upwards)

> the code quickly gets bloated, doesn't it?

Does C code quickly get bloated? Because you're also supposed to check for error codes after each function call which can fail, and C doesn't provide much abstractive power to mitigate that.

[0] http://doc.rust-lang.org/std/result/enum.Result.html

[1] http://doc.rust-lang.org/core/macro.try!.html

[2] https://github.com/rust-lang/rfcs/pull/243

Rust has macros, so boilerplate can be swept up pretty tidily. In the case of propagating up errors, there is the try! macro that encapsulates a match that returns early with the error

try! macro results in code that looks pretty similar to exceptions: https://doc.rust-lang.org/std/macro.try!.html

Yeah Error handling bloat is a problem.

You can use convenience functions: expression.expect("panic with this message if expression evaluates to an Err")

You can also use macros: try!(expression) makes it so if expression evaluates to an error it returns the error immediately, otherwise it does nothing.

This approach is still more verbose than using exceptions but on the flip side dealing with errors up front can make it easier to write reliable code.