Parse is less explicit than unwrap because the following C# code is legal:

  uint foo = uint.Parse("3");

But the following Rust code is not legal:

  let foo: u32 = "3".parse();  // error: mismatched types

It's impossible to use the return value of parse as though it's a u32, because it's not a u32. You can't accidentally add it to some other number or use it to index an array, because it's the wrong type entirely. You invariably must acknowledge the possibility of failure, and if you're okay with terminating your thread in the event of an error you can do this via an unwrap:

  let foo: u32 = "3".parse().unwrap();  // just fine

Rust's parse is even more explicit than C#'s TryParse, because even with TryParse it's possible to forget to check the return value:

  uint foo;
  uint.TryParse("Hello", out foo);  // this compiles and runs!

And it's not just about string parsing. The overarching point here is that not only does the compiler protect you from errors that you know about, it also brings your attention to errors that you didn't know about. The OP has a great example in that it's very easy to forget that the `min` method on vectors can fail if that vector is empty.

Finally, this assurance extends in the other direction as well: knowing that libraries are architected to make errors explicit via return types means that if I don't get yelled at for not handling a return type, then I have peace of mind knowing I'm not overlooking anything. This is somewhat analogous to the considerable assurance given in knowing that types aren't implicitly nullable.

Now, if you're looking for something that can still go wrong, there's a better example then OOM: dividing by zero in Rust will implicitly panic. So while it's unlikely that a library author will use unwrap in their code (there's a strong culture against Rust libraries causing panics), it's possible that a library author could accidentally cause a panic by dividing by zero.

Both Rust and C# provide throwing/failing interfaces for parsing, it's just that Rust's is written:

    let foo: u32 = "3".parse().unwrap();

and C#'s is written:

    var foo = uint.Parse("3");

Both require familiarity with the stdlib (Parse throws, TryParse doesn't, unwrap fails).

I agree that TryParse is worse than Rust's ADT approach, but that's a different issue, much like nullable references. The author is asserting that results are superior to exceptions and I am asserting that no, that is just a bad application of exceptions. Additionally, I am asserting that without exceptions, you limit what programmers are willing to propagate through their interfaces because errors become viral.