Can Rust prevent logic errors?

Rust <i>absolutely</i> can (and will!) prevent logic errors. Will it prevent all of them? Certainly not. But when I started using Rust there was a whole heap of &quot;wait, did I ever even think about this class of error in any other peogramming language?&quot; — and it turns out I did not.<p>The logic error prevention Rust has is purely done by the type system. E.g. when you read a file name this is a special kind of string (OsString), because some operating systems allow for combinations of bytes as filenames that are not valid unicode. Now if you want your regular Rust string, you have to do a conversion and that conversion will return a Result&lt;String&gt;, which means you either get an Ok&lt;String&gt; or an Error. If you don&#x27;t handle that unpacking your program won&#x27;t compile. Now you could just unwrap the result and live with a crash when there is an Error (and in some cases that would be totally valid), but you now know and have to decide how to handle it.<p>This for example would be something I didn&#x27;t even know could be a problem and Rust made me handle it properly just be representing the thing in the type system. There are countless such things in the language.<p>Of couese if you go deeper, <i>you</i> have to represent your problems properly in the type system and there you can certainly introduce mistakes.

The relevant maxim comes from John Ousterhout&#x27;s <i>A Philosophy of Software Design</i>, specifically Chapter 10, &quot;The best way to eliminate exception handling complexity is to define your APIs so that there are no exceptions to handle: define errors out of existence&quot;.<p>This approach isn&#x27;t unique to Rust, though I applaud Piotr Sarnacki for going into detail about how to approach the concept. The undercurrent of design this article suggests is to avoid primitive obsession, and define appropriately constrained types. In the example of concurrency, the HashMap type is, outside of the owner, immutable, unless ownership and mutability becomes part of the type definition.<p>Too often programmers use String or Integer when they really should be using a domain-relevant type (which might be implemented under the covers with a primitive) enforcing the bounds. For example, using an integer for the Natural Numbers opens up all kinds of issues. Even using unsigned int is wrong, because subtracting a larger number from a smaller number because subtraction of natural numbers is not closed.

Rust has features that look like equivalents of footguns in other languages, so it&#x27;s easy to assume it can have the same failures.<p>For example, Rust has Option&lt;String&gt; that is a &quot;nullable&quot; string. missing.unwrap() will throw an exception or abort the program, just like a null pointer access would. You could think that a &quot;bad programmer&quot; will find these footguns and write just as bad code. But subtle differences in how these features work make a big difference in real-world use, even in the hands of careless programmers. A change between non-optional and optional is a type error that needs to be fixed everywhere. Option requires answering &quot;what if it&#x27;s empty&quot; on <i>every use</i>, so a properly lazy programmer will avoid making things optional in the first place.<p>Rust also has good defaults. A struct type by default can&#x27;t be copied, can&#x27;t be compared, can&#x27;t be serialized, can&#x27;t be printed, can&#x27;t be implicitly created from default values. The programmer is forced to think and explicitly write what can be done with the type. So users of a type can&#x27;t carelessly copy a unique handle, or end up comparing addresses when they mean to compare values, <i>even if</i> the programmer writing the type forgot to consider these issues.