Never patterns, exhaustive matching, and uninhabited types in Rust • Hacker News Board

Re: Never patterns, exhaustive matching, and uninhabited types in Rust

#81

Post by Rusky » Sun, Aug 19, 2018, 6:45 PM UTC

saagarjha wrote: post #74

Rusky wrote: post #46

Earlier quoted context omitted.

I'm all for leaving asserts in release builds, but leaving in dead code based on uninhabited types isn't gonna help you catch RAM or CPU errors. You'll just continue into the error branch with an impossible value instead. It's the wrong layer for that.

This isn't an assert, it's not a runtime check; it's done at compile time. You need to prove to the compiler that your code can never reach this point; common ways of doing so are by calling exit or inserting an unconditional infinite loop. If your underlying computational platform is broken, this isn't going to save you, but I don't think there's much you can do at that point.

Yes, I know- that was my point. The comment I replied to was talking about CPU/RAM errors somehow bypassing that proof.

Re: Never patterns, exhaustive matching, and uninhabited types in Rust

#82

Post by derefr » Sun, Aug 19, 2018, 9:28 PM UTC

hinkley wrote: post #52

zlynx wrote: post #44

Earlier quoted context omitted.

This kind of thing has been plenty annoying in C++ code. Things like switch, default, abort that used to catch RAM or CPU errors and provide useful information now get optimized away and execution continues in the face of impossible values. Removing checks for "cannot possibly happen" cases isn't usually worth the tiny time savings.

I think ones of the design books I read years ago talked about a piece of building infrastructure that “could not fail” so they incorporated it directly into the concrete pour. Of course it failed, and it was a royal pain to get to the bits that failed because they were embedded in concrete that was probably holding the building up. You build for robustness because you might be wrong, the new guy might not understand…

Static languages in general aren't good at catching impossible conditions.

If anything, you probably want something more like Erlang's supervision hierarchy where pattern-match failures (due to a cosmic ray, or anything else) kill the actor-process that was running, and then the actor's parent reinstanciates it and it tries again. Then you just need to draw fine-grained failure boundaries (i.e. what things end up in new actor-processes) to ensure that crashing out a process doesn't waste too much work unnecessarily.

Or the Mars-rover "six CPUs on separate NUMA nodes are each running a copy of the program, and quorum-consensus on the result of each function-call" strategy, but that's a bit expensive.

Re: Never patterns, exhaustive matching, and uninhabited types in Rust

#83

Post by Baal » Mon, Aug 27, 2018, 10:26 AM UTC

dang wrote: post #79

Baal wrote: post #77

Earlier quoted context omitted.

I don’t see any personal attack. Can you quote? I don’t even know nor care about the identity of people here. As for flamewars, what are you even talking about? I have not said a single thing in favour of any language. Have you read the thread?

This is a personal attack: "It seems you don’t understand (or more likely you don’t want to understand)." This is bullying: "Prove Rust is controlling critical systems _today_ ". And this breaks the site guideline against calling names in arguments, as well as returning to personal attack: "Otherwise, please stop spreading bullshit". Please review https://news.ycombinator.com/newsguidelines.html . Your comments need…

Well, it seems you consider a “personal attack” any comment directed to another person, even if it is meaningful for the discussion and in-context. Your own guidelines ask for maintaining an identity (“On HN, users should have an identity that others can relate to.”); yet you don’t want any comments questioning anyone.

As for the rest: I don’t see how asking for proof can be considered “bullying”.

Please review the definition of bullying, because you are trivializing it and therefore hurting actual victims of bullying.

Thank you on behalf of them.

Finally, since it seems HN are in the business of deleting fair comments, I will leave the site and do my best warn others of what is happening here.

Good luck.