Pybites Podcast

#169 - Bridging Python and Rust: An Interview with PyO3 Maintainer David Hewitt

Julian Sequeira & Bob Belderbos

In this episode Bob chats with David Hewitt, passionate Python and Rust programmer, core maintainer of PyO3, and part of the Pydantic team.
 
PyO3 lets you write a native Python module in Rust, or to embed Python in a Rust binary. David shares his journey of getting involved and how this tool set helps Python programmers integrate with Rust more easily. 

We talk about how PyO3 helped the Pydantic v2 Rust integration, how to design for a great developer experience, the mindset of dealing with complex issues, PyPI getting more packages with Rust, how to best learn Rust and more. 

Enjoy and let us know when you give PyO3 (and maturin) a try ...



Reach out to David: 
https://github.com/davidhewitt 
(additional social media links there)

Ad segment: Pybites PDM coaching program: 
https://pybit.es/catalogue/the-pdm-program/

Join our community: 
https://pybites.circle.so

Hello, everybody, and welcome back to the Pibytes podcast. This is Bob Eldeboz, and I have a very special guest with me today. With us today is David Hewitt. David, welcome to the show. Hey there. It's a pleasure to be here. Thanks very much for inviting me. Yeah, thanks for joining. We got the pleasure of meeting up at the astral event at Pycon Pittsburgh, and we had a really nice chat. And, yeah, I'm really excited about all the work you're doing, mainly about bridging Rust and Python. As most people know, I took on rust for a month or so, and now life got in the way. But I got to interface with your stuff and I think it's a plus. But we're seeing rust being used in the python ecosystem. I think it's a very exciting thing. So I'm going to ask about all the great stuff you do, but maybe to start off, people don't know you yet. Yeah. Can you give a short interaction? Yeah. So these days I like to describe myself as trying to unite Rust and Python. I've been working on PI Zero three, which is an open source, primarily a rust project, but it's an open source project that's meant to bring Python and rust together. It's that functionality used to cross between the two languages and then as well as that for a day job, I work with the team at Pydantic. So if you use the pydantic open source package, well, they now have the core built in rust. So that was started before I joined the team, but then I've done ongoing contributions to that piece, too. So hopefully I'm bringing useful functionality to you, maybe. Yeah, no, definitely. I think it's hard to find a Python developer these days that is not aware of pydentic and is using it in some shape or form. Of course, it's very big in fast API, and we all use and love that. Yeah. So, I mean, I think one of the obvious benefits of the rust port into Python is the performance and security. But just in general, what motivates you to work on this, to bring rust into Python? Yeah. So I think that talking about the performance is like a nice one to start with, actually bringing aside the whole connection to Python for a moment. One of the things that I hear a lot about people who talk about Rust is like, I came to rust for the performance, and then what they often go is, oh, but I stayed at rust for the reliability, or I stayed at rust for like, its ease of distribution or loads of other reasons that people have found joy in the language after they found it. And yeah, you're right, that like performance is probably that hook. So for me personally, I used to a long time ago now work professionally mixing Python and c actually. And that was like both for performance but also for like the reliability or like a compiled language can bring. Unlike Python with all its dynamic ness, you kind of have to deal with that dynamicness in production as well, which is for better or for worse. And so what happened then is I learned Rust separately to working on Pyro three. This was again predating that just as a hobbyist, I was really enjoying playing with Rust. And it was, yeah, the hook was the performance a bit, but also just like the pleasure of using the language. It's got some stuff that feels really familiar to python programmers, but it's also like got really, really nice modern functionality, things like options, which is like, we kind of have those in Python now as well in the type hit system like option int or whatever. But Rust has these two. And so then it got to a point where later down the road I was like, hey, I want to start contributing to the rust ecosystem, and then realized that PI three already existed before I joined it. But I was like, I want to use this and I want it to be better because it was still like a long way from being production ready at that point. And so ever since then, I think that's really been like the driving star. It's like it's a thing that I want to use and I can see it being useful to python developers for like, yeah, the performance or for the reliability or for any one of a number of reasons. People, you can talk to them about why they're using rust and they'll come up with different answers. And so for me, yeah, I just keep going now because it's like I still want to use it and I get so many feedback from people who are also, yeah, they're enjoying to use it and so it just makes sense to keep going now. That's awesome. So it really started something like scratch my own age, I really need this. And then you found that PI o three was already out there, it was already in existence, and then you started to contribute it as the obvious way to do, to make a tool better that you really benefit from yourself. So how was that journey getting into it? Was that difficult or how. I mean, the whole endeavor is there's quite some complexity involved with this. Right? Yeah. So I was lucky again that I've been doing in the professional work before that the mixing of Python and c. So it kind of gave me, like, an idea of how, like, mixing python and a compiled language works. But, you know, then there's a whole different, like, set of problems to solve when mixing rust with python than there is with C with Python. How did I get started? I was just, like, I had some time to get into the open source project and started just contributing to small issues at the beginning, people were asking questions about how to use it or some functionality which wasn't working, maybe a bug report, or maybe it was more complicated things like, hey, I'm trying to make a blender plugin. Blender, I think, has a python API, but you can do rust pieces. Well, they wanted to compile rust into their Python Blender plugin, and I was like, how on earth is this supposed to work? And just, like, tinkering around and trying to figure out what people were using. It's like the constant question was like, hey, how can I make this better so that people don't find it so hard next time? And it taught me a lot about all of this integration. And, like, I wasn't, I wouldn't have said that I knew everything going into it. I've learned so much over those, like, five years now. And so, yeah, it's just like an incremental start from the really small. Like, hey, someone has a real need here. And then it got more and more high level and broad picture as I've gone along. Yeah, that's very similar to what Marcelo shared here on the podcast. Right. You just have to dive in. You don't know everything, but if you just work from the issues and troubleshoot and solve problems, or even just do small contributions, like documentation, but mostly working backwards from the bug reports, then you just organically grow into it, right? Yeah, exactly. I actually have some, like, interesting, or since, like, you know, the first features that I actually contributed to PI, three. Interestingly, I've now since ripped out again for various reasons, like whether they were poorly designed or, like, had subtle bugs in them or stuff like this. And so, like, you know, even that first stuff that I did, like, it solved some user needs at the time, but we learned, like, why that was a mistake later. So I think that was an interesting part of the journey, to realize that, you know, everyone's got to learn, and you go from the beginning. You don't need to worry necessarily about getting it right first time, because hopefully there's someone else to also guide you and give you feedback to make it better in the future. That's a good point. And we see that often with our coaching as well. In the program where people build applications, you don't have all the answers, so you just have to start and push code out there and you might have get it wrong, but then you fix it later. But what happens a lot in our space is that people get into that tutorial paralysis or paralysis by analysis, but you have to take those steps right, even if you might be wrong. But it's all fixable. Yeah, absolutely. And that's actually a good touching point on rust. Again, actually, is that compared to a language like c, I find that with rust, I feel more confident to try things. And the rust compiler, I guess you've experienced this yourself. It's very pedantic. It will tell you, hey, this is wrong, or it gives you quite good feedback as well on what you might try instead. But I feel a lot more confident trying experiments in rust, knowing that I'm not going to create massive security vulnerabilities just from typing three lines of code or whatever, which is a refreshing feeling. Yeah, I'm going to butcher this, but in one of the manning books, I think the rust compiler was compared with this very critical partner or spouse that's going to criticize you a lot before you go out of the door, and you will hate it, but once you get out of the door, you actually will look good because of all that. That's kind of a weird comparison, but, yeah, just that was my experience as well, especially coming from Python. The compiler is so strict and pedantic, what it seems. But then for your own good, right. That later down the road, things don't blow up because that unfortunately can happen with Python. It's so permissive. But then at runtime, you might find surprises. Yeah, precisely. Yeah. Okay, so, yeah, so PI o three, that has been pivotal in the rust, in the pydentic core rewrite, that's actually the tool that allows. That has allowed rust to come into the core of pydentic, isn't it? Yeah, exactly. So Samuel started, Samuel being the founder of Pydantic, who did all of the early work on it, including the beginnings of the rust integration. I think it was like 2022 or something. He started doing this. It wasn't actually the first time that he'd used PI three to build some python packages. He'd done one called rtoml and another one called watch files previously. But. So he took his experience from building Pydantic v one and thought, how can I extract the core logic of that and turn it into a rust program instead. So that really heavy lifting that Pydantic's doing, taking your JSON data or whatever and turning it into useful python types, is done in rust, which rust is very, very good at, and trying to just bring the speed up and the energy efficiency up and all of those good things about having a rust core to the package. Yes. Samuel was basically building it on top of PI O three, and at the time I got to know him because he was just reporting bugs on the PI three issue tracker or saying, hey, how do I do this? Because the documentation is not helpful. We incrementally fixed some pieces, and over time, the PI Atlantic core, as we call it, built up in rust about May 2023. So it's been a year and a bit now. It released for V two, which brought the speedups, and we've been working on it since as well. Yeah, massive. And also all the rippling effect of that and making fast API faster. Yeah. Yes. Samuel was on the podcast talking about this as well. Yeah. Super exciting. And are rough and polars then also using PI o three, is that. Yes. So, in different, uh, ways. So, um, Polis is using PI o three in the kind of way that we're already talking about here, where Polar's is a rust app or library where you import it and you use PI o three to, like, wrap the rust core, which Polas has to make a Python API, which, you know, if you're a Python user using polas, that's what you experience. You experience the PI o three wrapped API that polis is providing. Rough is a little bit different, because that is just a rust program that's passing Python source code and doing linting or analysis based on that. It doesn't actually use PI zero three itself, because PI three is more about talking to the Python interpreter. In Rust's case, there actually isn't a Python interpreter running. It's just a rust program, but it still uses our packaging tools to take that rust code, compile it, put it into a pip installable package so that you can just do pip install rough. So it benefits from the PI three ecosystem, if you like, but not PI three directly. Yeah, that's good to know. The others are more like libraries, and this is more like a tool. Yeah, it's good to know that both still leverage PI O three. Yeah. And is there also. So we talk a lot about getting Rust into Python, but the tool also supports bringing Python into rust, but I was not sure what the use case for that is. Yes. So the use case for this is more like you have a rust program. And an example of this might be a video game is quite a good example where the thing is in rust primarily for performance, but you want to provide some flexible extension language, like a scripting API or something like that. Then you could embed a Python interpreter using PI three and make calls from rust into your embedded Python interpreter, where you can let users provide plugins if you like. So that would be the model there. So a video game is the most natural fit you could imagine. If someone built a text editor, built in rust, then maybe they could use PI zero three to provide a scripting interface for it or something like that. Yeah. Okay. Makes sense. Cool, cool. What are you working on at Pydentec these days? Yeah, so I split my time. Pydantic is now a commercial company, and I think Samuel's actually been on your podcast before to talk about a bit of that commercial history. So I won't really go into it here, but so we have, as a startup, we obviously need to keep putting bread on the table if it were like. And so the primary focus for us at the moment is getting our first product to general availability. It's a product called Pedantic Logfire, and it's a. An observability platform. I think Samuel's talked about it, so I won't go into much more detail here. He was on the podcast the day or the week before launch or when it just launched, and we had even a quick demo on the podcast. That was cool. Perfect. Yeah. Yeah. So these days we're working towards basically getting to that general availability where we can say, hey, this is a product that we're feeling comfortable enough in its refinement that we can charge money for it, and then that's hopefully going to provide a sustainable future for the company. And so what do I do there? You can imagine there's a lot of data being pushed around an observability platform, and Rust is a little bit more efficient than Python at handling these large volumes of data. And so I'm working on our database in the backend at the moment and making sure that that's as performant as it can be because that's crucial for a good user experience to be able to access and retrieve and insert your data as efficiently as possible. That's interesting. Yeah, I'm having a lot of fun with that. We're working on providing a SQL interface to all your data, and it's about how to query it quickly and where do we store all that data to make it quick to retrieve. There's lots of interesting rust programming and I'm having a lot of fun working on that. But then I do a little bit on pedantic on the open source stuff. It's a bit less time for that at the moment because as I say, we're focusing on getting to availability for pydantic log file. But I still do read reviews of user contributions and I'm kind of thinking in the background about our next work that we want to do on the core pydantic core to make it even more efficient and easy to use in the future. No, that's fascinating. Yeah. Talking about the user experience, what I noticed as a new rust user how friendly IO three is, because I could, I remember I sent you that little mind map I made, and it was very easy to wrap my head around around and to write a little bit of rust and then integrate it and yeah, turn it into an importable library or function. And that, I think is also in part due to the metron wrapper, which takes care of the whole packaging aspect. But yeah, how do you think about the ergonomics of a library like this? Right. Python users being due to rust. How do you think about design to make this successful? Again, kudos. It really is accessible. That's really pleasing to hear. I think that's personally, I guess, one of my guiding stars of what I want to do with PI O three, it's important for performance to be good, but it's also equally as important, or maybe in some cases even more important, that the user experience of someone writing these bindings just, it works as they expect. And so I guess, like if we want to talk about the mature and wrapper in particular, as like a nice example of this, like I, back a long time ago, yeah. When I was mixing Python and C and trying to figure out how do I like, compile a C library and then turn it into something that's importable from Python and all of this, like, it was a really long, hard journey to like figure out how to get the C compiler to do what I wanted and how am I supposed to set this up so that python can import it properly? And then, oh no, the first thing that happens when I compile it is I get a segmentation fault and it all crashed. And it's like, well, why? And then it's like I sit down with the C debugger and try and figure out, okay, what on earth have I got wrong here? And one thing that I found just as a rust hobbyist is that your debugging experience tends to be a lot nicer because that compiler is so strict and it's about applying that whole ethos to everything. Let's just make the obvious thing feel nice and nudge users onto the obvious path and make it all just flow well. And so, yeah, Matchurin, the idea is that it should be just as easy as Pip, install my rust code and it can go away and do the hard thinking for you. Get all the compiler options right or all of that kind of complicated stuff, and then in combination with PI zero three being the actual like, code that you've written, it should just work. And it's like, you know, that's a really important thing to me. I actually like the first experience I actually had using PI O three as a user before I was a contributor to it. I was working on a personal project with my father and it was like, my dad's not a computer programmer, but he's a hobbyist. He's got a few personal projects that he does to look after some data for some volunteer groups that he's related to. And I was like, hey, you could process this data faster with a little bit of rust because he was reaching challenges of doing it all in Python. At that time, I wasn't contributing to PI three. I was looking through the PI three user guide and like, okay, how do I install this? How do I get this working? And I had a really hard time, just as I had had doing it with Python and C. And so that kind of experience, I was like, my dad was then just not going to buy into it. He was like, this is way too complicated for me to understand. And ever since then, that was like a lesson for me that if I want to tell other people, hey, you should give this a go, then it has to be straightforward and easy. Wow. So your dad had an influence on this, on your programming journey. That's awesome. I'm not sure if he knows that directly, but it definitely stuck with me. That experience of like, ah, that was just too hard. Whereas I think if I went back to him now and said like, hey, rust is ready for you to like, you know, use this in your application, I think he might be convinced this time. He actually does more stuff with like typescript and web frontends at the moment than he does with the python data processing. But maybe he can come back to that in the future. I think he'd be going to give it a try now. That's awesome. So, yeah, there's inherent complexity with all this, and as you described as a long, arduous journey. How do you manage complexity? Like, what is the mindset you adopt, the problem solving techniques? Because again, this stuff is just complex. I mean, I will link your Pycon 24 talk below. You also did another interview on a podcast. And yeah, the complexity there is large. So I just want to, from a mindset perspective, how do you tackle that? Do you have certain techniques, things that just work for you to manage complexity? Yeah, it's a great, great question. So some people are really good at self introspection and having measured approaches or like, hey, I know that if I want to solve a problem like this, I need to go have a coffee and write down the problem and map it out or whatever first, there's different ways that people like to think. What I find is, I guess I start by trying to think, what do I actually want people to experience here? What's the nice user end result? Sometimes it's, oh, this needs to be faster. Or quite often, the nice thing about working on a library like PI zero three is that people have an obvious expectation of, you have a rust string. You want it to become a python string. When you pass it across the boundary, it's like, okay, how do we make that actually happen? And then it's like, I tend to be a bit random of, like, I'm just reading material when I've got a chance to, to understand that problem. And it might be then, like, you know, I'm in the shower or like on a walk or whatever, it's like in the back of my head, it's just like going. Sometimes my poor family can like get really annoyed, actually, because, you know, like, if there's a problem that I'm thinking about, like that, it kind of consumes me a little bit. And then once I'm finished thinking, I'm really tired and it's like I almost can't stop myself sometimes when I'm in that kind of problem go too deep and it's been a problem for like 20 years or something, you know, it's just like, that's how I think sometimes. But blessing and the curse we have as programmers, right? Like, you cannot detach sometimes. Yeah, I remember, like, talking to my family about that, actually. Like, when I was a teenager, before I ever went into like, software as a professional. And I remember telling them, like, I shouldn't go into software as a professional because, like, when I do code, like as a teenager, I did a little bit of hobbyist coding just to play. I never really produced anything interesting, but I loved learning about it, and every time I did it, I had this exact same problem as a beginner programmer, my mind just got consumed by trying to understand this little thing that I was trying to do to my family. I was like, I shouldn't be a programmer because it just makes me too tired and it consumes too much of my time. 20 years later, it's like, well, I couldn't stop myself. Here I still am, consuming all my time thinking about it. My wife is very, very patient about it, and I'm very grateful to her for that. Yeah, we have to thank the wise partners in this. Was there an alternative? Well, so the realistic options when I was choosing what to study was between computer science and physics, and someone told me from their family, who was a computer scientist, that if you know, like, yes, there are important parts of computer science degree, but it's probably the easier to, like, become a computer scientist without a computer science degree than it is to become a physicist, you know, without a physics degree. And so I went. I actually ended up doing a physics degree kind of based on that kind of advice. But, yeah, at the end of the degree, then the cooling of software basically pulled me away from it pretty much straight away. Yeah. Gotcha. So, I wanted to talk about rust grow. Anything else you wanted to say on the complexity part? So I hear a lot of like, yeah, the tenacity of cannot let loose, you cannot detach from a problem, which is kind of what we have as programmers, but then also the real breakthroughs then come actually when you are doing something else. Right. Shower, walks, whatever. So, yeah. Oh, well, oftentimes, I guess if I was to break it down into a process, it's like, I need to know what the end result I want is, because without trying to find the end result, then I would just get lost in this sea of thinking about it. But once I've got that, then it's about. I kind of keep asking myself, okay, what bit do I not understand now? Or what bit is not working, and why is it not working, or why don't I understand it? And it's about going to some cases it's reading C Python documentation, or other times it's actually looking inside the python interpreter or looking at articles on the rust language. If it's a rust design question, reading and whatever kind of stuff, I'm always remembering. What's that end user experience that I want to get to in the end so that I don't get too lost in the depth. But there is often a lot of depth and you just got to go there. That's a great piece of advice. In our programs as well, we do mind mapping, but sometimes for people, that doesn't really work. And then we always ask about, do the ideal end user result exercise. So imagine the end user of your software comes in. How does it look? What can the user do? What will be their optimal experience? When you work back from that scenario? Then it becomes much clearer and it can be hyper focused. Yeah, definitely. I like to say that if people have built software in PI o three, that people using that software hopefully shouldn't notice that the cool is built in rust. It should be invisible to them. Is like a goal. I think in practice there's some bits that don't quite work like that, but that's the goal. Yeah. With my short exposure experience, I can definitely attest that that's the case. So three more questions. Rust growth. So, yeah, we see. I think you spotted a trend, right, that the rust related packages, and correct me if I'm wrong, the rest related packages was doubling every year on Pipi. Was that the. Yes, which was extremely exciting to see. So to talk about the stat a bit more specifically, I looked at download numbers, no, sorry, upload numbers to pype for different packages which contained rust. Like how many different packages in a given month were being uploaded which contained rust code. And I just looked at April, like every year. 202-020-2120 222-023-2024 and it goes in a pattern where every April, the number of different packages that have been uploaded with rust code in the next April has doubled. So it went from twelve to 25 to 50 to 100. I can't remember the exact trend, but it was that sort of pattern, and it was just getting twice as big every year. And I think c and c, for a sense of scale is something more like, maybe it was like 1000 or 1500 or something like that. So rust is still quite a bit smaller, but every year it doubles and it's becoming a bit closer to a comparable size. Will that trend continue? I don't know, but it's exciting to see for sure. Yeah. You presented that table in your pycon talk as well, I think, and I think c was more linear, but then there were just a lot of packages already around there. So the nominal number is bigger, but an exponential almost trend, and that might catch up very quickly. Right. But, yeah, we don't know, but it's kind of a signal that not rust has taken over, but it's definitely just being used increasingly also in the Python space. So I wanted to ask for the audience, mainly consisting of pythonistas, should I learn rust, and if so, why? Or is it more a matter of partner up with some great rust programmers and learn more about the integration? What would you recommend? So that's an interesting question. I think I would say it like this. I don't think as a Python Easter, you should feel like you have to learn Rust, because Python is an incredibly useful language, and it's because of its ability to tap into not just rust, but like c, C and like Fortran. And I think you can even mix like go or other languages if you wanted, into your Python code. But like, you don't have to do that yourself. It's done through other integrations, and the fact that Python can do this. And so Rust is just another one of those tools at that layer, if you like, and you don't need to know it, you shouldn't feel like excluded from being in Python, because Rust is also becoming a presence on the scene. But for those people that have an interest in doing so, then I think that there absolutely can be valuable insights to learn from learning a language like Rust. It has quite a novel take on a few different ideas. It cuts away object oriented inheritance. I don't know if you noticed that in the time that you were working with Rust, but it also introduces new concepts like lifetimes or traits. I mean, traits come from, I think other languages, more like Haskell, I think has a similar idea, maybe, and they feel a bit like Python's protocols, sorry, not prototypes, protocols, or abstract base classes, but they work a little bit differently. Or even things like rusthas enums as a language thing, and it's kind of hard to explain those without just going and try them, but I just love those as a concept. And so, yeah, for the python Easters that want to go a little bit deeper and want to have a try tapping into if you've got a problem where the performance is not good enough. As I say, that's often the first hook for why you might try rust out. Sometimes it's just for intellectual curiosity, then, yeah, it can definitely be a super valuable learning experience, and it might unlock a next level of what you can do with your own python, but it's certainly not an essential. Yeah, definitely. I did it for a month and then life got in the way in summer and all that. Also, I was just pressuring myself and it's like, no, let's take this as a long term journey. But it definitely expanded my mind. You just come way more rare typing. And so you start to be way more fanatical about type ins in python because you see the benefit in rust where it's required, the compiler, the tooling is amazing cargo, absolutely fantastic. But also, yeah, exception handling, for example, with match case. And there's definitely a lot of elegant things there, but it's also still a quite steep learning curve. Right. You have that whole. So there's no garbage collectors, you have the whole thing with lifetimes and borrowing and that's really mind blowing. Right? I mean, conceptually I do get it, but then to actually use it, that's quite difficult. Right? Yeah. You have this really famous rust saying called fighting the borrow checker, where it's basically, it's again, going back to that. The compiler is your strict spouse that's telling you no all the time. A lot of the time. What it's telling you no is because you've got lifetime rules wrong and it takes a lot of trial and error. I find more or less everyone finds as a rust learner to understand the rules. But once you get there, then it's another useful tool to have in the back of your mind. Yeah, it's daunting, but it's rewarding. But on the other, for me it was also more like an intellectual thing, because after a month I concluded what I actually have done is mostly scripting, which I could have done in Python. I didn't even touch the system programming side. I like your advice. If there's something performance sensitive, then it makes most sense. But to go rewrite the Pibyte search command line tool, that was a nice exercise, but that was just fast enough in Python. Right. So it was again more like an intellectual thing. Yes, that makes total sense. But yeah, if so, if people want to take it up in terms of learning resources, how would you? Because as we established, it is a steep learning curve, especially if you have done mostly dynamic languages and not compiled languages. Like my experience was. Do you have any advice how to best get started? Yeah, I think. Well, it depends a bit on like your preferred style of learning, right. Because some people, I think, like to structure learning by just doing something, and some people like to structure something by more like reading a course or reading a book or whatever. And like, I'm not a great reader, actually, recently I used to be a reader when I was much younger, but these days I don't find time for it. So I'm a bit out of touch with what the good books are. I think you might mention the Manning book. So maybe you've got better recommendations than I have on good books to read. I hear a lot of good things about the rustlings course of exercises. It's like practical exercises where you can try incrementally. They kind of like up the complexity and ask you to do more complicated things with the language. And I think that that is still being maintained and actively improved. It's meant to be like a nice first experience for people wanting to learn rust in isolation. If you're a learning by doing type, then I guess that's sort of like a halfway. That might work for you, but you might also just prefer to have a personal project where you're like, hey, I guess for you, that was writing the Pibyte search engine as a rust program. Instead, there was a very concrete project and you could kind of chip away at that. And so, I mean, I always am mindful as well that for some users, PI three is going to be the first time they try rust. And so, like the PI O three user guide, in the back of my mind, I'm always like, does this make sense to a Python reader? It's hard to really achieve that, and especially I'm tainted at this point. I've been thinking at rust for four and a half years, so it's hard for me to ask the question, if I knew nothing about rust, does this make sense to me? But I do try and imagine that if someone was a Python user and they want to just pip install, mature, and start a new project, there's a mature and new command that you can do. To do that, you get your and python template that you can then start editing the rust code in. I want it to kind of like, make sense, hopefully, and, you know, that can be a way for people to learn by kind of like play and experimentation, or maybe they have a real performance problem to solve, as we say. Yeah, no, those are great tips. Yeah, I defy bytes, right? It was like, build something, fake it before it. So you go straight into the dean and I would do card working packages or, or libraries. I'm really sorry, I've lost your audio for a moment there. I'm not sure what's going on. Okay. You can still hear me? All right. Yes. Oh, you've gone really faint there. Yeah, that's because my microphone died. Oh, okay. Sorry. Yeah, it's connecting and disconnecting. Yeah, it just suddenly went through that last comment. Yeah. Which, man, we can add it, right? But this ATR 2100, I had it returned, I got a new one, and now exactly the same thing is happening that it just dies. Yeah. So let me try another USB port, see if it comes back. It's really annoying. Yeah, it's just, it's just dead. What the hell? Aw man. Sorry about that. Okay, now it's connected. Hear me? Yeah, I hear you loud. I try not to touch anything now. Okay. And zoom that. It picked it up and it's super loud and clear. It's brilliant. I can hear you well. Yeah, I will just retake and then if it goes away, just let me know and then I can do it with this one. Right. But then there's a difference in audio. Yeah, don't touch it. So I think I dropped off where I said like about the book. Right? Yeah, about in, you know, sorry, experience with like clap and all of those tools as well, I think. Oh, that was even before that. I will just pick up from the book. Okay. Yeah. The official rust programming book, which is free online. It's good, but it's also pretty in depth. So just read it and knowingly that you won't get it all at first. And the rustlings are great. I really like how they have set it up. You just clone the repo and then there's that watchdog thing going. So as you type the code, it just runs the test in parallel. So it's a really, it's like hundred mini exercises and it's really good. Yeah, I think they recently rewrote it to have like a terminal view or something as well. I should really try it out because I'm recommending it to people all the time and like, you know, I haven't looked at it for a long, long time myself, but I hear it's really good. Everyone who I recommend it to is like, that was good fun. And again, the compiler shout out, because with AI tools you have that danger of hallucination and stuff, but that won't get past the compiler. Yes, that's totally true. Yeah. Cool. So Escher, you said you were so busy and not reading that much. I won't do the book question, but I saw in your bio that you're streaming PI o three stuff to YouTube. So I did want to ask about that. Yeah. So I have actually had a little gap at the moment. So I started it earlier in the year and I found it was a really super valuable thing. Like basically every Friday morning I managed to keep it up for, I think, something like two and a half, three months before family life got in the way. We had some sickness in the family and I had a baby and stuff. So it's been a long break, but just talking about either side. I'm hoping to get back to it in September. I've got buy in from my family that things are calm enough with the new baby's arrival and all of that, that I can return to it. That's the current plan, but yeah. So every Friday morning I was basically thinking about something that I was working on, on PI o three that week, which was like a meaty enough problem that it was interesting to kind of like talk about and try and solve, like ideally with the community, like having a chance to have a little bit of input, but also just seeing me like think about it myself. And I thought that this would be a good way to show how PI three is working for those people that really want to go into the depth and like see what it's like to try and solve some of those like complex problems, as you say. And it was a really interesting journey for me. We did some different topics. We did some stuff about how rust is interacting with C Python, the interpreter and the FFI that goes on there. And we actually had some of the C Python core developers join and watch the stream and give me a lot of feedback as we were doing that stream, which was super valuable. And I think actually we've built a bit of a connection since, and that's helping improve the quality of both what C Python API is delivering, but also what we can do in PI three as a result of what we learned from seeing what each other wanted from that. But also, I remember one stream where I came in, I had this idea for I want to create a nice error message, basically for if you did something wrong with a particular case in PI three, you say the rust compiler is strict and gives you errors. And I want that same experience to go on to if you're writing bad or incorrect PI three free code, you should get helpful error messages out too. And I had an idea of how it might work and I spent the first half the stream, maybe 45 minutes to an hour, talking about the problem and how I thought it could work. And then we went and started trying to implement it. And the reality was much more complex than the idea I had. And I knew I had a relatively hard cutoff for family related reasons. And so it's just like, as we get closer and closer to the end of the stream, I'm just more and more just typing furiously, like, oh come on, we can get this to work. I'm sorry everybody, this is probably less interesting for now as I'm like just typing and typing and typing. But that was kind of like, that's the reality sometimes of what it's like when I'm trying to work on these problems. And so maybe people found that interesting, too. I don't know. But, yeah, I had a lot of good fun with those, and I think it actually helped welcome new contributors into PI o three by, like, showing them what was going on. And so I'm looking forward to getting back to that again soon. Yeah, kudos on that. Because it takes a lot of guts to actually do that, to go on there and keep it raw and things might not come to closure and you might have Phil and all that, but I did learn over the years that that's actually the part that people like the most. They don't seek perfect, crafted solution videos. I mean, they do, but that's another type of YouTube video. But actually the raw process and seeing you in the guts of it and failing and the thought process, and then if you talk through the thought process, that's what people really like. Plus, it's kind of the expectation of a live stream. Right. You know, you're going in there and you're going to see something that's not, like, pre edited, so. But, yeah, it takes a lot of guts. Yeah, absolutely. Like, I, you know, if I was making a regular commitment like that, I wanted to, like, do something to broadcast the community, but because, as I say, like, I'm already so time poor, I was like, it has to somehow fit with actually, like, what I'm doing on the PI three, maintenance. And so being raw was the only real option. But it, it was good fun. I'm looking forward to going back to it. As I say, the plan is we've got Python 3.1 three's pre threading support coming up, and there's more that Python three needs to do to support that. Well. And so I want to really get into the problems related to that and think about those on stream. I think that'd be a really fun series that we could have there. That's awesome. I might join one one day, but also the lesson of we get into our silos, but we have to not only do the work, but actively pursuing putting it out there. Right. So that's really nice to hear. That builds up connections and that actually got you contributors. Yeah, that was a lesson that was really instructive to learn, I guess, because for a long, long time I was working on PI three, and maybe it was also because it was earlier days for PI three, the adoption was smaller or whatever, and it was more in that silo, as you say, but then to go out and realize that actually there's enough people using this, that this needs to have a bigger community and more connections was like. There's almost like a light bulb moment for me. It's like I need to be trying to do this as well as just writing code. Yeah, yeah. Awesome, awesome. Yeah. The balance of coding, and I wouldn't call it marketing, but just this. Outreach. Yeah, it's about like. Yeah. Building that network so that everyone can help each other in our little silos. Then it's no good for anybody. Like, exchange of ideas helps us all make it better. Yeah, exactly. Oh, cool. Well, thanks for the great work you're doing there, getting rust into Python, and very interesting for us pythonistas, and thanks for sharing all the great insight. Anything else? A final shout out or something you couldn't tell with the questions you want to share? I guess that's kind of it. I guess if there's a call out, it's like, if you want to. I guess I'd want to talk about getting started in open source, I thought was an interesting thing for me. I mentioned it already. I just started by doing issues and picking up the small pieces and even contributing features that then I've ripped out since. And people have asked me since, how did you get started in open source? And it is kind of that don't be afraid to make the first step, because over time, you'll learn more and more, and then you'll find it easier and easier to keep going and you don't have to get it right first time. And just support and a bit of be brave and make that jump is something that I'd like to shout out for. Yeah, I'm glad you mentioned that because it can be very intimidating. It seems like everybody is scrutinizing your code, or there's a lot of critique, but people are actually really grateful to get the help. Right. Because often there's just more work than resources on those projects. But it's also a gradual exposure of things. Like the first time, it's hard, and the second time, third time, the end time, it just becomes normal. It normalizes, right. Yeah, absolutely. Fantastic. Oh, again, thanks for joining us today, David, thanks for all the work, and, yeah, we'll be in touch. It's been a pleasure. Thanks for having me on. Right,