RustConf 2017 - Closing Keynote: Safe Systems Software and the Future of Computing by Joe Duffy

Related: "Safe Systems Software and the Future of Computing by Joe Duffy" at RustConf 2017. [VIDEO] I summarized this excellent talk here [1], but one of the main points is that compatibility with existing systems is important for adoption. (They learned that the hard way -- by having their entire project cancelled and almost everything thrown out.) He advocates unit-by-unit rewrites rather than big-bang rewrites, just like Kell does in this conference article. And compatibility with C in Windows should be easier than it is in the Unix world, because the whole OS is architected around a binary protocol AFAIK -- COM. My sense is that Rust may not have thought enough about compatibility early in its life. Only later when they ran into adoption problems did they start talking more about compatibility. Also, it seems Rust competes more with C++ than C, and there seems to be very little attempt to be compatible with C++ (although perhaps that problem is intractable.) Personally I don't think Rust will be a successful C replacement. It will have some adoption, but the Linux kernel will still be running on bajillions of devices 10 years from now, written in C. And in 20 years, something else will come along to replace either C or Linux, but that thing won't involve Rust. [1] [LINK]

See also "Safe Systems Software and the Future of Computing" by Joe Duffy, the closing keynote at RustConf 2017: [VIDEO] Midori and Rust have several striking similarities, and Microsoft's recent uptick in interest in Rust (and Rust-like languages) bodes well for improved software quality.

It doesn't matter what Rob Pike says regarding Go and systems programming, because Google, the company that employs him, has decided Go makes sense to write system components of Fucshia in Go. That is a fact, easily validated in Fuchsia's repository. According to you, Rob Pike should call management and let them know it is not a good idea to use Go for writing Fuchsia's TCP/IP stack. You only read Joe's blog years ago, yet you missed the talks he gave. Two years ago is not that long time ago, [LINK] "My biggest regret is that we didn’t OSS it from the start, where the meritocracy of the Internet could judge its pieces appropriately. As with all big corporations, decisions around the destiny of Midori’s core technology weren’t entirely technology-driven, and sadly, not even entirely business-driven. But therein lies some important lessons too." [LINK] "Over the course of 8 years, we were able to significantly narrow the gap between our version of C# and classical C/C++ systems, to the point where basic code quality, in both size of speed dimensions, was seldom the deciding factor when comparing Midori’s performance to existing workloads. In fact, something counter-intuitive happened. The ability to co-design the language, runtime, frameworks, operating system, and the compiler – making tradeoffs in one area to gain advantages in other areas – gave the compiler far more symbolic information than it ever had before about the program’s semantics and, so, I dare say, was able to e

I don't know why but I'm actually less excited about Fuchsia than the old Singularity/Midori. As Joe Duffy said [0] when they worked on Midori they also wrote UI, editors, browsers and many more applications in months so it's not surprising Google engineers also managed that. [0]: [VIDEO] For me it looks like the classic Not Invented Here syndrome - we already have microkernels, even formally verified ones (seL4) but AFAIK Google didn't want that to "be more flexible". Using C for kernel also looks like a poor choice nowadays, unless Google has some magic static analysis (for example Singularity/Midori had custom languages with ownership tracking akin to Rust). Maybe Fuchsia is for bringing microkernel architecture for masses using "boring technology"?

It has been proven multiple times, at Xerox PARC, ETHZ, DEC Olivetti, Microsoft that garbage collection systems programming languages are doable. However technology adoption always needs to fight against non-believers. Joe Duffy has stated on his Rustconf 2017 presentation [0] that even Midori running on front for their eyes, with some use cases where System C# was even shoulder-with-shoulder with C++ [1], that Windows devteam was not getting it. Nowadays he is an happy Go coder instead of trying to convince them otherwise. D has a big problem with their GC implementation, which provides good arguments for the anti-GC crowd in systems programming. However they have been improving it quite a bit during the latest releases, as well as, making the runtime library more @nogc friendly. As for reaching mainstream, I share your thoughts. It is not only Rust and Go. There is also Swift, C++17 and the ongoing improvements to make Java and C# more machine friendly (memory management and AOT compilation). Still, even if just a small group gets to use it, it is already a victory. Most languages never achieve it. [0] - [VIDEO] [1] - [LINK]

First of all, there is no such language as C/C++. 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. Chapter 9.12 of z/OS Basics, [LINK] .NET has hardly any pure C code, rather C++. 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." [LINK] Also the first version of .NET's GC was actually prototyped in Common Lisp, [LINK] 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 wi

At RustConf 2017 keynote presented by Joe Duffy regarding Midori at a certain moment, he mentions that even with Midori running in front of them, WinDev guys were still not open to the idea of such kind of system being possible. "Safe Systems Software and the Future of Computing" [VIDEO] Sorry a bit lazy to track down the exact moment.

To fully get where I am coming from, you have to go back to when .NET was released. .NET was supposed to be the great reunification of VB, C++ and COM runtimes, then also got a Java touch into the mix and .NET happenend (initially was known as Ext-VOS). [LINK] Hence why CLR is just like WASM + GC if you prefer a modern comparisasion. If you go back into web archives, when Visual Studio.NET was released, it was going to be .NET everywhere, across the whole stack. However a big management mistake happened, .NET was part of DevTools business unit, while C++ was kept under WinDev, up until Satya started to change the culture, it has been pretty much WinDev vs DevTools. So Managed DirectX comes, eventually gets killed, XNA and Silverlight take over Windows Phone 7, get killed by WinRT and DirectXTK and so on. Going back to the originally statement, if you Google for why Longhorn did not work out, you will find many .NET blaming. [LINK] Yet Android, ChromeOS, Midori are examples of what happens when actually everyone works into the same direction bringing an OS into production. Joe Duffy does some remarks on his two talks, where he hints at why it was a failure to fight Windows culture "Systems Programming in C# " - [LINK] "Safe Systems Software and the Future of Computing" - [VIDEO] Note that for some time the Asian Bing nodes were actually running on top of Midori as production test. A big decision of Vista, was to replicate the .NET design using COM instead (hello WinDev), hence