>A good example would be that functions of the Std library that deal with the Filesystem often return an OsStr instead of the Str/String Rust uses elsewhere. Th

>A good example would be that functions of the Std library that deal with the Filesystem often return an OsStr instead of the Str/String Rust uses elsewhere. This means you cannot ignore the fact that the stuff the OS gives you might not be valid UTF-8 bytes. All functions that can be interrupted from the outside or fail, return their values wrapped in a Result Type and make you handle it. This is the essence of why optional/result types lead to more stable systems than exceptions. With exceptions they can come from anywhere, you don't know if you've handled all of them (depends on the language). It's goto with a new name. With result types you're forced to deal with corner cases, or if you unwrap, you know you've omitted some corner cases, but it's still very visible what you did in your code. With exceptions your code looks clean when it's dirty, with results and optionals your code looks dirty when it's dirty. This is a talk about F#, but it explains the concept of railway oriented programming quite well. It's a paradigm for keeping your data flow clean with result types and optionals. https://www.slideshare.net/ScottWlaschin/railway-oriented-programming https://www.slideshare.net/ScottWlaschin/railway-oriented-pr...