Lol if you don't know who Mark is and his real world experience particularly developing critical and low level windows tools. I think it's safe to say his opinion on the language and its use with Microsoft/Windows is very relevant.
As he appears to have been wholly concerned with details of Microsoft's walled garden, I would not have heard of him. It seems like his opinions today involve only Microsoft's internal management of its hosting products, which nobody outside Microsoft can know much about.
Maybe he thinks Azure should standardize on one of Go/Rust, Java/C#, or Haskell/OCaml for managing its hosting service. He is apparently in a position to enforce his opinion on the division. It is hard to know how anybody outside will be able to tell which he has chosen without his announcing it: "Azure has designated Haskell/Ocaml as its preferred language for hosting management utilities."
Microsoft is no stranger to C-suite fads in software development. Back in the 90s each lasted about 2 years. The constant has always been that bugs have never had any detectable effect on company revenues.
What other people are saying about it being a shorthand for similar languages, but also...
C/C++ is a coherent thing to write a single program in. You write some files with a .c extension and compile with gcc, some with c++ and compile with g++, and as long as you're careful in your header files everything works out just fine. People have actually done this, and because C isn't a subset you end up with C files that you can't compile as C++ and you really do have a heterogeneous project.
Nobody is talking about one language named "C/C++". It's a shorthand for two languages that are closely related at the abstract machine level, and in terms of co-existing compiler frontends.
Then you might as well talk about "C/Rust". Both go to LLVM. But nobody says it, because it would be BS in exactly the same way "C/C++" is.
What matters about a language as a technology, as in the context of this Mark guy's blurb, is how it works in use. There, C and C++ share hardly anything in common: what you do writing good code in one is nothing at all like what you do with the other.
You might get a C program compiled with a C++ compiler, but it would be utterly crappy code, considered as C++.
So, "C/C++" is an inherently dishonest construction. Anybody using it for a context outside of, say, ELF formats or peephole optimization is promoting a lie.
Lying says more about the speaker than about the supposed topic.
LLVM is not a compiler frontend. It’s the middle- and back-ends; Clang is the frontend.
Neither Rust nor C is inextricably linked to LLVM either, as I’m sure you’re aware. And the former doesn’t align with the abstract machine assumed by the latter in important regards, like forward progress.
The rest of this is just a screed. I’m not here to defend his honor, and you shouldn’t waste your time posting about it on random sites on the Internet.
