Perhaps verus would be helpful to the op: https://github.com/verus-lang/verus
No-Panic Rust: A Nice Technique for Systems Programming
71–80 of 143 posts
Re: No-Panic Rust: A Nice Technique for Systems Programming
#72This seems..absurd for a programming language with goals like Rust. Why isn't this a compiler option? Just set -nopanics and the compiler errors and flags anything which is pulling in a panic at the very least?
https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-... ``` [profile.release] panic = 'abort' ```
After using rust for several years, I'm shocked this isn't the default. Making panics recoverable leads to them being used incorrectly.
Re: No-Panic Rust: A Nice Technique for Systems Programming
#73OP sounds like they'd be very interested in Zig to tackle this particular problem. they'd get to a very similar place and not have to fight the language or the standard library to get there.
Re: No-Panic Rust: A Nice Technique for Systems Programming
#74> If we are trying to port a C library to Rust, we really do not want to introduce panics in the code, even for unusual error condition.
"We'd much rather like to make library to corrupt the memory of the rest of the application and generally make the demons fly out of the users' noses, as it does when written in C"?
I believe implementations of C stdio also can abort on program startup if somehow the pthreads' locking mechanism is broken (or if e.g. fcntl(2)/open(2) keeps returning -1), Rust is not that unique in this regard.
Re: No-Panic Rust: A Nice Technique for Systems Programming
#75Earlier quoted context omitted.
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 is why Result (or Maybe, or runExceptT, and so on in other languages) is a perfectly safe way of handling unexpected or invalid data. As long as you en…
Say a function has some return type Result . If our only error handling mechanism is Err(e) then were restricted to E representing the set of errors due to invalid arguments and state, and the set of errors due to the program itself being implemented incorrectly. In a good software architecture (imo) panics and other hard failure mechanisms are there for splitting E into E1 and E2, where E1 is the set of errors that…
You shouldn't pass invalid values to a function. If a function can return some sensible value for some input, then the input is not invalid - even if the return type is an error by name.
Ideally, you can constrain the set of inputs to only valid ones by leveraging types. But if that's not possible and a truly invalid input is passed, then you should panic. At least that's the mental model that Rust is going with.
You do lose out on the ability to "catch" programming errors in subcomponents of your program. For example, it's extremely useful to catch exceptions related to programming errors for called code in response to a web request, and return a 500 in those cases. One could imagine a "try" "catch" for panics.
The thing is, it takes a lot of discipline by authors to not riddle their code with panics/exceptions when the language provides a try/catch mechanism (see C# and Java), even when a sensible error as value could be returned. So Rust opts to not introduce the footgun and extra complexity, at the expense of ungraceful handling of programming errors.
Re: No-Panic Rust: A Nice Technique for Systems Programming
#76This website makes by browser freeze... No idea why. Not able to read the article.
This happened to me too (Safari on iOS).
Here’s a archived link:
https://web.archive.org/web/20250204050500/https://blog.reve...
Re: No-Panic Rust: A Nice Technique for Systems Programming
#77Most people are using a prebuild standard library. That comes with the problem that it comes with the features it was build for. Most of the bloat around panic for example can be eliminated by just compiling the std library yourself. This is done via the `-Zbuild-std` flag.
Using this flag one than can use `panic_abort`. This will eliminate the unwinding part but would still give a "nice" printout on a panic itself. This reduces, in most cases, the mention bloat by a lot. Though nice printouts also cost binary space. For eliminating that `panic_immidiate_abort` exists.
But yeah the above is only about bloat and not the core goal to eliminate potential path's in your program, that would lead to a panic condition itself.
Also currently building the std library yourself needs a nightly compiler. There is afaik work on bringing this to a stable compiler but how exactly is still work in progress.
Re: No-Panic Rust: A Nice Technique for Systems Programming
#78This seems..absurd for a programming language with goals like Rust. Why isn't this a compiler option? Just set -nopanics and the compiler errors and flags anything which is pulling in a panic at the very least?
It's sad. If anything panics in the stdlib should be opt-in, not opt-out.
Re: No-Panic Rust: A Nice Technique for Systems Programming
#79Earlier quoted context omitted.
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 is why Result (or Maybe, or runExceptT, and so on in other languages) is a perfectly safe way of handling unexpected or invalid data. As long as you en…
The program can detect invalid state, but your intention was to never get to that state in the first place. The fact that the program arrived there is a Logic error in your program. No amount of runtime shenanigans can repair it because the error exists without your knowledge of where it came from. You just know it's invalid state and you made a mistake in your code. The best way to handle this is to crash the progra…
> The fact that the program arrived there is a Logic error in your program.
No, your program correctly determined that user input was invalid.
Or your parser backtracked from parsing a Bool and decided to try to parse an Int instead.
Re: No-Panic Rust: A Nice Technique for Systems Programming
#80[dead]