3 ms·

There are several languages which are motivated by providing a better experience than C in C's native domain. Rust is not one of those languages. Rust has an i

There are several languages which are motivated by providing a better experience than C in C's native domain. Rust is not one of those languages. Rust has an innovative, but highly opinionated, memory model: the premise is writing high performance memory safe programs, with 'zero cost' abstractions and so on. You might write a program in Rust rather than C in the way you might write a program in Go rather than C: because the application is better modeled in a language which isn't C. 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. But no, C is not fine. It has a stunning amount of own-goals making it pointlessly difficult to write a program with a fine-grained memory policy that is correct. C also doesn't have a syntax at all until you've run CPP, and then you have a context-sensitive parse. Neither of these are mere technical formalities, they actively inhibit understanding a C program.

steveklabnik 2y ago
> 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.

steveklabnik 2y ago

> 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.