Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No-Panic Rust: A Nice Technique for Systems Programming

blog.reverberate.org

Post reply on HN
Print view View original

121–130 of 143 posts

Re: No-Panic Rust: A Nice Technique for Systems Programming

#121

Post by ninetyninenine »

mrkeen wrote: post #110
ninetyninenine wrote: post #97

Earlier quoted context omitted.

That’s not invalid state. Your program correctly determined input is invalid. Say user input is a number and can never exceed 5. If the user input exceeds 5 your program should handle that gracefully. This is not invalid state. It is handling invalid input while remaining in valid state. Let say it does exceed 5 and You forget to check that it should never exceeds 5 and this leads to a division by zero further down y…

> You crash the program. No thank you. > Or you can put in a fail safe before the error bubbles up to main and do something else In other words, >> your parser backtracked from parsing a Bool and decided to try to parse an Int instead > but now (if your program retains and mutates that state) has invalid values in it and a known bug as well. Unless, >>> The thing with functional programming (specifically, immutable d…

Your parser backtracking from a bool when it tried to parse an int is VALID behavior. Your parser tries to parse text into several possible types at runtime. Backtracking is STILL valid state. You’re not thinking clearly.

Look at my auto pilot example. You have a bug in your program you don’t know about. Altitude reads -9999 meters your heading and direction is reading at the speed of light. Your program sees these values and recognizes invalid state. There is a BUG in your program. Your program WAS never designed to go here.

You want to try to recover your autopilot program? How the fuck are you gonna do that? You don’t even know where the bug is. Does your recovery routine involve patching and debugging? Or are you gonna let your autopilot keep operating the plane with those nonsense values? That autopilot might hit the wind breaks to try to slow down the plane and end up crashing the thing.

You don’t recover this. You restart the program and pray it doesn’t hit that state again then when you are on the ground you debug it.

>>> The thing with functional programming (specifically, immutable data,) is that as long as the invalid state is immutable, you can just back up to some previous caller, and they can figure out whether to deal with it or whether to reject up the its previous caller.

This makes no fucking sense. Where the hell will you back up to? Your error came from somewhere but you don’t know where. Return an error value in the child function the parent function receives the error and returns an error itself and this keeps going until you bubble up to the main function because you don’t know where that error came from.

Now you have an error in the main function. Wtf are you gonna do? How do you handle an error in the main function that you have no idea where it came from? Here’s an idea. You have the main function restart the program loop. See a similarity here? It’s called crashing and restarting the program. Same effect!

This isn’t a functional programming versus non functional thing. It’s a concept that you’re not seeing.

Re: No-Panic Rust: A Nice Technique for Systems Programming

#122

Post by sunshowers »

dathinab wrote: post #108
nicce wrote: post #103

Earlier quoted context omitted.

I would say that you are using them incorrectly if you assume them as recoverable. You should make everything you can so that they never happen. However, since it is still possible to have them in a place where the exiting the process is not okay, it was beneficial to add a way to recover from them. It does not mean that they are designed to be recoverable. > this is where most of it's overhead comes from Overhead co…

> I would say that you are using them incorrectly if you assume them as recoverable. no it's them being recoverable at well defined boundaries is a _fundamental_ design aspect of rust > Overhead comes from the cleaning process. If you don't clean properly, you might leak information or allocate more resources than you should. and that same cleanup process makes it recoverable

There is a social norm to treat panics as unrecoverable (in most cases — some do use panics to perform cancellation in non-async code).

Re: No-Panic Rust: A Nice Technique for Systems Programming

#123

Post by tga_d »

Groxx wrote: post #64
wongarsu wrote: post #16

The approach at the end of declaring invariants to the compiler so the compiler can eliminate panics seems accidentally genius. You can now add the same invariants as panicking asserts at the end of each function, and the compiler will prove to you that your functions are upholding the invariants. And of course you can add more panicking asserts to show other claims to be true, all tested at compile time. You've basi…

> and the compiler will prove to you that your functions are upholding the invariants From the article and only vague background Rust knowledge, I'm under the impression that the opposite is true: the compiler does not prove that. Hence why it's "assert_ unchecked " - you are informing the compiler that you know more than it does. You do get panics during debug, which is great for checking your assumptions, but that…

That's my understanding as well. The thing I was wondering as I read it: how difficult would it be for someone to make an extension or fork of Rust that allows annotating sufficient type information to prove these kinds of invariants, like F*?

Re: No-Panic Rust: A Nice Technique for Systems Programming

#124

Post by lilyball »

amelius wrote: post #87
lilyball wrote: post #59

Earlier quoted context omitted.

This is basically what Cap'n Proto does, and it uses offsets instead of pointers so that way the mmapped data can be used as-is.

Good to know, but does Rust have the machinery to make it work with standard Rust data structures?

What do you mean by "standard Rust data structures"? Like protobuf and other such formats, capnp uses code generation. The tooling for Rust is at https://github.com/capnproto/capnproto-rust and the generated code gives you structs that wrap borrowed data and give you accessors rather than direct field access.

Re: No-Panic Rust: A Nice Technique for Systems Programming

#125

Post by lilyball »

lilyball wrote: post #57
saghm wrote: post #39

Earlier quoted context omitted.

This isn't quite the same, but it reminds me of something a bit less clever (and a lot less powerful) I came up with a little while back when writing some code to handle a binary format that used a lot of 32-bit integers that I needed to use for math on indexes in vectors. I was fairly confident that the code would never need to run on 16-bit platforms, but converting from a 32-bit integer to a usize in Rust technica…

What about just doing something like #[cfg(any(target_pointer_width = "32", target_pointer_width = "64"))] #[inline(always)] const fn usize_to_u32(x: usize) -> u32 { x as u32 } and this way you can just call this function and you'll get a compile-time error (no such function) if you're on a 16-bit platform.

Oops, I flipped the conversion here, that should have been `u32_to_usize()`.

Re: No-Panic Rust: A Nice Technique for Systems Programming

#126

Post by amelius »

lilyball wrote: post #124
amelius wrote: post #87

Earlier quoted context omitted.

Good to know, but does Rust have the machinery to make it work with standard Rust data structures?

What do you mean by "standard Rust data structures"? Like protobuf and other such formats, capnp uses code generation. The tooling for Rust is at https://github.com/capnproto/capnproto-rust and the generated code gives you structs that wrap borrowed data and give you accessors rather than direct field access.

Well, it would be super convenient if you could use the standard collections like Vec, LinkedList, HashMap, etc. just like you would use them normally except now they are allocated inside an mmapped file.

Re: No-Panic Rust: A Nice Technique for Systems Programming

#127

Post by deschutes »

swiftcoder wrote: post #114
gpm wrote: post #42

Earlier quoted context omitted.

Rust doesn't want to add any proof-system that isn't 100% repeatable, reliable, and forwards compatible to the language. The borrow checker is ok, because it meets those requirements. The optimizer based "no panic" proof system is not. It will break between releases as LLVM optimizations change, and there's no way to avoid it. Trying to enforce no-panics without a proof system helping out is just not a very practical…

> This code is obviously correct. It never panics It doesn't panic within the code you typed, but it absolutely still can panic on OOM. Which is sort of the problem with "no panic"-style code in any language - you start hitting fundamental constructs that can can't be treated as infallible. > Basically every practical language has some form of "this should never happen" root. 99% of "unrecoverable failures" like this…

Assuming memory is infinite for the purposes of a program is a very reasonable assumption for the vast majority of programs. In the rare contexts where you need to deal with the allocation failure it comes at a great engineering cost.

It's not really what this is about IMV. The vast majority of unrecoverable errors are simply bugs.

A context free example many will be familiar with is a deadlock condition. The programmer's mental model of the program was incomplete or they were otherwise ignorant. You can't statically eliminate deadlocks in an arbitrary program without introducing more expensive problems. In practice programmers employ a variety of heuristics to avoid them and just fix the bugs when they are detected.

Re: No-Panic Rust: A Nice Technique for Systems Programming

#128

Post by ninetyninenine »

petee wrote: post #106
ninetyninenine wrote: post #97

Earlier quoted context omitted.

That’s not invalid state. Your program correctly determined input is invalid. Say user input is a number and can never exceed 5. If the user input exceeds 5 your program should handle that gracefully. This is not invalid state. It is handling invalid input while remaining in valid state. Let say it does exceed 5 and You forget to check that it should never exceeds 5 and this leads to a division by zero further down y…

I know this is not your point for the last paragraph, but have you read about the C-130 complete navigation system failure while trying land below sea level at the Dead Sea? :) https://news.ycombinator.com/item?id=14409950

good one.

Re: No-Panic Rust: A Nice Technique for Systems Programming

#129

Post by swiftcoder »

deschutes wrote: post #127
swiftcoder wrote: post #114

Earlier quoted context omitted.

> This code is obviously correct. It never panics It doesn't panic within the code you typed, but it absolutely still can panic on OOM. Which is sort of the problem with "no panic"-style code in any language - you start hitting fundamental constructs that can can't be treated as infallible. > Basically every practical language has some form of "this should never happen" root. 99% of "unrecoverable failures" like this…

Assuming memory is infinite for the purposes of a program is a very reasonable assumption for the vast majority of programs. In the rare contexts where you need to deal with the allocation failure it comes at a great engineering cost. It's not really what this is about IMV. The vast majority of unrecoverable errors are simply bugs. A context free example many will be familiar with is a deadlock condition. The program…

Deadlocks also don’t result in panics in most environments. The problem isn’t so much bugs - those can be found and fixed. The problem is more that no_panic in most languages implies no_alloc, and that eliminates most useful code

Re: No-Panic Rust: A Nice Technique for Systems Programming

#130

Post by gpderetta »

ninetyninenine wrote: post #25
rtpg wrote: post #11

I've had an unpleasant amount of crashes with Rust software because people are way too quick to grab `panic!` as an out. This was most shocking to me in some of the Rust code Mozilla had integrated into Firefox (the CSS styling code). There was some font cache shenanigans that was causing their font loading to work only semi-consistently, and that would outright crash this subsystem, and tofu-ify CJK text entirely as…

Sometimes the program is in an invalid state. You don't want to keep running the program. Better to fail spectacularly and clearly then to fail silently and try to hobble along.

This is correct in a memory unsafe language like C, where you can't make any assumption on the state of the program, so the only safe escape is to the address separation boundary (i.e. the program). In a safe language you can usually make reasonable assumptions [1] regarding the blast radius of an assertion violation. And that's why rust allows catching panics.

[1] even safe languages have unsafe escape hatches and safe abstractions sometimes have bugs, but on most cases you can assume that the runtime is not compromised.

Post reply on HN