It almost seems like they forget what it means to compile to machine code.
I can say I have some sort emotional attachment to python, but I can't deny that C++ is just a more capable language, but at least I can admit that I'm just not always competent to always write C++.
Like most people say "just use the parts of C++ you need".
Many others don't even have the same insane "features".
Just a couple of possible languages, there are many more if we take out the good support constraint.
I don't see good enough alternatives to C++, which have enough support, not a steep learning curve, good backward compatibility with existing ecosystems, not owned by a single company, etc.
> not a steep learning curve
well, it's steeper than most languages, but less so than C++ IMO, especially if you're already familiar with C++ and therefore understand the problems Rust is intended to solve.
Still ,there aren't that many languages that compile to native.
My point is that maybe most of those languages are not suitable, and that nobody really like those languages. Just cross all the arguments I gave about those languages, how they score, etc: C/C++ are the most used language that compiles to native and it gets criticized.
"There are languages people complain about, and languages people nobody uses" Meaning we only complain about language we use.
If having a GC makes a language not native, then C++ isn't a native language as well.
ISO C++11 introduced the GC API, C++/CLI and C++/CX dialects use a GC, Unreal C++ has a GC, regular C++ with Boehm GC is another option, C++ Builder has also a GC.
ISO C++ is basically driven by Microsoft, Google, Apple, IBM, given the amount of employees that go to ISO meetings and submit papers.
While it isn't a single corporation, it isn't a community driven process either.
Who can put money on ISO get the features.
This is standard in C (and allegedly C++ and rust), awkward but somewhat doable in Java, C#, and some of the weaker LISPs, damn near impossible in Haskell, Javascript, etc, and completely impossible in "real" LISPs (with first-class macros and/or fexprs).
It's obviously always possible to "compile" a (interpreter,somewhat-preprocessed-program) tuple for any language (give or take turing-hard/easy-ness) and you can usually inline/specialize/optimise the interpreter a lot for one particular program (Haskell/ghc is a good example of this), but that's not what people mean when they talk about designing a language to compile to machine code.