Regarding restrictions vs. perfect freedom, I think it's also about trade-offs, implementation quality, etc. Typescript has very easy and well-defined escape hatches. Conversely, Rust's escape hatches are an active research field, not well-defined, considered significantly difficult by prominent Rust figures, the safety is leaky (for instance no_std), etc.
C is also a significantly stricter language in some ways than Perl, due to its static type system, despite that type system being primitive. C, ironically, is in some ways way stricter than Rust, since it has a goal of simplicity in its language, and thus writing compilers for it (despite its ancient syntax) and standardizing it is much easier than for Rust. And those properties are rather good for a systems language. Simplicity in the language does of course not generally necessarily translate to simplicity in the code, the ability to create good abstractions is worth a lot.
Rust has also experimented with editions. And there is the issue of Rust allowing backwards compatibility to be broken regarding type inference AFAI recall, in part leading to the 1.80 time crate debacle.
C is also a significantly stricter language in some ways than Perl, due to its static type system, despite that type system being primitive. C, ironically, is in some ways way stricter than Rust, since it has a goal of simplicity in its language, and thus writing compilers for it (despite its ancient syntax) and standardizing it is much easier than for Rust. And those properties are rather good for a systems language. Simplicity in the language does of course not generally necessarily translate to simplicity in the code, the ability to create good abstractions is worth a lot.
Rust has also experimented with editions. And there is the issue of Rust allowing backwards compatibility to be broken regarding type inference AFAI recall, in part leading to the 1.80 time crate debacle.