 Super happy to be here very lofty title. So I hope that I don't disappoint So for those of you who don't know me. I most recently worked in Microsoft I was in charge of the languages and compilers and IDE and taking dot-net open source and and cross platform and all those sorts of things I was actually there for 12 years a significant amount of the time was actually working on safe system software Not to cut to the chase too much, but to cut to the chase you probably Haven't seen much about it because we actually didn't ship it and so that's actually part of the story So I left Microsoft in September To do a startup. So I'm currently CEO of Pulumi in Seattle and we're a cloud startup Currently stealth mode, but hoping to change that pretty soon So I'm gonna tell you a story and I'm hope hoping this story doesn't depress you too much The goal is to learn from the story. I sort of went through this And emerge stronger than before and I'm hoping that I can share some of the key lessons And then talk a little bit about why I think Some of what everybody in this room is doing and something some of what we were doing really tells us where the future of Computing is going in particular for system software and that's a pretty broad topic pretty broad scope System software, but I'll try to break that down a little bit as well And so first the story So myself my background when I was at Microsoft basically throughout the entire 2000s I was in charge of sort of threading concurrency Primitives for for net some of C++ So as soon as you know, the the Moore's Law is over sort of panic set in You know, we were working closely with Intel to come up with new technologies to solve that software. So that included Pretty basic things like introducing thread pools and better ways of introducing concurrency Better synchronization primitives pretty basic stuff that people take for granted these days Some exotic things like software transactional memory So we actually had a version of the CLR with STM built into it turns out, you know that never ship but something like eight nine ten years left after that Speculative lock-a-lision in processors and some of the HLE instructions started showing up And maybe most lasting during that era was coming up with a task parallelism and better data parallelism primitives that today Are sort of the underpinning of async and await as you see them in C sharp And so back then we were working with, you know, the F sharp team who is really the one of the earliest pioneers of doing async Await and trying to get those ideas into C sharp and that eventually panned out But notably absent during this period was anything about safety There's a little bit of message passing so you could say that was absent as well But really the biggest thing was safety we tried the software transactional memory But it turns out that was the wrong solution to the wrong problem But the whole beauty of STM was you could slap an atomic block around a big honkin piece of code and not worry about what it Does it turns out that doesn't work in practice because you end up with lock-intention in places that are completely bizarre that you didn't expect And so it turns out taking a step back and thinking about safety in an entirely different way was a better path forward And it's not that STM is bad, you know, it's definitely got its place But the fundamental architectural principles of isolation and safety were far more important And we sort of missed the point back then and partially it was because we were we were dealing with constraints We're trying to wedge this into existing systems like, you know windows The windows theme will recur So around the same time obviously, you know, this is a pretty abysmal situation It really hasn't gotten better over the years. In fact, it's gotten kind of worse You know every week you see the top of hacker news is like, oh some new buffer overrun and some new exploit some remote Code execution in some critical piece of software that literally the world depends on it's it Is kind of ridiculous that we're in 2017 in the situation has not gotten much better Thankfully, you know, we're all kind of jointly working on a solution to that But this was back then even back then where we're looking at hey security and windows is really terrible And it's a really bad PR thing and and this is back around the trustworthy computing initiatives If you remember that, you know Bill Gates is one of his top priorities And so this is top of mind as well And so you add those together and we're kind of like hey worse screwed. What do we do? You know windows had this antiquated threading model that didn't scale any of you that know calm single-threaded apartments You know threat affinity. There's so many kind of deeply rooted problems in the architecture That we were really running into a wall when multi-core arrived And of course the growing security threat, you know, what if it accelerated even further and this lack of safety at the very Fundamental heart of the system became a critical and fundamental weakness. What would we do? We really didn't have an answer and Furthermore, it is more of a windows sort of trivia thing, but I don't know There's like a hallway of the architecture of windows and the dependency diagram And it looks like somebody smeared spaghetti across like a 20-foot wall and that really inhibits the ability to innovate and And and you know if you don't have componentization, you don't have separation of concerns You can't have separate authors for these components and so we looked at this and You know, there are many promising alternatives furthermore, you know Kikos arrows coyotes these sort of more secure Capability-based operating systems had been around for a long time. We had been working on safe At least type in memory safe languages in you know, sort of the net space The I don't know if people remember the windows Vista experiment But you know cramming C-sharp into the heart of the operating system without anything more than just that turns out It's not a good approach But at least we had some experience with what that looked like And so that's when we came up with the idea. This is probably somewhere around 2006 2000 late 2006 to start an effort to build the new safe operating system from the ground up And so this was literally reuse no code To start an architect at the right way don't focus on you know Compatibility that's the big thing. I don't know if folks realize how big at Microsoft compatibility was You know a breaking change was just forbidden completely even if the only way that it was allowed was it was a security fix But people really took compatibility very seriously And so we were saying hey, no, it's greenfield we're gonna start from scratch and we'll see where it takes us and Really, this is an insurance policy. We didn't go in thinking. We're actually going to replace windows. We thought hey Worst case we could take some of the ideas and apply them to windows Best case we don't actually need it because it's an insurance policy And so we focused on these core concepts isolation And so singularity we actually took some of the singularity ideas to start with this is a project That came out of Microsoft research that use software isolation for Safety so it's actually building on the fact that it had type and memory safety at its core to actually have lightweight isolation And this is what's necessary especially compared to windows where they the process model is so terribly heavyweight. I think you know Windows thread Is roughly the cost of a unit or Linux process? And so you know Windows process is just enormously heavyweight and that discourages some of the message passing is sort of important architectures that we saw Capability based security both in the application model and the programming models who actually use the fact that we had type and memory safety to Actually embed capabilities into the programming model such that you know an object reference really is an unforgeable Token and so we actually used object references as essentially capabilities Similarly, there is no ambient authority. So there's no mutable statics. No thread local storage, etc error model You know comparing to win32 with return codes and some exceptions But mostly return codes and you know C sharp that had implicit any API can throw, you know Have no idea what it is. In fact, there's something called asynchronous exceptions So the the garbage collector can come in and like suspend your thread and injecting exception between arbitrary Instructions and so it's not even possible to know where all the errors can come from which I know that sounds Ridiculous it is And so we said no no all errors are going to be explicit and we will bet on fail fast in a big way So not just fail fast for you know unhandled errors, but fail fast for unexpected conditions like arithmetic overflow even out of memory and So What we ended up with was essentially free safety sort of working in harmony memory safety type safety and Concurrency safety for all code with the exception of essentially some very low-level, you know microkernel stuff that entered face with the hardware But 99% of the system was type memory and concurrency safe code So that was sort of the system architecture and so we got to you know writing lots of code and it turns out You know, we started using static analysis. We started from C sharp Why do we start from C sharp? Well, we're at Microsoft. So that's one reason and so, you know C sharp is a great line Which is very you know productive, but it definitely has some problems Like the fact that exceptions can permeate, you know or emanate from any instruction There are other problems too. It's garbage collected There's no way to do stack allocation. There's no notion of lifetime safety There's no notion of concurrency safety and so we essentially took C sharp and we started Changing it and the goal was really to You know, this is sort of a false bifurcation of the space but rough approximation, you know You tend to have you know performance and safety and productivity and they're often that you know odds with one another And so we're looking for the sweet spot where it was a safe and productive language while also being performant and What we did is we sort of went and looked, you know, I was familiar with a lot of the research in you know, sort of Advanced type systems. I'm a big Haskell fan So it basically dug around, you know I was aware, you know cyclone and all these, you know region based systems in the past and borrowing and effect types And we sort of took all those things and threw them into a blender along with C sharp and said, okay What what actually comes out and turns out what came out was something that was really a good Blend of some of the productivity you have in C sharp and the performance we needed and the safety we needed and it turns out You know, this this is all happening 2007-2008 somewhere around that time frame and It's funny because it's around the time frame that you know Some of the rust concepts started coming out and so I remember, you know We would compare notes with some of the early rust, you know folks and some early go folks and Folks in the research community and we ended up in a semi similar place. We even used ampersands for borrowing and then this happened and so You know, we had some wins and I'll talk about some of those wins later We were actually running this in production. So we're running the Microsoft speech server on this You know, so anytime you spoke into your Windows phone, which I'm sure a lot of people did You would actually hit Midori on the back end We'd be serving up requests in that that was massively parallel because I use deep neural networks and and it was using all safe parallelism and It replaced the existing 1 million lines of code C++ system that that had existed beforehand So better performance safety better productivity. I mean it was great And it turns out we were trying to figure out. Okay, so this experiment seems to be going well What are we going to do next and so? Things like this started happening, you know, the government actually came out and said hey You shouldn't be using Internet Explorer because it's just not safe It turns out a lot of these bugs in Internet Explorer were used after free bugs basically What would happen is you'd be on a thread you'd call out to some user code It would run the JavaScript it would call back into the the Engine and the engine would re-enter into some piece of code that wasn't expecting to be re-entered It would release some critical resource and then you unwind the code and the memory would be freed and game over And this happened all the time in Internet Explorer and it's partially the way they wrote the code But it's partially, you know, just a hard problem. There's a huge C and C++ code base. I should mention just as an aside Even though Windows and a lot of its components are C++ it's really C with classes And so it's not very modern C and so as we talk about some of the future improvements, that's something to keep in mind So We went to Windows So we actually moved the project into the Windows team and said, okay How do we actually make this thing happen? It turns out we bit off a lot there and we'll see the outcome wasn't wasn't awful But I think this starts to talk to some of the challenges that we have with just safe systems programming in particular essentially What we found was there are a lot of guys who have been and gals who have been programming C for the last, you know 30 years and Not only were unwilling to To adopt some of the C++ Things that would make their lives easier like smart pointers and everything and never mind some new fancy language That had this type in memory safety stuff like why do we need that right? We seem to be doing well without all those fancy things See see previous slide with the use after free bugs But that really is when you look at some of the Harriest code bases on the planet that really need this stuff It is human human challenges that are going to get in the way like hasn't anybody talked to Linus But whether he wants to replace parts of the Linux kernel with rust Good luck, and yet that's where we need to go So the outcome of this So I'll save you the the gory details of what it looked like in the end But essentially we ended up with lots of learning unfortunately not shared broadly Which is shame on us We should have been writing research papers the whole time if the project started in Microsoft of today it would have been open source That's a sort of a big change since when I was when I was there Or towards the end of my tenure there We did end up with some improvements to C sharp So we basically said okay Let's take this all the sets of things that we needed to change and dot net and C sharp and make you know Bring those back to C sharp so that it could be used for more systems II things It turns out you know got some nice performance wins Slices are coming out, which is basically the ability to take a subsection of an array without actually having to copy and allocate That's something that should have been there from day one, but wasn't Many of them still in the works We also launched a bunch of efforts to try to improve the state of affairs in C++. You probably hate me for that I kind of I have trouble sleeping with myself at night sometimes as well But some good things came out of it Like, you know better ways of writing C++ better tooling to enforce some of the safety things, you know Really with modern C++ you can stick to a safer subset With smart pointers and the team tried to define, you know sort of a borrowing like thing that would work with C++ references and smart pointers Some improvements in windows not as much as we had envisioned But it turns out all this happened around the same time that You know the government was coming to say don't use IE and so that that's actually what birthed this edge browser Which was this new rebranded thing But a lot of the core tech actually made its way into that as well with some associated safety wins So you didn't have these use after free issues of running rampant so I want to talk a little bit about some of the key lessons from from this overall experience Like I said, I hope not to be depressing. So let's get on to the inspiration and innovation part. So what what worked? Well surprisingly safety everywhere worked. I I thought that was the biggest bold bet that we're making I thought there was no chance it would work, you know, the idea of writing entire operating system With safe code just seemed crazy at the time Everybody else told us we were crazy What was particularly interesting is That you could actually have data parallelism because we had data race free ways of introducing parallelism This is nothing new to folks, you know using rust, but at the time this is pretty novel and There were productivity wins as a result of that, you know, just not having to worry about all the classical, you know Buffer overruns and standard things that just kill productivity and suck your time drive, you know debugging Just we're not present by construction where this phrase, you know, correct by construction Which was a little bit of a lie because, you know, it's not really correct by construction safe by construction But had a nice ring to it So the magical combination of isolation security capabilities and message passing was actually Really powerful actually you see this in Erlang and other, you know Even some some programming models that you don't even need to, you know, change the language like Aka for example It really, you know, most of the system was massively parallel because of this alone Our web browser for example, you would fire up a single page and it, you know behind the scenes of spawning 32 processes And so a lot of the things were exposing latent parallelism and we're able to take advantage of it And so that that was actually really powerful for a long time We didn't even think we'd need data parallelism as a result until we started doing things like, you know decoders encryption Speech recognition. I mean there were certainly areas where even with super cheap processes You still needed data parallelism to really get the the maximal scaling that because remember we were trying to compare ourselves against what you could get with C++ and so, you know We were benchmarking continuously against the best workloads in C++ and so if somebody can Introduce data races intentionally if somebody can roll up their sleeves and you know really hyper optimize the thing That's a pretty high bar to jump over I'd say fail fast was actually Wonderful, I think one of the funny stories I'd like to tell when we first ported the speech server to this model It was in C++ And he used H results and it turns out Like all Taiwanese speech requests were failing with the same error code and the code just silently forgot to check the H result and so some garbled answer would come back every single time now I don't know what it says about the QA and validation that this wasn't caught before it get into production But when there was ported to a fail fast model boom, it just failed right away. You found it It turns out, you know, we ran pretty aggressive Stress programs, you know run run one program and do as much as you can, you know run multimedia stuff in the background with some web-serving with some, you know Random just random things that compile going on in the background and see what fails and it turns out we get to the point where Most of the failures were actually integer overflows Because we failed fast on integer overflow It's kind of annoying, but it actually pointed out like hey, did you mean for this integer to overflow in some cases? It's okay, you know, it's just a simple performance counter or something But in many cases that actually pointed out a bug in the system that for many other systems would have lain dormant for Who knows how, you know Years if not longer And the result was performance parody with Linux and Windows. We measured mostly server-side benchmarks like spec web In some internal benchmarks the speech recognition benchmark a lot of client-side benchmarks So like, you know some spider and octane and these sorts of things But you know our goal wasn't really to beat the performance of a lot of these systems Although we ended up doing that largely because of the inherent concurrency in the process model But the fact that we even got close exceeded our expectations I mean we thought we would never get there We thought this is gonna be the thing that killed the project like we'd never get to performance parody and in the end people really didn't Care about the performance that much. It wasn't like a selling feature and I don't think even a 10 or 20 percent performance hit For some scenarios would have been Catastrophic I think people would have accepted the benefits that you get from the safety and the productivity I would say the long-term productivity was great But I'll return to this and it was very interesting to see this morning That you know productivity Is gonna be you know a focus for for the next couple years because I think that's spot on that's exactly what you need to focus on And when I say long-term productivity, I like to differentiate because the long-term productivity was like if you look over the course of the entire project You know, we wrote Five seven million lines of code something about the team of a hundred people We're constantly rewriting pieces of the system as we went because we were learning as well The system was built on itself. So it was fairly complicated But for a team of 100, you know, we basically built, you know editors web browsers compilers You know a shell file system networking stack Basically everything on an operating operating system has notepad, you know everything from the bottom to the top with just you know a hundred people and Doing that in C and C plus plus like it just would not have happened. It really wouldn't have But here's the things that didn't work and I'm gonna spend a lot more time on these It's short-term productivity And what I mean by that is like how quickly can I just write a piece of code and see what it does? It turns out that was a constant struggle for us. I'll talk a little bit about that in a moment People are generally unwilling to give up Productivity now for a gain later on Maybe maybe there's just a thing in like the United States or something. Everybody wants instant gratification. I want to see it now but the reality is You know the business, you know business happens at a breakneck pace nowadays, you know startups are coming and going all the time It's you know, it really is innovation happens a lot faster And so anything that seems like it's an impediment to succeeding at that Which frankly is the thing that my you know CEO or whatever is going to reward me for like that's a difficult Equation for a lot of people to work through People as I mentioned, you know really convincing people that hey, yeah, you can write safe systems code Safety is possible like you don't need to you see in some C++, you know You can actually get a lot of benefits from using this thing It's just a lot of people are stuck in their in their ways And it's it's a new concept for a lot of people like if you've been reading research papers for less 20 years 30 years, it's it's not a new concept But there's a lot of sort of bias that people have against Even the word safety, which I was really astonished by I would say another place that we really Failed on was we really did try to boil the ocean and partially we didn't know like what were the pieces that we actually wanted to survive in the end and So what we ended up with was something that didn't have any incremental adoption Yeah, we had some way of you know doing C ABI stuff and and you could Potentially use your own build system if you wanted but really you had to buy into our whole thing and to end to get even the first A little bit of benefit and that I think was ultimately the most critical failure So the type type systems are wonderful. Like I said, you know, I've I've been a huge Haskell fan for a long time I actually worked with Simon Payne Jones and a lot of the type system stuff that we did in the dialect of C sharp We caught hundreds of bugs if not thousands I mean you can't even quantify because you catch a bug simply by the program not compiling So maybe it's even millions of bugs. I don't know It's a large number of bugs that we caught that never made them their way into the system people take that for granted There's not an easy way to quantify it unfortunately And even the ones that did become bugs Because of defense in depth the fact that you've got this belt and suspenders type and memory safety thing underneath you It's it's harder to break, you know, basically jailbreak the whole system You can't even if you find an exploit up here Well, turns out you're gonna turn around and try to do something over there and that's gonna, you know fail fast on you so that defense in depth actually was very powerful as well and Using the type system we actually used a lot of We we use that to enable a bunch of pretty novel compiler optimizations It's interesting to see that the const you know generic const evaluation conversations today So like one of the nice things is because we had immutability in the type system and all statics were Guaranteed to be immutable we can actually evaluate all statics at compile time And so all these like giant tables that you have to build up that that cost you at runtime because you have to well In C sharp at least it basically it does double-check locking to make sure that things are initialized And and we could have lied all of that in terms of that was you know Like 5% of the instructions throughout the entire system could be elided simply because we had guaranteed frozen immutable objects Which it turns out much closer to sort of C++ in terms of you know manual initialization In const expert And yet despite these wonderful things people didn't love it all the time I would say don't underestimate the syntactic You know a lot of people say awesome text doesn't matter what matters is is the is the Concepts in the semantics and it's true, but it's not into not since it's not the whole story The syntax is the user interface for the for the language and so if the syntax is You know scary foreign, whatever that's just going to be yet another adoption blocker yet another barrier for people to overcome And I'd say some of the syntax we had especially around borrowing You know one of the interesting things I looked at C sharp is C sharp ended up with this Ultra simplistic model and similar to Java just because they wanted to save you know you having to put a star character Right, they don't differentiate between values and rep pointers to values or pointers to objects and That actually turns out to be one of the critical problems that we tried to solve in C sharp But that is actually where most of the syntactic Challenges came from and it's not just syntax like I said, it's really the model as well But the syntax and people look at it say whoa, this is bizarre. What does this mean? Rigor is not what people want when they are prototyping. I talked about this earlier in fact The type system It's not just the rigor. It's also, you know, oh, I wrote this very simple code and I got this wonky error message I have no idea what it means the type system isn't mapping to my mental model of this problem at all What do I do? Well a lot of that you can solve with Better error messages, so I know the mirror stuff that came in Last year, I guess it would have been made the borrow checker able to give out much more diagnosable error messages It was a fantastic thing But you know, if there's any places where the type system doesn't match the humans mental model It's gonna be constant friction and we ran into this all the time And it led to a feeling people would say hey, I feel like I'm just fighting the compiler I just want to get this thing working. I just want to see what it what it does and you know or and And they just spent all their time, you know tracing air tracking down error messages trying to figure out what's going on We're writing code weird ways contorting themselves. And so that that was a problem And I can't say that we ever really cracked that and even great IDs and tooling wasn't enough And so I think the core problem was You know certain Developers just are accustomed to not even thinking about the memory management whatsoever It's like this completely opaque thing that just happens, you know, like Python or and C sharp is in that category And so you could argue hey, we started with the wrong language But I feel like if you're gonna as soon as you try to appeal to a much broader audience This is going to be a fundamental problem And I don't have a great answer But really paying attention to this and really Getting to the essence. I think is is critical and like I said earlier paying more upfront to save time later is is a tough sell This one surprised me So reliability security even productivity Didn't sell and it's not that it didn't sell like, you know, you would think that The chief executive of a company the size of Microsoft Would care deeply about security given that that's sort of the business that they're in and I'm not saying they're they don't care but Cranking out features being more competitive in the marketplace, etc. Etc. To the extent that security productivity reliability helps with that problem Yes, I think you get a lot of support when you try to go into a large organization You know, you've got to sell the the project right you've got it or you you can sort of go go rogue and And try to make it happen sort of as a grassroots thing and that I've seen that work quite a bit But if you're trying to do something as large as like, hey, let's get support for replacing components in windows with rust or something like that I Thought that there would be more support, you know, like obviously it's 2017. We should be writing Systems code in a safe language if we can but that's not the prevailing Opinion at least from my biased experiences And one of the challenges we rarely ran into was this notion of systems programming when we were trying to sell it to people like What is systems programming? It's this vague term I don't know what a system is but you go to Wikipedia. It's not I mean it helps a little bit It's a systems programming aims for the software and software platforms which provide services to other software our performance constrained or both So I guess that narrows it down a little bit, but especially today with Lots and lots of distributed systems like a lot of code falls into this category and I actually think that's a good thing The only other thing I'd add is really correctness. It's paramount And unfortunately often at the expense of productivity Which is a lengthy topic in and of itself and your mileage might vary but for us systems turned out to be a terrible branding strategy It required constant, you know reiteration of the message people say oh, but I'm doing application development So you're telling me I can't use this. No, no, you can but it's just not for you like it just set us up for a difficult conversation And it's true. It's great for systems, but it was you know I also think the world is sort of Go is an interesting example where people are building systems But they're able to get by with sort of garbage collection and maybe less rigor And so you could argue like that's one language that works for both categories And so the more you sort of bifurcate the target audience for a language I feel like it's It makes it a tougher sell But in the end I think inertia is the biggest hurdle of all I think You know the most critical software on the planet has already been written by definition otherwise mission critical today and That's the software that's already picked a language in many cases. It's going to be see and Convincing people to move away from that is is quite difficult so That's not to say we shouldn't try so what is the future? Well, I think all of us have sort of seen a slice of the future. I really do I think When I go talk with folks like deep in the bowels of windows and talk to them about the problems that they're struggling with and You know, I think Microsoft's getting better about seeing outside of the holes of that, you know those buildings I think you know if you go talk to Linux contributors They probably have a better awareness of what's available in the ecosystem compared to you know Windows engineers, but I think neither category has really lived and breathed the experience of writing a very fundamental systems Component that really demands the highest performance reliability security You name it they haven't lived through the experience of actually writing that code in rust or you know insert favorite Contender for the new systems programming language of the future here And the question is how do we get them to see the value? I think for me living through the experience made me a believer But the question is how do you how do you get people to become believers when they haven't actually done it themselves? I think one way is really lowering the barrier to entry and making it super easy to experiment and play around with this stuff But there are other things too This I borrowed this from Simon Payton-Jones. I think it's beautiful Basically tells the story of what happened to our language clearly not rust, but this is What you want to avoid you know the like hey you appeal to the geeks But not the practitioners and then over time, you know people just slowly forget about it I would say our death was a little bit faster than than this, but it happened almost overnight So how do we avoid that well the good news is there systems everywhere? Based on my definition earlier, you know operating system kernels device drivers browsers distributed systems, which I'll return to Databases you can go on and on And all of these are systems that really should be using a safe language I think there are more systems being built today than ever before I think the the trends to do more distributed programming means like you know Kubernetes is clearly a system Linkerd is clearly a system There are a lot of these systems components and the nice thing is people are writing lots of new code here as well And so certainly looking for areas where people are creating new things I think that's a very good recipe for for starting to sort of take over the entire space and make it the Default answer for people in that space Unfortunately, there is no silver bullet. I wish there was but I think it's some combination of doing big bold new things Patience and hard work and being in the right place at the right time And those three things over the long run. I think put you in a good position So this is a good example of big bold new work. I think Redox is a great Shining example of really innovating and using rust to change the world in a in a big way But I think in addition to those things incrementality is absolutely Essential And this is something I think I learned from my experience in the project, you know We did not foster an incremental solution and every step of the way that was one of the major things that prevented People from betting on us, you know, you want to make it easy for folks to bet on rust or whatever component that you're building for a very targeted Solution and then allow it to sort of grow from there, right this whole like swallow the whole thing at once Value proposition is a very tough sell In fact, many large ecosystems just can't be replaced all at once like imagine, you know Linux and GNU Okay, you can't just rewrite the whole world all at once. It has to be an incremental path It's certainly easier to write new code and that's one of the traps that we fell into It's not only easier. It's a lot more fun. You can just go write lots of code and do great things And then, you know, especially today With such a vibrant open-source ecosystem that that approach works better today than ever before but really to get at the heart of the issue and You know get some of these mission-critical systems on on the right path It's gonna require getting messy and getting into the the existing C code bases and really trying to Turn them on their heads and Eventually the disruption comes but You can hardly ever predict when that's going to be So one possibility this is just a thought exercise, you know If I if I were to not be doing my startup This is probably something I'd be working on which is you know Take GNU and Linux ecosystem and start rewriting components maintaining as much compatibility as possible so take something like this and Really, you know use a C ABI as sort of the outer shell and really start replacing the guts of these components one one at a time You do this over a long enough period of time next thing, you know one of the most important pieces of software on the planet Linux Becomes safe and then eventually you can get rid of the C ABI and life is beautiful. I Sort of liken this to a Skittles analogy except that it's like an inside-out Skittle It's not the exterior isn't hard if the exterior is soft the inner core is hard I think also You know finding a way to ride or making a new one is also a super successful strategy. I think It's largely by accident. I think but you know, it's partially goes heritage as well but I see you know the correlation of go plus Docker plus Kubernetes like this whole ecosystem of You know cloud native components really picks go by default and Largely, I think you know, it's it's part of the culture. It's part of you know, there's this I've got a cute logo But I actually use go for a lot of the stuff at my new company And it's you know, especially if you're trying to build a new eco open-source ecosystem You want to sort of go with the flow if you will and I think You know Docker and Kubernetes really set the precedent there But I think finding that sort of an analogy like what is the next? Big system or big important technology that's really going to take over the world and making sure that's written in rust I think that's a very compelling approach now. Who knows right like the go team as far as I know Didn't have much involvement in convincing, you know, Solomon and Docker to write everything and go So you sort of have to be in the right place at the right timing. There's a little bit of luck involved as well But that also leads me to this notion of distributed systems where you know New pieces are being written and swapped in and out and really that's that's an opportunity where people are writing new code They can pick up new technologies. They're willing to do that There's an RPC boundary and so there's not this messy Disgusting C interrupts stuff that you have to deal with you have to worry about memory management on both sides Because if you have the C a bi is the shell you have to worry about all pointer came in and now it's Technically unsafe, but we pretend it's safe on the inside and if somebody screws up then the whole system's at risk At least here you have much stronger isolation boundaries And I think this is one of the things with Midori that sort of made it work as well The entire system was sort of a distributed system in a sense all processes were sort of distributed software isolated processes and communicated using RPC And the world is sort of going this way So it maybe maybe I'm wrong maybe Linux is the wrong thing to focus on maybe the right thing to focus on Is the fact that you know, there's this distributed operating system that's being created now out of heterogeneous polyglot components and maybe being a key player there is really the right long-term strategy That very well could be the case So returning to my original premise I think in the future all systems will be safe systems the question is you know How long until we get there and what's the path from here to there? But I'm pretty convinced that the people in this room and the community around you guys are in the best position to answer that question and Really make that change happen. And so for that, I'm super excited And I say let's go build a safer future