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

121–130 of 329 posts

Re: My Struggles with Rust

#121

Post by burntsushi »

p0nce wrote: post #111
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…

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 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.

The more succinct advice that I like to use is this: "if end users of your Rust application see a panic, then you have a bug." But this is slightly harder advice to follow because it's a statement about the user experience.

Re: My Struggles with Rust

#122

Post by kstenerud »

One thing I've found with rust is that you struggle struggle struggle trying to do a simple task, and then finally someone says "Oh, all you need to do is this".

Rust has already reached the point where it leaves the world behind. Only the people who have been there since the early days really understand it, and getting into rust gets harder and harder as time goes on.

Yes, there's some awesome documentation, and the error messaging has gotten a lot better. But the power and flexibility of Rust comes at the cost of it becoming harder and harder to figure out how all the thousands of little pieces are supposed to fit together. What's really needed is a kind of "cookbook" documentation that has things like "How to read a text file with proper error handling" and "what is the proper way to pass certain kinds of data around and why".

Right now there's a lot of "what" documentation going around, but little that discusses the "how to and why".

Re: My Struggles with Rust

#123

Post by ahoka »

vvanders wrote: post #92
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…

As someone who's been doing C++ for a close to few decades I's challenge you on that. In C++ you need to understand: Exceptions(and the runtime/memory costs they incur by pulling in RTTI) ERRNO(on relevant *nix platforms) Lifetimes tied to objects when things fail(this is a big one) Plus any library-specific hackery(I've seen raw strings as errors before) In contrast I've been writing Rust for ~1.5 years now and each…

Exceptions don't need RTTI and have only runtime cost when thrown.

Re: My Struggles with Rust

#124

Post by steveklabnik »

kstenerud wrote: post #122

One thing I've found with rust is that you struggle struggle struggle trying to do a simple task, and then finally someone says "Oh, all you need to do is this". Rust has already reached the point where it leaves the world behind. Only the people who have been there since the early days really understand it, and getting into rust gets harder and harder as time goes on. Yes, there's some awesome documentation, and the…

There is an active (but just started) project to write a cookbook: https://blog.rust-lang.org/2017/05/05/libz-blitz.html

Re: My Struggles with Rust

#125

Post by burntsushi »

kstenerud wrote: post #122

One thing I've found with rust is that you struggle struggle struggle trying to do a simple task, and then finally someone says "Oh, all you need to do is this". Rust has already reached the point where it leaves the world behind. Only the people who have been there since the early days really understand it, and getting into rust gets harder and harder as time goes on. Yes, there's some awesome documentation, and the…

> but little that discusses the "how to and why"

Have you read the book's chapter on error handling?[1] It's being replaced in the second version of the book, but I still plan on maintaining it as a blog post[2]. Any advice you might have to add more of what you want would be helpful. (And I ask this because I tried to attack the "how to and why" angle, so I'm wondering if I got that wrong.)

[1] - https://doc.rust-lang.org/stable/book/error-handling.html

[2] - http://blog.burntsushi.net/rust-error-handling/

Re: My Struggles with Rust

#126

Post by jjnoakes »

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 have to have exceptions as well

Why do you think that? unwrap() is meant to be the same as throwing an uncatchable exception; if you want to throw an exception that you mean to catch somewhere, you should be using something else.

> people prefer to use [unwrap()] than use the verbose match statement

People may not be aware (which will come with time) but there are more than just those two choices when it comes to error handling in Rust.

Re: My Struggles with Rust

#127

Post by std_throwaway »

kstenerud wrote: post #122

One thing I've found with rust is that you struggle struggle struggle trying to do a simple task, and then finally someone says "Oh, all you need to do is this". Rust has already reached the point where it leaves the world behind. Only the people who have been there since the early days really understand it, and getting into rust gets harder and harder as time goes on. Yes, there's some awesome documentation, and the…

How is this problem solved for C++?

Re: My Struggles with Rust

#128

Post by Double_Cast »

erickt wrote: post #65
QuercusMax wrote: post #48

Earlier quoted context omitted.

Was the expect method​ supposed to be named except, as in exception? That would make a lot more sense.

If I recall correctly we just couldn't come up with a great name for it. To me "expect" is a positive action, but the argument is about it failing to meet the expectation. Semantically I like `thing.unwrap_or(|| panic!("failure message"))`. It feels more like what I would want to say, but it just is so wordy. Ultimately I'm happy we just picked something and moved on, but still mildly annoys me whenever I write it. I…

  .beware("could not open file");

Re: My Struggles with Rust

#129

Post by marcosdumay »

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.

Well, if you start doing more with monads than error handling, you will have complex interactions between them.

They are still superior for error handling, exceptions would have a more complex interaction with them.

Re: My Struggles with Rust

#130

Post by skybrian »

eximius wrote: post #97
eriknstr wrote: post #57

Earlier quoted context omitted.

While it's too late to change the name "expect", could one create an alias for it and call it say, "on_error"?

I'd expect 'on_error' to take a function as a callback, not a string. But yes, a better named function could be added

Perhaps or_die, similar to Perl?
Post reply on HN