←back to thread

Matt Godbolt sold me on Rust by showing me C++

(www.collabora.com)
611 points LorenDB | 5 comments | 06 May 25 17:51 UTC | HN request time: 0s | source
Show context
dvratil ◴[06 May 25 18:20 UTC] No.43908097[source]▶
The one thing that sold me on Rust (going from C++) was that there is a single way errors are propagated: the Result type. No need to bother with exceptions, functions returning bool, functions returning 0 on success, functions returning 0 on error, functions returning -1 on error, functions returning negative errno on error, functions taking optional pointer to bool to indicate error (optionally), functions taking reference to std::error_code to set an error (and having an overload with the same name that throws an exception on error if you forget to pass the std::error_code)...I understand there's 30 years of history, but it still is annoying, that even the standard library is not consistent (or striving for consistency).

Then you top it on with `?` shortcut and the functional interface of Result and suddenly error handling becomes fun and easy to deal with, rather than just "return false" with a "TODO: figure out error handling".

replies(24): >>43908133 #>>43908158 #>>43908212 #>>43908219 #>>43908294 #>>43908381 #>>43908419 #>>43908540 #>>43908623 #>>43908682 #>>43908981 #>>43909007 #>>43909117 #>>43909521 #>>43910388 #>>43912855 #>>43912904 #>>43913484 #>>43913794 #>>43914062 #>>43914514 #>>43917029 #>>43922951 #>>43924618 #
zozbot234 ◴[06 May 25 18:48 UTC] No.43908381[source]▶
> The one thing that sold me on Rust (going from C++) was that there is a single way errors are propagated: the Result type. No need to bother with exceptions

This isn't really true since Rust has panics. It would be nice to have out-of-the-box support for a "no panics" subset of Rust, which would also make it easier to properly support linear (no auto-drop) types.

replies(6): >>43908410 #>>43908496 #>>43908674 #>>43908939 #>>43910721 #>>43914882 #
kelnos ◴[06 May 25 19:19 UTC] No.43908674[source]▶
I wish more people (and crate authors) would treat panic!() as it really should be treated: only for absolutely unrecoverable errors that indicate that some sort of state is corrupted and that continuing wouldn't be safe from a data- or program-integrity perspective.

Even then, though, I do see a need to catch panics in some situations: if I'm writing some sort of API or web service, and there's some inconsistency in a particular request (even if it's because of a bug I've written), I probably really would prefer only that request to abort, not for the entire process to be torn down, terminating any other in-flight requests that might be just fine.

But otherwise, you really should just not be catching panics at all.

replies(6): >>43908859 #>>43909602 #>>43910885 #>>43912418 #>>43913661 #>>43914377 #
j-krieger ◴[07 May 25 11:35 UTC] No.43914377[source]▶
Honestly, I don't think libraries should ever panic. Just return an UnspecifiedError with some sort of string. I work daily with rust, but I wish no_std and an arbitrary no_panic would have better support.
replies(1): >>43917054 #
1. burntsushi ◴[07 May 25 15:33 UTC] No.43917054[source]▶
Example docs for `foo() -> Result<(), UnspecifiedError>`:

    # Errors

    `foo` returns an error called `UnspecifiedError`, but this only
    happens when an anticipated bug in the implementation occurs. Since
    there are no known such bugs, this API never returns an error. If
    an error is ever returned, then that is proof that there is a bug
    in the implementation. This error should be rendered differently
    to end users to make it clear they've hit a bug and not just a
    normal error condition.
Imagine if I designed `regex`'s API like this. What a shit show that would be.

If you want a less flippant take down of this idea and a more complete description of my position, please see: https://burntsushi.net/unwrap/

> Honestly, I don't think libraries should ever panic. Just return an UnspecifiedError with some sort of string.

The latter is not a solution to the former. The latter is a solution to libraries having panicking branches. But panics or other logically incorrect behavior can still occur as a result of bugs.

replies(2): >>43919808 #>>43923414 #
2. 0x457 ◴[07 May 25 19:37 UTC] No.43919808[source]▶
Funny that as a user of this library, I would just unwrap this, and it results in the same outcome as if library panicked.
replies(1): >>43925872 #
3. stouset ◴[08 May 25 05:48 UTC] No.43923414[source]▶
My main issue with panics is poor interop across FFI boundaries.
replies(1): >>43925875 #
4. burntsushi ◴[08 May 25 13:21 UTC] No.43925872[source]▶
Yes. A panic is the right thing to do, and it's just fine if the library does it for you.
5. burntsushi ◴[08 May 25 13:21 UTC] No.43925875[source]▶
This is like saying, "my main issue with bugs is that they result in undesirable behavior."

Panicking should always be treated as a bug. They are assertions.