Dave Herman’s contributions to Rust • Hacker News Board

Re: Dave Herman’s contributions to Rust

#171

Post by iudqnolq » Thu, May 06, 2021, 9:50 PM UTC

da39a3ee wrote: post #170

iudqnolq wrote: post #168

Earlier quoted context omitted.

You just phrase things the opposite way. I don't think it's clearly better to say the expected happy path or the unexpected sad path in a crash message. > That reads as "I expect this to be already validated". Is that what you intended it to mean? Yes > foo.expect("There was a problem and I had to crash") > That _reads_ as "I expect there to be a problem and have to crash". But it _means_ something totally different.…

OK, that would be nice but...what you're saying just doesn't work! The user gets an error message saying thread 'main' panicked at 'foo invariant upheld' And everyone, except those who are inured to the illogic via experience, will read that as thread 'main' panicked because 'foo invariant upheld' especially new users, less experienced programmers, and non-Rust programmers seeing the panic message. Now if the Rust la…

Outside of tests and toy examples you're generally expected to only panic when the developer has failed to uphold an invariant, not when the user has. As a result there's generally nothing a non-rust-developer can do with the message besides post it on the bug tracker.

Re: Dave Herman’s contributions to Rust

#172

Post by da39a3ee » Fri, May 07, 2021, 1:34 AM UTC

iudqnolq wrote: post #171

da39a3ee wrote: post #170

Earlier quoted context omitted.

OK, that would be nice but...what you're saying just doesn't work! The user gets an error message saying thread 'main' panicked at 'foo invariant upheld' And everyone, except those who are inured to the illogic via experience, will read that as thread 'main' panicked because 'foo invariant upheld' especially new users, less experienced programmers, and non-Rust programmers seeing the panic message. Now if the Rust la…

Outside of tests and toy examples you're generally expected to only panic when the developer has failed to uphold an invariant, not when the user has. As a result there's generally nothing a non-rust-developer can do with the message besides post it on the bug tracker.

Right, so that's relevant to a minor incidental comment I made. But what do you think of the main points, which are

(a) If you write the message the way you suggest the printed error message is misleading, and

(b) The Rust community does not encourage using .expect() in the way you suggest; in particular the canonical Rust documentation source instructs us to use it as

  foo.expect("A thing I do not expect")

Re: Dave Herman’s contributions to Rust

#173

Post by chrismorgan » Fri, May 07, 2021, 11:05 AM UTC

est31 wrote: post #169

chrismorgan wrote: post #157

Earlier quoted context omitted.

Mutex::lock() takes &self. RefCell::borrow_mut() takes &self. Those (and try_ variants) are the main ways people will use those types to gain access to their interior mutability. Sure, both do have get_mut() which takes &mut self (though these came after 1.0), but that’s seldom how you’ll actually access it. > But even if Rust had &uniq and &shared pointers, the challenge would be the same. Remember again that the mu…

> Mutex::lock() takes &self. RefCell::borrow_mut() takes &self. Those (and try_ variants) are the main ways people will use those types to gain access to their interior mutability. Yeah they take &self, but that wasn't my point. My point was what they expose , which is MutexGuard in the case of Mutex, and if you want to modify the interior, you'll likely use the DerefMut impl which returns a &mut T. Same goes for Ref…

I steadfastly maintain what I’m saying.

RefCell allows you to get a mutable reference via an allegedly-immutable reference. That it goes via a guard type is quite immaterial. It breaks the model.

&mut implies & is immutable.

Rust is teaching an incorrect mental model, which I believe is the wrong mental model to teach. Sure, &uniq is not devoid of problems, because most of the time &mut will suggest the right thing for beginners. But the spelling &mut is categorically wrong at the fundamental technical level. It was never actually about mutability.

Re: Dave Herman’s contributions to Rust

#174

Post by da39a3ee » Sun, May 09, 2021, 12:57 PM UTC

da39a3ee wrote: post #172

iudqnolq wrote: post #171

Earlier quoted context omitted.

Outside of tests and toy examples you're generally expected to only panic when the developer has failed to uphold an invariant, not when the user has. As a result there's generally nothing a non-rust-developer can do with the message besides post it on the bug tracker.

Right, so that's relevant to a minor incidental comment I made. But what do you think of the main points, which are (a) If you write the message the way you suggest the printed error message is misleading, and (b) The Rust community does not encourage using .expect() in the way you suggest; in particular the canonical Rust documentation source instructs us to use it as foo.expect("A thing I do not expect")

Similarly, from the rust stdlib docs for process::Command

  let hello_1 = echo_hello.output().expect("failed to execute process");