It has been done, you just weren't paying attention.
Burroughs B5500 was written in ESPOL, an Algol dialect for systems programming, later improved as NEWP.
This is still sold by Unisys as ClearPath MCP mainframes.
Xerox PARC initially used BCPL, but then created Mesa, used to develop their Xerox Star workstations, which then evolved into Mesa/Cedar.
The Solo operating system was written in Concurrent Pascal for the PDP 11/45.
IBM did all their RISC research using PL/8, a safe systems programming language based on PL/I with an architecture that you would find nowadays on LLVM. They only adopted C for RISC when they decided to bet on UNIX workstations as means to sell their RISC research.
UCSD Pascal OS System was a mix of interpreted and AOT compiled environment, later adopted by Western Digitial for some of its firmware.
Apple designed Object Pascal with input from Wirth, implementing Lisa and Mac OS on a mix of Assembly and Object Pascal, later switching to C++ as means to make the platform more appealing to other developers.
None of IBM mainframes were developed in C, rather a mix of Assembly, PL/S, PL/8. They only started to move into C and C++ as POSIX compatibility on those mainframes became a selling point as well.
There are plenty of other examples available.
Backwards compatibility, lack of actual research on most companies with eyes only on short term profits, UNIX clones available for free, managers not willing to bet on the team even if it is an up-hill battle, there are plenty of reasons why we aren't still there, most of them not technical.
There are alternatives to UNIX's design, hence why POSIX has been loosing relevance all these years.
On Apple platforms, Swift is the future even if it takes a couple of years to reach there, that is clearly the way Apple sees it.
"Swift is a successor to both the C and Objective-C languages."
Even on NeXTSTEP, drivers were written in Objective-C, and UNIX compatibility was a way to embrace UNIX software then extend it with Foundation code.
On Google platforms, the fact that the underlying kernel is an UNIX clone is irrelevant, the Web platform, Android Runtime or the NDK APIs don't expose any of it on the official APIs.
On Windows, C is considered done and the future for systems programing on the platform is a mix of C++ and .NET Native.
Many embedded vendors do sell Basic, Pascal, Oberon, Java and Ada bare metal compilers.
It is slowly getting there, we just need a couple of developer generations to get it back on track.
I'm well aware of many of the above systems. You may have missed the part where I specified "mass-market" though, right at the start. Perhaps you weren't paying attention.
UNIX itself predates POSIX by a large margin and early versions were written in assembly, not C.
I'm talking about the bulk of modern commodity desktop and web application development, which is really the lion's share of modern software development. This overwhelmingly occurs on and for workstations running Linux/Windows/BSD, all derived from C, with large parts of the userland still written in C code, or in languages which were bootstrapped from C, depend on C, or depend on a thin language-specific wrappers around existing C libraries.
Many if not most of the popular languages supported by LLVM have a frontend written in C/C++.
Sure these languages can become self-hosted, eg. Rust (albeit dependent on LLVM, written in C/C++), or Golang.
But I posit that until large parts of these systems (kernel _and_ userland) and the extensive collection of C libraries which are used for application development today are rewritten or replaced, you will not see the huge paradigm shift in commodity application development you are describing. I think it's going to take longer than that. I am not as optimistic as you. Stakeholders, programmers and product managers alike tend to favour the path of least resistance.
C is the lingua franca of these existing systems, and forms the common basis around which multiple higher-level languages currently wrap and leverage.
Which new common denominator is going to take its place? LLVM bytecode? Are we going to rewrite libz/libpng in each new language-of-the-week instead?
This is even before getting into embedded, where C is still king, C++ is really only starting to become more popular over the last 10 years or so, and Rust is barely a blip on the radar. Linux's popularity growth in this area is phenomenal, unmatched by any other as well.
On IBM and Unisys mainframes the common denominator is the "language environment", the intermediate format that has allowed them to evolve all these years since the 60's.
On Windows the common denominator are COM and .NET, with COM upgraded to UWP on recent versions.
On Android the common denominator is Dalvik bytecode.
On macOS/iOS the common denominator could be indeed LLVM bitcode, depending on how much Apple would like to deviate from upstream to make their own toolchain actually hardware independent.
Natural Linux's popularity has sky rocketed, UNIX's path to success and its clones, has always been free beer, which tastes even better when it comes with source code.
I am optimistic, but I am also aware it won't happen on my lifetime, changing mentalities requires changing generations, one person at a time.
Z/OS is written in, amongst other things, in C/C++.
.NET is implemented in C/C++.
Dalvik is written in C. And the specification allows for calling into unmanaged code via JNI, mostly for performance reasons.
LLVM is written in C/C++.
Windows, MacOS, Android/Linux kernels are all written in C.
The Swift, Rust, Objective-C communities et al should put their money where their mouth is after all these years, and provide feasible replacements for just _one_ of these consumer systems.
Otherwise it comes off at worst as grandstanding, at best, navel gazing.
Where is the consumer ready Rust replacement for LLVM?
Where is the consumer ready Obj-C replacement for Dalvik?
Where is the consumer ready operating system kernel based on .NET?
Where is the consumer ready Swift library of high performance video codecs?
These languages need some sort of flagship IMHO if they are ever to displace C/C++. Developer mindshare is important to getting critical mass and these languages are fighting each other for it, while C/C++ is still sort of sitting by eating their lunch and getting shit done.
C++ although tainted by copy-paste compatibility with C89, does offer the language features for security conscious developers to make use of, and C++17 is quite a pleasure to use.
C on the other hand could be nuked for what I care, it has been clear since 1979 that security and C would never go together.
Now regarding your assertions.
z/OS was initially written in a mix of Assembly and PL/I. C and C++ came later into the picture as the system got a POSIX personality.
The way to write libraries exposed to all languages available on z/OS is via the z/OS Language Environment.
Even so, the C# and VB.NET compilers have been bootstrapped thanks to Rosylin and now C++ is gone from the compiler side. F# was bootstrapped from the early days.
Since Roslyn came into production, the .NET team started planning moving parts of the runtime from C++ to C#.
"So, in my view, the primary trend is moving our existing C++ codebase to C#. It makes us so much more efficient and enables a broader set of .NET developers to reason about the base platform more easily and also contribute."
Unity introduced HPC# at GDC 2018 and they are now in the process of migrating C++ engine code into HPC#.
Both the requirements of HPC# as C# subset for performance critical code, as the experience with Singularity and Midori drove the design of C# 7.x features regarding low level GC free data structure management.
Dalvik was written in C++ and is dead since Android 5.0.
ART was written in a mix of Java and C++ between Android 5 and 6 as AOT compiler at installation time.
It was rebooted for Android 7, where it is now a mix of an interpreter written in highly optimized Assembly, with JIT/AOT compilers written in a mix of Java and C++, making use of PGO data.
On Android Things, userspace device drivers are written in Java.
Oracle is also in the process of following JikesRVM example, and with the help of Graal, bootstrap Java thus reducing the dependency on C++, via the Project Metropolis.
LLVM is written in C++. Yes it does expose a C API, but it also has bindings for other languages.
At WWDC 2017, Apple announced that launchd and the dock were rewritten in Swift. I expect other OS components to be announced at this years' WWDC.
Windows kernel was written in C. Since Windows 8, C++ is officially supported on the kernel and given the company's stance on usefulness of C, they have been migrating the code to compile as C++.
"We do not plan to support ISO C features that are not part of either C90 or ISO C++"
Thank you for the long list of examples. I think some of them are a little fringe and fall outside the scope of my argument (eg. Sun literally "toying" with Java device drivers, or Microsoft compiling their C code with a C++ compiler), and you haven't refuted my point that the kernels of the most popular systems are still written in C for the most part.
Listing endless reams of discontinued research systems (eg. Singularity and Midori) isn't reinforcing your point.
Redox (Rust) and Zircon (C++) are more what I'm alluding to.
However Redox AFAIK doesn't even have USB drivers yet and Fuschia is even less useful in its current state. These systems have to be available, and I venture, usable, in order to be able to displace eg. Linux which is already both of those things.
I'm hopeful we can see more progress in the next few years on some of these. It's nice to see some serious attempts in this space, however with the current pervasiveness of and dependencies on C at so many layers of these systems, I suspect it is really going to take much longer than hoped.
Singularity and Midori were killed by political reasons, you just need to see Joe Duffy stories about how it all went down.
However .NET AOT compilation on Windows 8 was taken from Singularity Bartok's compiler, while Midori influenced async/await, TPL, improved references on C# 7.x and .NET Native on UWP.
I guess you missed my "As I mentioned, change requires replacing generations one person at a time.".
So yeah, it is going to take awhile until all those devs and managers that are religiously against safe systems programming are gone, replaced by newer generations with more open mind.
The only way to convince Luddites is to wait for change of generations, unfortunately also means one doesn't get to see change him/herself.
Burroughs B5500 was written in ESPOL, an Algol dialect for systems programming, later improved as NEWP.
This is still sold by Unisys as ClearPath MCP mainframes.
Xerox PARC initially used BCPL, but then created Mesa, used to develop their Xerox Star workstations, which then evolved into Mesa/Cedar.
The Solo operating system was written in Concurrent Pascal for the PDP 11/45.
IBM did all their RISC research using PL/8, a safe systems programming language based on PL/I with an architecture that you would find nowadays on LLVM. They only adopted C for RISC when they decided to bet on UNIX workstations as means to sell their RISC research.
UCSD Pascal OS System was a mix of interpreted and AOT compiled environment, later adopted by Western Digitial for some of its firmware.
Apple designed Object Pascal with input from Wirth, implementing Lisa and Mac OS on a mix of Assembly and Object Pascal, later switching to C++ as means to make the platform more appealing to other developers.
None of IBM mainframes were developed in C, rather a mix of Assembly, PL/S, PL/8. They only started to move into C and C++ as POSIX compatibility on those mainframes became a selling point as well.
There are plenty of other examples available.
Backwards compatibility, lack of actual research on most companies with eyes only on short term profits, UNIX clones available for free, managers not willing to bet on the team even if it is an up-hill battle, there are plenty of reasons why we aren't still there, most of them not technical.
There are alternatives to UNIX's design, hence why POSIX has been loosing relevance all these years.
On Apple platforms, Swift is the future even if it takes a couple of years to reach there, that is clearly the way Apple sees it.
"Swift is a successor to both the C and Objective-C languages."
-- https://developer.apple.com/swift/
Even on NeXTSTEP, drivers were written in Objective-C, and UNIX compatibility was a way to embrace UNIX software then extend it with Foundation code.
On Google platforms, the fact that the underlying kernel is an UNIX clone is irrelevant, the Web platform, Android Runtime or the NDK APIs don't expose any of it on the official APIs.
On Windows, C is considered done and the future for systems programing on the platform is a mix of C++ and .NET Native.
Many embedded vendors do sell Basic, Pascal, Oberon, Java and Ada bare metal compilers.
It is slowly getting there, we just need a couple of developer generations to get it back on track.