Do you think so? I would consider myself an Expert C programmer. I haven't written a C compiler but I can see how I would go about it, I know a lot of the weird arcana, and I followed WG14 enough to be heartened but not astonished when C23 got #embed while C++ still can't unstick their version of this work (and thus in practice if you're a C++ programmer you should hope your vendor's C++ compiler just offers the C feature anyway)
But I fell very much for Rust in about 2021, and now definitely wouldn't write any more C. Rust has coherent answers to a lot of questions that, to my mind, should be in any C programmer's head.
Now, maybe it helps my CS course's first language was SML/NJ and of course Rust is basically an ML in a trench coat pretending to be a semi-colon language like C. But that CS course was at least half a decade after I began writing C, which was in turn after many years of BASIC (and somewhere in there a little bit of Z80 assembler, but man assembler sucks when the CPU is as limited as the Z80 was, you young people who have a fucking floating point multiply instruction don't know what you've got etc...)
To me, the veteran C programmer, Rust's implementation makes lots of sense, while at the same time it's type system appeals to the more principled Computer Scientist I was taught to be, and its tooling to the Engineer I became as an employee.
Two examples: Wrapping<i32> is exactly how a 32-bit signed integer actually works in any vaguely modern computer. The machine can do this, and so unsurprisingly on a real computer this is nice and fast, despite also being completely safe. But, Wrapping<i32> is a nice elegant type, Wrapping is a polymorphic type, which grants to integers the property of wrapping (modulo) arithmetic for their normal operations, and so i32 is just a type parameter. Beautiful, and yet also fundamentally exactly how the machine works so it's fast.
Second, Option<&T> is exactly the same implementation as a C-style pointer. But it has the same ergonomics as rich Maybe types from a language like ML. So you use it in an inherently safe way, with the compiler catching many common mistakes you could make because they don't make coherent sense in the type system - but at runtime it's exactly the same performance as the nasty C code you'd have written where those mistakes wouldn't be caught.
Rust had include_bytes! from Rust 1.0, include_bytes! is philosophically the same thing, given a filename, it gives you an immutable reference which lives as long as your program, to an array of bytes from the file -- &'static [u8; N]
But I fell very much for Rust in about 2021, and now definitely wouldn't write any more C. Rust has coherent answers to a lot of questions that, to my mind, should be in any C programmer's head.
Now, maybe it helps my CS course's first language was SML/NJ and of course Rust is basically an ML in a trench coat pretending to be a semi-colon language like C. But that CS course was at least half a decade after I began writing C, which was in turn after many years of BASIC (and somewhere in there a little bit of Z80 assembler, but man assembler sucks when the CPU is as limited as the Z80 was, you young people who have a fucking floating point multiply instruction don't know what you've got etc...)
To me, the veteran C programmer, Rust's implementation makes lots of sense, while at the same time it's type system appeals to the more principled Computer Scientist I was taught to be, and its tooling to the Engineer I became as an employee.
Two examples: Wrapping<i32> is exactly how a 32-bit signed integer actually works in any vaguely modern computer. The machine can do this, and so unsurprisingly on a real computer this is nice and fast, despite also being completely safe. But, Wrapping<i32> is a nice elegant type, Wrapping is a polymorphic type, which grants to integers the property of wrapping (modulo) arithmetic for their normal operations, and so i32 is just a type parameter. Beautiful, and yet also fundamentally exactly how the machine works so it's fast.
Second, Option<&T> is exactly the same implementation as a C-style pointer. But it has the same ergonomics as rich Maybe types from a language like ML. So you use it in an inherently safe way, with the compiler catching many common mistakes you could make because they don't make coherent sense in the type system - but at runtime it's exactly the same performance as the nasty C code you'd have written where those mistakes wouldn't be caught.