Algorithms + Data Structures = Programs - Episode 252: Sean Parent on Rust and AI

Episode Date: September 19, 2025

In this episode, Conor and Bryce chat with Sean Parent about Rust and AI!Link to Episode 252 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)SocialsADSP: The Podcast: TwitterConor Hoekstra: Twitter | BlueSky | MastodonBryce Adelstein Lelbach: TwitterAbout the Guest:Sean Parent is a senior principal scientist and software architect managing Adobe's Software Technology Lab. Sean first joined Adobe in 1993 working on Photoshop and is one of the creators of Photoshop Mobile, Lightroom Mobile, and Lightroom Web. In 2009 Sean spent a year at Google working on Chrome OS before returning to Adobe. From 1988 through 1993 Sean worked at Apple, where he was part of the system software team that developed the technologies allowing Apple’s successful transition to PowerPC.Show NotesDate Recorded: 2025-08-21Date Released: 2025-09-19C++ Under the SeaBetter codeAdobe ASL Adam & Eve ArchitectureAdobe Software Technology LabASL LibrariesRust Programming LanguageIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

Is this the first time you're writing, like, production Rust Code? Yeah, I'm actually writing Rust Code now. So what's your experience? I mean, this is going to, this could be a very hot news for the orange websites of the world. You know, the C++ Luminary, Sean Parent's thoughts on working day-to-day with Rust. You better be careful. They're going to take away your keynote from the CPPN to the C. I know.

I've got this keynote, and I'm like, yeah, I'm not doing much in C++ anymore. Takes on Rust. There's a lot to like. Now, are you writing this rest code with directly or are you using AI? I am certainly using AI. I mean, one of the great things that I have found with Cursor and Claude, I'm in kind of the Conner camp here. It's rocket fuel.

Welcome to ADSP, the podcast, episode. 252 recorded on August 21st, 2025. My name is Connor, and today with my co-host, Bryce, we chat with Sean Parent about Rust and AI. There was an audible sigh from Sean after Bryce complaining about Gemini's integration with his email. Feel free to follow up that sigh with your thoughts and feeling, Sean. It's just the unpredictable nature of AI.

Oh, we were just, so we were talking about this earlier that I was telling Connor that I feel like we both are doing the AI coding thing and we're both big proponents of it. But I feel like Connor's experience is a lot cheery where I have what Connor is calling the, Connor's vibe coding, I'm rage coding, where I'm like, oh, you stupid robot, why would you do that? And it's like, I know it's not a person, but it's still, it feels like it's intentionally being incompetent. It feels like it's personally, like I feel personally wounded every time it does something, you know, silly. And it's like I can't, I can't overcome this desire to, it's like the worst thing where like it makes a mistake instead of me just being like, all right, I'll just tell it to correct the mistake. I'm like, explain yourself. You tell me why. Why did you not listen to my instructions?

Well, something I've had recently good luck with in Cursor is to say, say you keep doing, you know, X. So please create a prompt for yourself. That will have the rule set, so you will stop. And sometimes it'll create like, you know, I had like a one-sentence thing. I told it to stop doing it, and it will create five paragraphs. And it's like, okay, now it works.

Like, that's what it took. Wow. What do you call that? Like bootstrapped context engineering? Yeah. I tried something like that where I asked Cursor to write a cursor role for itself. But as it turns out probably intelligently that they have blocked Cursor from writing from modifying the cursor roles,

which I guess is a sensible thing to do. Yes, it can't modify them, but it can put it in the text that you're going to copy and paste into one. So, yeah. Sometimes I'm a little frightened by the lack of guards as it's like, here's this massive mumbo-jumbo. Execute that in the terminal.

You're like, really? Wait, wait, wait. Actually, I have a, before we start delving into the details and weeds, because we haven't talked to Sean in a while, let's, well, because I'm curious to get you mentioned cursor, but we'll, we'll put that question on the back burner. The first question, how have you been? We haven't chatted in a while. I know, I think one of the topics we'll get to is you are keynoting at C++ under the C if I'm not mistaken, which by the time the listeners are listening to this should be in roughly, I think, a month from now, because this will come out in early September. So anyways, how have you been? We'll talk about the upcoming keynote, and then, yeah, we'll take some time. Because I did see that on GitHub, because I follow you. At one point, you pushed a commit or a PR that was updating the documentation of something. And it said explicitly in the details, like, thanks to Claude or something like that.

And I was like, all right, people have been asking to have you back on the pod. But also, we got to get, you know, someone who's a little bit more senior than Bryce and I, their thought on, you know, the age of AI coding. But anyways, how have you been? I've been doing well, yeah, keeping busy. Let's see, probably since last time we talked, I stepped back from managing, so I'm no longer STLAB manager here. I handed those reins off to David Sankle.

I heard that in a talk that he gave. He said that you, like, Jedi mind-tricked him into, like, giving him what he wanted, but, like, you also, in order to get what you want, must become manager. Yes, a couple times in my career, I've hired my own manager, so it's worked out well. Yeah, so I'm coding and writing. Dave Abrams and I are working on the book, which is moving, but slowly. This is the better code book. This is the better code book that I announced and have had a contract with Pearson since 2014,

so we're a little more than a decade late. But it will happen eventually. I don't know if it will matter at this point because AI is changing everything. Well, I mean, the book might be helpful for the AI. I know. That's what David and I keep saying. It's like, you might be writing this for the last reader, right? So that's going along.

We also, you know, the first software technology lab, which was with Steppenoff and Paul McJones and Matt Marcus and Foster Burriton. One of our big projects was a couple of libraries. The most important one, I think, was the property model library, which is also known as Adam. It's still kicking around. It's part of ASL out there.

And it was always part of a larger vision, which is how do we move past imperative coding into a world where we can stay in tents and have the system solve for it under the hood. And so property model libraries or property models are a constrained constraint system where you can specify relationships between discrete properties, and then the library will solve for them. And so it typically gets used for using building UIs where you want to specify constraints and relationships around arguments to some operation. And then you can bind a U.I against that model, and then you get a functioning U.I.

So when you check on this checkbox, that checkbox over there gets disabled, not because there's any code that says when this is on, disable that. it's because the rules around disablement are when an item is either implied by something else in the system or disconnected in the system. It should be disabled. And so it becomes a much more compact and has a bunch of proofs around it, a way to describe behaviors. So our team has resurrected basically that project and the expanded vision of it as something we call project less. And there's a lot of no-code, low-code systems out there. But the vision here is to try to build a low-code environment where you describe large systems in terms of intent, and the system constructs from that models, and you get an executing application and do it in a scalable

form. And we're writing that in Rust, so I've been working on the underlying run-back system for that in Rust. It doesn't sound like you're coming, well, you're coming back to the project from an idea standpoint, but not from an implementation standpoint. My guess is that the initial iteration of this was in C++, and this time you're doing it in Rust. Yeah, the initial implementation of this was in C++, and, you know, it's been used at Adobe for 20 years now. You know, so we have lots of experience with it. And, you know, there are some common issues that have come up around the ergonomics of the system, you know, insights into being able to see what the actual structure is that gets built for a given declaration. The previous system was dynamically typed.

And now there are various act solutions to try to retrofit schemas on top of it. so you can verify things that compile time instead of having them fail at runtime. And so then the new system that I'm working on is statically typed and kind of from the ground up and has much better facilities for introspection and much better error reporting.

So trying to address all of those issues. So it's a full rethink and rewrite. And is this the first time you're writing like production Rust Code? I imagine you've dabbled in it before, but I don't recall chatting with you saying that, oh, yeah, we're doing, you've mentioned libraries at Adobe,

but I thought that was, you always were referring to them as a project somewhere else, but it sounds like you're actually writing Rust Code now. Yeah, I'm actually writing Rust Code now. So what's your experience? I mean, this is going to, this could be a very hot news for the orange websites of the world, you know, the C++ Luminary,

Sean Parent's thoughts on working day-to-day with Rust. You better be careful. They're going to take away your keynote from the CPP under the C. I know. I've got this keynote, and I'm like, yeah, I'm not doing much in C++ anymore, which isn't quite true. I've been spending, I spent my morning here working on C++ libraries. But it takes on Rust.

There's a lot to like. One of the things I really like about Rust is the tooling and the set of environment and, you know, cargo for doing package management. And the fact that unit tests are directly in your source. files along with documentation tests, and in Cloud or VS code, you can just click on the test to execute it and, you know, run things directly in your IDE and build your documentation and view it. And so all of that is just so much easier to get set up in cargo. And then from a language standpoint, there's a lot to like about it. There's a lot of things they got

right. Destructive move as the default. are explicit and usually not necessary, so it's not like a reference semantic language, you know, like Python or things like that, so you can write efficient code. They don't have production co-routines. You know, their co-routines are in nightly built.

They do have kind of a partial implementation of co-routines that they use for async and await. But even at that level, their co-routines or function objects of that level are just objects, unlike in in C++, where you get this implied heap allocation and type erasure that goes on with co-routines,

and so co-routines become fairly heavyweight. The fact that void, which is just the empty tuple in Rust, is regular, cleans up so much code. So that's all. What do you not like about Rust? Well, you said that those are the things that you think they're doing right. What are the things you think they're doing wrong? There is no specialization in Rust. So if I have a, for example, in C++, you get used to this notion of you've got forward

iterators and bidirectional iterators and random access iterators, and those each specialize the other one, right? So random iterator is more specialized than just a forward iterator. And if I'm writing an algorithm in terms of forward iterators and I call some, something that could be done more efficiently if it's a random access iterator, and I happen to have a random access iterator, it will call the specialized function and I'll get the more optimal path. Rust doesn't have this? Rust does not have this. But they have like operator overloading, right?

They do not have operator overloading directly. They have it through traits, which isn't bad. But the syntax is incredibly verbose. You know, in Rust in general, the syntax is even worse than C++, which is unbelievable because C++'s syntax is so horrible. You know, but in Rust, it's like, oh, I want to create a class. And in C++, I could create a class and in line all of my member functions in it. And if I have the right set of member functions, then that might conform to some concept. and, you know, the fact that I don't have to declare conformance is problematic in C++.

But the fact that I can kind of write everything in one unit is nice. And in Rust, I have to say, okay, I've got a struct, and my struct just has data members and no methods on it. And then I have to write a separate block that's an implementation of that struct that provides the methods on my class. And then I want to say, oh, this thing is going to, you know, conform to a trait. Well, I have to say I'm implementing the trait for my class, and then I have to specify how I'm implementing the trait. So it just becomes, you know, a bunch of blocks and very verbose, and the generic syntax is very verbose.

And, you know, a lot of people complain about the borrow checker. Honestly, I've never had a problem with the borrow checker, but it's because I'm I write everything in terms of whole part relationships anyways. And so the borrow checker, when it does come into play, it's just syntactic noise. I just have to say, you know, tick A, tick A, tick A, tick A, which is basically, you know, I'm returning a reference and the reference is going to be to one of my arguments because I'm following strict whole part relationships. Or I have to say tick static around a generic type because otherwise it wouldn't compile

because I'm taking that type out of a scope and Rust has a notion of local type. So you have to say, no, no, no, that has to be a global type. So I can basically take it out scope. Now, are you writing this Rust code with directly or are you using AI? I am certainly using AI. I mean, one of the great things that I have found with Cursor and Claude, I'm in kind of the Conner camp here. It's rocket fuel. And for learning a new system, you know, I,

I can ask, you know, okay, here's what I want to do. How do I do that? And it will give me a block of Rust code. Now, if I don't understand that Rust code immediately, then I will go and ask questions, like, why are you doing it this way? And then I will usually double-check that information, in part because I got burned badly once, because I asked a question about if a tuple in Rust, like, let's say I had a tuple of A, comma, B. And then I had another tuple that was A, comma, B, comma, C. The question was, is there a guarantee in Rust that the prefix A, B, has the same layout between those two tuples? And since I was doing a bit of hyperasure and a bit of unsafe code inside of Rust, the answer to that question was very important.

Yeah. And I believe it was Claude gave me a very beautiful. answer about why that was guaranteed with logic and links and, you know, it started with, well, it's not explicitly stated in the standard, but it must be true because, you know, A, B, C, D, E, very well-reasoned, very nice. And so I took that at face value and implemented my code accordingly. And two weeks later, I had a really hard bug to track down. and it took me a solid week because it's, you know, a memory stomper, you know, in unsafe code to hunt down what was going wrong. And it turns out that that is not a true statement. Those layouts are explicitly not guaranteed to match. They just happen to usually match. And so I got away with it. And I went back to my tab with the proof and actually clicked on all the list.

links and half of them went nowhere. This is just total hallucination bullshit. So after that experience, I'm a bit more cautious with just accepting things at face value. Yeah, I never trust it. I never trust it.

Do you remember what, was it 3.5, 3.7, 4.0? Probably 3.5. It was before 4.0. Certainly 4.0 has been nicer. I still think Claude 4.0 I still think does a better job than GPT5

although the one thing I do like about GPT5 is it doesn't blow so much smoke at you right, right? Cloud 4.0 is like, hey, that's a great question. Yeah. No matter what you ask, right?

It's always like, that's a great insight. Let me go munge all of your code with that great insight. And it's like, no, that was a horrible insight. I'm almost afraid to ask it questions that I I'm almost afraid to ask it questions or make suggestions because it's like I know that it's going to be like

oh like I want to make the user happy so I won't tell them no I'll just do whatever they suggest yeah yeah and GPG5 doesn't tell you no but it doesn't doesn't compliment you for your incompetence the one feature I really really really want in these AI systems is for them to be competent enough, you know, if I say, hey, how about you do it this way to go, to go, well, that's a pretty stupid request because that way, you know, it would contradict these other things that you said you wanted or it would just make a mess or for

whatever reason, right? But it will never tell you no. I've only just realized now that maybe this is a skill that I have honed for different reasons than coding is that my fiance, say, Shima and I constantly, like, if we disagree on some kind of factual thing or whatever, she'll be like, well, let's just ask, you know, chat, GPT. And I'll be like, at first I'd be like, sure, a month later of that, I'd be like, no, sweetie. Like, I'm going to ask the question because you load your question. Like, it's so loaded. You put the answer that you want in your question.

And then she's like, no, I don't. And I was like, all right, well, ask it the opposite of what you said. And then, well, I don't want to ask it that. Because then, you know, so it's, there are ways where if you know there's uncertainty, like, you don't know if this is a good or bad idea. I will explicitly be like, hey, I'm looking for suggestions on how to architect this little piece. Like, give me five different things and tell me what you think the best is. Whereas if you already have like, oh, maybe this is good, but I don't know. And then you ask it, is it this a good idea?

It'll be like, sure, you can implement it like this, even if it's completely wrong. And I've never realized that that maybe is something I'm secretly or like silently doing. and that it's like it's a honed skill of like how to ask the question based on your confidence level of of what you're looking for. Yeah. And I mean, certainly if I'm not, if I'm confused,

right, right? And I know I'm confused. Then I will try to say, say something like, you know, don't change any of my code. Here's the problem I'm trying to solve. Give me three suggestions on an approach. Right, right? And that can be really useful.

But it's the times where, where I'm like, oh, I want to just add this feature. So please just add this feature. And it's like, sure. And it just destroys all of my code and, you know, generates a bunch of errors. And it's like, oh, well, let me go fix those errors. Well, now that unit test is failed. Let me just remove that unit test.

And it just goes off. And it's, okay, how about you just say, say, you know, I could do that, but. Yeah. I've played around with like rules to tell. it like don't like the two of my two biggest gripes are when it makes when it makes uh when changes are made that were not things the thing that i explicitly requested like i asked it to do x and it noticed something else and it went to try to do that other thing too and it's like no i told you to do this just stick with that and then the second thing is freaking comments it adds

so many comments and most of them are low quality comments so i almost i almost always when i'm asking it to do stuff like the last sentence all right is like no comment So my, yeah, an annoying thing I hit the other day is it's, it's, I had it refactor a file into a separate library and put it in a separate library. And I wanted it all set up with doxygen and stuff, C++ library to, to build a documentation. And so it does it all. And I look and the documentation is empty. And I'm like, I'm like, oh, why is this, right? Because I had all of, in the source file, I had all of the inline doxygen comments.

and I go and I look at the source file, and all of the doxygen comments are stripped, and it's just got one non-doxygen comment that says, this file was moved from this other library. I'm like, no. I found that for some tasks like that, if you ask it, like when you're asking it to refactor code, if you ask it like, hey, like move this file, like this, like I was trying to merge two libraries together, a similar thing. And asking it, like, just take the functions from this thing and put it into this other

thing. That was really tough for it. Whereas, like, for me, it was very easy for me to copy and paste all the functions and dump them into the file and then ask it to refactor it. But I think that what happens is when you ask it to, like, move code from one place to another, like, it doesn't, at least some of them don't have, like, a native tool for doing that. And so what it means is that the way that it's moving the code is it gobbles it up in the context, and then it spits it out in the output. And that means that your code is going through,

going through the network, and that stuff might happen to it when it does. Yeah, it's like, oh, let me read this code. Now let me try to recite it from memory. Yes. Yeah. Be sure to check these show notes, either in your podcast app or at ADSP the podcast.com for links to anything we mentioned in today's episode, as well as a link to a get-up discussion where you can leave thoughts, comments, and questions. Thanks for listening. We hope you enjoyed and have a great day. Low quality, high quantity. That is the tagline of our podcast. It's not the tagline. Our tagline is chaos with sprinkles of information.