3 ms·
My impression as a non-expert who has only dabbled in Rust is that while it is ‘easy’ by design to write memory-safe code, it is relatively difficult to write p
by kps 4y ago
My impression as a non-expert who has only dabbled in Rust is that while it is ‘easy’ by design to write memory-safe code, it is relatively difficult to write panic-free code, and by and large the ecosystem doesn't try. (I know about `no_panic`.) In some domains (e.g. the rust-analyzer panic discussed here yesterday¹) this is fine; in others “this is fine”.²
The first Ariane 5 launch is an example of the latter. The code was written in a ‘safe’ language, Ada. A conversion overflow (that, as it happened, was in fact genuinely harmless) triggered a panic that (by design) brought down the subsystem, and with it the rocket.³
¹ https://news.ycombinator.com/item?id=34775549 https://news.ycombinator.com/item?id=34775549
² http://gunshowcomic.com/648 http://gunshowcomic.com/648
³ http://sunnyday.mit.edu/nasa-class/Ariane5-report.html http://sunnyday.mit.edu/nasa-class/Ariane5-report.html
- hdhrufjdi 4y agoInteresting point. I allow for panics when the panic is expected to never execute, i.e. logic errors. I see how it can be problematic, and thought of adding a general logic error for such cases. However, it adds work for devs and the machine. Still, panics can happen for allocations, where I don't know a solution. Would you consider this as a problem as well? If not, no_panic should suffice, right? Yeah, it might make things harder, but for rockets you probably won't use that many external crates and a bit more work should be acceptable, shouldn't it? What would you like to see the devs and the lang team to do?
- kps 4y agoI'm not knowledgeable enough about Rust's actual current state and plans to make concrete suggestions. Given the wide interest in Rust for security, I do think it's likely that in the long run significant effort will go into avoiding DOS-by-panic. I think it's unfortunate that LLVM had no popular small targets during Rust's early years, so it didn't get much attention from embedded devlopers. Heap allocation is one place where this shows. It's not really worse than C++, though, where in principle many parts of the standard library can use a custom allocator, but handling errors is awkward, and in practice the ecosystem doesn't try. C and C++ standards also don't generally specify which library components are allowed to perform heap allocations internally. C and C++ have ended up with small parallel ecosystems for such use cases. Since Rust aims to have one true ecosystem under cargo, it might be nice if library components could be explicitly tagged as panic-free, heap-free, etc.
- steveklabnik 4y agoRust doesn't exactly have things tagged as heap-free, but no_std category[1] contains many crates who have at least indicated that they don't use the standard library. Some may pull in liballoc and still want to do allocation, but it's better than nothing. Additionally, many packages that normally require the standard library let you opt out of that, with reduced functionality. My team works in no-heap Rust. We use external packages. It's much easier than in any other ecosystem to do so. Even that bit above goes a very long way and saves a lot of work. 1: https://crates.io/categories/no-std https://crates.io/categories/no-std