6 ms·
This is actually something about the code samples in Rust docs that irks me a bit. My view is that sample code such as this should be as idiomatic as possible
by sidlls 10y ago
This is actually something about the code samples in Rust docs that irks me a bit.
My view is that sample code such as this should be as idiomatic as possible and that means providing a sample demonstrating a typical real use case. So seeing "unwrap" in this context doesn't sit well with me.
In fairness, this isn't specific to Rust. I find sample code like this in many projects regardless of language. However Rust is billing itself as a safe systems programming alternative to C and C++. It would help its marketing efforts, in my opinion, by having more robust samples than the competition. And let's be honest: given the competition is C and C++, that's a low, low bar--and this comes from a guy who's about as big a fanboy of those two languages as possible.
Edit for more disclaimer: documenting Rust code is a real pleasure. The team has done a stellar job at making documentation an easy thing to do while writing the code. It's already better in most cases than many other projects I can think of.
- steveklabnik 10y agoSo, to be clear, unwrap is safe. It is never going to cause the sorts of memory issues that an uncontrolled crash is. That is, in terms of safety, this is the same thing as explicitly handling the error and then terminating the process. Which is the only real way you're going to handle this error anyway, unless you wanted some sort of retry logic. Which you might!
- threatlock 10y agoBzzzt, wrong! You're on the right track though, fuzz harder
- sidlls 10y agoI agree that in terms of safety it's equivalent. However in terms of how an actual program would be written it's...Less than optimal. I almost never simply allow a panic-like termination in a program like this, if it can be trapped, without doing something else, even if it's just to spit out a log/stdout message with a descriptive reason. Then again the plural of anecdote isn't data, and maybe I'm the oddball here.
- Manishearth 10y agoYeah, unwrap()s in examples should be written to use expect() (which spits a message and then panics). But for most example programs there's no easy way to handle errors further than just using expect() unless you want there to be more error handling code than actual useful example code.
- pygy_ 10y agoRust n00b here (I read a lot about it but haven't written a line yet), but wouldn't `.orPanic('error message')` be a better name than `.expect('error message')`? The latter seems backwards.
- steveklabnik 10y agoIt'd be or_panic, following conventions. The idea is that I expect this to be Ok/Some, and if it's not, please use this error message.
- pygy_ 10y agoI understand the intent, but usually the programmatic object is the subject of the sentence, the method is the verb and the parameter/argument is the grammatical object. Here, the programmatic object is the grammatical object. That's what I meant by 'backwards'. could_fail().or_panic_with('message') may be even better.
- steveklabnik 10y agoI don't neccesarily disagree. Names are hard :)
- cgag 10y agoA lot of people don't seem to agree with me but I think even expect is too long of a name and terseness for commonly used names seems more important to me than reading like natural language.
- tedunangst 10y agoThe mention of memory safety is kind of weird. Reading or writing to -1 in C is memory safe too. It's even sometimes done deliberately as a debug technique if you want to insert messages in your IO traces. (Wrt your post that rust is more than just safety, people will get that impression when you introduce memory safety into unrelated threads.)
- deleted 10y ago[deleted]
- steveklabnik 10y agoWhile Rust is more than memory safety, it's really important that people accurately understand what safety actually means in Rust. Because then they oversell it. Common misunderstandings here: * Rust prevents deadlocks * You can't leak memory in Rust * Rust prevents race conditions * Panic is not safe etc. In my mind, bringing up memory safety here isn't a red herring; the parent said this: > However Rust is billing itself as a safe systems programming alternative to C and C++. The way in which we are safer is memory safety, nothing more. And knowing that is crucial. Rust code will have bugs. Rust code will have security vulnerabilities. Rust is not a panacea.
- jdf 10y ago> The way in which we are safer is memory safety, nothing more. I know you want to not overstate rust's claims given recent articles, but I think you're actually underselling a little here. For example, a rust `enum` make it much easier for the compiler to enforce code correctness. It's hard to go back to similar code in C or Go once you've gotten used to `match`.
- steveklabnik 10y agoYes, I guess in my mind, "correctness" and "memory safety" are two different things. I like that Rust can help you write more correct software, but it's not nearly as strong of a guarantee as our memory safety guarantees are.
- 10y ago
- wyldfire 10y agoIf the bind fails, panic seems totally appropriate. Bonus points for telling me it failed for EADDRINUSE. This is head and shoulders above anything C could deliver IMO. It's a fair debate whether we should prefer the simplicity of panic over the elegance of unwinding and handling.
- deleted 10y ago[deleted]
- Manishearth 10y agoFWIW it's unwrap()ing on a known-good address, which is an okay way to use unwrap(). Kind of. It's one of the more common ways of using unwrap. (The examples unwrap elsewhere in less known-good scenarios, I agree that we should improve there)
- saghm 10y ago> My view is that sample code such as this should be as idiomatic as possible and that means providing a sample demonstrating a typical real use case. So seeing "unwrap" in this context doesn't sit well with me. I've starting trying to use `if let Some/Ok(...) = ...` in examples for my projects rather than `unwrap` for pretty much this reason. I feel like it strikes a pretty good balance between providing a relatively terse example without the risk of implying that `unwrap/expect` is considered normal usage for the library.