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

What Hacker News said

Recommends chubot · 2017-09 · on “Some Were Meant for C: The Endurance of an Unmanageable Language [pdf]”

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

Recommends shepmaster · 2020-01 · on “Blogging about Midori (2015)”

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.

Cites pjmlp · 2017-12 · on “Re: Moving from PHP to Go and Back Again”

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

Cites Promarged · 2018-01 · on “Google’s Fuchsia OS on the Pixelbook: It Works It Actually Works”

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]: [this 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

Cites pjmlp · 2018-03 · on “D on embedded Linux (ARM)”

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

Cites pjmlp · 2018-05 · on “The Evolution of C Programming Practices: A Study of Unix (2016) [pdf]”

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, r

Cites pjmlp · 2018-10 · on “A History of .NET Runtimes”

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" [this video] Sorry a bit lazy to track down the exact moment.

Cites pjmlp · 2021-07 · on “A Look into CBL-Mariner, Microsoft’s Internal Linux Distribution”

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,