Confreaks
2 HN recommenders · recommended in 14 months, 2017–2025
42:45 · 2.5K views · Sep 1, 2017
Joe Duffy's RustConf 2017 closing keynote on his experience at Microsoft building Midori, an operating system written in a Rust-like safe systems language. He covers the technical and cultural challenges of applying those lessons to Windows.
HN repeatedly cites it for Midori lessons: compatibility matters for adoption, and the Windows team stayed sceptical even with Midori running real workloads.
14 comments from Hacker News
Related: "Safe Systems Software and the Future of Computing by Joe Duffy" at RustConf 2017. this 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: this 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.
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" - this 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
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
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