over-obsession with the language's aesthetics ignore that the type system / borrow checker / ... are good and legitimately assist with development and did so even before the widespread use of LLMs.

many of those who ended up as Rust developers came from C and C++, seeing improvement from what they were using.

languages have been designed more and more to allow for higher level behaviours, in Rust's case, although not pursuing psuedocode, generally allows for very high level abstractions. regardless the computer still has to run things, languages are typically deterministic in their handling and psuedocode leaves much undetermined, unfully specified.

> I tend to wonder, in an alternate reality, where the buck stopped at C for systems languages, would we be better off because more people would use it and know how to fix memory related issues?

I think that period has arguably already come and gone. C and C++ have been the most popular systems languages for decades. I think it's clear that mere popularity is not sufficient to produce memory-safe software with those languages. If anything, those languages are experiencing somewhat of a renaissance these days and it's these more recent developments that end up producing improvements with regard to memory safety.

> I just wonder why don’t we just keep using C, C#, and Java? I mean the former two are memory safe, and they can do “unsafe” just like Rust.

Bit of a nitpick, but I think you meant "latter" instead of "former".

That aside, there's more to picking a language to use than just memory safety and the ability to perform "unsafe" operations. Take your pick from more technical reasons (zero-overhead FFI to C, low-level control over data structures/operations/runtime, etc.) and more "soft" reasons (language affordances/features, ecosystem, etc.).

> Another thing: why do we write pseudocode and not design languages to look like pseudocode?

Perhaps COBOL might be what you're looking for? :P

As with many things, language design is full of tradeoffs, particularly when you want to produce something that is not too unfamiliar to a certain audience. IIRC another factor is that languages that want to work well for "experts" will tend to favor different points on the design spectrum. Consider APL-family languages - those are completely incomprehensible to anyone not familiar with them, but that same terseness is highly valued by proficient practitioners and is something pseudocode-like (or even "regular" code-like!) could never replicate.