C is a smaller language on some axes. That's not necessarily a good thing.

Looking at the following function definition, can you figure out how to use it safely?

    int foo(char* text, char* out,
            char* s, char* x);

If you were to have the same signature in Rust, it would look more like the following:

    fn foo(
        text: String,
        out &mut String,
        s: &str,
        x: &mut str,
    ) -> i32;

Now it is clearer that foo is responsible for getting rid of the allocation corresponding to text, which is on the heap. out can be modified and potentially reallocated. s is read only and it won't be deallocated by foo. x might be mutated in-place by foo, but it won't be deallocated.

Having a more "complex" way to represent in the typesystem something that C only bothers to call "a pointer" makes things better: safer, easier to skim, explore and understand an API, and allows the compiler to catch API misuses.

Being a smaller simpler language doesn't make it easier to read or write. Go is an even "simpler" language than C, but you quickly suffer from boilerplate-blindness when reviewing it. Being able to write good abstractions can make a huge difference. Having lifetimes, or the use of the semantically-correct integer type checked by the compiler reduces the cognitive load on the writer and reviewer.

>"is objectively much smaller, simpler language than Rust."

Brainfuck is an even smaller, simpler language, it has only 4 characters!

Yep that is my experience. C++ sucks. Thinking in rust and getting your ideas out is much much much easier. C is portable assembly, I prefer a language that protects me from footguns. I have better things to think about.

It's even worse, C is “portable” PDP-11 assembly. It has been a few decades that a C program is only distantly related to the assembly the compiler will generate.

On the Rust vs C++ scenario, try the next level with Rust:

- GUI code

- Generic datastructures crates coupled with lifetimes, macros and attributes