I’m glad the author finally figured out that the abstraction he was using was the wrong one and just ended up using a C-like API - calling some global procedures that mutate the (external) global state.
I’m not a rust expert, but perhaps this usecase is particularly hard because you’re holding it wrong? It seems to me that the strength of rust is in preventing panics as much as possible by moving the error checking to the compiler; so sure, fixing the terminal is an interesting challenge, but probably not going to make development any easier.
You can easily make lots of fragile Rust code by poor error handling that cause shitty panics like "Some(2) != None" and suppressing backtraces for even more obscurity. Good backtraces need to be human- and machine-readable. Ideally, you'd throw (pun intended) panic objects (not backtraces) as structured data in individual files. Anyone who gets into reinventing flat log rotation management at scale is holding it wrong.
I think the key there is "as much as possible". It's really hard to guarantee that panics won't happen.
I like Rust, but the panic mechanism is a bit of a weak point in the language. It's not like I have a better solution -- you really do need a way to handle exceptional cases that shouldn't ever happen but aren't statically checkable. But it's unfortunate that it interacts with so many other parts of the language, rather than being orthogonal. Every single API needs to answer "but how does this interact with panics". Rust is a very good language because panics are one of just a couple of things that work this way.
Unsafe code needs to be paranoid about panics, because that’s equivalent of exception safety in C++.
However, other safe Rust code doesn’t need to care that much, because it will either unwind and run destructors, or abort the program. Both are well defined and safe.
Rust uses panics to signal programmer bugs, not normal error handling, so there isn’t much to do about them in the code, because actual “handling” of panics is fixing the bug.
Sort of. There are a bunch of places in the safe API where you have to care. Off the top of my head:
- Lock poisoning and dealing with locks failing to open because they’re poisoned after some other thread panics.
- The whole scoped thread thing.
- Panics across async calls have a bunch of unintuitive (but reasonable once you think through the constraints!) behaviors.
It all comes down to the same thing: a function call could return or it could panic. Even when writing safe code, you have to know what you’re doing to do in case of panic. Usually that’s just passing the panic upward*, but not always, and those behaviors aren’t well-captured in the type system. Because of that, writing truly panic-free Rust is hard to impossible.
I don’t have a better answer than the panicking system. But you do have to care even in safe code, and it is a design weakness.
* I know about panic handlers and abort-on-panic. It doesn’t change the overall point.
It's an area of active development! I'm hopeful the situation will improve significantly this year.
For tracing suspended Futures, I've worked on a few approaches:
1. If you don't mind annotating your async functions, you can use the async-backtrace crate, which provides pretty-printing out-of-the-box: https://crates.io/crates/async-backtrace
2. If you are already using the `tracing` ecosystem, you can use the tracing-causality crate (it doesn't yet include pretty-printing, but it's not too hard to add that on): https://crates.io/crates/tracing-causality
The article wasn't about adding ASCII art, only about allowing the default panic handler to print the output correctly when the application uses raw mode in the terminal. It is a good introduction to what registering a panic handler looks like, no more than that. If you want colored backtraces, you can look at https://crates.io/crates/color-backtrace, https://crates.io/crates/better-panic or https://crates.io/crates/color-eyre, which leverage the same machinery shown in the article.
In this article, I interpret "pretty" to mean "readable". There is a sample of the alternative in the post. Raw mode requires an explicit carriage return to accompany each line feed if you want the CR behavior, so if the default panic handler prints its normal string, each line is horizontally indented to the end of the previous line.