I'm not saying anything about what is possible. What would be the amount of time it takes to create a new language, create a stable compiler, create a sizable community? It can easily be ten years.
There are lot's of organizations that are not going to wait ten years. And we still have to wait for the language to be designed in the first place to suggest that waiting might be an option.
And 10 years from now, the people who have running Rust code are no going to switch to a language that is similar to Rust but may have a slightly better syntax or otherwise be closer to C.
you said, 'Rust, though large, is in some sense quite minimal. Lot's of features in Rust are actually needed to allow x'
this logically entails that x is not possible without those features. if x is possible without them, they are not actually needed to allow x. so, although you hadn't noticed, you were saying a lot about what is and isn't possible
there are lots of organizations still using cobol, and people who have running cobol are not in any hurry to switch, either. but i have the luxury of not having to care
Obviously Rust has some features, like async, that are not needed for 'C with safety'.
But in my experience you need most of the other features. So any 'C with safety' will have a lot of the complexity of Rust. Though of course the syntax and defaults may be different.
At some point it becomes very subjective. Does a language need a UTF-8 string type, or is an array of 8-bit characters enough?
The research question would be, what is a minimal subset of Rust that still allows for programs that are commonly written in C to be easily written in this subset.
Some things, like the tuple type, or 'if let' can be removed, but is it still convenient to write programs without them? Closures are a bit tricky to see if they can be removed.
In any case, C struck a very good balance between being small and powerful. In my opinion Rust strikes a similar balance. Rust is a lot bigger, but it gives powerful tools to write reliable code.
it is impossible for you to have experience with better alternatives that haven't been invented yet; they are unlikely to look like subsets of rust. c is not a subset of pl/1
Indeed, I don't. But languages can be compared based on features. Even a language that doesn't exist can be described based on what features it needs to have. I'm not an expert in type systems, but there is a huge amount of research in how type systems can be described, what features you need to make a type system safe, etc.
If we compare C and PL/I then obviously the syntax differences between C and PL/I are mostly based on the taste of the language designer. But there are a lot of features in PL/I that simply have no equivalent in the C language. Either because when C was design they no longer needed to be in the language or because the features are move to the standard library.
In particular I/O is something that lots of language have as part of the language and C doesn't. So it is in many ways obvious why C a lot smaller than PL/I without losing any power.
But now we go in the opposite direction. We know what the safety outcome should be. So we can make a list of things that need to be in a 'C with safety', even if we cannot predict what the exact syntax will look like.
safety isn't achieved by adding capabilities, but by omitting capabilities. the hard part is how to avoid omitting necessary capabilities
> In particular I/O is something that lots of language have as part of the language and C doesn't. So it is in many ways obvious why C a lot smaller than PL/I without losing any power.
There are lot's of organizations that are not going to wait ten years. And we still have to wait for the language to be designed in the first place to suggest that waiting might be an option.
And 10 years from now, the people who have running Rust code are no going to switch to a language that is similar to Rust but may have a slightly better syntax or otherwise be closer to C.