Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Struggles with Rust

compileandrun.com

Post reply on HN
Print view View original

131–140 of 329 posts

Re: My Struggles with Rust

#131

Post by p0nce »

burntsushi wrote: post #121
p0nce wrote: post #111

Earlier quoted context omitted.

That and the bizarre thinking that ".unwrap" is a perfectly ok thing to write in some cases (don't worry it will never make it to production!). No, ".unwrap" turns input errors into bugs, and there is no production code where this is more desirable than an exception.

One of the hardest things about teaching error handling in Rust is that there is a lot of nuance. It's fun to say "unwrap is evil, don't use it," and more than that, it's not exactly wrong either. The nuanced version is that you shouldn't use unwrap for error handling, but: 1. If you're prototyping or writing a quick throwaway program, then unwrap will neither pick your pocket nor break your leg. 2. If you have an in…

> 2. If you have an invariant that you either can't (or won't) move into the type system, then unwrap/expect/panic'ing can be appropriate precisely because if that unwrap gets tripped, then that will indicate a bug in your program that should be fixed.

Absolutely but using the same mechanism (unwrap/panic) for both types of errors - recoverable and recoverable - can creates confusion. panic'ing for wrong user input for example as can be seen in example code.

Re: My Struggles with Rust

#133

Post by shadowmint »

jjnoakes wrote: post #126
shadowmint wrote: post #76

It makes me sad to see the example. This is why I maintain `.unwrap()` is one of the worst things in rust. ...because people use it; and then say; 'but don't use unwrap...'; and then use it, and your 'safe' language then happily crashes and burns everytime something goes wrong. Blogs and documentation are particularly prone to it. Result and option types are good; but if you're gonna have unwrap, you basically have t…

> your 'safe' language then happily crashes and burns everytime something goes wrong I'm not sure why you put 'safe' in quotes here; nothing about 'unwrap()' (or even 'panic') is unsafe in the context of Rust. In fact, it acts just like Python would in the same circumstances: print a developer-centric message out and exit with a bad return code. What's unsafe about that? > if you're gonna have unwrap, you basically h…

I didnt say it was unsafe, I said it crashes.

Unwrap is a shortcut to let you be lazy; it exists for no other reason, and it causes application level crashes in way that is very much easier to avoid in other languages.

That 'catch_unwind' exists is evidence that some kind of panic recovery is necessary... and I wonder how often you hit it from a real panic, vs. a stray lazy unwrap?

Whats your justification for unwrap? I've never seen a meaningful justification for it other than not wanting to handle errors properly.

An application error (returned null) shouldn't abort your application with a hard error, no logs. Its just plain poor practice to use unwrap().

Re: My Struggles with Rust

#134

Post by e12e »

MaxGabriel wrote: post #113
e12e wrote: post #105

Earlier quoted context omitted.

otherwise(msg)?

I would expect such a function to provide a default value

I actually initially had it as sort of a callback:

.otherwise(panic(msg))

(although I assume a rust panic! isn't really a function call).

But isn't the way to get the default, simply to use unwrap()?

In a simple script, failing to open a configuration file for reading is likely a show stopper, and you probably want to log/print an error (no such file, wrong permission, etc).

But in, say, a paint program, you'd normally not want to panic and crash if the image file a user selected to open in a file dialog is invalid or went away between the click-to-select and the click-to-open. In such a program you'd want to handle most file errors much more defensively.

Re: My Struggles with Rust

#135

Post by huntie »

erickt wrote: post #31

Hello Justin Turpin! Sorry to hear your struggles with rust. It's always going to be a bit more verbose using rust than Python due to type information, but I think there are some things we could do to simplify your code. Would you be comfortable posting the 20 line code for us to review? I didn't see a link in your post. Anyway, so some things that could make your script easier: * for simple scripts I tend to use the…

It might be easier to do:

  let config: HashMap = serde_json::from_reader(file)
      .expect("config has invalid json");
This means that you can just do

  let jenkins_server = config.get("jenkins_server")
      .expect("jenkins_server key not in config");

Re: My Struggles with Rust

#136

Post by kibwen »

p0nce wrote: post #131
burntsushi wrote: post #121

Earlier quoted context omitted.

One of the hardest things about teaching error handling in Rust is that there is a lot of nuance. It's fun to say "unwrap is evil, don't use it," and more than that, it's not exactly wrong either. The nuanced version is that you shouldn't use unwrap for error handling, but: 1. If you're prototyping or writing a quick throwaway program, then unwrap will neither pick your pocket nor break your leg. 2. If you have an in…

> 2. If you have an invariant that you either can't (or won't) move into the type system, then unwrap/expect/panic'ing can be appropriate precisely because if that unwrap gets tripped, then that will indicate a bug in your program that should be fixed. Absolutely but using the same mechanism (unwrap/panic) for both types of errors - recoverable and recoverable - can creates confusion. panic'ing for wrong user input f…

panics aren't for recoverable errors, in any circumstances. It is technically possible to "halt" the unwinding from a panic, but 1) that's intended for C interop, 2) the feature has been deliberately designed to make your life hell if you try to use it to emulate recoverable exceptions, and 3) Rust makes no guarantees that panics will unwind at all, it is entirely legal for a user to configure panics so that they all abort instead.

Re: My Struggles with Rust

#137

Post by placeybordeaux »

hota_mazi wrote: post #61
marcosdumay wrote: post #30

Earlier quoted context omitted.

Monads are a superior form of error handling than exceptions... The only problem is that AFAIK (but I'm still learning it) Rust is missing something equivalent to Haskell's do notation.

> Monads are a superior form of error handling than exceptions No, they're not, not by a long shot. As soon as you start having multiple monads returned by functions and you need to combine them, you need to introduce monad transformers and your code turns into a giant untractactable spaghetti mess. Exceptions have issues but they are the sanest way to handle errors today.

I honestly found error codes in go to be pretty pragmatic. You pay a small cost on the writing side, but it's very clear and straight forward.

Re: My Struggles with Rust

#138

Post by look_lookatme »

burntsushi wrote: post #47
ajross wrote: post #39

Earlier quoted context omitted.

I think the complaint is more that Rust has seemingly tried very hard to make error handling "simple". But in the process it has managed to invent a whole series of new idioms and special syntax that is alien to pretty much everyone. There's a thread in /r/rust about this same article where you can look and see people suggesting all sorts of ways to write this that are split into clear sedimentary layers depending on…

> There's a thread in /r/rust about this same article where you can look and see people suggesting all sorts of ways to write this that are split into clear sedimentary layers depending on when the writer learned the language. As someone that participated in that conversation, I think that's a pretty inaccurate characterization of it. It's not about when the writer learned the language, but rather, what problem you'r…

> The one exception to this is that, recently, there has been a surge in use of crates like error-chain to cut down on the code you need to write for defining custom error types and their corresponding `From` impls. But it's still all built on the same fundamental building blocks.

One takeaway I got from playing around with Rust (and using GitHub code search to work through my issues) was that coding style will probably differ considerably from project to project, which is very C/C++ like and maybe a good thing for the language, but I found a little disappointing.

Re: My Struggles with Rust

#139

Post by p0nce »

kibwen wrote: post #136
p0nce wrote: post #131

Earlier quoted context omitted.

> 2. If you have an invariant that you either can't (or won't) move into the type system, then unwrap/expect/panic'ing can be appropriate precisely because if that unwrap gets tripped, then that will indicate a bug in your program that should be fixed. Absolutely but using the same mechanism (unwrap/panic) for both types of errors - recoverable and recoverable - can creates confusion. panic'ing for wrong user input f…

panics aren't for recoverable errors, in any circumstances. It is technically possible to "halt" the unwinding from a panic, but 1) that's intended for C interop, 2) the feature has been deliberately designed to make your life hell if you try to use it to emulate recoverable exceptions, and 3) Rust makes no guarantees that panics will unwind at all, it is entirely legal for a user to configure panics so that they all…

> panics aren't for recoverable errors, in any circumstances.

And I understand that. Hence why unwrap everywhere is harmful.

Re: My Struggles with Rust

#140

Post by steveklabnik »

look_lookatme wrote: post #138
burntsushi wrote: post #47

Earlier quoted context omitted.

> There's a thread in /r/rust about this same article where you can look and see people suggesting all sorts of ways to write this that are split into clear sedimentary layers depending on when the writer learned the language. As someone that participated in that conversation, I think that's a pretty inaccurate characterization of it. It's not about when the writer learned the language, but rather, what problem you'r…

> The one exception to this is that, recently, there has been a surge in use of crates like error-chain to cut down on the code you need to write for defining custom error types and their corresponding `From` impls. But it's still all built on the same fundamental building blocks. One takeaway I got from playing around with Rust (and using GitHub code search to work through my issues) was that coding style will proba…

We are actively working on rustfmt, which should add some consistency overall. Some people won't use it, of course, but many have said they will.
Post reply on HN