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

281–290 of 329 posts

Re: My Struggles with Rust

#281

Post by pixel_fcker »

resf wrote: post #272
twic wrote: post #161

Earlier quoted context omitted.

I don't get it. .unwrap() turns an undesirable situation into printing an error message and exiting with a nonzero status. There are plenty of situations where that is exactly what you want, and not a bug at all. For example, in my production Rust code, i deal with all errors in reading and parsing config files with .unwrap() or .expect(). If a program cannot read its config file at startup, it cannot correctly do it…

Prints to where? stderr? Fine for a simple CLI tool, but people might want to do something more complicated when an "unrecoverable" exception occurs. Take for instance a web framework like Django that responds with a 500 error page with a stack trace when an exception occurs. There are interesting problems to be solved in the space of error handling, e.g. error handling in asynchronous code. But Rust is not even matc…

...then don't use unwrap(). Instead check the error, do whatever handling you want and exit gracefully.

unwrap()'s behaviour is essentially the same thing as an uncaught exception in Python, only you can actually check for where they occur in the code with a simple grep rather than hoping your test suite caught every possible failure case.

Re: My Struggles with Rust

#282

Post by int_19h »

burntsushi wrote: post #280
int_19h wrote: post #259

Earlier quoted context omitted.

It is exactly the same kind of polymorphism that languages like Java and C# had before they adopted generics. In practice, what this means is that you have downcasts all over the place, which is tedious, non-typesafe, and is why both C# and Java have generics now. The fact is that Go is the only statically typed language, with any claim to being mainstream, that doesn't have generics. And it's not like generics are s…

> It is exactly the same kind of polymorphism that languages like Java and C# had before they adopted generics. That's false. Go provides a smattering of blessed polymorphic types (slices, maps, chans, pointers) and functions (len, append, delete, chan send, chan recv) that go a long way. They are horrifying to civilized PL enthusiasts, but they cover a lot ground. As I said in one of my sibling comments, navel gazin…

C is one of those things that hasn't meaningfully changed in decades now. So yes, technically it is a mainstream language without generics (and many other things) - but I don't think that's a viable role model. The only reason why C is what it is, is because of all the legacy code written in it.

Re: My Struggles with Rust

#283

Post by int_19h »

grahn wrote: post #274
int_19h wrote: post #259

Earlier quoted context omitted.

It is exactly the same kind of polymorphism that languages like Java and C# had before they adopted generics. In practice, what this means is that you have downcasts all over the place, which is tedious, non-typesafe, and is why both C# and Java have generics now. The fact is that Go is the only statically typed language, with any claim to being mainstream, that doesn't have generics. And it's not like generics are s…

If you want to understand the reasonings the Go maintainers have about generics, there is a GitHub issue[1] on it that is probably a better place to start than to argue with me. The thread references both recent academic research as well as other programming languages' take on the subject. I don't think their crux is so much that generics "as such" needs more baking, but the specifics of how to implement them with th…

No-one is suggesting that they're idiots, though. The original argument is that Go designers are very conservative, and extremely averse to some language features that aren't even "new" anymore - not that they're unaware of those features or how they work.

Re: My Struggles with Rust

#284

Post by [deleted] »

grahn wrote: post #274
int_19h wrote: post #259

Earlier quoted context omitted.

It is exactly the same kind of polymorphism that languages like Java and C# had before they adopted generics. In practice, what this means is that you have downcasts all over the place, which is tedious, non-typesafe, and is why both C# and Java have generics now. The fact is that Go is the only statically typed language, with any claim to being mainstream, that doesn't have generics. And it's not like generics are s…

If you want to understand the reasonings the Go maintainers have about generics, there is a GitHub issue[1] on it that is probably a better place to start than to argue with me. The thread references both recent academic research as well as other programming languages' take on the subject. I don't think their crux is so much that generics "as such" needs more baking, but the specifics of how to implement them with th…

[deleted]

Re: My Struggles with Rust

#285

Post by mikebenfield »

dom96 wrote: post #233
mikebenfield wrote: post #91

Earlier quoted context omitted.

I think Nim may be the most underdocumented project I've ever used. I spent a week or so with it, but quickly grew extremely frustrated as I was constantly scouring old forum posts to learn how to use the basic features of the language. That is not a tolerable situation for me.

If you don't mind me asking, what in particular were you searching for? I agree that Nim's documentation needs a lot of love but would like suggestions on what specifically you had trouble with so that I can at least improve that (for now) :)

Unfortunately I can't remember the details at this point. There was something I couldn't figure out with the `new` function and heap allocation in general, and I also got frustrated trying to understand some things about the type system. I do know one thing about `new` was that it took me forever to figure out how to allocate anything on the heap at all, only to find a couple lines about `new` in the API docs. At least, I think that's what happened.

Sorry I can't be more specific.

Re: My Struggles with Rust

#286

Post by [deleted] »

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

[deleted]

Re: My Struggles with Rust

#287

Post by hasenj »

wtetzner wrote: post #23
hasenj wrote: post #19

Earlier quoted context omitted.

It would crash but would print an error message along with a stack trace. The rust version will probably just crash with a confusing error.

Why would the Rust version crash? The compiler will warn you if you if you haven't used a result type, and it's up to the programmer to decide what to do in the case of an error, just like when handling an exception. If you were going to use the JSON result for something, then you are forced to check if the result was Ok or Error. The only time you'd get a crash is if you just called .unwrap(), and even then you'll a…

I think the point of the question was that in Python errors can still happen but they tend to get ignored when writing small scripts. So if one were to explicitly ignore errors in Rust how would the resulting program's behavior differ from the Python version?

Re: My Struggles with Rust

#288

Post by Const-me »

jsolson wrote: post #217
Const-me wrote: post #101

Earlier quoted context omitted.

> I've yet to encounter a case where these ~15 codes were insufficient Insufficient on Windows. There’re thousands error codes you can get from any Windows-provided API. You can pack each of them into a single int32 value (using HRESULT_FROM_WIN32 macro for old-style error codes, the newer APIs already return HRESULT), but still, significantly more than 15.

Google's util::Status and util::StatusOr are actually quite flexible. While the generic error space is recommended for most work (and really, rather a lot fits in that space), it does support the notion of other error spaces like POSIX or Windows. At Google† I do quite a bit of interacting with the kernel, so my code makes fairly heavy use of the POSIX space. That said, in the vast majority of cases any error I might…

I mostly work on desktop and mobile software. “Unable to open the file: access denied” is helpful for end-user, will cause them to go fix filesystem permissions on the file they are trying to open, or restart the app elevated. “Unable to open the file: failed precondition” translates to “this software is broken, we don’t know why”

> With enormous error spaces that is much more challenging.

Not sure I understand the problem. On Windows, APIs are typically designed as reliable (this applies to both OS API, and the way third-party developers design stuff). If something is failed but the condition is temporary and might have fixed with retry, well-designed API will retry itself, possibly accepting timeout argument. That’s why you can do generic error handling just fine: FAILED() macro is enough for 99% cases.

Re: My Struggles with Rust

#289

Post by [deleted] »

jsolson wrote: post #217
Const-me wrote: post #101

Earlier quoted context omitted.

> I've yet to encounter a case where these ~15 codes were insufficient Insufficient on Windows. There’re thousands error codes you can get from any Windows-provided API. You can pack each of them into a single int32 value (using HRESULT_FROM_WIN32 macro for old-style error codes, the newer APIs already return HRESULT), but still, significantly more than 15.

Google's util::Status and util::StatusOr are actually quite flexible. While the generic error space is recommended for most work (and really, rather a lot fits in that space), it does support the notion of other error spaces like POSIX or Windows. At Google† I do quite a bit of interacting with the kernel, so my code makes fairly heavy use of the POSIX space. That said, in the vast majority of cases any error I might…

[deleted]

Re: My Struggles with Rust

#290

Post by shadowmint »

steveklabnik wrote: post #142
shadowmint wrote: post #133

Earlier quoted context omitted.

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.

meh.

I feel like any time someone mentions the word 'safe' regardless of context, the rust safety pedants roll out of the woodwork to dispute to dispute any minute detail of what's been said, regardless of if its relevant to the discussion at hand. I shouldn't have put 'safe' in the comment at all, what a waste of a thread.

My point had nothing to do with safety; it was purely that having given advice being to write good code that doesn't panic, and then having code that shamelessly panics in all your examples is hypocritical.

`?` is a better choice in basically every case; I'm glad to see the documentation will be moving eventually towards using that.

Post reply on HN