zlacker

It's more like "let's improve on C by catching errors C compilers don't check." Rust took a lot of inspiration from Cyclone, which was meant to be a safe version of C.

Writing C makes certain classes of sloppy assembly bugs unwritable, like accidentally using the wrong calling convention, forgetting to preserve a register, or forgetting to pop something off the stack. Similarly, Rust makes classes of sloppy C bugs unwritable, like using a dangling pointer.

Why do you view that as an attack on C programmers? It's no more an attack on them than C was an attack on assembly programmers.

>>treali+(OP)
The attack is the idea that everybody needs to have the same priorities that Rust has and so everybody else is wrong. With regard to memory safety, this even something I could partially agree with, but then there is another problem: In contrast to Cyclone, which was a safe version of C, Rust changes a lot more than simply adding memory safety features. It is not at all like C but has completely different syntax, different conventions, and complexity similar to C++. So in many ways, I find it inferior to C (although I agree that memory safety is good), but Rust people think it is superior in every way and behave like this.

>>uecker+YJ
It's true, not everyone has the same priorities, and Rust may not provide the right set of tradeoffs when one is deciding which language to use. I don't believe that C is strictly inferior to Rust. There are cases where it's not worth trying to use Rust instead of C.

Unsafe Rust is more complex to use than C in some ways. For example, an iterator for a slice, which contains two raw pointers, relies on the lifetime of the array it refers to lasting longer than the slice, and to encode this you need to use PhantomData [1]. Things like this make it look more arcane than plain C, simply because in C, this is implicit, and on the programmer to enforce.

[1]: https://doc.rust-lang.org/nomicon/phantom-data.html