6 ms·
These struggles are real. I don't see a way around them other than just learning them (and then they go away, because you know what code won't work, and don't f
by pornel 10y ago
These struggles are real. I don't see a way around them other than just learning them (and then they go away, because you know what code won't work, and don't fight it).
It's probably because Rust looks and operates mostly like a high-level language, but still satisfies low-level constraints.
e.g. the confusing difference between `&str` and `String` is equivalent of C's `const char * str = ""` vs `char * String = malloc()`.
In C if you had a code that does:
char *str = foo();
free(str);
you'd know that in `foo()` you can't return `"error"`, since an attempt to free it would crash the program. And the other way, if the caller did not free it, you'd know you can't have a dynamic string, because it would be leaked. In Rust you don't see the `free()`, so the distinction between non-freed `&str` and freed `String` may seem arbitrary.
- rvense 10y agoThese struggles are indeed real, but at least as far as verbose error handling goes, remember that Rust is forcing you to handle a lot of things that are silently ignored in Python. Truly equivalent Python code would include a bunch of exception handling and checks for nil.
- nathan_f77 10y agoI haven't done much Rust, but why isn't there a safe way to do some of this implicitly? If you don't want to think about errors and just want to crash, then I feel like there should be a sane way to crash the script with a default error message. Could you write a thin abstraction to achieve this? Maybe there could be a new crate called "rust-script" or something, where the goal is to write code as easily as Python or Ruby. Again, I'm not a Rust developer, but it's not hard to imagine an abstraction (or even a transpiler) that makes it easy to read a file, parse it as JSON, and do something with the data.
- AsyncAwait 10y agoThere's unwrap() and panic!, does that not do what you want?
- bombless 10y agoYour answer is simply `unwrap`. OP know it but struggles to believe it, it's that simply.
- rvense 10y agoAs the other comment says, that's exactly what's done with unwrap and try. You do obviously have to write that out, but on the other hand that means you know where to add the error handling when you come back after the fact. It might take a little getting used to, but it's a decent compromise. I'd say it's a matter of taste, but yeah, there are a few more characters there.
- MichaelGG 10y agoCouldn't there be an opt-in Deref for Option and Result? Then you could just pretend everything unwrapped fine.
- leshow 10y ago> If you don't want to think about errors and just want to crash, then I feel like there should be a sane way to crash the script with a default error message. We have `expect` it's like unwrap(), but takes a string. When the program encounters some error, it will exit and print the string.
- cowsandmilk 10y agoThe author seems to want to not use unwrap() in the rust version when that is basically what is done in the python version. The python version will die with an exception if: 1) the file does not exist 2) the file is not readable 3) the file cannot be parsed Rust forces you to say you want to panic in these cases (by using unwrap), but beyond that, the behavior is similar.
- amelius 10y ago> 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.
- Veedrac 10y agoRust is targeting an audience where silently degrading performance is problematic.
- vbezhenar 10y agoExceptions 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.
- pmarreck 10y agoI agree with you but until there is an empirical basis for our opinion-probably-honed-by-years-of-coding, these 2 languages will just continue to chug along without real exceptions My argument would be this: What is a runtime exception, really? It's a state that the programmer did not handle (either due to lack of thoroughness or flaws in mental model). Suppose the error is just ignored: To this I ask, why would you ever want code to continue in some state that has gone off the rails of determinism relative to the mind of the programmer? Imagine a bug that goes undetected because the corrupt state it generates only becomes a real problem many stack levels later under some corner case. Can you imagine a more hellish debugging scenario?
- hashhar 10y agoI have run into something very similar in somebody else's python program where they declared a string that was later used (based on some conditionals) to locate a file. The thing is that most of the conditionals were never hit under ideal conditions (like passing all args etc.). It took me a lot of time to track down the bug (also because of the lack of awesome debuggers for Python).
- tyingq 10y agoI don't know Rust, or the general direction of the community around it. Is there some chance, that over time, most popular functionality will end up in well architected crates that abstract away some of these complaints? A bad example, perhaps, because they probably go too far with it, but a lot of java's verbosity fades away because there's a rich ecosystem of libraries that already know how to do what you're trying to do. There is, of course, a downside to that...important implementation details become opaque to the users of these libraries.
- eximius 10y agoThere is currently an effort to make Rust more 'batteries included' by auditing and improving many of the most commonly used libraries (emphasizing crates outside of std).
- leshow 10y agoThe was an easy solution that he failed to use. His return type could have just been Result<MyConfiguration, Box<Error>> and he could've used try!/? freely