3 ms·

> Modern, high-level language features I think this is something the article overlooked. Sure, Rust has the ability to be a system level language, but you don'

by onei 6y ago

> Modern, high-level language features I think this is something the article overlooked. Sure, Rust has the ability to be a system level language, but you don't have to use it that way and the breadth of good, albeit commonly immature, libraries is testament to this. Rust enums and pattern matching are some of my favourite features in any language. Python is often my go to for writing tools, but I mistrust its typing and how it behaves when a library throws an exception - not forgetting that pylint warns if you try to catch Exception. Conversely, Rust error handling feels a bit more verbose, but I worry less about what it does in failure scenarios. I either handle the error or pass it up the stack and carry on with my day.

deleted 6y ago
[deleted]
saghm 6y ago
> Conversely, Rust error handling feels a bit more verbose, but I worry less about what it does in failure scenarios If you're just writing a tool, you can have main return a Result with Box<dyn Error> and then just use `?` everywhere. The code doesn't really end up that much more verbose other than needing to add a return type everywhere, which can be mitigated with a type alias if needed.
- onei 6y ago
  That's a good approach if you don't care about the nature of error and plan on logging it or outputting it as is, but you lose any metadata for the error unless you want to use unsafe to get it back out. What I order to do is use pattern matching for control flow in error handling, e.g. was this a server error or was I given something invalid? Depending on the error, I might want to try again. With Python, you can create a rich hierarchy of errors using inheritance, but to achieve something similar in Rust the best option I've come up with is maintaining an enum that wraps the different error types. It feels clunky, so I hope there's better ways.
  - saghm 6y ago
    If you're interested in generating a lot of the boilerplate for an error enum, I'd highly recommend `thiserror` (https://crates.io/crates/thiserror https://crates.io/crates/thiserror). It's made by the same person who made a lot of the other prominent proc macros libraries in the Rust community (e.g. serde).
    - onei 6y ago
      That looks exactly like what I'm looking for! Many thanks for the recommendation.

by onei 6y ago

deleted 6y ago

[deleted]

saghm 6y ago

> Conversely, Rust error handling feels a bit more verbose, but I worry less about what it does in failure scenarios If you're just writing a tool, you can have main return a Result with Box<dyn Error> and then just use `?` everywhere. The code doesn't really end up that much more verbose other than needing to add a return type everywhere, which can be mitigated with a type alias if needed.

onei 6y ago
That's a good approach if you don't care about the nature of error and plan on logging it or outputting it as is, but you lose any metadata for the error unless you want to use unsafe to get it back out. What I order to do is use pattern matching for control flow in error handling, e.g. was this a server error or was I given something invalid? Depending on the error, I might want to try again. With Python, you can create a rich hierarchy of errors using inheritance, but to achieve something similar in Rust the best option I've come up with is maintaining an enum that wraps the different error types. It feels clunky, so I hope there's better ways.
- saghm 6y ago
  If you're interested in generating a lot of the boilerplate for an error enum, I'd highly recommend `thiserror` (https://crates.io/crates/thiserror https://crates.io/crates/thiserror). It's made by the same person who made a lot of the other prominent proc macros libraries in the Rust community (e.g. serde).
  - onei 6y ago
    That looks exactly like what I'm looking for! Many thanks for the recommendation.