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

71–80 of 329 posts

Re: My Struggles with Rust

#71

Post by kstenerud »

Sharlin wrote: post #44
dbattaglia wrote: post #26

I was under the impression that the (somewhat) verbose syntax for error handling and memory management via the type system was a necessary side effect of Rusts entire point of existence: a compiler-guaranteed safe systems language. Neither Python nor C force you in any way to pay attention to errors, making simple scripts much easier to write. I guess I'm just surprised people think that Rust should be as simple to u…

There are many ways to have both enforced error handling AND less boilerplate. Java's checked exceptions are much maligned but would work very well here. Another way would be having more syntactic sugar for Result-style monadic error handling, like the do notation in Haskell or for..yield in Scala. Another issue raised by the original post is the fact that Rust has no top-level concrete error type that is convertible…

Java's checked exceptions were a disaster. It essentially handcuffed you, limiting what you could do in an overridden method (because you can't add more exceptions to the throws list). So you end up wrapping in RuntimeExceptions and then later having the whole app fall over because the framework that's expecting your class was only designed to handle the checked exceptions.

So yeah, want your implementation to consult a database? Sorry, the interface you must implement doesn't declare any checked exceptions, so say hello to app-killing RuntimeException wrapped SQLExceptions :/

Re: My Struggles with Rust

#72

Post by mastax »

vbezhenar wrote: post #22
amelius wrote: post #8

Earlier quoted context omitted.

> It's probably because Rust looks and operates mostly like a high-level language, but still satisfies low-level constraints. In an ideal language, you could decide to ignore low-level constraints and your code would work just fine, although perhaps less efficiently.

Exceptions are the best way to handle errors. You can either handle them everywhere or ignore them and they'll rewind the stack. Unfortunately Rust and Go decided to use return values, instead of fixing problems with exceptions, which is step back, IMO.

I have no opinion about whether exceptions are better or not, but .unwrap() is basically the same as an uncaught exception, no? Program closes, prints a backtrace and a somewhat cryptic message which is usually enough for a programmer to understand what happened.

Re: My Struggles with Rust

#73

Post by jackcviers3 »

ajross wrote: post #39
dbattaglia wrote: post #26

I was under the impression that the (somewhat) verbose syntax for error handling and memory management via the type system was a necessary side effect of Rusts entire point of existence: a compiler-guaranteed safe systems language. Neither Python nor C force you in any way to pay attention to errors, making simple scripts much easier to write. I guess I'm just surprised people think that Rust should be as simple to u…

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…

It didn't invent any of these. This is railway-oriented-programming[1], using Either, leftMap and bind/flatMap, a conversion from Either to Try, with forced recover calls and explicit implicit conversions via typeclasses.

Other than the enforcement by the compiler, this is common in scala and f#, two other languages where raising errors is common.

Railway-oriented-programming is nice because it typechecks, and because it reduces cyclomatic complexity by short-circuiting without forcing you to handle the error until the end of the chain. Now, it is unfamiliar to those outside the FP community, but much of the rust language seems to be unfamiliar mixes of FP and low-level optimisation techniques.

With the Either type you don't even need to do that, but then errors on the left becomes convention instead of an enforced habit. The only odd part is the try macro. That should wrap the Val in a right, to preserve type information. I guess I could be convinced that Either = Error | Id [A].

[1]: https://fsharpforfunandprofit.com/rop/

Re: My Struggles with Rust

#74

Post by sidlls »

ajross wrote: post #39
dbattaglia wrote: post #26

I was under the impression that the (somewhat) verbose syntax for error handling and memory management via the type system was a necessary side effect of Rusts entire point of existence: a compiler-guaranteed safe systems language. Neither Python nor C force you in any way to pay attention to errors, making simple scripts much easier to write. I guess I'm just surprised people think that Rust should be as simple to u…

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…

Maybe I was doing C++ wrong all those years, but I find the cognitive load for Rust about equivalent. The error handling idioms of Rust exist, more or less, in well-composed "--no-exceptions" C++ code. The syntax might be a tad different, but the principles are more or less the same.

Re: My Struggles with Rust

#75

Post by AlphaSite »

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…

The java optional api uses orElseThrow which I think is quite clear.

Re: My Struggles with Rust

#76

Post by shadowmint »

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 to have exceptions as well (or some kind of panic recovery), because, people prefer to use it than use the verbose match statement. :/

Re: My Struggles with Rust

#78

Post by mcguire »

vfclists wrote: post #52
Symmetry wrote: post #17

Earlier quoted context omitted.

The author was using this as an opportunity to learn Rust so while it might look sort of crazy to use a systems programming language for build failure notification there was a reason behind their decision. Nim is a lovely language but in the author's case he doesn't really care about speed for the use case so if they were being strictly pragmatic they could have just stuck with Python.

Does that warrant being deprived of 2 of 190 or so points thereof of my hard earned karma? Not that I am suggesting that you are the "hater" here.

The problem is that the author wanted to learn Rust. Your comment? "Use Nim."

Can you see how that it's not helpful, or a good addition to the conversation?

Re: My Struggles with Rust

#79

Post by shepmaster »

JoshTriplett wrote: post #15
thegeomaster wrote: post #10

The `error-chain` crate [1] exists to get rid of precisely the error handling boilerplate the author has encountered. That's not ideal, though, as I believe that a place for such functionality is in the core language, not a separate library, but it gets the job done. As for the `let mut file` bit, that makes sense to me: a file in the standard library is an abstraction over a file descriptor in the operating system,…

I'd like to see error-chain standardized into the standard library as well. It seems by far the most sensible approach to building Error types.

Conversely, I really hope it doesn't. error-chain doesn't implement `PartialEq` which means that I can no longer write tests for my failure types. I'm a big believer in quick-error instead.

Re: My Struggles with Rust

#80

Post by SyrupThinker »

vfclists wrote: post #53
Symmetry wrote: post #17

Earlier quoted context omitted.

The author was using this as an opportunity to learn Rust so while it might look sort of crazy to use a systems programming language for build failure notification there was a reason behind their decision. Nim is a lovely language but in the author's case he doesn't really care about speed for the use case so if they were being strictly pragmatic they could have just stuck with Python.

What!! Just as I was responding another of my hard earned points got deducted Who are these mean Rustaceans? Is Nim considered such a threat to Rust?

I guess people consider your comment not really helpful. Everyone could come into this thread and write "Use ".

If you'd have provided some good advantages of Nim in this case, or in general added to the discussion at hand, you might have gotten less downvotes.

Maybe you want to stop attacking a community directly, aswell... last time I checked this site wasn't Rustacean only.

Post reply on HN