> often ignoring that their favorite language's libraries/runtime/compilers/vm is most likely implemented in the very same languages they are putting down
I don't see how that's an argument against a language being "superior to C or C++". You can't create a self-hosting compiler for your language without having already created a non-self-hosting compiler for your language. That means every language is going to have to be "bootstrapped" in terms of something else first. C is the usual candidate just because there are a plethora of useful compiler/runtime/vm-ish libraries people like to rely on for "language prototyping" that expose C bindings—and there are very few other languages than C/C++ that have zero-overhead, zero-friction C binding support.
Rust is one of those languages—and it does indeed look like things are going in the direction of new languages getting prototyped/bootstrapped with a Rust compiler/runtime/vm instead.
> Rust is one of those languages—and it does indeed look like things are going in the direction of new languages getting prototyped/bootstrapped with a Rust compiler/runtime/vm instead.
I'm curious what examples you have in mind here? LLVM seems to be the default go-to compiler infrastructure, at the moment.
I don't see how that's an argument against a language being "superior to C or C++". You can't create a self-hosting compiler for your language without having already created a non-self-hosting compiler for your language. That means every language is going to have to be "bootstrapped" in terms of something else first. C is the usual candidate just because there are a plethora of useful compiler/runtime/vm-ish libraries people like to rely on for "language prototyping" that expose C bindings—and there are very few other languages than C/C++ that have zero-overhead, zero-friction C binding support.
Rust is one of those languages—and it does indeed look like things are going in the direction of new languages getting prototyped/bootstrapped with a Rust compiler/runtime/vm instead.