Most active commenters

    ←back to thread

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

    (www.collabora.com)
    611 points LorenDB | 17 comments | 06 May 25 17:51 UTC | HN request time: 0.619s | source | bottom
    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 #
    1. dvt ◴[06 May 25 18:27 UTC] No.43908158[source]▶
    Maybe contrarian, but imo the `Result` type, while kind of nice, still suffers from plenty of annoyances, including sometimes not working with the (manpages-approved) `dyn Error`, sometimes having to `into()` weird library errors that don't propagate properly, or worse: `map_err()` them; I mean, at this point, the `anyhow` crate is basically mandatory from an ergonomics standpoint in every Rust project I start. Also, `?` doesn't work in closures, etc.

    So, while this is an improvement over C++ (and that is not saying much at all), it's still implemented in a pretty clumsy way.

    replies(4): >>43908206 #>>43908469 #>>43908676 #>>43909810 #
    2. maplant ◴[06 May 25 18:33 UTC] No.43908206[source]▶
    ? definitely works in closures, but it often takes a little finagling to get working, like specifying the return type of the closure or setting the return type of a collect to a Result<Vec<_>>
    replies(2): >>43908345 #>>43925266 #
    3. ◴[06 May 25 18:45 UTC] No.43908345[source]▶
    4. ackfoobar ◴[06 May 25 18:56 UTC] No.43908469[source]▶
    > the `anyhow` crate is basically mandatory from an ergonomics standpoint in every Rust project I start

    If you use `anyhow`, then all you know is that the function may `Err`, but you do not know how - this is no better than calling a function that may `throw` any kind of `Throwable`. Not saying it's bad, it is just not that much different from the error handling in Kotlin or C#.

    replies(4): >>43908675 #>>43909119 #>>43909718 #>>43912137 #
    5. efnx ◴[06 May 25 19:19 UTC] No.43908675[source]▶
    Yes. I prefer ‘snafu’ but there are a few, and you could always roll your own.
    replies(2): >>43908842 #>>43909226 #
    6. singingboyo ◴[06 May 25 19:20 UTC] No.43908676[source]▶
    There's some space for improvement, but really... not a lot? Result is a pretty basic type, sure, but needing to choose a dependency to get a nicer abstraction is not generally considered a problem for Rust. The stdlib is not really batteries included.

    Doing error handling properly is hard, but it's a lot harder when error types lose information (integer/bool returns) or you can't really tell what errors you might get (exceptions, except for checked exceptions which have their own issues).

    Sometimes error handling comes down to "tell the user", where all that info is not ideal. It's too verbose, and that's when you need anyhow.

    In other cases where you need details, anyhow is terrible. Instead you want something like thiserror, or just roll your own error type. Then you keep a lot more information, which might allow for better handling. (HttpError or IoError - try a different server? ParseError - maybe a different parse format? etc.)

    So I'm not sure it's that Result is clumsy, so much that there are a lot of ways to handle errors. So you have to pick a library to match your use case. That seems acceptable to me?

    FWIW, errors not propagating via `?` is entirely a problem on the error type being propagated to. And `?` in closures does work, occasionally with some type annotating required.

    replies(1): >>43910678 #
    7. shepmaster ◴[06 May 25 19:39 UTC] No.43908842{3}[source]▶
    Yeah, with SNAFU I try to encourage people going all-in on very fine-grained error types. I love it (unsurprisingly).
    8. jbritton ◴[06 May 25 20:09 UTC] No.43909119[source]▶
    I know a ‘C’ code base that treats all socket errors the same and just retries for a limited time. However there are errors that make no sense to retry, like invalid socket or socket not connected. It is necessary to know what socket error occurred. I like how the Posix API defines an errno and documents the values. Of course this depends on accurate documentation.
    replies(1): >>43910468 #
    9. smj-edison ◴[06 May 25 20:19 UTC] No.43909226{3}[source]▶
    +1 for snafu. It lets you blend anyhow style errors for application code with precise errors for library code. .context/.with_context is also a lovely way to propagate errors between different Result types.
    replies(1): >>43909310 #
    10. bonzini ◴[06 May 25 20:28 UTC] No.43909310{4}[source]▶
    How does that compare to "this error for libraries and anyhow for applications"?
    replies(1): >>43909367 #
    11. smj-edison ◴[06 May 25 20:33 UTC] No.43909367{5}[source]▶
    You don't have to keep converting between error types :)
    12. Yoric ◴[06 May 25 21:14 UTC] No.43909718[source]▶
    Yeah, `anyhow` is basically Go error handling.

    Better than C, sufficient in most cases if you're writing an app, to be avoided if you're writing a lib. There are alternatives such as `snafu` or `thiserror` that are better if you need to actually catch the error.

    13. skrtskrt ◴[06 May 25 21:23 UTC] No.43909810[source]▶
    A couple of those annoyances are just library developers being too lazy to give informative error types which is far from a Rust-specific problem
    14. XorNot ◴[06 May 25 22:50 UTC] No.43910468{3}[source]▶
    This is an IDE/documentation problem in a lot of cases though. No one writes code badly intentionally, but we are time constrained - tracking down every type of error which can happen and what it means is time consuming and you're likely to get it wrong.

    Whereas going with "I probably want to retry a few times" is guessing that most of your problems are the common case, but you're not entirely sure the platform you're on will emit non-commoncases with sane semantics.

    15. josephg ◴[06 May 25 23:21 UTC] No.43910678[source]▶
    I agree with you, but it’s definitely inconvenient. Result also doesn’t capture a stack trace. I spent a long time tracking down bugs in some custom binary parsing code awhile ago because I had no idea which stack trace my Result::Err’s were coming from. I could have switched to another library - but I didn’t want to inflict extra dependencies on people using my crate.

    As you say, it’s not “batteries included”. I think that’s a fine answer given rust is a systems language. But in application code I want batteries to be included. I don’t want to need to opt in to the right 3rd party library.

    I think rust could learn a thing or two from Swift here. Swift’s equivalent is better thought through. Result is more part of the language, and less just bolted on:

    https://docs.swift.org/swift-book/documentation/the-swift-pr...

    16. dwattttt ◴[07 May 25 03:59 UTC] No.43912137[source]▶
    I find myself working through a hierarchy of error handling maturity as a project matures.

    Initial proof of concepts just get panics (usually with a message).

    Then functions start to be fallible, by adding anyhow & considering all errors to still be fatal, but at least nicely report backtraces (or other things! context doesn't have to just be a message)

    Then if a project is around long enough, swap anyhow to thiserror to express what failure modes a function has.

    17. ninkendo ◴[08 May 25 11:55 UTC] No.43925266[source]▶
    Mapping a Vec<T> to Result<U, E> and collecting them into a single Result<Vec<U>, E> made me feel like a ninja when I first learned it was supported. I’m a little worried it’s too confusing to read for others, but it works so well.

    Combined with futures::try_join_all for async closures and you can use it to do a bunch of failable tasks in parallel too, it’s great.