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

141–150 of 329 posts

Re: My Struggles with Rust

#141

Post by skybrian »

kstenerud wrote: post #71
Sharlin wrote: post #44

Earlier quoted context omitted.

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 consul…

Checked exceptions probably would have been fine if there were only one kind of checked exception. Most methods would declare it and they'd all be compatible.

This would be similar to how Go functions always return the same error type, but without the boilerplate.

Re: My Struggles with Rust

#142

Post by steveklabnik »

shadowmint wrote: post #133
jjnoakes wrote: post #126

Earlier quoted context omitted.

> 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 didnt say it was unsafe, I said it crashes.

Your phrasing implied that you said the crash was not safe, as you put "unsafe" in quotes and contrasted it with the crash. At least, that's what I understood you to be saying too.

Re: My Struggles with Rust

#144

Post by cornstalks »

ahoka wrote: post #123
vvanders wrote: post #92

Earlier quoted context omitted.

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.

Exceptions actually can need RTTI, though not necessarily all of the RTTI that things like provide. For some details, see the -fno-rtti flag for GCC, for which the documentation says[1]:

Disable generation of information about every class with virtual functions for use by the C++ runtime type identification features (`dynamic_cast' and `typeid'). [...] Note that exception handling uses the same information, but it will generate it as needed.

[1]: https://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/C_002b_002b-Dia...

Re: My Struggles with Rust

#145

Post by kazagistar »

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.

In case someone cares to understand what this means:

- "An Error trait" means that when you define a new type that will store error information, you have to define how it implements the Error interface.

- "appropriate From impls"... you are trying to wrap a number of error types in your own special error type, you need to tell the compiler how to convert another specific type into your type new type. There is an interface (trait) in the standard library for this purpose called "From". This is done as an alternative to inheritance in an error system. The trait signature looks like this:

    trait From {
        fn from(T) -> Self;
    }

Re: My Struggles with Rust

#147

Post by ufo »

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…

For reference, here is the link to the reddit thread:

https://www.reddit.com/r/rust/comments/69i105/

Re: My Struggles with Rust

#148

Post by jjnoakes »

shadowmint wrote: post #133
jjnoakes wrote: post #126

Earlier quoted context omitted.

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

> unwrap [...] causes application level crashes in way that is very much easier to avoid in other languages

Unwrap does what just about every other language with exceptions-by-default does: it prints out a message for developers and exits. If you don't want that behavior, that's fine; in Rust you'd not use unwrap(), and in other languages you'd catch the exception.

Now, I agree that if you are using a library which does unwrap() in Rust vs a library that throws an exception in Python, you have different situations. But unwrap() isn't meant to be used in libraries (or if it is, only for fatal errors which should be uncatchable).

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

That is the justification for it: you are writing a simple short script-like tool (or you are prototyping or exploring some problem through one-off or throw-away code) and you want any errors to immediately exit with a developer-centric message and failure code. unwrap() is perfect for this.

It's the same justification for not catching every exception in other languages. Sometimes you are fine with an error printing a message and exiting.

Re: My Struggles with Rust

#149

Post by dep_b »

scriptkiddy wrote: post #102
dep_b wrote: post #7

The big question is would the Python script crash or handle the error when obvious problems like not valid JSON or file not found happen? My experience with Swift vs Objective-C is that clean Swift is crash free but more verbose when all other things are equal. If you don't need that level of security because it's just a small script Python was the right choice.

Depending on where it crashed, the Python script would raise an exception. It would most likely be an `IoError`, `KeyError`, or `ValueError`. Then it would show an error message with a line number, column number, and traceback. Using a debugger would allow you to step backwards through the traceback to determine if the error was caused by something further up the line or where the exception was raised. All of Python'…

So the Python script proposed in this article really just skips all error checking and will die just the same as the hard unwrapped Rust version with the only benefit it actually produces a more user-friendly error and it doesn't look as ugly.

I can't edit my reply anymore but the question was actually meant to be rhetorical rather than I really wanted an answer.

Re: My Struggles with Rust

#150

Post by nemo1618 »

mikebenfield wrote: post #107
burntsushi wrote: post #90

Earlier quoted context omitted.

> were an essential feature Do you mean, "this feature is required for me to write code in that language"? Or do you mean, "this feature is required for any project in the language to flourish"? If the former, why do you think your preferences generalize? If the latter, how do you explain the large number of successful Go projects? Are we all stuck in the 1980s? And if so, what does that even mean?

Well, at the time I would have thought it was required for the language to become widely used. But since that's clearly not true I suppose I have to downgrade that statement to say it's required for me to write code in the langauge and not feel like I'm constantly banging my head against a wall. Frankly, yeah, I think Go programmers are kind of stuck in the 1980s in some respects. This isn't something I'm completely…

The payoff of the simpler type system is that people don't write posts like OP's about Go. The language has its rough edges, but it's not a brick wall the way Rust is -- you can learn the idioms and become a productive Go programmer very, very quickly. On top of that (or maybe as a related consequence), most Go code looks roughly the same. If you dive into the source of one of your project's dependencies, you aren't likely to find some esoteric or too-clever-by-half coding style. There are no fancy macros to untangle, because the language doesn't support them.

Writing that sort of clever, super-concise code scratches an itch that a lot of people have (myself included) but it's not something I want to encounter when I'm trying to debug something. When you're working with other people's code, you want it to be simple and consistent. That's what Go's primary strength is.

btw, I'll take this opportunity to plug my own "Go generics" solution: https://github.com/lukechampine/ply. It's like a Coffeescript for Go that lets you use stream HOFs like map/filter/reduce without any runtime cost.

Post reply on HN