3 ms·
Nice, love to see posts where people give their experience like this. It's a rare thing. > the Cargo compiler Really small thing, cargo is a build tool, not a
by insanitybit 4y ago
Nice, love to see posts where people give their experience like this. It's a rare thing.
> the Cargo compiler
Really small thing, cargo is a build tool, not a compiler. `rustc` is the main compiler, cargo wraps that and provides helper utilities for stuff like package/ project management.
> Detecting an out-of-bounds access at compile time requires a deeper analysis of the code that would significantly slow down compilation time (which is already too slow IMO).
The compiler actually is likely doing this stuff already because it's trying to optimize away any branches. I bet it already can see in these basic examples that the panic is unconditional. There are crates that leverage this fact, like `no-panic`, to try to see if your code is panicking.
Also worth noting that "panic" is kinda like a runtime exception in Java and it can be caught. In fact it's automatically caught at the thread boundary - that's going to just be the main thread in your example.
> This section is about a recent behavior I observed where our team woke up to one of our crates’ (dependencies’) dependencies starting to panic in production under specific conditions
Bummer! Especially for a crate as popular as reqwests. My suggestion would be to assume any code can panic and build around that. That means a few things.
1. It means to test your code. Integration tests are great for catching bugs like this, even a basic smoke test would likely catch it.
2. Use a control plane that will automatically restart services, monitor their health, and reverse deployments if they don't get healthy soon enough.
Ultimately, no matter the language, crashes happen. That said, I get that it's frustrating and no one likes a panic.
> A quick idiomatic alternative to dealing with this problem could be overriding Rust’s panic_handler but unfortunately this is only possible in #![no_std] projects.
FWIW people are thinking about how to solve this for the std case.
https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capabilities/ https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capa...
One option is capabilities. This is kind of like what `unsafe` is - in order to call 'unsafe' you have to be in an unsafe context.
There are other options as well. Anyway, the point is, I hear you and so do others - understanding where a panic might occur is definitely of interest to rust devs.
> Program binaries can be huge
Indeed, but not really inherently huge. You can get quite small - I suggest stripping your debug info, that's a ton of the space.
> On a more personal note, I wish to be more involved in shaping Rust’s future by making contributions to its software while keeping learning its concepts and intricacies.
Honestly, this is a good start, it's always important to let the people behind the language know what's working for you and what's not.
My final suggestion would be to consider asking for help in either the Rust discord, subreddit, or user forum.