> Rust is too big for my small brain, unfortunately.
Rust is harder because it imposes constraints on the programmer in order to enforce memory safety. These constraints don't magically disappear if you are trying to write memory safe code in C.
The difference is that you can just use any kind of valid constrains or invariants to prove safety in C (but unfortunately these are just in mind or documentation and not verified by compiler), while you have to fit to specific model of constraints used by Rust.
The constraints imposed by Rust are more difficult to deal with though. There are so many cases where I know for sure 100% that something is completely safe, but I have to spend a whole lot of brain power trying to come up with a way to convince Rust that it's completely safe which doesn't just involve unnecessarily boxing a value.
We've all been there – you know for sure something is 100% safe and then the fuzzer finds and UB that was outside of your mental model bounds...
Thing is, if some system/concept/abstraction/model is memory-safe, more often than not it directly translates to Rust concepts via lifetimes and the such. If you've done it a number of times, you will find it very easy to map the former to the latter. In the rare cases when it doesn't fully translate, you can always dip into unsafe (usually at the lowest levels of your abstractions), same as the Rust's standard library does, and test/fuzz that part extensively.
I am not against the concept of safety guarantees.
We have all been there where we have written code based on a faulty mental model which resulted in bugs. Yes. And more often than not, Rust would have prevented those bugs or made them less severe. But we have also all been there where we have had a solid mental model of what a system is doing and written correct code.
Rust helps in the former case, but it makes the latter case harder.
And no, it's not the case that "more often than not", if you need one const reference and one non-const reference to some data, your code is wrong. In fact, almost all code in almost all mainstream languages end up with multiple references where at least some are non-const, and it's fine most of the time. In Rust, all of those situations require type system and borrow checker gymnastics.
I'm not against Rust. I think it's a fine language. I also think it's significantly harder to write than most other languages if you don't want to just punt and use Rc<RefCell<T>> all over the place.
Rust can't encode non linear lifetime at compile time. This means anything where ownership or access patterns can be self referential or "go up" statically. This includes things like intrusive data structures (linked lists, graphs) and concurrent/callback based control flow. Rust doesn't have the constraints to model these so they do in fact "disappear" (at least statically) as far as both languages are concerned.
Rust is harder because it imposes constraints on the programmer in order to enforce memory safety. These constraints don't magically disappear if you are trying to write memory safe code in C.