Also, as a note, high-reliability microkernels disallow direct access to DMA registers (as, absent an I/O MMU, being able to write to a DMA register is the same as being able to write to any physical memory), and instead provide an API for programming them that can be verified on its own. This is often just dozens of lines of code, so can be as correct as the hardware.
So the separation of register-bashing vs. the rest of the software already exists, but it solves the memory safety problem by just moving the unsafe code out of the kernel.
I agree that memory-safe languages need to come into low-level systems programming, but garbage-collection is a non-starter for many many reasons, and the various academic languages (e.g. cyclone) have not made any inroads to industry that I'm aware of.
Rust is very interesting to me in this field because the simple fact that it originated outside of academia may make it more palatable to many people; time will tell.
[edit]
I still think a microkernel is a good idea even with a memory-safe language just for defense in depth if nothing else (memory-safe runtimes tend to be complicated, and complicated code tends to have bugs).
> I agree that memory-safe languages need to come into low-level systems programming, but garbage-collection is a non-starter for many many reasons, and the various academic languages (e.g. cyclone) have not made any inroads to industry that I'm aware of.
Yet it was proven to work with:
- Mesa/Cedar at Xerox PARC
- Oberon, Oberon-2, Active Oberon at ETHZ
- Modula-2+, Modula-3 at DEC/Olivetti
- Sing# and System C# at MSR
Apparently we can only get it properly done if a big company bullies the developers to adopt such an approach.
Which is why I see as positive Apple, Google, Microsoft bullying devs to use mostly Swift, Java/Kotlin/Dart and .NET on their platforms, with C and C++'s role reduced to a few use cases.
It really annoys me when I need to use the NDK on Google's case, but somehow it makes sense from security point of view.
> Which is why I see as positive Apple, Google, Microsoft bullying devs to use mostly Swift, Java/Kotlin/Dart and .NET on their platforms, with C and C++'s role reduced to a few use cases.
Microsoft is actively encouraging developers to use C++ for development on Windows. The phase when Microsoft was trying to push (or as you call it "bully") developers into ".net for everything" is long gone.
Since October 2016 there is radio silence on the actual state of C++/WinRT, including the status of feature parity with C++/CX for XAML, Blend and creation of UWP components.
VS 2017 already had two releases since those presentations.
The only Microsoft talk at CppCon 2017 are about VS Code support for C++ and ANSI C++ compliance, nothing relevant to actual Windows 10 application development.
Any long time Windows developer is recognising the signs that UWP is turning into what Longhorn aspired to be, just remains to be seen how willing Microsoft is to keep pushing it.
So while Swift might not be yet there, if Apple tomorrow releases a system that according to those statements, the only available SDK language is Swift, anyone that wants to be on that system will use Swift, regardless how serious challenger it might be.
As another example, are you aware that Brillo was supposed to be a pure C++ based variant of Android, before they pivoted it into Android Things? Now you can even write user space device drivers in Java.
Microsoft has also adding been adding low level features of System C# into C# roadmap, and UWP model (which they really want to be the future) only uses .NET Native. How far they will push it, who knows.
Windows 10 has a new UI composition engine, naturally it is programmed in DirectX with C++, however all the APIs are exposed as UWP projections and so far, every single demo I have seen used C#.
The big difference between OS companies and the FOSS world regarding systems programming, is that regardless how we think a given language is fitted for a given purpose, they can make it into the only door to the system.
But you are right they are clearly not yet there, and it remains to be seen how far they would actually bully devs into using only those languages.
So the separation of register-bashing vs. the rest of the software already exists, but it solves the memory safety problem by just moving the unsafe code out of the kernel.
I agree that memory-safe languages need to come into low-level systems programming, but garbage-collection is a non-starter for many many reasons, and the various academic languages (e.g. cyclone) have not made any inroads to industry that I'm aware of.
Rust is very interesting to me in this field because the simple fact that it originated outside of academia may make it more palatable to many people; time will tell.
[edit]
I still think a microkernel is a good idea even with a memory-safe language just for defense in depth if nothing else (memory-safe runtimes tend to be complicated, and complicated code tends to have bugs).