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

61–70 of 329 posts

Re: My Struggles with Rust

#61

Post by hota_mazi »

marcosdumay wrote: post #30
cousin_it wrote: post #13

Rust's aversion to exceptions is exactly like Go's aversion to generics - a strongly held position that doesn't actually make anyone's life easier.

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.

Re: My Struggles with Rust

#62

Post by jackmott »

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…

"new idioms and special syntax that is alien to pretty much everyone"

->

"an `Error` trait with appropriate `From` impls."

Note, that it may be entirely necessary for us to invent new idioms to make progress in the art of programming.

Re: My Struggles with Rust

#63

Post by GolDDranks »

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…

If I know that the unwrap is 100% safe I tend to write: `.expect("Invariant: $REASON_WHY_THIS_NEVER_FAILS")`

Re: My Struggles with Rust

#64

Post by swsieber »

QuercusMax wrote: post #48
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…

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

I think it's like Assert. You pass an error message the same way you pass an error message to assert.

Re: My Struggles with Rust

#65

Post by erickt »

QuercusMax wrote: post #48
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…

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. If only we found that perfect method name way back when...

Re: My Struggles with Rust

#66

Post by erickt »

eriknstr wrote: post #59
Pxtl wrote: post #58

Earlier quoted context omitted.

Not a Rust guy, but it looks like a way to say "this option value is required and if it is not present, crash with the following error". So "expect" is a fair name, since it means a value is expected and the absence of a value is unexpected. I could see "required" or "require" as a better name. Or even just break the "positive names" rule and go with "notOptional".

Looking at it that way, I think it's possible to make "expect" more comfortable to read by how you phrase your error messages. Instead of let mut file = File::open("conf.json") .expect("could not open file"); and let config: Value = serde::from_reader(file) .expect("config has invalid json"); and let jenkins_server = config.get("jenkins_server") .expect("jenkins_server key not in config") .as_str() .expect("jenkins_s…

That is a good point. I'm going to have to start being more positive in my expectations :)

Re: My Struggles with Rust

#67

Post by burntsushi »

djhworld wrote: post #51
burntsushi wrote: post #36

Earlier quoted context omitted.

> The author doesn't really justify why he needed to port the python script to rust in the first place. And they don't need to. When I first learned Rust, I tried to write a `filter` function. Why would I ever do that? I could write `filter` much easier in Python, or heck, just use the `filter` method on iterators that is already in the standard library. I did it because I saw it as an opportunity to learn. I wanted…

I guess I was getting at the fact that porting the python script that does something very simple is the wrong tool for the job. A good candidate for trying to learn Rust is to find a script or tool that currently has the problems that Rust claims to fix.

When someone comes to me and says, "I just spent the weekend porting a simple Python web crawler that was working just fine to Rust, and I came across problems x, y and z." What do you think an appropriate response is? Should we berate them for "choosing the wrong tool for the job"? Or should we ask them what they're problems were and help them fix them?

I'm not saying we shouldn't have a conversation about which-tools-are-appropriate-when, but when someone is obviously trying to learn, let's put that on the back burner.

Re: My Struggles with Rust

#68

Post by [deleted] »

Matthias247 wrote: post #37
Inufu wrote: post #4

My main gripe with Rust so far has been the unnecessary profusion of Result types, making it hard to process and forward errors. Case in point: the example in the article from the rust documentation that converts errors to strings just to forward them: https://doc.rust-lang.org/book/error-handling.html#the-limit... In practice, I find a type like Google's util::StatusOr ( https://github.com/google/lmctfy/blob/master/…

I think having Result alone does not make error handling complicated, but having different error types for each operation (and concrete result) instead of using one generic error type for all of them does by pushing the job of unifying erros towards the user. Go works around the problem by Error being an interface, which means any function can return any kind of error without needing to transform it to another form.…

[deleted]

Re: My Struggles with Rust

#69

Post by jeremyjh »

jimktrains2 wrote: post #49
jeremyjh wrote: post #28

Earlier quoted context omitted.

The anti-pattern I've seen in dysfunctional enterprise development shops (i.e. most of them) is that checked exceptions mean exceptions that "we'll never have" get buried lower in the stack; so code can fail silently and continue running just to avoid the monstrous checking code and propagation of exception type declarations up the call stack. I don't see how the Rust approach would avoid this fate but I doubt it wil…

I think that part of it is that the idea of a Result type being normal will help prevent much of the cruft and burying we see with exceptions. I also feel like handling Result types is more natural than exceptions. First, you _have_ to do it, even if that means a try! and passing the buck. The syntax for this isn't as monstrous as it is for checked exceptions as well. Second, it feels more like a natural code-flow, n…

You don't have to convince me of the value of Result types, I prefer them too. I've only written a couple thousands of lines of Rust but tens of thousands of Haskell which rely on the same concepts (though its nicer with do notation). I don't have faith in the masses though and right now there is a strong selection bias in Rust that means only people concerned with quality and correctness are using it in the first place.

I think twenty-five years ago there were similar hopes and dreams for Java checked exceptions.

Re: My Struggles with Rust

#70

Post by Coding_Cat »

jackmott wrote: post #62
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…

"new idioms and special syntax that is alien to pretty much everyone" -> "an `Error` trait with appropriate `From` impls." Note, that it may be entirely necessary for us to invent new idioms to make progress in the art of programming.

I will say that as someone who was not a real expert at anything when Rust came out, but familiar with a lot, I find that learning c++ these days has the same problems, and so does learning a functional language.

They're all unique in what they do. I'd still say a simple procedural language like C is easiest to read, but 'modern c++' has more idioms and quirks than Rust, in my experience.

And Rust has the advantage that the ecosystem is very well tied together and it has a great community and documentation.

Post reply on HN