3 ms·

> For programs which pertain to the domain where C should be considered on its merits, if you try to write them in Rust, you may as well start each module with

> For programs which pertain to the domain where C should be considered on its merits, if you try to write them in Rust, you may as well start each module with an unsafe block. This is often said, but does not reflect reality. At this point, we have tons of bare-metal and OS-level Rust code existing in the world, and it still has very little unsafe overall.

samatman 2y ago
Granted, that was put poorly, let me try again. What I said doesn't in fact have the implication you took from it, but I didn't explain myself particularly well. There are many programs one can write in C, or Zig, or some other manual-transmission language, which, if you wrote them in Rust, would just be wrapped in a big unsafe block. That isn't because those programs have memory errors in them, it's because they have a memory policy which safe Rust doesn't support. Examples include certain garbage collection algorithms, and embedded programs where all memory is pre-allocated and references shared somewhat promiscuously. It's possible to write analogous programs in safe Rust, but not the same program. The space of programs which are both correct, and not possible in safe Rust, is infinite. They don't come with compiler guarantees, so other support is needed. CompCert is a good example of an approach to that which isn't Rust's. Keeping in mind that I'm referring to specific programs, not "a program which solves the problem domain". Otherwise we could just say that since you can write a program which solves the problem domain in Python, there's no use for Rust. That wouldn't lead to a productive conversation, would it. People still choose C over Rust, even knowing what Rust is. This isn't the early days of the evangelism strike force, Steve. The above is why. Sometimes they might be better off writing the analogous program in Rust, or seeing if they can get the program they're trying to write with limited use of unsafe blocks. Sometimes not. I know you've put a lot of work into your hammer over the years, but it's never going to be the only tool in the box. Languages, and I'm thinking of Zig here, which make it easier to correctly implement a memory policy which doesn't happen to be Rust's, should be applauded, and not called "a massive step backwards for the industry <pouty sad face>". Like it or not, they're working in the same domain as Rust, based on different principles. But yes, there is an infinitely large class of programs which can be written in the embedded and OS spaces, in Rust, with very little unsafe overall. I didn't intend to imply otherwise.

samatman 2y ago

Granted, that was put poorly, let me try again. What I said doesn't in fact have the implication you took from it, but I didn't explain myself particularly well. There are many programs one can write in C, or Zig, or some other manual-transmission language, which, if you wrote them in Rust, would just be wrapped in a big unsafe block. That isn't because those programs have memory errors in them, it's because they have a memory policy which safe Rust doesn't support. Examples include certain garbage collection algorithms, and embedded programs where all memory is pre-allocated and references shared somewhat promiscuously. It's possible to write analogous programs in safe Rust, but not the same program. The space of programs which are both correct, and not possible in safe Rust, is infinite. They don't come with compiler guarantees, so other support is needed. CompCert is a good example of an approach to that which isn't Rust's. Keeping in mind that I'm referring to specific programs, not "a program which solves the problem domain". Otherwise we could just say that since you can write a program which solves the problem domain in Python, there's no use for Rust. That wouldn't lead to a productive conversation, would it. People still choose C over Rust, even knowing what Rust is. This isn't the early days of the evangelism strike force, Steve. The above is why. Sometimes they might be better off writing the analogous program in Rust, or seeing if they can get the program they're trying to write with limited use of unsafe blocks. Sometimes not. I know you've put a lot of work into your hammer over the years, but it's never going to be the only tool in the box. Languages, and I'm thinking of Zig here, which make it easier to correctly implement a memory policy which doesn't happen to be Rust's, should be applauded, and not called "a massive step backwards for the industry <pouty sad face>". Like it or not, they're working in the same domain as Rust, based on different principles. But yes, there is an infinitely large class of programs which can be written in the embedded and OS spaces, in Rust, with very little unsafe overall. I didn't intend to imply otherwise.