Conor

Has this stuff been talked about before, or is this is this kind of like breaking news?

Sean Parent

Aaron Powell I guess it hasn't. This is somewhat breaking news. So so we ported it to Rust. We're within about 15% performance of the C implementation. In some cases, the Rust implementation actually wins.

Conor

Aaron Powell This is a straight port of the new concurrency features that Nick wrote in the C library. He ported them to Rust. So when you say they were running inside Rust, it wasn't like Rust bindings to the C library.

Sean Parent

No, no, no. This is a port of gotcha. I wrote the portable executor. And so and then Nick ported it to Rust. And not just Rust, but safe Rust. So we we did it without using unsafe calls, which is nice because now we have established that there's no race conditions in this body.

Conor

Welcome to ADSP the podcast, episode 160, recorded on December 12th, 2023. My name is Connor, and today with my co-host Bryce, we chat with John Parent about the latest updates on the Hilo programming language and the state of rust and safety at Adobe. I think the plan for today is we will try to record probably three different mini episodes. Um, because the way that this is gonna roll out, we're current we're currently recording this on December 12th. So this episode, first episode, will come out on December 15th. And then next Monday we're recording with Zach Lane the holiday special, which should just be one one hour-ish episode that'll come out on the 22nd, and then part two and part three of this conversation will come out on the 29th of J uh December, and then the 5th of January. So, with that in mind, I was thinking for the first mini episode, 30 minutes or so, we could, I mean, we'll introduce Sean. I mean, no needs no introduction at this point. This has got to be, I think, your 12th episode, fourth recording, if we include the last time we recorded, which was in June of 2023 at CPP on C in Folkestone, UK. That's right. Which was an absolute blast. That was fun. Hopefully we will be able to repeat that at some point in the future. Not necessarily at C on C, but at some other conference. And we can just catch up on everything that has happened since then. Because I know Bryce, you were uh at a one at least one conference. You were at Meeting C in November, right?

Bryce

Um and I don't think we have I was not at Meeting C in November.

Conor

You were not? No. Why did you two just show me uh Meeting C I gave a talk remotely. Oh, okay. But that was at the conference or at a meetup? At the conference. Okay. So you were not in Berlin, but you were presenting at the meetup. And I know, Sean, you as well have attended, I think, CPPCon and potentially one or more conferences. Anyway, so we'll start we'll start with Sean. Sean Parent, you know, longtime guest, longtime listener. Everyone should know him. Uh we will link every single one of his past appearances on ADSP the podcast, as well as appearances on other podcasts. I know you've been on CPPcast. And we'll throw it over to you. Feel free to update us on conferences and also how things at Adobe have been going. I know that you uh not sure if it was the last time we recorded with you or two times ago, you mentioned that you know you've been putting together the dream team and bringing back to life the ST lab. So yeah, we'll throw it over to you. And this is our catching up with Sean, part one of our three-part uh conversation here.

Sean Parent

Well, thanks. Um uh yeah, since last time we talked, let's see what's been going on. Um on the Hilo front, we talked a lot about Hilo last time, and actually, thanks for the PR on that. Uh uh after after my interview came out on your podcast, we had a significant uptick in in Hilo contributors. So it was very helpful.

Conor

And that's that's a whole announcement in itself because at the time we were referring to Hilo as Val, because Val Val hadn't been rebranded, and then I think like a month later I got a message saying, hey, you might want to go rename your episodes.

Sean Parent

And I was like, well, I mean it turns out there's a uh another Val programming language, uh uh which is a robotics language. Uh been around since the 70s, corporate owned, and so the trademark was owned. Uh so the Val team got a cease and desist, and we had to pick a different team.

Conor

Actually, that's the reason. So you got a cease and desist. Yeah. Wow. So And where did the Hilo name come from?

Sean Parent

Uh the Hilo name came from making a big long list of potential names and uh vetting them with legal and crossing them off until we had one left. So not not the ideal way to pick a language name.

Conor

Do you remember any of the top contenders or your favorites that uh did not did not make the legal removal process?

Sean Parent

And and uh you know, like Valkyrie and things like that. And and unfortunately, uh basically if you've got a trademark named and you're you're you've been you're you potentially violated it, any derivative name is also off the table. And so all names that included Val were immediately off the table.

Conor

So this is just because you got the C and Assist? Yeah. Yeah. Interesting. So if you had gone for a more specific name and had never gone through the path of getting the CS and Assist for Val, you potentially would have been okay to have that more specific name including Val.

Sean Parent

It's kind of like if you said, you know, like, oh, I'm gonna call my new operating system Windows, and Microsoft sued you, and you said, okay, I'm gonna call it Blindos, they'd be like, no, that's still too close. But if you had started with Blindos, they might have never had a case, right? So that is amazing.

Bryce

So how how did they hear about Val?

Sean Parent

Probably from your podcast. Whoops. So I I don't know.

Bryce

Um Well, that that's unfortunate. That's that's also that's that's pretty aggressive if they like they they started with like a cease and assist letter. If they had just sent you an email, you probably would have figured out some solution.

Sean Parent

Exactly. Exactly. So so but you know, it is what it is. Um so the Hilo name's kind of sticking, so so that's that's doing well so far.

Bryce

It's more Googlable.

Sean Parent

It's more Googlable, yeah. Uh yeah, and then uh let's see. We are now available on uh on compiler explorer. So you can select Hilo as a language and and write a little bit of code. Uh we are making, you know, our biggest breakthrough here recently was we got arrays working, an important data structure, uh, which is kind of the the start of the standard library, which is going. It's it's the language is very much in the flavor of Swift, where where all your types, including you know your your integer types, are are library types. And so getting to the point where we had enough of the facilities in place to build arrays has been significant. Uh emphasis right now is uh uh uh we trip up something in LLVM's optimizer. And so if you turn on optimizations on our project, the compiler uh LLVM explodes. And uh that's unfortunate because we'd like to start to get a feel for what kind of code we actually generate without the optimizers. You know, it's just just uh uh very crude and uh and shows it.

Conor

So I mean I think it's of the actual because we were talking to Richard Feldman over the last few episodes, and Rock is not a successor, uh C successor initiative, but of the C successor initiatives, I think yours is the only one that's actually hosted on Compiler Explorer or is CPP2 potentially as well. Although that's that's slightly different, right? Because it's transpiling to C and then compiling the C code where you're actually building a completely different front end and then having to compile that. But like compared to carbon, I think. Or I guess Circle as well. So I guess it's just Hilo versus Carbon of the ones that are actually building their own like compiler stack uh or you know, targeting L L VM at the end of the day.

Sean Parent

Yeah, yeah. And it was interesting because uh you know, not well, less than a year ago, our our we'd actually started targeting LLVM early on, and then and then the decision was made that that was kind of too big of a lift, and so we were gonna compile to C and do the transpiler thing, and we thought there would be benefits there for kind of bringing things up quickly. And that turned into a a bit of a nightmare. And uh uh so we backed off and went back to to LLVM. And that's working pretty pretty well right now. So we can target uh uh uh Mac, Linux, and the Windows support is limping. Uh most of the Windows issues are around. We we leverage the Swift Package Manager until they're actually Swift Package Manager on Windows issues.

Conor

Oh, the beautiful thing is Windows these days has WSL too, so um you can find a way to run it if it works on Linux, right?

Sean Parent

Yeah, exactly. Uh so yeah, so it's uh you know make it making progress. Um I'm hoping over this next year I've got Dave Senkel uh working on university relations for our team. And so I'm hoping that we can get a collaboration going with uh a university or two uh around Hilo development and keep it going that way. You know, right now officially Adobe's we've got one person on it part-time and and uh not gonna be hard to double or triple that amount. Not gonna be hard to double or triple that amount, right? Right. It's a long effort, and and I think I think building building community support is is is critical. So we've got a big meeting this afternoon, we're just or not this afternoon, tomorrow afternoon we're discussing uh concurrency model. Uh we've got uh Lucian, who's one of the collaborators uh uh uh on sender receivers. He collaborated with Eric Niebler on some of that work and now he's jumped into the Hilo project and he's been helping us on on the concurrency front. So we've got a big meeting tomorrow to try to get everybody on the same page. So hopefully I can convince them that we can do better than senders receivers.

Bryce

So what do you what do you have in mind?

Sean Parent

I like the sender receiver model, but I think the concurrent I think the cancellation model in sender receivers is broken.

Bryce

Elaborate.

Conor

Yeah, should we should we dig into this in our in our catching up episode? We are taking a hard right to Sean's thoughts on why the sender and receiver model is broken.

Sean Parent

In in what way? So the cancellation model in sender receivers is is very manual and it's top-down. And so so what I mean by that is you need to carry around a token, a cancellation token, and then you can flip the cancellation token to say cancel, and then then something up the call chain basically receives that and cancels down to the caller. The problem there is anything within that chain could be holding on to effectively a sender for uh uh uh another asynchronous task that it's not yet waiting on. And so that cancellation won't happen until the things that are currently executing finish up. So the the ST lab model is the other way around. It's bottom up. When you drop a future or equivalent of the sender, it it unravels the chain automatically going backwards. Any task that hasn't started is destructed, or any task that's suspended is destructed. Means that if you have a future being held up the chain, it's the destruction of that future that cancels that operation. And so you get a faster and asynchronous cancellation. And where that came from was doing real-time rendering, right? The whole ST Lab library came out of me working on uh Lightroom Mobile and Lightroom Web. And in that model, when you're sliding the slider, say adjusting exposure, uh where we're doing approximate frames, trying to give you quick feedback at 60 frames a second. And as you slow down on the slider, we're going to generate a higher resolution image. But if you move the slider again, we need to get back to 60 frames a second immediately. So we need to cancel the operation. We need those resources back now, and we're going to fall back into generating an approximate thread or an approximate frame. Uh you know, and we do that at various dynamic levels, so we can kind of tune things the faster you move the slider, the lower quality frames you get. And as you slow the slow your slider movements down, you get you get higher quality frames. And so the the sender receiver cancellation model basically as it's written, it's it's too manual and it's it's too slow. So I'm hoping that we can, you know. That said, sender receivers has a huge amount of benefits too, right? The whole uh building up task chains before you start to execute them so that you're not paying synchronization costs every time you're attaching a new task. Um you know, it's got a nice composition model in there. So it's got some huge benefits. So I'm hoping we can kind of blend blend the two models.

Conor

My understanding of SNR is not as good as Bryce's, but Bryce is there is that like a fundamental limitation, what Sean just explained? Like there's no way to design that into like basically the way it's designed. You'd never be able to replicate that.

Bryce

You'd need to uh I don't know.

Sean Parent

That's a that's an open issue. Uh Eric Niebler asserts that it's doable. Um I've taken a couple stabs at it. Um basically building the ST Lab cancellation model on top of senders and receivers. Um I've taken a couple stabs at it and failed, but part of that is because I ran into a bunch of things within the the uh uh sender receiver library that were not yet implemented. Um now I've got uh uh Nick DeMarco on my team uh taking another stab at it to see see what he can do. On updates, too, I guess. Uh Nick DeMarco did some work on the ST Lab concurrency libraries, where uh kind of at the base of that we've got this nice library that provides uh an abstraction over the system thread pool. So so if you're running on Windows, it will target Apple's lib dispatch, and if you're running on Windows, it will target the Windows thread pool. And if you're on Linux and you have Lib Dispatch available, it will target that. It's also got a very high performance uh uh portable task stealing thread pool. And so if if there's no system thread pool available, it will target that. Um it's also got a notion of uh of a main executor because most most platforms have such a thing uh uh uh or frameworks do. So if you're if you're running on on Mac, the main executor is the the main queue for lib dispatch, and uh and if you're running in in Qt, it will pick up the the main main executor in Qt.

Conor

And these are updates to Hilo or a ST Lab concern concurrency library that Nick.

Sean Parent

No, this is the ST Lab concurrency library, which is a C library that's got that's been available for a while. And uh uh one of the experiments that uh Nick did recently is he's gotten the our our portable high performance executor running inside of Rust. And what? Yeah, and so so so we ported it to Rust. We're within about 15% performance of the C implementation. In some cases, the Rust implementation actually wins.

Conor

This is a straight port of the new concurrency features that Nick wrote in the C library. He ported them to Rust. So when you say they were running inside Rust, it wasn't like Rust bindings to the C library.

Sean Parent

No, no, no. This is a port of got I I wrote the the portable executor, and so and then Nick ported the to Rust, and not just Rust, but safe Rust. So we we did it without using unsafe calls, which is nice because now we you know have have established that there's no race conditions in this this body.

Conor

Was that the motivation for reporting it to Rust, or was it just a curiosity to see the the perf of uh the portable, the ported Rust version?

Sean Parent

Well, uh a few things. One is you know what my team is tasked with, where we started with, was being tasked with with basically how do you do correct and efficient concurrency. And and it turns out there's a really strong correlation between uh uh correct concurrency and safety. And if you go back to the Leslie Lampert papers, which were all written about how do you reason about uh concurrent code, you'll find a big part of that is about safety and liveness properties. And so you have to prove a set of safety properties to prove your concurrent code is correct. And that has a turns out has a strong correlation to what we talk about when we talk about memory safety and things of that nature. So this so we started working on concurrency, and then then because of all the pending legislation around uh uh safety, we kind of took a detour to focus a little bit more on safety because it very much much fell within in our domain. Uh but in looking at that, uh, you know, within C, it's a huge challenge if you say something like, you know, well, I've got a high performance task stealing thread pool. Um how do you know you implemented that correctly? And and that you don't have some subtle race condition buried in there. And you know, you can run it with thread sanitizer, but that's uh not a proof. It will only show you a race condition if you hit the race condition. So a programming language like Rust, as long as you're within safe Rust, uh uh lets you demonstrate uh no races by construction. And so that's where the where the interest came from. Could we start to move critical concurrency components into Rust? You know, we're also looking at moving critical safety components into into Rust. So things where we're you know within our products parsing untrusted inputs. Uh uh, those should either be sandboxed or moved into uh a memory-safe language like Rust.

Conor

Interesting. And so this is this is to actually have that code being run through the Rust compiled executable, not you know, verifying that it works in Rust and then continuing to use the C version.

Sean Parent

No, the plan is to to we want to continue to performance tune the Rust implementation, but if we can get the Rust implementation um a little bit closer, right? We don't have to have 100% the performance we have on the C side, but if we could get within a few percentage points, which I think is doable, uh then we'll just probably swap out the implementations and we'll we'll uh we'll have it there. The other thing we want to do is we want to do Rust bindings to the platform thread pools. Because within a product, you really don't want to have multiple thread pools running. And so if you're running on Mac, you as great as our portable implementation is, you really want to be using Apple's lib dispatch. And same on Windows, you want to be using the Windows thread pool. And so we'd like to release this as uh as a library for for Rust developers, because we think it's something kind of missing in the Rust ecosystem. So you could go to Cargo and pull down your Rust code and you'll have uh uh uh uh uh a library uh for a high performance thread pool that will run anywhere and it will target your your platform thread pools where appropriate. So we think there's value there also. Uh it's also giving us experience in how difficult it is to do the bindings back and forth, which are not bad. Adobe has a lot of experience with binding C to other languages. We were a little surprised in that the bindings that are available, few of them start with basically how do you do uh uh function object calls between the two. And that's kind of always where where I start. It's like like you know, how do you call function objects from C into Rust? And how does does Rust call a C function object? And kind of the once you get that, you can bridge all the rest. And so that's where we've been been starting with our bindings, and we found the the existing work that was a gap. So so hopefully people can look at what we're doing there and also pick up some some tips.

Conor

Is there any talks that have been given or blogs that have been written on this kind of Rust at Adobe or Rust at ST lab? Because this, I think, like Reddit and the internet are gonna have a field day with if we title this episode like Rust at Adobe and you talk about how, you know, due to the safety and you know critical nature of pizza parts of our code, we're trying to migrate to Rust, and uh there's like a 15% gap. And I'm sure like the listeners uh would be very interested to hear like, you know, what is it the you know, you think it's one to two percent is possible, but there's a gap right now. Like, what are the things that are causing that? Uh but the the first part of the question was has this stuff been talked about before? Or is this kind of like breaking news?

Sean Parent

I guess it hasn't. This is somewhat breaking news. Adobe's got something called our Content Authentic Authenticity Initiative, which is a way that we tag content that's generated with AI or content that's been edited otherwise versus content straight off your camera as a way to build trust. So it's an opt-end system. It's not something where we're trying to like auto-detect uh what's AI or what's not AI, but the idea is that it uses a blockchain and builds a chain of trust, and it's starting to get built into cameras. And so that if you're a photographer and you're taking pictures and you're sending them off to the New York Times, the New York Times has a token that's that they can validate that says, yes, what this photographer says about the origin of this image and that it wasn't edited inside of Photoshop or any other application is true. Um and so it allows you to build a uh uh a chain of trust around your content, and it's become incredibly important as as we're moving into uh uh the AI realm. And so you have uh it's you know increasingly difficult to tell what's real and what's not. But in any case, the the the content authenticity plugin that's written for Photoshop is is itself written in Rust. So that was you know that choice was made because you know they thought they they needed a high level of assurance that the code was was correct and Rust seemed like a better starting point than C. So that's one project at Adobe that's currently in Rust. Around the concurrency stuff, yeah, uh Nick is working on a couple of blog posts on that front, and hopefully he'll give some conference talks on it here soon. So that's coming. Uh, you know, and then we're also discussing internally around the pending legislation around safety and security, uh, what Adobe's response is going to be. And right now our thinking is we would like to publish a roadmap on basically how we're going to address that. And that's not finalized yet in any form, but but I expect you know a component of that roadmap is going to be that uh some of our critical components will get rewritten uh into Rust or another memory safe language.

Conor

Aaron Powell When you say pending legislation, is that a nod to some pending leg legislation that you actually know is on the horizon or just anticipating that it's going to happen at some point?

Sean Parent

Oh yeah, no. There's um uh so there are two bills. Sorry, I don't have.

Conor

It's alright. We'll we'll find them, we'll find them and link them in the show notes afterwards.

Sean Parent

Uh yeah, yeah. I can hunt down the links. Uh so the the one in the US uh uh that's pending basically says that the Department of Defense is going to uh within 270 days of the bill passing, and it's a funding bill, which means it will probably pass late this year, early next year, uh that the Department of Defense will establish uh uh guidelines around safety and security, including uh uh uh memory safety for software products purchased uh uh uh by Department of Defense. The EU has a similar wording in a bill that's slowly winding its way through through their channels. Um I don't have insight into when that will pass. Uh the US one uh will almost certainly pass here within a month or two. Oh wow. There's a long way between having a bill passed that says almost a year later, they have to establish a plan for what they're going to do, right? So it's uh you know, it's it's not hard legislation in in any way. But I view this, uh I can send you a link. There was a uh a podcast I listened to recently on uh macOS folklore. Actually got a call out to your podcast within within that podcast.

Conor

I've never even heard of this podcast. Now I'm gonna have to go, how many episodes? This is gonna cost me like a month or two of uh listening to all the backlog?

Sean Parent

It's all in in in one episode, uh so so I can I can hunt down the link. Uh but it's talking about how in the early 90s uh there was a uh a somewhat similar round of legislation that went around around POSIX compliance. And basically the uh uh Department of Defense decided that in order to have portable software, every operating system that they purchased had to have POSIX compliance, and there was a roadmap put into place. And that's why Apple pursued uh uh building their own Unix, which was AUX, and then eventually partnered with IBM to do AIX and Microsoft in the same timeframe, had a big push to get POSIX compliance uh uh in Windows OS. And the thinking was eventually, in order to sell to the government your operating system, it would require POSIX compliance. Um, what actually happened if you wanted to buy just traditional Macintosh operating system, you would just say, well, I require Photoshop or pick your application, and there is no alternative that runs under Unix. Uh so therefore I need an exception to buy Mac OS. And it was extra paperwork, but it got signed off on, and and so so really never materialized into hard restrictions on on sales of non-POSIX compliant OS. And we expect the or I expect the the safety legislation to take somewhat the same route, which is there will be pressure uh uh to write more software in in memory safe languages. Where you don't write software in memory safe languages, there's going to be more pressure for you to document what your your process is to mitigate the risks. You know, it and this is all initially it's going to be all in the realm of government sales, although there's some discussion in both the EU legislation and in the on the US side of extending this to just uh a consumer, to a consumer safety issue. Uh but there will be you know an escape hatch because you you couldn't wave any kind of magic wand as a legislator and say you can't sell software anymore if it's written in C. Like the world would grind to a halt. Uh so there will be an escape hatch and there will be pressure. Um and so as a company you have to look at how are you going to mitigate that that risk going forward. And and and and what's your plan going to be so that you can continue to sell products to the governments? And uh how do you make sure that you're not opening up a competitive threat if you've got a competitor that can say, well, we're written entirely in rust, so we don't have to do the paperwork. Yeah, that becomes a faster path. So you want to make sure that you're you're aware of those issues and that you've got a plan in place to mitigate them.

Conor

I wonder if there's like an analogy to uh JF and I think it was his C Now Safety Talk, has this comparison to seatbelts and how at the time, you know, a bunch of people said, like, I'm a safe driver, I don't need a seatbelt, but now we live in a world where everyone wears a seatbelt, even if you know 90% of drivers are never gonna get in an accident and no one's gonna get hurt. But like the analogy I'm thinking here with respect to sure, you know, trying to the legislation that was passed with respect to operating system is one thing, but like the legislation being passed here is with respect to like safety in critical systems, and the same way that if you're caught not wearing a seatbelt these days, you get ticketed. Like you can make the choice not to put this wear the seatbelt that was put in every vehicle, but you could end up with a ticket. Potentially that's gonna be the same thing in the future with this. Like you can make the choice not to use the you know mandated language that are safe for critical systems, but if something ends up happening and you took the escape hatch and said for these reasons it'll be okay, and then it ends up not being okay, that there's gonna be, you know, fines that are handed out by the government saying that like, you know, we made this recommendation, etc., and or not recommendation. We passed some legislation, you chose to take the escape hatch, people died, or something bad happened, and now you're getting fined.

Sean Parent

That's the the basics of it. And this is the White House put out a cybersecurity strategy, and and part of that cybersecurity strategy is to uh uh shift liability. And what that means is right now, if you're a consumer and you buy a piece of software and the software crashes, you signed a EULA that said the software manufacturer doesn't warrant that this does anything. And so if it crashes and it takes out your hard drive, uh that's on you for running the software. Uh, you know, and there are very few exceptions where people have have won cases around that. And so part of the strategy is to start to shift liability to the manufacturer and say, look, if if if that happens, you know, you're liable for the for the loss that your your your customer uh uh paid. And so so you know, and that's true in almost every other industry, right? If you if you buy a phone charger and your phone charger explodes or your the phone and your battery explodes, that's gonna be on Apple or Samsung or whoever whoever built that component. And so to protect organizations around that, to protect them from suits for negligence, is you get uh industry established standards on best practices. So kind of in the hardware industry, you have you know UL listed, right? So you'll see you know this product is UL listed, and that basically means that there's a lab that's certified that, yeah, this this component was built following best practices and is safe to use. And I expect over time, as the software industry matures, we'll see similar industry uh practices appear. I mean, the the closest equivalent right now is is MISRA, which is largely the automotive industry. But you know, I think you'll you'll start to see uh similar industry standards appear and similar compliance requirements and more transparency in how software is developed. And so it's just gonna be a little bit stricter engineering practice and a little bit more bureaucracy around what it takes to build software. Uh, you know, personally, I think it's a good thing, right? It's yeah, the number of times where I'm utterly frustrated by the quality of software on my devices a day is uh is amazing. And we've just come to accept it. You know, we started this meeting and we were talking about two of us, two of three of us, updated Teams to the latest version of Teams, and it's like, oh my god, is this gonna work? Is it gonna crash? Are we gonna get any audio? Um not to pick on Microsoft, but but we go through this every time. We we expect failure from our software. And and we shouldn't. We should expect success, right? Right. If my phone exploded the no you know, the number of times my software crashes per day, yeah. It would be a pretty dangerous world.

Conor

So and it costs like uh to pick on a different company, Google. One time, I think I had the Pixel 2 or 3 at the time, I did a software upgrade, it bricked my phone. And then I contacted Google thinking that like this is clearly a Google software program. I hit the upgrade, you know, OS. Now my phone no longer works. You owe me a new phone. And when I contacted Google, they were like, that's not on us. Like, you know, we don't guarantee that like software or OS upgrades are gonna be like you know, bug free or whatever. And I was like, this is not a bug problem. This is a you bricked my phone. And uh I was so angry, like I was like, you know, I'm taking a break from Google. I love the Pixel phones, they're amazing, software's great, you know, but I switched to OnePlus for the time being uh and haven't gone back because OnePlus has been treating me great. But it's just like like well, you know, that's like a thousand plus dollar phone, and uh it's ridiculous that like you know something like that can happen and they're not they they don't owe me anything for that, you know. Like it's like, oh well, we we didn't we didn't guarantee you that this wasn't gonna completely set your phone on fire.

Sean Parent

Uh yeah, by clicking okay to uh to do that update, you accepted the the risk.

Conor

Which is absurd. I think we've mentioned this on the on the podcast before, but I'll I'll drop a link in the show notes of I think it's Jonathan Blow, uh, and there's this like 10-minute lightning talk within a larger talk that he gave where he just goes through, he's like, I got really frustrated with the how terrible quality of software is and and then he goes for 10 minutes and he documented for a week just like everything that happened. And it was it was like 50 things or something, and he was just like, Nothing works here, you know. Like I open this window and it's off the screen, and so I need to know that I need to window snap something. But like someone that doesn't know that stuff, they're just constantly restarting, and that's we we accept it, right? Like, you know, people know if it doesn't work, just restart it, and probably that'll that'll fix things. Like we've just gotten uh completely like desensitized to the quality of our software.

Sean Parent

Yeah, that's a reason why Intel's effort around Optane, which was kind of you know promising technology, it was like like like what if your RAM were persistent? Right. And what they discovered was nobody knows how to write software for persistent RAM. We assume that you can always just restart and clear things out. But but but if you're if you're not saving things, if just everything just keeps running, what happens? And uh nobody knows how to write software in that environment. And so they found that people wouldn't utilize optane, they would write software as they were writing software today. And so instead of having a you know slightly slower RAM but a slightly faster SSD in one, the only way people used Optane was was as an SSD, and it wasn't competitive in that space. Uh so so you know it's it's interesting, right? Right, our software has involved has evolved in this environment, and and we just take for granted that there's uh you know a reset button. We can just just like okay, put everything back to at least some initial known state, and we can start from there.

Conor

Yeah. I mean Windows has that built in. I mean, just just the other day, uh, Windows auto restarts. They give me a little warning, but then I'll say, I'll decide later, and then I forget to decide, and then they just restart my computer and you know, I lost some file. And like it's like that's why I hate Windows. It's just like, come on, like let me not restart my computer if I don't want to. And they're like, no, no, no, we have to. So you don't you don't get a say in this. Uh, you're gonna lose whatever notepad file that you had that doesn't have like autosave built into it, which is why basically everything other than notepad has autosave built into it because you know, VS Code, you don't actually lose anything from your computer restarting because it happens so freaking often.

Sean Parent

Yeah, Mac does that, and uh it's it's you can turn it off, but it's like really friggin' hard to get it turned off and keep it off. And even if you turn it off, there's still like critical updates where they will force a restart on you. And it drives me nuts because if you have encryption turned on on your hard drive, then when the machinery starts, you can't remote into it. And so like I'll be working from home and my machine in the office will have been forced restarted, and it's like now I have to drive to the office to log back into my machine so that I can start remoting into it again. It's like, oh yeah. And Apple's answer to that is well, turn off hard drive encryption. I'm like, how is that better?

Conor

Uh it's like going into the doctor and saying, This hurts doc, and they say, well, don't do that. Uh it's not what I was hoping for. And with that then, we will transition to this was what, episode 160. We've now skipped ahead over Zach. Be sure to check these show notes either in your podcast app or at adspthepodcast.com for links to anything we mentioned in today's episode, as well as a link to the GitHub discussion where you can leave comments, thoughts, and questions. Thanks for listening. We hope you enjoyed and have a great day.

Bryce

Low quality, high quality, that is the tagline of our podcast.

Conor

That's not the tagline. Our tagline is chaos with sprinkles of information.