Illustrates why projects don't do this:
> If you're breaking backwards compatibility anyway, why not go all the way?
Rust usage, even with millions of dollars of marketing and eleven years of hype, is still almost a rounding error in terms of usage.
Within the tiny set of scenarios where Rust is applicable as of now, isn't it completely dominating?
It's dominating in hype and excitement for toy and pet projects. This is just the first few steps. Too few people have dabbled enough yet.
The next step is enough stability/maturity that more open source and maybe fang infrastructure can use it. And when the reasoning behind this becomes widely digested, most "green field" projects will choose Rust.
But that may be ten years away?
But that's not the right comparison. The use of the C language itself is a rounding error compared to all the languages that replaced it. Java, C#, C++, Python, Javascript, Go, they all replaced most use cases of C in modern programming. Rust is just attacking the last vestiges of C's usefulness.
One tiny hobby language I use was changed to accept semicolons as an additional end-of-line, just to allow more easy copy-pasting of C code. It's surprising how portable C is in that sense too. If you're going C-style, probably best to stick C-style. (But I used fn in my own C-alike... who am I to judge?)
I agree there is a need for easy transition, but I think that ease mostly comes from being able to be compiled and linked in existing tool chains like this project does.
I wrote a C compiler as well, got as far as compiling a hello world and all the includes it needs on a standard Linux or MacOS system. My plan was to have a sort of strict option that would be enabled if you wanted to use the new features like modules and namespaces, and the strict option would error on problematic C code.
Anyway I stopped the project when Rust released their first version without garbage collection. It seems to me they solved all my concerns and they didn't even need to integrate C itself.