C is light but it does have some things worth breaking IMO. Type inference is something I dearly miss when I write C these days (and I do that a lot). C didn't have any generic programing for a long time (if you don't count macro soup, that is), now it has some very limited support but it still looks like banging rocks together compared to more modern languages.
C's unsafety is legendary, and segfaults a common problem even for experienced programmers. Rust's lifetimes makes them impossible by design for safe code.
You may not like that of course, but those are all good reasons for experimenting with other paradigms.
>Arguably, the preprocessor is orthogonal to the programming language itself. I fail to see how that's relevant.
Arguably it is, practically it very much isn't.
That's a pretty awesome place to be, as C++ is one of the most successful programming languages in history.
Perhaps there are lessons there.
> or you're willing to break things and then why not take the opportunity to improve the syntax and get rid of the cruft?
Break things just for the hell of it is not much of a tech argument.
C is already pretty light, and already gave origin to successful programming languages such as C++ and Objective C. Unless you find a compelling reason to break backward compatibility in a very specific way, I don't see how that argument makes any sense.
> An other big problem with C interop for newer languages is that while C itself is relatively small and easy the C preprocessor isn't.
Arguably, the preprocessor is orthogonal to the programming language itself. I fail to see how that's relevant.