[steveklabnik]

This code is equivalent to

    result.unwrap_or_else(|e| panic!("error traversing directories {}", e));

There are a lot of methods on various types to reduce this kind of thing. If you didn't want to interpolate the value of e, it would be even simpler:

    result.expect("error traversing directories");

[shepmaster]

> If you didn't want to interpolate the value of e

For those reading along (not Steve) expect does do that, but using the Debug formatter instead of Display, as the grandparent used.

[boxmonster]

the unwrap_or_else makes a lot more sense, because I could just use the ? operator, but if I don't want to panic, then I'll use unwrap_or_else. I am not by any means an advanced Rust programmer and in fact learning from your book, so I didn't mean to offend anyone. My initial impression of the match syntax for return values was that I didn't like it. Sorry.

[adkadskhj]

Match has it's place in unpacking common Enum types like Option and Result, but typically you'll reach for functional patterns like `Result::map`, `Result::expect`, `Result::unwrap_or`, and of course `?` as they're able to do the same thing but in far less code.

I think the downvotes are because both the example and the generalized statement that C# is "noticeably faster" is bait / lazy.

[nobleach]

The railway error-handling paradigm is superior (in my mind) to the common try/catch/throw pattern in many other languages. It promotes errors to first class citizens. It's a monadic pattern that many functional programmers like to employ.

[boxmonster]

Definitely not bait because I like to jump around with languages so it's natural for me to compare them (that's why I do it.) I wrote my web server in Go, my util to find duplicate directories in Rust, etc.. I wasn't saying C# is faster than Rust, I said C# got faster.

[adkadskhj]

> I wasn't saying C# is faster than Rust, I said C# got faster.

Ah gotcha - my mistake :)

[steveklabnik]

It's all good!