Erik:
Hello, welcome to Picture Me Coding with Eric Aker and Mike Mull. Hello, Mike.

Mike:
Hey there.

Erik:
Mike, today's guest, David Beazley, is one of the best known people in the Python programming world recognized for code contributions, programming classes, and inspiring conference talks. He's written programming books, including Python Distilled and the Python Cookbook, Recipes for Mastering Python 3. He's also a fellow of the Python Software Foundation. I'm pretty excited to speak to David Beazley today. Welcome, David. Thank you so much for coming on the show.

Dave:
Glad to be here. Nice to meet you guys.

Erik:
Now, Dave, our listeners, some of them may be coming from the Python world. And if so, they've probably already heard of you, but others are not necessarily. Can you give a little bit of your background for our audience?

Dave:
Well, I guess my background is I started programming as a kid, sort of a child of the 80s, you know, personal computing revolution and all that. So I've been programming a while. Programming has always been something that I've been kind of good at, but it hasn't always been my major area of study. So in school, I was a math major, studied science physics, sort of professionally got involved doing physics software. So doing sort of computational physics kinds of things, but I always ended up more on sort of the software side of that sort of writing, you know, simulation code and other things. Part of that led to Python, ultimately, you know, that's kind of a long story, but at one point wanted to figure out some way to control physics software
and decided that Python would be a good way to do that. It was at least a lot easier
than doing it in C, which is what we were programming in at the time. So I sort of wrote some tools on that. And that, I don't know, has led to a variety of things. So, you know, kind of early career, I was doing a lot of work for the government, working at National Lab, worked at Los Alamos doing physics and then did an academic career, which kind of, I don't know, went in certain directions. I've done a lot of teaching kind of in academia. And then, I don't know, kind of this whole Python thing. I mean, it might sound weird, but I feel like a lot of this has been kind of accidental, actually. I mean, even like the Python book stuff, you know, I was kind of early involved with Python and some publisher. They're like, do you want to write a Python book? And I hadn't even thought about writing a python book and i'm like yeah okay i could do that and the only uh kind of requirement at least at that time is i showed him the the kernigan richie c programming book which was really thin and
i was and i was like if we're gonna do it i want it to be kind of like this then

Mike:
when you were starting python programming there's a little bit of resistance to it i imagine

Dave:
oh yeah no people hated it
the python people didn't hate it but like the the people in charge of things really did not like

Mike:
I mean, we sort
of think of Python as being sort of fundamental to the data science and science ecosystem now, but it wasn't always that way.

Dave:
No, we made people angry at the lab. Because I figured out how to run Python on the
 supercomputer, this like $30 million supercomputer. And we were literally running the 
 interactive prompt of Python on the supercomputer. And they're like, what are you doing? Like, you're just burning CPU cycles with your interactive REPL there on the supercomputer. Yeah, you know, it worked great because we were doing a bunch of interactive data analysis. But at that time, people didn't know what to, you know, what to make of it. I gave a talk about the Python stuff at the supercomputing conference. I remember it was like a room with about 500 chairs. I think like 20 were occupied. It's like, okay, I can see people really into this Python stuff.

Erik:
I started really working on Python maybe 2010. And at that time, there weren't necessarily jobs. You wouldn't go and apply and work just in Python. And I just found it interesting. I was fascinated by it. Very early in my career, I started learning about Python 3.
And I bought your book, The Python Cookbook. And I pretty much read that book cover to cover.
So I laughed pretty hard when you said K&R was really thin. The Python cookbook was like 600 pages, 700 
pages.

Erik:
And then there was a lot of stuff in that book that I thought these were normal Python coding practices. So I would do stuff. You have a section in there called concurrency where you were like instantiating an object. You put it in a queue and then you check if that the queue is exhausted. And I would do this and people go, where did you get this? I'd be like, isn't this normal? Like everybody
does this. I read this in the Python cookbook.

Dave:
That cookbook was kind of a weird project. So there was a cookbook prior, like there was like a second edition cookbook, which was a whole bunch of community recipes. So there was a site where people contributed recipes.
And what we were trying to do in that third edition cookbook is modernize to Python 3. And, you know, that was not an easy transition.
And essentially what we did with that third edition is Brian Jones and I, we had a spreadsheet. So we made literally a spreadsheet of topics
 And it was maybe 50 or 60. I don't remember how many topics were on the spreadsheet.
 It was just like, here are things that we want to put in the cookbook. And then we wrote the whole thing from scratch. Try to write it in probably like the most modern,
  forward-looking way possible. Where it's like, this is Python.  We're not even going to pay attention to the past. We're just going to look forward. and we're going to try to write the code in what we think is like a really forward looking way. And so
that
could be part of that. I mean, if you had people like, where did you get that? 
It's like, we probably just made it up. I mean, I don't know, for better or for worse.

Erik:
So one of the reasons we were eager to have you on the show is Mike and I have been talking a lot about what makes programming fun. What do we get out of it? Like personally, what's enjoyable about it? And I think looking at your career, you have talked publicly about how you could have stayed in academia and you didn't. And it seems like the reason you didn't was you followed your interest. Is that I don't know if that is that the right characterization?
What motivated you to get out of academia and
pursue what you're doing now?

Dave:
OK, I mean, well, I mean, the exact mechanism of getting out of academia was getting denied tenure.
but it was you know you hear the term publish or perish and it's like yeah somebody's
got to hold up the perish side of that right


Dave:
no i think a lot of that you know it's like i just genuinely like the programming stuff i like you know it's like here's this thing and it's like fun to figure stuff out and it's fun to make a big mess out of it and like the worse the debugging the better because like when you figure out what's wrong with it you know it's like you feel great one of the things i found in academia is that you didn't really do that i mean it became much more about management as a professor like uh where you know you're managing students you're managing grant you know grants and other stuff like that and and it's sort of like you got taken away from that the hacking stuff the programming stuff and and i you know i always enjoyed the programming stuff a lot more so

Dave:
I wouldn't say i like consciously had hoped to get to like, like thought quitting academia per se. But when I, when I, when I got booted out, I was like, yeah, okay. You know, I was like, okay, that was fine. I'm not going to do other stuff.

Mike:
So, uh, part of our format is that, uh, we talk about music that we listen to while we work. We know that you're a bit of a musician, so we wanted to give you an opportunity to talk about your musical experiences and your musical tastes if you'd like.

Dave:
Okay, yeah, I thought that's a very complicated topic. You're talking about programming for work. Like, what
to listen to? I mean, I guess one comment I would make on that is I listen to almost everything, 
including stuff that would be, like, probably cringe. I'll even give an example. I listened to the last, like, Lady Gaga album.
It came out, like, a week ago. It was like, okay, fine, you know. But I listen to jazz and other things. Actually,
this is really stupid, but since he asked about the academia thing, one of the first things that I was doing after
I got booted from the university is I had this bass player friend. He's like, do you want to play in a No Doubt tribute band? 
And I don't know whether people know who No Doubt is, but No Doubt Gwen Stefani, you know, like I'm just a girl kind of thing. 
I was like, I'm there. I'm like, I'll do it. So I'm like, I'm playing like keys and all of a sudden in a short-lived, no doubt tribute band. And I
remember visiting the CS department like about six months later. Somebody wanted to have coffee. I go in there and they're like, the faculty are like, oh, what are you doing now, Dave? And I'm like, I just said point blank, oh,
I'm playing a no doubt tribute band. And the look they gave me for that comment was priceless. I mean, it was just like, there's no response to that. Just turn around and go out the door.
I listen to almost everything.

Dave:
Maybe in the current climate of coding, one music that I like to code to would be the Mars Volta.
music is... Actually, somebody in the No Doubt band turned me on to that.

Erik:
Yeah, this is a safe space for musical choices. musical choice. We will not look down on you for any musical choice.

Dave:
Not even the Lady Gaga thing?

Erik:
Mike and I have pretty diverse choices.

Mike:
One of my sons was in a ska band in high school. He started a ska band in high school 
so we're totally there for No Doubt too.

Dave:
That was a fun group. I don't know. I had like 30 No Doubt songs memorized at one point. Okay, great. useful useful skill to have


Dave:
still play now i'm playing trombone and um like community band so that's like symphonic band like we have a 70 piece group to that and i'm also doing uh jazz combo it's like a four or five piece group on trombone so still still out there playing not no no no doubt thing no so

Mike:
a lot of your talks which i really enjoy have these sort of uh exploratory or even like whimsical themes. Like I, I really love the talk you gave about getting your Ohio scientific computer working again. That was, you know, that was kind of my era as well.
 Are you just making talks out of things that you're working on?

Dave:
Yeah. Most of the talks are just things I happen to be doing. So like that, the Ohio scientific talk that, that just kind of spiraled out of control. I mean, literally that got started because my brother found the computer in the basement.
And then he's like, oh, I'm driving to Chicago. Should I bring it? I'm like, sure, bring it. And so, you know, and then we powered it on and saw that it sort of worked.
And then I spent kind of the summer fooling around with that computer. 
And then it just kind of got, you know, I just sort of started real simple. 
It's like, can I communicate with it from my Mac just over the headphone port? 
Because those old computers, all they had was the cassette port. I was like, could I just put like a connector cable from my Mac over the headphone port and talk to the thing? 
I wrote some Python code for that. And then it just got more and more and more and more and just crazy. And then at some point it's like, oh, I got to give a talk about it. 
It's like too crazy. But yeah, nothing is really planned out. One thing that I have a lot of trouble with is being on what I would call the creation treadmill, if you will. 
If you're constantly forcing yourself to put out content. And I don't know whether you guys ever feel that way or not,
but that's really hard for me to do that with conference talks and stuff, to be in this mode where it's like, oh, I have to have a conference talk.

Erik:
At PyCon 2015, I saw your talk, Python Concurrency from the Ground Up. this is in Montreal and it was a similar experience and there were hundreds of people in the audience and you like live coded async event loop 
you're using co-routines it was amazing it was really cool and I've told the story a number of times but you were up there you're like writing it all in emacs if 
I remember right
so it's like completely stripped down emacs like raw environment and at one point you had this tuple unpacking like a destructuring assignment to an empty list and I didn't nobody I didn't notice it somebody in the audience was like what did you do there You just, you were like,

Dave:
I didn't notice it either until they pointed it out.

Erik:
Yeah. And suddenly we were like on this exploratory journey. And so the talk was more performative. It wasn't just here I am to teach you about this thing. It was go on this journey with me. And I think that's, what's been inspiring about your work and your careers that you model this exploratory engaged in what's happening process. And I think that's kind of what I aspire to, too. 
like I want it to be always that fun and I don't want it to
turninto drudgery. I want to follow that inspiration.

Dave:
Okay. Okay. That was kind of a crazy talk. If you want to hear more about how
that, yeah, that was a, I mean,
I would say the inspiration for that talk is I kept reading these blog posts where people were saying, don't ever, ever, ever do a live demo in a talk. And like, and like, no, there were a lot of people that are like putting these blog posts out. It's like how to give a conference talk. And then the number one bullet point, never do a live demo. And I had done live demos and talks before. I mean, I'd given talks and usually they've been like, well, five, like maybe sometimes five minute demo and other stuff. And, you know, I've been teaching classes and all these things. And I just had this, honestly, a brain fart of this idea where it's like, what if I just made the entire talk a live demo? Like just go against the rules of the talk, the prevailing wisdom. Let's just do the whole talk is live demo. And I pitched it to the PyCon people. I just said, I'm going to do this talk on concurrency. And by the way, it's going to be 100% live demo. And they bought it. Probably from the other talks, they're probably like Dave.

Erik:
You got a track record. They're like, okay, we trust Dave on this one. Yeah.

Dave:
But getting now, okay, so I got accepted. And then I'm sitting there and I'm like, oh, God, what the hell did I just sign up for? Like, OK,
know, it's so there were no like there was no backup on that talk. I mean, it's just live live demo. The way that that had to come together, I had to practice that talk in the same way that one would might practice a jazz solo. So I'm into jazz improvisation. So there were basically certain topics they wanted to cover in the talk, like threads and async. So there were maybe three kind of main topics. But I didn't know how that was going to happen. So the practicing, what I was doing for the talk is I just set a stopwatch on my laptop. So I just set a stopwatch, and then I would just start coding from scratch on my laptop. And I would just time it. Like, how long does it take for me to talk about these three topics, doing just a completely exterranean, you know, just kind of talking, going through the topic. And I'd get through it and then I'd stop the stopwatch. And I'd just look at what the time was because I knew I had like a 45-minute slot at PyCon. So you do it and then you're like an hour and 10 minutes.
And you're like,
shit. Okay, I got to cut something out. And so the talk went through about probably about 15 practice runs where you just learn to not cop about certain things. Like one thing I realized that if I did anything involving objects or classes, it was game over.
do any object-oriented programming, you know? And it's like, so you learn these things not to do. And then you get up there in the room and just pray that you're going to finish it in time.
I cannot
actually believe that that talk finished on the time limit. That blew my mind.

Erik:
Well, I think I was pretty blown away by how you ran the talk. And just again, like the live coding, like being in the audience for it, some of what you're describing was communicated. It did feel like free and fresh and kind of flowing. Like I think the jazz metaphor makes a lot of sense for me. And so when most of us didn't even notice that you had like assigned to an empty list and somebody was like, well, what about that? And we were all like, well, how does that even work? And you just went with it.

Dave:
Yeah, I had no idea.

Erik:
I remember the time Raymond Hedinger stood up, you know, he's contributed a lot to CPython. and he was like oh well here's what's actually happening we were it was like as a room we were involved in something together it was a really cool experience okay it

Dave:
was it was fun to do i mean i i kind of viewed it as a teaching exercise i mean i would i do teaching all the time so it was like just a really high pressure teaching teaching thing but you know maybe one thing on the prep the talk was practiced but not scripted that
might have been

Dave:
like uh like a key like i didn't it wasn't really predetermined what I was going to say per se, but there were certain highlights. And then if it, you know, if it went off in a different, like with that unpacking thing, like, whoa, okay, you know, let's, okay, we'll talk about that.

Erik:
I happened upon this article that you wrote for Login, the Usenix publication. This is back in 2014. The article is titled Python Gets an Event Loop Again. I was thinking about it because I was trying to remember your involvement in Async. I remember reading a lot of your work about coroutines. I had never heard about coroutines in 2012, 2013, and it was kind of blowing my mind, the stuff that you were doing with coroutines. And then it seemed like you naturally transitioned into talking about async, async.io. And there's a paragraph at the end of this article I was kind of happy to discover in 2025. You write, as for the future, it'll be interesting to see whether async.io is adopted as a library for writing future asynchronous libraries and applications, As with most things Python 3, only time will tell. And I kind of chuckled a little bit when I read that. Have you been surprised at all by the popularity of async IO or async programming in Python?

Dave:
Yes. Yeah. I have kind of always thought that I've always been kind of an async skeptic, to be honest, because like every single time I've seen async, it always turns into this horror show of complexity. and you know where it's like i mean there's like this you know if you talk to people oh don't look inside async
io because
your head will explode if you go in there and then and then you hear about people talking about callback hell and all these other things associated with async and so i've always been kind of skeptical of like like why are we doing a do you need async like what are you doing in python that needs the async like so there's been kind of a skepticism there and then Also just trying to teach it. Like I've tried to teach async on a number of times. And it's like whenever you bring that up in a class, the class is just over at that point. It's like just asynchronous thinking is super hard, like to teach and to get your brain wrapped around it. I mean, actually, that talk that you mentioned, the 2015 talk, part of the motivation on that is like, Can we just try to do something that explains async in some kind of way? I don't know. I've always been kind of an async skeptic, I guess. And so seeing it adopted, maybe that's been a little bit surprising. Maybe you're kind of surprised on the skepticism on my part.

Erik:
I mean, maybe, because I learned coroutines from you. I learned about async a long time ago, it feels like, from you. And now I write async Python practically every single day.

Mike:
I've seen the argument, and you
may have made it, that one of the difficulties with async is you have to sort of buy into it totally. 
If you use async, your whole system is async. You can't sort of use it in isolated places.
And I think that's one reason why I think I'm surprised how much it's taken off. You know, 
I run into this all the time when I was working with Eric. I'd find something that just doesn't have an async version,
and now you have to figure out some way to wrap that so you can use it without introducing blocking.

Erik:
The what color is your function problem?

Dave:
One thing on the async I think is super interesting is the SANS I.O. stuff. I don't know if
other people have seen that, but Corey Benfield gave a talk, I think at PyCon, it might have been 2016 or something, but about implementing network protocols without a dependence on an I.O. layer.
That is a really interesting approach, and I've kind of taken that approach and expanded
it in other areas,
like in courses where it's like maybe async would be used, but trying to write code where I can test it and work with it without having a dependence on the async I.O. So maybe I can use some threads or something.

Erik:
When I took your raft class, we were doing socket programming. We're running these RAF nodes. And I loved that class. It was absolutely phenomenal. Listeners, if you have a chance to take one of Dave's classes, I would urge you to do so. Dave, you offer quite a lot of different interesting classes. But the RAF class I took was, I would call it extreme or hardcore programming. It's a week long. We're going to build RAF in a week. We were using sockets and lower level networking. And we're like, we're going to just define our own protocol. It was absolutely phenomenal class. And I remember I was so turned around trying to make sure that I was able to cancel threads or shut down threads. And I just kept saying, I think async would be easier. And I remember he being like,
I don't know, buddy. I think you're just trading one set of problems for another set of problems.

Dave:
That class is nuts. Probably not selling it well by that description. But when I came across Raft at one point, I tried to code it, and I just got
destroyed by it. But first time, I was like, whoa, what is this? Needless to say, I was like, oh, that's going to be a good class.


Dave:
you know, like two summers ago, I had a pair of programmers show up in that class. Probably between them, they had like 60 years of programming experience. So they're like super experienced devs. They came in and announced on the first day, we're going to win. We're going to win Raft. We're going to pair program. And then by the fourth day, they weren't even talking to each other. It's probably the first time I've ever seen a pair programming divorce.

Erik:
So here you are breaking up marriages with your classes. You're ruining friendships.

Dave:
Brother versus brother. Well, I just couldn't fit. I mean, I'm willing to, you know, it's like, okay, win. Okay, maybe, you know, I'm not, you know, that confident in my programming abilities. You know, maybe I suck at programming. This will be different, but, you know, I kind of got killed the first time I tried it.

Erik:
I think following on the async and the concurrency path, you had a library curio where you were exploring patterns in async. And that, I think, was the inspiration for the structured concurrency movement, which went out all over the place. Now you see people talking about that in Rust and other languages. But maybe Curio is just one example for me, and this might be the wrong characterization. I see you as kind of a reluctant open source maintainer. Is that a bad characterization?

Dave:
It's probably accurate, yeah, a little bit.

Erik:
Can you talk a little bit about the burdens of open source and why you are reluctant to be kind of behind the wheel of a popular or
term project, I guess?

Dave:
Yeah. OK. Yeah. What to say about that? I think for me, the open source just personally, it's like publishing ideas and stuff where it's like, hey, here's this cool thing. Right. It's like, you know, we're messing around with code. here's this cool, interesting thing that we could do. And they're going to put it out there with the hope that, you know, people will play around with it, you know, have fun with it, maybe
contribute to it,
learn from it and so forth. You know, so those are like the curio project in some sense, I got inspired by, you know, like can we just like re-envision the async IO thing in a different way and play around with it, whether it inspired structure concurrency, I, maybe, that was not, I was not thinking about that. So that would have definitely been like, you know, Nate's thing. I think, you know, Nathaniel or something like that worked on
that.

Dave:
But one of the things I've kind of noticed at open source, and maybe this is a bad characterization of it, but I feel like a lot of it has really started focusing on being what I would call professional. You know, like that can mean many different things, but you put a project out there and it's like there's all this like professional stuff. You've got to have the right license. You've got to have the right tooling. And, you know, it's got to be formatted correctly. You've got to have the type hints on it. It's got to be blessed. You know, like the code has got to, you know, I don't know. You've got to do like the 50 blessings on the code that everybody wants. And it's like, to me, that's just not that interesting. Like, I'm not that, you know, I get it. I get the importance of that. But
that's just not
where I'm at. Like, that's not what I want to be doing.

Erik:
I'm going to take your library to work and show it to my bosses. It's got to look professional, Dave.

Dave:
Yeah. And I'm not saying I want to be unprofessional, but it's just like, you know, that like, like, and now, you know, things like I've got to have like, you know, software bill of materials like all the supply chain. I don't know. I don't care about that. And so I've kind of backed off a little bit.
I kind of feel like my model of the open source is more the free puppy model,
I can give you a free puppy. And believe me, puppies can be awesome. Like, this puppy is going to be great. You treat it right. You know, it'll be your best friend. And it'll lick your face while you're tying your shoes. No, it'll be great. But it's your puppy. Like, it's not my puppy when I give it to you.
It's your puppy. Okay, so that's, I don't know. I sort of feel the same way about code right now. It's like, I'll put it out there. But if you take it, it's your puppy at this point.

Erik:
There's maybe another related question involved in what you're saying, which is it's like when I am a user of open source, maybe there's a negative pattern here, but I kind of expect it to never be done. I expect your work to not be once. It's not finished. It's you are. You produce this thing. You put it out there in the community. I expect you to permanently be improving it and supporting it and fixing bugs or fixing CVEs. Is that part of what inspires your reluctance as well? It's like, you don't want to be tied to these ideas forever necessarily.

Dave:
Maybe. I think it's okay for a code to be done though. I mean, maybe it's just this thing and that's what it is. Like, here it is and this is done. I'm like, I'm fine with that.

Mike:
So Eric and I both, I think, really just like to write code. And we tried to do an episode called Why is Programming Fun? And we couldn't really articulate it ourselves. And we asked friends, you know, why do you think it's fun? Do you have any thoughts on that?

Dave:
I think it's just, I don't know. It's fun to figure stuff out, you know, to solve problems and to figure, you know, figure things out, see things work and so forth.

Dave:
I don't know. I just, I think it's fun just to kind of dig into stuff and play around and, you know, try to figure things out on your own. And, you know, I don't know. I think kind of the figuring stuff out is like a really just fun thing.

Erik:
It reminds me of when people talk about vibe coding and AI coding now. Mike said to me a couple of months ago, it just doesn't seem as fun to be using LLMs to write code. And I kind of had a similar feeling. And so when people talk about vibe coding or LLM coding, they seem like they're having a good time. But I have a hard time getting real worked up about it and excited about it because it just doesn't seem as fun to me. Maybe I'm just old school or maybe not old school, but maybe my expectations are based on me trying to puzzle through things. I don't know. What do you think about when you hear people talk about the vibe coding, LLMs, AI stuff? Is that a threat to what we're doing? Or maybe it's just a different way of the same thing?

Dave:
I don't know. It's not my thing personally. you know it's like i don't really want to i don't really want to do that and and maybe you know maybe this is like an analogy from music right it's like i i learned how to play musical instruments you know it's like i play piano i play trombone and stuff like
that and

Dave:
you know a big part of the enjoyment of it is actually being able to like play the instrument i don't i like i don't really want like a to just press like a button and have it like pop out like a trombone solo or something like that it's like okay like i don't like i don't i don't want that but you know at the same time i mean you see like some of these like new musical art forms right you know like heavily like you know like a lot like rap and stuff where they're using heavily involved like samples samplers and samples and things like that where it's like okay they're playing some sample from a jazz thing and okay the guy's not playing that but at the same time there's something creative going on you know i can say well okay i don't really you know the sampling thing is not my thing but i can still listen to what's happening and say okay well something interesting is happening here maybe maybe it's that i you know i don't know your point about the vibe coders claiming that they're having fun maybe they are having fun and it's just not you know it's not my fun but i don't

Erik:
i guess it's a contrast for me because i i don't know why i find programming engaging i i don't know why i find it like i've read some of your some of your work and i'm talking about like some of your python examples but it's like you're going on a journey and you're on this exploratory process and you suddenly get this point where you're like oh wow i didn't know you could do that there's this light bulb moment i have that sometimes on my own and it's that light bulb moment that i i come back to the
just i just went somewhere i'm not just solving a problem but i'm on this like discovery process something happened and it feels ineffable like it's very hard to get at that creative part

Dave:
i guess one one thing that worries me a little bit about the ai coding is i feel a lot of it is so focused on just getting an answer

Dave:
opposed to the discovery process and I just, I don't, you know, I don't know. I

Dave:
there's a discovery process and it's just operating at a higher level that I'm not seeing. But that's one fear. It's just, you know,


Dave:
we don't really, you know, we don't care how any of it works or anything like that. We just want to see the final result.

Erik:
That's been my complaint working with data scientists in the past. I don't really care that much about how the code looks. It doesn't have to be pretty. It doesn't have to make sense. I've got my I's and J's and at the end, you pull the crank and out of the machine comes the answer that I want.
Could you ship that, please?


Dave:
Well, that's actually kind of been part of my problem with some of the AI stuff, actually. As a programmer, I feel like so much of that just feels like install this framework and do this command. Maybe the data science is the same thing. It's like, just install pandas and then tell me the command to type to do the data science. I'm not into that.

Dave:
I want to know what's going on inside.

Dave:
What's the algorithm going on? How does it work? I don't care about the command that much.

Erik:
The people who come to your classes, I'm curious about that audience. What are they looking for when they come to your classes? Are there patterns? concerns? What are they seeking?

Dave:
I think, so a lot of the people coming to classes tend to be a little bit older than I've noticed. I don't tend to get like college graduates in there, but I think I get some people who are interested in just kind of doing like a challenging programming project, but they're

Dave:
like, I don't want to enroll in graduate school, right? You know, it's like, I don't want to take on it. I don't want to sign up for a master's degree program just to take compilers class or something like that so part of was i i get like certain people like that where they're just like oh i've heard that you know you know writing a compiler or something is you know

Dave:
an interesting project and it's like fine you can come we'll do that and you don't have to sign up for graduate school so i i get like probably certain crowd crowd like that um sometimes get managers who've realized that they haven't been coding in a while or they're

Dave:
like i can't code at work because i'm doing with all this management stuff so they're just like i'm gonna go away for a week and then i'm gonna i don't know relive the love of coding or something on some project so

Dave:
Why did you sign you took a course like what motivated you to sign oh 

Erik:
i took the raft course i read the raft paper 2016 2017 at papers we love i started getting into kubernetes i read that RAF paper and had notes all over it. And I really liked it. It never would have occurred to me to try to code it. And then I started seeing you on Twitter talking about how you have this RAF course. And it was just, it sounded gnarly. You were like, we're going to code RAF in a week. And I thought, I want to do that. I want to go. And it never would have occurred to me to be ambitious enough to read the paper and try to build the thing. I wanted to just understand the paper and i took your class and i loved it it was
 although i didn't finish my raft implementation a little bit of shame

Dave:
i know nobody does

Erik:
i wanted the challenge yeah and i i wanted to like you know that you understand a thing when you can build it


Dave:
it i'm really interested in kind of the problem solving space right now where it's like you have a project like that and it's like how do you start on it and how do you break it down into pieces and kind of work with it so i'm really interested in that a lot right now just you know the like problem solving and problem decomposition and how parts fit together and and so forth

Erik:
mike and i i keep telling him we got to come take your compilers class.

Dave:
Yeah. Okay.


Erik:
Yeah. You might see us in there someday. And by the end, we won't be talking to each other.

Dave:
Yeah. Well, just don't pair program it. That'll be fine.


Mike:
One of the nice things about Python in the early days was that it would fit in your brain. And I don't think it does anymore, at least not in my brain. So in 2025, as opposed to, you know, 20 years ago, do you think it's still a good language for people just starting out and trying to discover programming? I

Dave:
think it's still a good language, but I agree on that not fitting in the brain thing. It's like the complexity has gone way off the charts, at least as far as I'm concerned. The one thing that I've been thinking about a lot is just how can you program in it without getting overwhelmed by a whole bunch of details. You know, because it's like you start off just sort of writing super, you know, like really simple code. It's like, can you get back to just writing simple, you know, simple codes? I've been thinking about that a lot, just generally. Actually, I have this, there's this quote that I picked out of a video I saw over this last summer. There was some video from like 1975, believe it or not, talking about like programs. Programming, I'll maybe dig up a link that you guys can post. But there was this quote in this video that really struck me. And here's the quote. It said, we shouldn't worry too much too early about language details. Otherwise, we don't program, but just code lots of details. And that really sat on my brain in terms of like the problem solving thing. Maybe to pick on async a little bit. You have some project, you want to implement RAP. If your starting point, you come in and say, ah, async. It's like immediately you're focusing on an implementation detail that is sort of completely unrelated to what the problem is. It's like, what problem are we even trying to solve here? So I've really been thinking about that a lot. Like, can you stay focused on what the problem is and then worry about details later on? You know, you definitely program Python in that way.

Erik:
Mike and I saw Leslie Lamport speak a couple weekends ago at a conference in Pasadena called Scale. And he had the title of his talk was Coding Isn't Programming. And he was saying programmers love talking about languages. They love thinking about languages. They should stop worrying so much about languages. They should think about algorithms. They should think about abstract programs. Of course, he's alluding to TLA Plus. He did mention it a couple times. But he's saying you should really just think about what the sequence of states in your program are going to be. And everything else is sort of a detail. It sounds similar to what you're saying. Is that


Dave:
Yeah, I think so. You know, I mean, something else. So this is something else I've been doing in classes. And if you'll allow me, I'll pick on Rust a little bit. I'm going to pick on


Dave:
Graydon Hoare. And all respect to Graydon, by the way. So he apparently, one of the origin stories of the Rust language relates to elevators. So there's this story about Graydon Hoare living in this high-rise building and having the elevator be out of service all the time. And apparently this was some inspiration to creating Rust. And so there's this quote in this article about Graydon. And he has this quote. He's like, it's basically, it's like, it's ridiculous that we computer people can't even make an elevator that works without crashing. With this, you know, with this thought, it's like elevator. It's like,

Dave:
It's like a glorified, it's like not much more than a toaster, right? I mean,

Erik:
it's like. So easy. Yeah, easy. So easy. So

Dave:
I had, you know, I'd actually been doing an elevator problem in a course before I ever saw this quote. But, you know, I've got this project where it's like, okay, now I'm using this quote. It's like, okay, computer people, code an elevator. Like, tell me about an elevator, code it. And it ends up just being this horror show of, like, disaster go. I mean, like, every time. And it's like people are like, elevators are, like, way more complicated than they appear. Okay, so there's that. And then the other thing is, it's not can you just code, like, an elevator? How can you prove to me that it doesn't crash? And that's like a whole other horror problem as well. And so, you know, getting back to the thing that you just mentioned, I mean, part of the problem there is do you even understand what an elevator is? Like, forget about the coding part. Do you even understand how elevators work? And that turns out to be like a surprisingly difficult question to pin down sometimes.

Erik:
I think just recently on Mastodon, you posted that you had some code that people, it had a bug in it, elevator implementation. Is that right?

Dave:
People virtually never, ever see the bug.

Dave:
Yeah. Well, I had an experiment just this last week. So there's a flip side to this problem. I have one version of this problem where it's like you code the elevator and prove that it's going to work. And then the evil twin of this thing is

Dave:
I give you code for the elevator and you prove that it doesn't have any bugs in it. and so I gave that that version to a group this week at a like a high frequency trading company where they like super experienced programmers like well

Dave:
maybe not experienced but super smart people out of like MIT and places like that I'm like here's your code prove to me that it doesn't have any bugs in it and they got kind of close but no it was

Dave:
AI didn't get it either so it's

Erik:
Can I go back to just one thing you said there? You said that programming in Python has gotten more complex. There's more details. You mentioned async. Are there other details that are getting in the way of just the pure problem-solving stuff? Anything else that has accreted over time?

Dave:
I don't want to dump on the typing stuff, but that is like a whole different universe of programming, getting into the type hinting kind of thing.

Dave:
In Python, in particular and it's like there's like a surface level of typing where it's not too bad where it's like okay that's fine but there are certain features of Python that make that extraordinarily difficult and then you end up fighting like you're just going down this rabbit hole of weird complexity with type hints and that

Dave:
I don't know whether I'm into that are you guys doing type hinting code at all?

Erik:
It's pretty common in function declarations. It seems a lot less common. This is just day-to-day professional code. Professional maybe makes it sound better


Erik:
than it is, but within the guts of a function definition or class method or something, it doesn't seem as common. It seems really common now to see it in function declarations.

Mike:
I think it will probably be more common because a lot of the LLMs stick it in there for you.

Dave:
Okay, yeah, they're picking it up. One thing that bothers me a little bit, I feel like the mix of untyped and typed code is really just a weird place to be programming. I mean, it's kind of strange. Over this last year, I taught a course where you use Racket, which is a scheme variant. And one of the things I thought was really interesting in that is that there's a typed version of Racket. So normal racket is kind of like old Python, kind of dynamically typed, untyped thing. And then

Dave:
they have this typed racket variant. But one thing that was super interesting about playing with that is that they strictly separate the two worlds. Like you can code in untyped racket if you want, and everything is untyped. Well, actually, untyped is maybe not quite the word I would use, but dynamically typed. It's kind of more like Python.

Dave:
And then in typed racket, it's very strict. Everything has to be typed. There's no choice of not typing it. So it's like you have these two very strict worlds. And then there's a lot of attention being placed at the boundary between the two worlds. So it turns out that both of those languages can talk to each other, but there's a lot of attention on the boundary of that. So if untyped racket is going to talk to typed racket, it turns out that there's going to be a runtime check at the boundary to make sure that you're obeying the types. So there's a runtime check.

Dave:
If you're going
the other direction from typed racket into untyped, then you have to tell the typed racket what the types are. So in advance, you've got to say, well, this is what's going to happen on that. call, on that operation. And just that really separation between those worlds was super interesting.

Erik:
I was like, I kind of wish we had that in Python. It's like we could have typed Python and untyped Python and have just a little bit of a more defined boundary between the two. I
think it would be cool. I guess I feel like sometimes I see type hints in Python code and in the back of my head I'm thinking, is this a lie? Because I could call it with whatever I want. That's the part that frustrates me. No,

Dave:
the typed racket thing, it was definitely not a lie. I mean, it was like literally compiled. Like if there was any type violation at all, it just would not even like run or anything. So it's like this

Dave:
idea of lying in Python. You could not get away with it in that. I thought that was

Mike:
There's a part on your website where you're talking about Python distilled and basically you say a recurring theme in your talks is how much 
low level information does a user need to know to be productive. Eric and I have had this conversation a lot and we actually did an 
episode on how much do programmers need to know about computers. Since I am old and started out writing assembly language, 
I have this opinion that that experience writing assembly language and learning how memory works and sending 
stuff through parallel ports actually helps me, you know, even this, even now, 40 years later. 
I know that you also, you know, based on your talk about your Ohio Scientific Computer, you've done those things, too. 
So, you know, do you think this modern environment that we live in now where everything is in a Docker container and a 
virtual machine and a cloud orchestration system kind of
takes away from the fun of learning and hacking? 

Dave:
Yeah, that's a good question. Do you think they're even kind of the same thing? I mean,
actually kind of in agreement that the low-level stuff has always been useful to me. 
But maybe I feel it's useful in just kind of a general thinking sort of terms. Like it's like going very low-level 
forces you to kind of think very clearly about how things kind of interact. You know, I don't know whether – like I don't know. 
having the deploy... You're sort of talking about deployment things, which are sort of at such a high level. 
I don't know. Is your concern that it just hides everything from view and nobody gets to see it?

Mike:
That's part of it. We've talked about how one of the intersections seems to be in scheduling. 
Even if you're just deploying something to Kubernetes, you still have to think a little bit about how much
 CPU it's going to use and how much memory it's going to use. And eventually that thing has to get put on a CPU. 
 And my view is that it's useful to know what's happening at the level of the actual computer.

Dave:
Okay, yeah, the layers of the thing. I think it's definitely useful to know that. How to teach people that? I don't know.

Erik:
Mike usually puts me on the other side of this conversation. If I don't have to think about stack and heap, I'm happy to not have to think about stack and heap. I think I recall when I took your RAV class that you talked about having an operating systems class when you were a CS professor. Is that right? Did you

Dave:
use operating systems? I used to teach operating systems. And that was like implement an operating system. That was great.

Erik:
Yeah. So I want to get. So what was good about that? What was your goal for your students to get by the end of that class? What do you want them to understand?

Dave:
I think part of it was just the stack. Like, you know, this, like the technical step going all the way from like machine code up to kind of like maybe the level of programming languages. There was maybe a secondary goal in that, which is that was probably the single largest software project that any student would ever code in school. So there was definitely a software engineering component to that as sort of how do you manage complexity and how do you test it

Dave:
and other things. But I definitely think that was part of it, just kind of understanding what's going on under the hood of that.

Erik:
I think there's so much, if you just take a piece of that, obviously the Linux kernel is millions of lines of code. You look at CFS and the scheduler in the Linux kernel, and that's a massive chunk of Linux kernel. There's so much complexity at all these different places where you could pause and dive deeper that it is almost easier for me to be like, ah, I'll just stay over here at this end of the pool that I'm interested in. I'm deploying stuff. I'm writing Python or Rust or whatever. And I could just sort of wave that other stuff away because how far do I need to go? The mental model that you mentioned seems extremely valuable, but it's hard to dip your toe in when you have this
massive wall of complexity below the surface.

Dave:
I've been struggling with that with the kids. I mean, I've got two kids. They're in high school now. And neither one is really, I don't know, they're not into coding.

Erik:
They're into video games. They're not into coding.

Dave:
And then, you know, and I've kind of seen like what they do in school. And what they do for coding in school just doesn't seem that motivating to me. I mean, it's like very high level where it's like you're not really exposed to anything deep. I mean, yeah, you see like little sprites moving around on the screen and stuff like that. And so I, part of me feels sort of like a failed parent, you know, tech parent. It's like, okay, they didn't get the kid to do coding. But I did do one project with a kid, which I thought was awesome. Okay. So I had, so I, you know, I have some vintage, he was wanting to do, he needed to do a project, middle school project. And he didn't know what to do. And I was like, well, maybe you could do a project about how computers work or something. And he was like, I don't know. It sounds like coding. I'm like, no, no, no, we could do something different. So I showed him the insides of like an Apple II. I was like, here's the – I have one. And it was like, open it up and looked inside. And then there's a bunch of chips in there. And then I told him, it's like, you

Dave:
know, I got a bunch of chips. You know, I have a box of electronic components. And then, I don't know, he went

Dave:
and looked at it. And then I picked out a, like a seven segment led display, you know, like they're just the led thing. He's like, Oh, I should make a clock. I'll have it count or something like that.

Erik:
Yeah.

Dave:
And I'm like, okay, we can do that. And then I don't think he like fully realized how complicated that was going to be. So I had like a tube that I, people, I think I'm crazy. I had a tube of like NAND gates that I bought online, like NAND chips.

Dave:
And I said, well, we could make this thing count, but you're only going to get to use NAND chips because that's all I got. And so this turned,

Dave:
we worked on it together, but it was actually really awesome, actually. So part of that process was actually just being able to turn binary numbers into seven segment display things. So there's that. And that involved a ton of algebra, actually. What you had to do is write out a, you'd take like every single piece of the display and you'd write out an algebraic equation for that in Boolean logic. It's just ands and ors. Like you do this for the, so you end up with like seven equations. And it's this mess of paper for that. And then he's like, oh God, where is this going? And then all of a sudden it turned into this huge algebra problem. The thing that was awesome is it made algebra actually real.

Dave:
In a sense, all that stuff you learned in algebra, we're going to do that now.

Dave:
Because it's going to save you from wiring 200 chips down to wiring 16 or something. So it went through all this algebra stuff and then it turned into this wiring project. This is a crazy project.

Dave:
And then, you know, all of a sudden, you know, we get like the seven segment display lighting. You could dial in like a binary number and see it like display. I thought it was awesome because it gave kind of a whole appreciation for just how complicated even like a really simple thing like displaying a digit is. And it put it like in a physical space where you can look at it and see like, wow, okay, there's like 16 chips on this board to do that. And I thought that was, I thought that was awesome. I don't think he's going to be a coder after that, but it was

Dave:
it was kind of a cool, fun project.

Mike:
That sounds great. I want to take that class now.

Dave:
I was doing
that in a class right before the pan, like not the seven segment display, but I teamed up with this Jeffrey calling guy. It was like a big Ruby on rails guy in Chicago. And he wanted to do like a computer science class for just people who never did computer science. So we teamed up on this class. And part of the class is like, you know what? I want to do digital logic with these people. And it was an in-person class. I put all these kits together. And for the third day of the class, it's like, nope, no coding today. You're going to get a kit. And then we built digital circuit for the day with just doing NAND gates and transistors. It was cool. But then the pandemic just killed it.


Dave:
And that's why I actually had all that stuff laying around. I was like, hey, kid, I got a whole box full of NAND gates. You want to build something? Let's do it.

Erik:
These classes sounded so fun to me. I want to go hang out at Uncle Dave's College and do all Uncle Dave's classes. Circuit. the circuit thing but yeah now that got


Dave:
i don't know but yeah i i kind of feel like like like just watching the kids like the school ought to do that just like i don't know program with nand gates or something we

Erik:
tried to talk a little bit about what makes programming fun if you go to las vegas and all the casinos they have these pamphlets about problem gambling and the
pamphlet's called when the fun stops and i also love that title because it's like it's like oh your gambling has become a problem now the fun has stopped there's like a moment in time where it stops but there's a maybe an analogy here somebody asked me recently about burnout in software dev and i said yeah it's real it happens a lot of people get burned out it seems to come almost for everybody eventually so maybe programmers need a pamphlet too when the fun stops do you i do you have any suggestions maybe advice is too strong a term but have you encountered people who get burned out have you ever had it yourself do you


Dave:
yeah i mean i definitely had it myself i mean in academia i burned out big time you know i was like disappeared from python like this probably would have been like 2003 maybe something like that and i i can i can even pinpoint it even to a date

Dave:
know i don't have the I can pinpoint it. It was like the third Friday in July of 2002. I had been under a huge pressure on a grant proposal. And I remember, I don't know, I went out after I submitted that thing and I'm just sitting in a jazz club or something. I just snapped. I was

Dave:
sitting there and it's like, I'm done. I'm done. I'm just done. I just knew in my mind. I was like, okay, I'm done with this. and kind of went through like a big, you know, burnout period, just, you know, which, which kind of, you know, sucked. I'm not going to, I'm not going to sugarcoat that. It really, it really sucked. You know, how to, I, I think, you know, I feel like a big contributing thing for me, at least with burnout, is like, is the work that I'm doing actually meaningful? Like whether it's like on a project or not, it's like, I think with your coding on stuff, You want it to be like some project that has like some kind of meaning to it or some genuinely like noble purpose of some kind. And unless that's there, you know, it's not so much the amount of work, but it's like, what am I spending my time on? Why am I doing this?

Erik:
Interesting.

Dave:
Trying to get out of burnout. I mean, I don't even, you know, I don't even know what to,

Dave:
I just started doing like a bunch of like really wildly different stuff just to try and get out of like the space. space that I was in, like started

Dave:
playing more in bands. Um, I think I started, I took like a French class downtown. I was like, Oh, I should learn French. You know, like, why the hell do I need to do that? But it just, just try like different stuff, you know, just get out of that, get out of the rut. So

Mike:
speaking of different stuff, I used to follow you on the platform formerly known as Twitter. And, uh, one of my favorite things was your, uh, documentation of your winter bike rides is that something you still do i

Dave:
have had to give up the winter riding um and the main reason for that is carpal tunnel

Dave:
and and which really i don't know like the cold temperature really aggravates the wrist for for some reason so

Dave:
to stop doing yeah I'm fighting with that.

Erik:
Sorry to hear that. That's a bummer.

Dave:
Either you guys deal with the...

Erik:
A little bit. Elbow, a little bit in the wrist, and it's exactly the same. It's not that cold here in San Diego, but I like to have my windows open all the time. I like the fresh air. And when it gets colder in the winter, I notice it. And as the weather starts warming up, it just pretty much

Dave:
goes away. Anytime I mention the carpal tunnel, people are like, ah, that's an Emacs crap that you guys. It's like it's coming to bed. Yeah,


Dave:
yeah, you're getting like you're getting punished for the email. And maybe. I don't know if it's, you know. Okay, you know, maybe. Probably a combination of Emacs.

Erik:
I haven't been an Emacs daily driver for years. Are you still using Emacs for your work?

Dave:
Yeah, I'm still using Emacs.

Erik:
I actually fired it up because I have Copilot, the GitHub Copilot extension in VS Code. And earlier this year I noticed that I would type a line. And if it were something I was expecting Copilot to help me with, because it's more trivial or something Copilot could specialize in or boilerplate or whatever, I noticed myself, I would type the line and pause. And Copilot would then suggest something. And then I've

Erik:
noticed my actually like my pattern, my flow state was different. And I was also kind of just a little bit more down at the time. I was like, you know what, turn this off. And so I started using Emacs and I went back to VSCO within a few weeks.

Dave:
Okay. And I don't know. People think I'm like some kind of Emacs master or something. Like, no, I only know like eight commands. It's like Emacs is what I learned in like 1990 on some job. They're like, Dave, here's a Unix workstation. Go figure it out. And I'm like, oh,

Dave:
We'll use that. But yeah, I don't spend a lot of time customizing or

Dave:
anything like that. I did write an editor for giving talks.

Erik:
Did you really?

Dave:
Yeah. But like some of those talks after the concurrency talk, I don't know if you've seen some of those, but there's like odd things that happen in some of those talks. Like one of those talks, I was doing basically impossible font rendering in the terminal. either fonts that were unusually big and then at one point rotated. Whoa. Like I'm sitting there in the terminal with this slightly rotated font. And, you know, what the hell is he

Dave:
doing? What I was doing, actually, is I realized that iTerm2 on the Mac could do inline images, like PNGs. So

Dave:
I'd written like this terminal thing where it would basically inject a PNG image of an impossible font rendering just in a very sly way and they would just sit there on the screen I was kind of hoping just to mess with people or like what the hell Emacs mode is like what is he

Dave:
doing in the terminal there and just kind of let it sit there he must have written some crazy Emacs lists just to run this talk

Mike:
anything you like to promote books or classes Is there anything?

Dave:
I don't know. I don't tend to be much of a self-promoter. Maybe I should promote the theater.

Erik:
Theater?

Dave:
Yeah, go to theater. I mean, since we talked a lot about some of these talks and things like that, this may be kind of a weird segue, but a lot of inspiration for some of that stuff has come out of theater. Really? So my wife goes to theater a lot. She's taken me to some things. And some of the stuff that I've seen in theater has just blown my mind. One thing in particular is we went to a Samuel Beckett play. This thing, I think it was called Crap's Last Tape. So Samuel Beckett. And Samuel Beckett, he's probably more well-known for this Waiting for Godot. Yeah. It's kind of this absurdist thing. So we go to this, this play and like the, the actor spent 20 minutes eating a banana on stage. And, and I was like my wife, she looks over at me. I'm like riveted, like in this play, like, what's he freaking going to, what's he going to do with this? What's going on with this banana? Like he's wandering around just for like nothing, nothing is going on except this guy is eating this banana. And, and it's like certain people in the audience are actually getting kind of angry they're like we paid like 100 bucks to come to this thing and watch this guy eat this banana you know what the hell did this guy do


Dave:
You know so finally you know he you know finishes the banana and they're like okay and he like sits down at his desk you know 
he's like you know desk on stage you're like okay something's gonna happen he opens the drawer and pulls out another banana. 
I'm like, oh! At that point, the audience is like, either people were really into it or really angry. 

Dave:
That's how he puts the banana away. That sort of thing has always been on my mind, even with the technical talks a little bit, where it's like, oh, man, it's just something I can do just to mess with people a little a little bit you know like you mess with the fonts or something like that

Erik:
so so like you're thinking about talks as like a genre you know as like a performance art


Erik:
and yeah i don't think anybody i've i've been to any other talks where people treat it that way they're trying to give a good presentation they're trying to be engaging and funny and dynamic

Erik:
but they're not thinking about the genre of the genre of talks talks i

Dave:
have this idea concept i don't think i could ever pull it off so maybe i'll throw it out there as a challenge for somebody to pull up but i thought about this like this this is a theoretical inspiration for a live demo so having done like the live demo talk i thought it would be really cool to do a talk where you get into like a live demo and then it goes just horribly wrong and and the response to it going horribly wrong is that I freaking rage quit the talk. Like I take like the laptop and I smash it to pieces over the podium or throw it on the ground and then just like leave the room. Okay, like just run out of the room. And then people, so this in my mind, like the audience would be like, holy shit, like what just happened? And then what you would do is all of a sudden, like 30 seconds after that, you'd be like, ah! And then you'd come running, I got it. Like you'd come running back in. but your laptop is smashed. So then what you would do is you'd point at somebody in the audience and be like, oh, can I use your laptop? And they're going to be like, no, no, no, no, no. I'm not going to let you use my laptop. I just saw what you did to yours. Because they convinced them to give them your laptop,
and then you plug it in up there and open it up, And then the code would be at the same place where you left off.
Oh, like a magic trick. It would
be like a plant. Like somebody in the plant. Like you'd have the code in there. And then people would be like, what the hell is going on? I thought it would be fun to do something like that. It would probably be some gross violation of the code of conduct or something. I don't mean,

Mike:
I don't know. If you do, please let us know so we can go to that conference.

Erik:
That'd be like Andy Kaufman giving Python programming to our just software software. software talks.

Dave:
Yeah, maybe it would be like an Andy Kaufman stunt or something like that. I don't know logistically how to pull something like that off. I could see it. It'd be fun.

Erik:
So, just to clarify, do you do a separate compilers course, or your compilers course is crafting interpreters with Rust? No,

Dave:
the compilers are totally different.

Dave:
Do whatever you want. The Rust thing is specifically, it's kind of like, let's learn Rust by writing an interpreter.

Erik:
Okay, that's pretty cool. Both of those sound right up my alley. I would love to do them. Maybe you'll see us soon.

Dave:
Yeah, maybe. I don't know.

Erik:
Well, David, it has been phenomenal having you on the show. Thanks so much for talking to us. It was really a blast.

Dave:
Thank you.

Erik:
So this has been Picture Me Coding with Eric Aker and Mike Mull and our guest today, David Beasley. Thanks so much for coming on, David.

Dave:
All right, thank you.

Erik:
All right, we'll see you again next week. Friends, bye-bye. 

Mike:
See you next time.