> Anyway, I think what you're feeling is more real than you've allowed for. This is concretely a better foundation, that's not an illusion. It's not perfect but the sense that this is how things should be makes sense compared to other popular languages.
I know that things like ownership are universal concepts. They are relevant to all languages, even those that don't have a borrow checker. People who do not think of ownership generally do not write good code. They may not be aware of the concept or what it's called, but their thought process contains some implementation of it, even if indirect or limited.
In C, you very often need to know who is responsible for freeing a value, or when it is safe for the one responsible to free it. Someone may think of it in different terms, but the end result is the same. Even in something like Java you still might need to know who is responsible for managing a value.
Because Rust includes these things, teaches us to think about these things, and is generally designed with these things in mind, it is absolutely a better foundation than something like C or C++. A lot of C/C++ software, I'd say most of it, sorely deserves to be rewritten in idiomatic Rust.
But, you know, it's the "right tool for the job" thing. Sometimes Rust isn't the best for a particular application. Just because it's better at what it does, doesn't mean it's also better at what it doesn't do, if that makes any sense.
Of course. I can buy for example that it's hard enough to learn Rust that you wouldn't want to teach say, Chemists to write Rust rather than Python when showing them some Computational Chemistry, even if maybe the ones who "got it" would be better programmers your focus is Chemists, not programmers.
Or on safety we should not write new codecs in general purpose languages, including Rust, because these languages necessarily (Rice's theorem) can not check the semantic constraints we want to deliver safe codecs. We should use WUFFS. WUFFS is also a hard language to learn and as a special purpose language it's not applicable to most problems people have, but it is inherently safe† and delivers extraordinary performance so that's the right choice for this particular work.
† In C++ bounds misses are Undefined Behaviour, likely a security disaster. In Rust bounds misses cause a panic, likely premature program exit. In WUFFS any code which can have a bounds miss isn't valid, you get a compiler diagnostic saying you wrote this wrong, fix it.
In C and C++, Undefined Behavior basically says it's safe for the compiler to assume this hasn't happened, because as a programmer it's your responsibility to ensure it's impossible. This might not have been so bad if completely normal things (such as signed integer overflow) weren't UB. It's not safe to assume the programmer did it correctly, and it never will be. So, these languages have tons of footguns.
UB also exists in Rust, however it's only supposed to exist in unsafe code, and even within unsafe code, you still benefit from Rust's great RAII, move semantics, deterministic destructors, and so on. It's still UB to index past the bounds of a memory region (well... uhh, insert Stacked Borrows or Tree Borrows here, this gets much more complicated, but you get the idea) but you can only do this unchecked from unsafe code, otherwise it'll always be checked and will panic if you attempt an out of bounds access.
When unsafe code is a special delineated section, you're less likely to forget to be very careful.
Although ownership only becomes necessary to think about, once you start mutating data. If you only use immutable data, then there is no need to think about ownership.
I know that things like ownership are universal concepts. They are relevant to all languages, even those that don't have a borrow checker. People who do not think of ownership generally do not write good code. They may not be aware of the concept or what it's called, but their thought process contains some implementation of it, even if indirect or limited.
In C, you very often need to know who is responsible for freeing a value, or when it is safe for the one responsible to free it. Someone may think of it in different terms, but the end result is the same. Even in something like Java you still might need to know who is responsible for managing a value.
Because Rust includes these things, teaches us to think about these things, and is generally designed with these things in mind, it is absolutely a better foundation than something like C or C++. A lot of C/C++ software, I'd say most of it, sorely deserves to be rewritten in idiomatic Rust.
But, you know, it's the "right tool for the job" thing. Sometimes Rust isn't the best for a particular application. Just because it's better at what it does, doesn't mean it's also better at what it doesn't do, if that makes any sense.