> writing a fast program in C is often simpler compared to writing a fast program in Rust
I think it really depends on what you need to do. If you need a HashMap or a BTree, getting your hands on high-performance implementations of those structures in Rust is much easier than in C. Also "sprinkling some threads" on existing serial code can be much easier in Rust, using a library like Rayon. But I take your point that designing new data structures and doing unsafe things with pointers can be more complicated.
> Overall Rust made programming harder
This is certainly a matter of opinion, but I like to argue that writing large, correct systems software was always this hard. Rust frontloads a lot of the difficulty, forcing you to handle every error condition, lifetime mismatch, and potential data race before it will even consent to run your tests. When you're first learning Rust, or when you're writing toy code where safety doesn't matter to you, this can feel like an unnecessary burden. But I think we've learned from experience that writing large systems software without this discipline leads to an endless stream of memory corruption and concurrency bugs.
I would agree. I feel like we keep seeing these “software has become more complicated!” blogs. But it’s really just that modern languages/stacks don’t focus on making software development easier for the individual, they focus on making it easier for the organization.
Related anecdote: I have been using GraphQL at work and holy shit it is boilerplate galore but I swear we hardly have to train new hires on how to structure their software to look like ours.
On top of that, our security standards have also gotten higher. No one was worried about corrupt spreadsheets causing segfaults in 1995. But today that corrupt spreadsheet is just as likely to be a malicious file from some attacker on the internet, deliberately crafted to exploit the buffer overrun behind that segfault. Any piece of software that might conceivably touch attacker-controlled input needs to be hardened against this sort of thing.
We're also going to be seeing more and more pressure to make things multithreaded. So so much of the old software was designed back when concurrency just wasn't in the picture. That's why PID reuse races are so nasty in child process management. And why anything that touches the environment (which lots of standard libc functions do under the covers: https://rustsec.org/advisories/RUSTSEC-2020-0159) is unsound in multithreaded programs. Making everything threadsafe is genuinely hard.
I think it really depends on what you need to do. If you need a HashMap or a BTree, getting your hands on high-performance implementations of those structures in Rust is much easier than in C. Also "sprinkling some threads" on existing serial code can be much easier in Rust, using a library like Rayon. But I take your point that designing new data structures and doing unsafe things with pointers can be more complicated.
> Overall Rust made programming harder
This is certainly a matter of opinion, but I like to argue that writing large, correct systems software was always this hard. Rust frontloads a lot of the difficulty, forcing you to handle every error condition, lifetime mismatch, and potential data race before it will even consent to run your tests. When you're first learning Rust, or when you're writing toy code where safety doesn't matter to you, this can feel like an unnecessary burden. But I think we've learned from experience that writing large systems software without this discipline leads to an endless stream of memory corruption and concurrency bugs.