You could argue that it's what these languages do, the C heritage is very strong in every one of them.
The problem is: do you want to maintain full backcompat or are you willing to break things to do it cleanly? If you do the former you end up with something like C++ which retains almost complete compatibility with C (but they you have a lot of baggage to carry around, which may get in the way at times) or you're willing to break things and then why not take the opportunity to improve the syntax and get rid of the cruft?
C is ancient now, its type system and its many quirks are quite far from the state of the art or language design, a modern language wouldn't have to mess with the nonsense that are, for instance, C arrays (including C++ which can't outright remove them but does everything it can to render them obsolete with std::vector and std::array).
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. That's usually where the friction is, because if you want to maintain compatibility with C macros you have to choice but to implement the language syntax wholesale.
In retrospective, the aversion of Go designers to current practices in other programming languages is quite similar to the aversion of them back when designing C, versus the other system programming languages that were being developed since 1961, like ESPOL, NEWP, PL/I, PL/S, BLISS.
> If you do the former you end up with something like C++
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.
C++ is hugely successful, that's true, but is there a need for an other C++-style language? C++ already feels like 10 languages under a trenchcoat anyway, whatever your style you'll probably find a subset of it you'll like. I think it showed how powerful "C-with-classes-and-the-kitchensink" can be, and also the limits of the concept.
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.
The problem is: do you want to maintain full backcompat or are you willing to break things to do it cleanly? If you do the former you end up with something like C++ which retains almost complete compatibility with C (but they you have a lot of baggage to carry around, which may get in the way at times) or you're willing to break things and then why not take the opportunity to improve the syntax and get rid of the cruft?
C is ancient now, its type system and its many quirks are quite far from the state of the art or language design, a modern language wouldn't have to mess with the nonsense that are, for instance, C arrays (including C++ which can't outright remove them but does everything it can to render them obsolete with std::vector and std::array).
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. That's usually where the friction is, because if you want to maintain compatibility with C macros you have to choice but to implement the language syntax wholesale.