Reinventing Python tooling with Rust (Interview)

30:19Basically that your environment matches what your declared dependencies are. It will do that every time you run UV run. and the thing that i think is cool is like that's kind of an experience you can only reasonably build if you have a really strong uh performant like baseline because you can't if that takes like imagine that took like 10 seconds then like you can't have that 10 second overhead every time anyone tries to run a command and so yeah so like for me that's one of the cool things where it's like, okay, focusing on performance actually lets you build like kind of different experiences because you can build things that otherwise would have been like prohibitively slow before.

31:03And so, yeah, we didn't want to have this workflow where like you might run a command and you're actually, your environment is like stale and you're like missing all the dependencies or something like that happens all the time. And with like NPM and node and stuff. And I'm like, I don't want that. I want the cargo version where you do cargo run and it takes care of resolving your dependencies, installing them, and then runs the command with all the right stuff. So yeah, it was a very much, that's probably the biggest example of us trying to provide a different experience for working with Python.

31:33I decided to install it with Homebrew as well. I don't know if that's anti-pattern because docs don't really mention Homebrew. You installed UV with Homebrew? Yeah, UV was installed with Homebrew. That's cool. That's cool. My preferred method is Homebrew because that's my mac os you know package manager basically so that's my preferred way versus the you know just the just the ways essentially that that uh that script on your on your yeah we have this curl script the reason that we generally recommend installing with the curl script only because it lets you do auto self-updates like if you install with the curl script then you can run uv self-update but but if you install any other way we can't really do that because like we're not homebrew so like we can't like so it goes stale over time and i'll maybe a few revs behind yeah yeah but you know it's all the same binary um for the most part that's a hidden unknown for me with homebrew i didn't think about that like being out of sync i i guess i know that by nature but the fact that you have a self-updating thing that's built into the package manager is a nicety that i really want and now i'm going to go and undo that and i'm going to install the right so thank you very much but yeah can you can you talk about um you know we just talked about run but what about init and add these seem to be like the things that really are the magic moments for anyone using python and yeah sure that's not that's not there otherwise yeah yeah so like like i said when we did the first uv release the things that we launched with were like uv pip install and like uvvm like and these are kind of like commands that match how people have historically worked with python packaging so it's like okay i want to create an environment i'm going to run this command to like create the environment then i'm going to like activate it then i want to install a package in it i'm going to run uv pip install torch like by torch or whatever um and so it's very imperative and it's kind of low level because it's like you have this directory on your machine that you're sort of like manually managing it's like i want to add things to it i want to remove things from the environment and like ultimately we wanted to get away from that And so like UV init, UV add, UV run, these are all designed to be very declarative.

33:40Like you tell us in your file, like what the dependency should be. And then we take care of like taking that declared state or that declared set of dependencies and making them correct on disk. Like you don't have to think about, I'm going to create this directory and add this dependency and add this other dependency. You tell us this is what my project needs and then we take care of the rest. And so getting there, yeah, UV init will create a new Python project for you. and then UV add, you can just add dependencies to it. And, you know, UV takes care of keeping everything in sync. And yeah, there are a bunch of, I mean, we talked about this a little bit earlier, just like taking good ideas.

34:14I mean, there are a bunch of ideas in UV too that we've like taken from other tools, even tools that, I know I've talked about cargo, even tools that have nothing to do with cargo, like in JavaScript, a couple of tools like PNPM and Bun, probably Yarn too, although I'm honestly a bit less familiar with exactly how their design works. But basically, the way that we manage our cache and do installations is that's probably one of the most like, oh, this is like, I never thought it could be this fast kind of thing where people get really confused, which is we use a global cache. So basically, if you install a package once, we put it in the cache.

34:59If you then go to a different project and install the same package, we effectively just like sim link that package into your environment. It's not exactly a sim link, but the basic idea is for each package you install, we actually only keep like one copy, one real copy on disk. And all your projects just point to that, which makes installation incredibly... Like if you are installing something that's already been installed before, it's basically a no-op. It's like it just points the files to the right place. And that's something that like PNPM and Bun do. And there are different tricks you can do on different file systems to make that faster or different, depending on what's available.

35:36But again, a lot of it's taking some of these ideas around how you can build these kinds of tools in a really performant way and bringing them to Python. Yeah, that seems like a pretty logical one, though. The global cache. Where'd you get that one from? I think probably from Bunn was probably the... I think I knew PMPM did this for a while. But then Bunn, I think, is the one that I probably looked at most when I thought about how our design should work. But yeah, there are trade-offs to it. Like the main downside is there's kind of two ways to do that. Like one is you can actually use like a hard link, kind of like a symlink.

36:15The problem with that is users can poison the cache. So like if they change the files in the installed environment, it will actually pollute the cache and affect everywhere else. So let's say that you open a file that's in your virtual environment. it's like add a print statement or something to debug which is something that people have done from time to time that thing gets point it sort of like poisons the cache so that also affects other projects that's one downside but um like mac os and some other file systems support a concept called copy on write or like ref linking which is much nicer the idea there is it's like a sim link until you edit it and then it creates a then it actually writes the copy and changes it there so that's kind of like the best case scenario but yeah it's a very nice idea and And it also means that you, in addition to being way faster, you save like a ton of disk space.

37:04So like in Python, especially packages can be really big because a lot of the time you're actually working with native code. So like PyTorch, for example, like it's almost like I think the Linux CUDA, like 12, 8 builds are about like a gigabyte compressed. so when you install that package we're actually like downloading and unzipping like a gigabyte compressed and so uh it's really nice to only have one copy of that package on your machine like if you're installing a new one in every environment the disk space actually adds up like tremendously so it's faster and it's more space efficient which is pretty nice is the uvfs when i browse the crates directory in the project is that literally a file system Is that what you mean by FS?

37:51It does mean file system, but it's really just like utility functions that operate on the file system. So do things like creating symlinks and stuff like that. Yeah, we have a pretty like unconventional structure to our Rust projects. We tend to break them. It's easy to browse. Thank you. We have a lot of crates. You can probably see it. It's kind of like we have a lot of... It's very ceremonious. I mean, you got tomls everywhere. you got source directories everywhere which i think is i've i've leaned into rust a little bit and you can appreciate that the verboseness of rust because there's uh explicit returns of types there's explicit types obviously there's so much in there but i think what it offers you is confidence and safety which is probably why you chose it as the the reason to change what you've done and go build these you know build rough and then build this or sorry build rough and then build this uh that's what i see there is like that's just seems to be the rust way is more than necessary by means of confidence yeah it's been a um i think it's a really good language for building this kind of tooling um i i don't think it's a the right language for everything otherwise i probably wouldn't be building python tooling i'd be building rust tooling i guess but like it's um i think it's a very good language for building this kind of tooling um which one's your favorite which one do you like more which programming language python or rust i mean you're building python tools to bring more pythonistas building them in rust so you must like rust yeah i mean i i would say i prefer writing rust to writing python um but i it's just um well first of all like i write a lot more rust than i do python now um so i'm just i've just spent a lot more time in the ecosystem and um rust is i think actually quite a hard programming language to learn um because it what i don't know it depends a lot on your background for me it was a hard programming language to learn because my background was um you know i'd done a lot of python but also a lot of type scripts um like maybe like two years of java professionally um like a little bit of go kind of barely um and then like not really any rust so i didn't have like a systems programming background and i wasn't really used to this idea of thinking about what in rust you would call it like ownership but thinking about like memory management and so when i first started writing rust at my last company someone else introduced it to the project a really great engineer and um but i didn't really like know it and so every time i went in there i was trying to in and out as quickly as possible.

40:37And like, I was like, I was trying to, I was thinking in terms of Python and trying to map that to Rust. I was like, why is it so hard to like do a comprehension over a hash map? And basically like nothing made sense to me. And so it took me like working on rough and kind of building something from scratch and kind of banging my head against those concepts. So I think really understand like what the language is about. And the thing is now Rust has this mechanism called the borrow checker, which is like the thing that makes sure that you don't break its rules around how memory works. And it's not really like writing Python or JavaScript where you can just like create things and like pass them around and do whatever you want.

41:16You have to follow certain rules that the compiler enforces. The thing is for me now, I don't really think about the borrow checker anymore because I've written a lot of Rust. So I think in terms of that kind of ownership, like the thing that makes it hard, eventually that kind of goes away in my experience. It's like, I don't, I just write my code now in the way that I kind of know what work for the borrow checker. And I don't really feel like I have a lot of overhead from it. So that's like the thing that makes Russ hard. I think at least when you're beginning is the borrow checker and that kind of dissipates over time.

41:46And then it just becomes, it just becomes a lot easier. I mean, there are still plenty of things I complain about. Like I would like compile times to be faster, for example, et cetera, et cetera. But I do find that the way I think about programming now is better to Rust now. And so that ends up being kind of an easier experience for me. Can you give a little bit deeper dive on ownership and borrowing in the vein of memory and memory safety and memory usage and how it just, once a variable goes off scope, it just falls off? Can you speak to that a little bit? Do you know much about that? Obviously.

42:18Yeah, I can try. I don't know that I'll give the best explanations of these things. Give us your best take then. How about that? that way everybody who's thinking about rust why well what i've learned about rust is is just that is like that is the centerpiece of what makes rust so safe is this borrowing method you can't allow a variable to be mutated i think you can only have one this is where i was hoping you could fill in charlie but i think you can have the variable use all the places but you can only mutate once or borrow plenty it's like that's the rule thing that you have to abide by yeah i mean i've i've never i don't even know if i've even tried to explain this before but i so i probably won't do a very good job but like you know if you're writing like c for example like i i have not written a lot of c but i wrote some c in college and so when i wrote c i had to think a lot about like malik and free like like allocating memory and then freeing it and thinking about like okay who's like allowed to free this and like how do i make sure that like after i free the memory like no one's like using the object and stuff like that.

43:24In Rust, you don't have to like think that way because the compiler does it for you. But the trade-off is the compiler enforces these rules at compile time. So the rules are things like, okay, like whenever you like initialize some sort of variable, like someone has to own it. And when that owner, like maybe it's an, maybe it's like an attribute on an object. Like when that owner goes out of scope, that value goes out of scope. So if other people need that value and they have to read from it, you have to make sure that the owner lives basically longer or as long as the things that rely on it. And so whenever you end up initializing memory, like a string or something, you need to think about, okay, who owns this and who's going to need it?

44:08And how long, how do I make sure that that owner lives long enough? There are a lot of things in Rust, like Rust enforces all these rules, and then you can also break them if you need to in sort of like special ways and um rust also has a lot of escape hatches for um kind of like different ways of managing the memory like i actually found that a lot of that stuff made the language more intimidating for me like when you go read rust guides there are certain things like refs like ref cell and like rc and like blah blah and it's interesting because like Those things exist in some ways to help you.

44:46Often, if you reach for those, it's actually a sign. If you're an experienced REST program, this isn't true. But as a beginner, I found that whenever I was reaching for those, it was actually a sign that I was doing something wrong. I was thinking about memory the wrong way. Because RefCell, for example, lets you do interior immutability. It's not super important what it is. But the idea was, I was like, oh, I need to have write access to this object here. But it's only letting me read from it. And I would like Google that. And then I would find like RefCell. And I'd be like, oh, okay. But actually I was just like thinking about things incorrectly.

45:18Like someone else should actually be owning it. Someone else should actually be doing the mutation. So for me, it was like, I tried to start by like, once I figured that out, I actually like ignored a lot of things in the language for a long time. And I was like, I'm going to try and write really dumb Rust. And then I kind of grew to understand those things over time, especially as I hired people into the team who are honestly like much better Rust programmers than me. And I could like learn from them. but I do I do sort of maintain that I think it's kind of an intimidating language to learn for that reason like the the mental model around borrowing is just very different there is a lot of stuff in the language to help facilitate that because it's like one of the most important concepts but you know the upsides that you get with Rust are like it's actually I think a little bit hard to appreciate if like I suspect that I don't fully appreciate it because I haven't spent a bunch of time writing in memory unsafe systems languages.

46:16But like in, in Rust, it makes it hard basically to make mistakes that otherwise would be very easy. And the cost is you have to play by those rules. Yeah. And the, when you compile, you get yelled at. So, you know, good luck on that part there. And it's also happening in compilation, not in production necessarily. I pulled back some of my rules. I'm not sure if this will just maybe pepper and spice up what you've shared here. So the three rules on ownership are this. Each value has a single owner. When the owner goes out of scope, the value is dropped. That means it's out of memory. And then the last one is there can be multiple immutable references or one mutable reference, but not both.

46:59Yeah, but not both is also critical. Yeah, so basically you can't have people who are allowed to read a value while someone else is allowed to write to it. because it would do what you just said with the global cache before it would corrupt it essentially it would do yeah it would cause polluted terminology yeah yeah yeah and i think i've like you i've never written c and i've really never written systems languages beyond my dabbling in rust recently ever so my only experience with it is the knowledge i've gotten from rust but i can appreciate what people have complained about about c and the reasons why people push up back on c-based network tooling because that's where there's so much you know critical nature to being safe being memory safe yeah i can appreciate this ownership model though yeah i i like i remember recently there maybe a few months ago there was a big you know there's a story in hacker news about like um i don't know like an llm finds a use after free vulnerability in some CE project.

48:03And I was reading the write-up about it and they were kind of like tracing through the code where basically, you know, it's written in CE and like someone was doing something after a variable had been freed that was like not allowed. And I was just looking at the code and I was like, how on earth are you supposed to keep track of this as a programmer? Like this just looks impossible. There must be so many of these out there. And anyways, that reading that actually, it had nothing to do, for me, the experience actually had nothing to do with the llm being involved it was just actually looking at the vulnerability and being like wow how would you possibly keep track of this and that's why anyway i shouldn't speak to it too much because again like i haven't written a lot of ce and like there are other things people do to try and mitigate against these things but i do feel like in rust i it was i took for granted for a while that basically we built like you know a couple tools that we get i don't know like 100 million installs a month like maybe more Like we just have, we've built really popular things and I don't think we've ever had a single like memory related vulnerability, which is, which is a job or error even like that I can think of.

49:10And it just comes from working within the language, which is cool. Like basically it's easy to take that for granted. And it's like not why I started using Rust at all. Like I started using Rust because I wanted to build something fast. But there are these other benefits that over time I've just come to appreciate a lot. let's focus on fast because that is uv's selling point i assume it was a rough selling point to a certain extent i remember looking at rough and seeing like how fast it can lint things compared to other things that are linting things which really speaks to developers because like we don't want to wait around for anything let alone a linter you know i'll just turn it off i'm not going to sit there and wait how much of the speed that you're getting with astral tools i guess we take rough and UV specifically are just fast merely because you just did it in rust instead of Python.

49:58And then how much of it is fast because of some, you know, smarts you got in there, Charlie, like what your, your decision to be on that one of like architecturally different. Yeah. Um, it's a great question. I think it's pretty nuanced and will be hard to put numbers on. So like, I guess the way I think about it is like, we get some baseline from like being written in Rust that's probably faster than the baseline that we would get from being in Python. But rough, even as rough as an example, has actually gotten significantly faster over time. And it was always written in Rust. So there's a huge delta that you can get even within just being Rust.

50:41An example is at one point, we rewrote our parser, the thing that takes Python source code and turns it into a syntax tree that we can analyze. And the initial version we used was based on something called a parser generator, where you write out your grammar, and then it generates the code for you to a certain degree, which can be really handy if you're building a parser, because often you can describe a parser in terms of the grammar. Like, okay, you have the def as a keyword followed by the function name, blah, blah, blah. And we ended up rewriting it to use, I guess what we call like a handwritten parser.

51:19So we got rid of the parser generator and we kind of like wrote it out ourselves and it became like way faster and like several times faster. It made rough as a whole, like, like 30 or 40 % faster. And so that's like the same, that's all within rust. Right. But it's like about thinking hard about how you're, how you're doing things. And you know, it also varies a lot. Like even if you look at rough and UV because in UV, we're doing way more IO. And so a lot of being fast, not all, but a good chunk of being fast is trying to be smart about how you do IO because we're either like downloading things from the network or like writing things to disk or like reading things from the cache and writing them somewhere else.

52:06And so like I talked about the caching trick earlier, like you could also do that in Python. Um, it would probably be, the program would probably be slower if you wrote the exact same program in Rust and Python for a bunch of reasons. But you could also do that to write a faster version in Python. In Ruff, that tends to be less true. In Ruff, there is IO. We have to read the files. But beyond that, it's a lot more, I guess, like a compiler. It has to parse all this source code and then figure out how to efficiently traverse it and collect diagnostics and report them back. um so you know i think rust like gives you a better baseline faster baseline how much better twice as good three times as good i don't know it depends what you're doing but yeah same python program well yeah yeah a python based linter and a rust based linter doing the exact same linting same exact same stuff i mean obviously there's a rough numbers no pun not intended yeah i don't know probably like probably like somewhere around an order of magnitude is okay So that's significant.

53:12Can I keep going? Yeah, for sure. But I think the other thing that I've come to appreciate with Rust is it kind of gives you the tools that you need to optimize further and think really hard. Allocating memory is pretty expensive in relative terms. And so a lot of what we think about when we try to optimize things is actually how can we allocate less memory or allocate memory less frequently or whatever. and like in python it's actually just pretty hard to have control over that because like you're not you don't really have any control over like the allocator and like where memory is getting created or destroyed it's definitely not staring you in the face like it is no but in rust yeah you're kind of thinking like we did this whole thing where we i went deep on i gave a talk at your rust where i like went through the exact design here but like when you run uv um we parse a lot of versions.

54:04Like it sounds like a silly thing, but just like package versions. Like for a very complex resolution, that code might run like 10 million times or something. Cause like just parsing versions. And so we saw that showed up in a flame graph and like when we were profiling and we redesigned how we represented versions. And we came up with the scheme whereby like 95 % of versions, something like that can be represented in a single U64 integer. Like we encoded them as an integer. So it's like, okay, the first eight bytes are the major version number, right? The next eight bytes are the minor version, et cetera, et cetera.

54:37And that actually had like a big, like a very measurable speed improvement. And like, that's not really something that you could think that would be intuitive to do or very easy to do in Python. Like in Rust, we have to think about how are things actually represented, for example. And so again, it's like, I guess for me, it's like, it gives you a faster baseline than it gives you the tools to care about this stuff if you want to. you know but but certainly like some of the things that we did in uv especially could be taken and used in other python package managers written in python and like that would be a totally i mean if they want to do that i think that would be a good thing like i'm very happy for that to happen but um but it's it ends up being a mix so your first product is out yes yes pyx called is that how you pronounce it?

55:22P-Y-X? Yep. Okay. P-Y-X, a Python native package registry. Registry. Yeah, registry. So you've learned a lot from all these other tools, open source world. How much have you studied NPM Inc.? A bit. A little bit. So certainly you want to avoid some of the problems that they've had. I'm curious the design of P-Y-X and the ambitions here and how you're going to go about building a registry that's commercial. Yeah. I mean, it's a little bit different because like we're, you know, at least right now we're like, we're not focused on this being like a public registry. This is a tool that's designed for companies.

56:05Um, like we work with lots of companies that either already pay for registries and we think we can build something a lot better or need to adopt some sort of internal registry as they grow or have problems that we think we can solve with the registry that we actually couldn't solve just with the client. And so for us, it's like, how do we go and help more of those users and fit the needs of those companies while continuing to build out the open source? So commercially, for us, we're not looking to charge money for rough or UV. like we view that as our like open source tooling, which we want to remain free forever, very permissively licensed.

56:48And what we're trying to do instead is kind of build these paid services that are complimentary and are sort of a natural evolution if you're already using our open source tool. So like I said, we talked to tons of companies who use UV, they buy registries. So we're going to go offer them a registry and we think it's going to be better in like a variety of different ways than the things that are out there already. So like a lot of why, we built this thing and are building this thing comes from like i said or as i alluded to like problems that users have brought us that we can't really solve like in the open source like um maybe people will come and they're using some private registry and it behaves in a way that's like incorrect and we're like okay we actually can't help you anymore because like that's a problem with like the software and so just being able to offer them something different I think is one manifestation of that.

57:42But the other is like, sometimes people want to install packages that are like broken in different ways or maybe there aren't builds available for like their Python version or maybe there aren't builds available for their GPU or something like that. And in that case, again, that's not something that we can solve with the package manager because to solve that problem, we actually need like a server that has like artifacts that we can manage. And so again, it's like try and look at these problems where we've spent a bunch of time in the issue tracker trying to help people and ultimately concluded that there's only so much we can do and saying, well, what if we had our own registry, our own server?

58:18Couldn't we do something pretty different? That makes tons of sense. Is there a world that you can envision in which Astral would want to host a public registry to make UV better in some sort of way that you can't do it as just a client? Maybe. I guess anything's possible. It's not like in our current mission for the problems we're trying to solve here. And I think, I guess what I would prefer to see happen is like PyPI, which is sort of the Python equivalent of NPM. It's like a public, it's the public registry that people use by default. It's run by the Python Software Foundation. So it's owned by a nonprofit.

58:56I want to make sure that that has longevity and continues to evolve and be stable because Because I think it's a really, like, I'm happy for that to be kind of like the public system of record and for people publishing packages and the way that, you know, the way that most people are maybe installing packages. But for us, like, we mirror that stuff in, for example. So, like, you can use PYX to install things from PyPI. And we're not necessarily focused on, like, the public serving. We're more focused on what's the experience we can build around the raw artifact storage. And also, are there other things that we can expand to over time that aren't a registry but are related to?

1:00:05hosting and serving artifacts. solve a bunch of new problems for users that we basically couldn't solve before. I think one of the things that's interesting about building in Python is the user base is incredibly diverse. What I like to say is every company on earth is using Python for something within some margin of error, but the things they're doing can be super different. We talk to users who have 15 million line code bases that are running web applications, that's like all python and then there's like ai and ml everything that's happening with gpus that's like super different even if you look at a company like ap like open ai like the things that they're doing with gpus are even super different like half the companies like research and half the companies like applied like chat gpt and like that's all super different so you know for us it's also about trying to figure out like where can we have the biggest impact like which of those user groups um and what can we build for those groups because the things they need are pretty different and so that's always been um it's always been something that's on my mind is like how do we how do we serve like all those groups and how do we figure out like where we can have the biggest impact and the registry is sort of another example of that where a lot of what we're building there not all of it but a chunk of it is actually focused on gpus and like people trying to install hardware accelerated packages basically things that involve cuda or like nvidia gpus and that's like relevant to some people but not to others but for us it's kind of about figuring out like where can we have the biggest impact with this like now that we have a server where we can host artifacts like where can we have the biggest impact amongst all these different people using python what does it mean to be gpu aware then like why is that such a take us into the details of why that's a problem how does it manifest outside of yeah was it pyx and then how do you solve that?

1:01:58Yeah. So it's, it's a problem for a couple of reasons. So like in Python, Python has actually very good support for like building and distributing native code, like native binaries. And it's part of why it's been such a success, such a, it's both a result of, and why it's been a big part of data science. Like, like if you think about installing NumPy or something like, you know, most of that is not Python. It's like a compiled binary. That's like native code that's compiled for your machine. And when you go to install NumPy, you don't actually have to build that from source. You don't have to download the compiler and compile everything yourself.

1:02:34What happens is when NumPy does a release, they publish, I promise this will get back to GPUs, but when NumPy does a release, they publish builds for Linux, Windows, macOS, macOS ARM, like M1, M2, like macOS Intel, x86, all the different Python versions. So they pre-build these things and they put them on the registry and the package manager knows how to look at your machine and figure out like which version of which numpy build is right for your machine so that's like that's like very central to python um it's it's where a lot of complexity comes from packaging but it's also like kind of a superpower because you can build like uv you can install uv you can like pip install uv and that's just a rust binary that we basically turn into a python package and publish and you don't have to build it from source like python standards let us do that GPUs make things harder in part because of some of the gaps in the standards.

1:03:29So like in the standards, there's no way to express that like I just built PyTorch and it was built for CUDA 12.8. Or I just built PyTorch and it was built for CUDA 12.6. Or I just built PyTorch and it was built for like AMD Rock M. These are just different kinds of GPUs. There's no way to actually express that. so um when they build PyTorch they go and the PyTorch team builds PyTorch for a bunch of different architectures and they basically have to hack in the way that they do this like they have to just like find ways to encode it that aren't really codified by standards which leads to a lot of complexity like there's no way in pip for example like let's say that you have an nvidia gpu on your machine there's no way to do like pip install torch and like get the right torch version based on your gpu like it just there's there's nothing in standards that would really allow them to do that so that's kind of the problem that we want to solve which is like uh there's actually a second what they do is they publish the different version of torch each each architecture basically gets its own registry wow so they create an index for cuda 12.8 and index for CUDA 12.6.

1:04:42And on the 12.8 index, they published the builds that they built for CUDA 12.8. And each library also solves this in a different way. So like JAX, which is like a Google library for working with GPUs, does like something totally different. So yeah, there's been a lot of experimentation around trying to make this work, but it ends up being pretty difficult. And there's sort of like a second order problem, which is that there are packages that build against PyTorch. And so it's not just like PyTorch needs a GPU. There are also other packages like VLLM, extremely popular piece of software for actually serving language models.

1:05:18Like if you actually want to run an endpoint that runs a GPU to do predictions and give back data, you would use VLLM for that. That has PyTorch as a dependency. And when they build VLLM, they not only have to encode the GPU version, but also the PyTorch version. So it gets very complicated very quickly. And that's kind of like the complexity that we're trying to tame with the registry. So like GPU aware means a few things. One, it means that UV, the client can actually figure out like what GPU you have on your machine. And then it can map that to basically the right endpoints in PYX. So in PYX, we have like curated distributions based on the hardware.

1:06:01And we go through and we not only take PyTorch, but we also pre-build a lot of other stuff that people commonly use with PyTorch. And we make sure all the versions are compatible and all the metadata is correct. So we do what I would call the sort of non-glorious work of making sure that all the things we put on there, it's like a well-curated distribution. And in UV, you can just install, we'll look at the GPU on your machine and we'll pull in the right things from pyx so that's like that's like one tack that we're taking on this problem which is we just want people to be able to like run on a machine with an nvidia gpu or an amd gpu or whatever just run like you know uv add torch vllm flash attention and not have to think about building from source not have to think about where these coming from not having to think about making sure that like the the cuda versions are all lined up like that's like part of the complexity that we're trying to solve.

1:06:54Is that ability to see the GPU particularly, is that a Rust level thing that UV inherits? No, it's, I mean, you could do that anywhere. And like a parallel, I think we're trying to do in parallel actually is like standardize a lot of this stuff. Like actually evolve the standards so that these things can be encoded. We've been working on that with like the NVIDIA team and the PyTorch team. It will take a long time. It may also never get accepted. Who knows? Standards are hard. Like we're working on that. but that would also involve similarly like trying to detect and understand like what gpu the user has installed um the thing that's a little different i think like the thing that is hard for others to do is like because we work on the package manager and the registry we can actually encode that contract of like okay this is the user's gpu so like this is where you should be getting the packages for example or like this is like constraints that the server needs to understand so like we can work on we can keep those apis in sync and make the experience really good ultimately hopefully this stuff gets standardized but until it does there's like uh i i think it's like hard to appreciate like how big pytorch is like we spend so much time like helping people install pytorch not in terms of size in terms of like the the wheel that just like or the artifact but just in terms of like how big the user base is and the community is like we just spend a lot of time trying to help people install this stuff and um uh it's gotten a lot better and i think the pytorch team has actually done quite a good job in the face of these sort of gaps and standards and like having to trailblaze a lot of this stuff um but you know for us it's like we're kind of like user obsessed and so it's like i hate seeing people struggle to install this stuff and i want to find ways to fix it and so for us some of that's in the uv client and some of that's in the registry so pyx your first commercial product but not necessarily like the future of Astral because you're not a registry company.

1:08:46We don't want to be necessarily a registry company, but it's a good, it's a revenue stream. It's another opportunity to make UV better for your customers who need it, but maybe just one of your products down the road, right? Like this is one thing we do. We have other things we do as well that we're selling, making our investors happy. Without making your investors mad, like what are some of your other ideas? You know, they don't have to like spill all the tea, but like what other aspects of Python tooling could you tackle, whether in open source, you got your type, you got your type checker going on or in the product side.

1:09:22Yeah. What else are you working on? Yeah. I mean, in the open source, it's, I mean, there's no shortage of like things that people have asked us to do in the open source. And I mean, I would, my philosophy, which we'll obviously stick to, as long as we can is that if there's a problem that we can solve in the open source then we should solve it in the open source like not with a commercial product um like again we'll see we'll get tested on that over time um but like i would like i would like the incentive structure of the company to be such that we're very much incentivized to like build things in the open source and grow the open source um and that the paid and the hosted products represent real value that can't go in the open source for like structural reasons.

1:10:10Like, uh, you know, like in the registry case, it's like, okay, security compliance, like all these things that are, don't really make sense to put in the open source in that way. Right. So there's no shortage of things that people have asked us to build in the open source. Um, I think the things that we've been, the things that we are building now, which you had, which I'll just like maybe mention again, is we're building a type checker and a language server. Um, probably like very comfortably the most technically difficult project that we've worked on um it's very hard we're looking to do the beta release for that um i can't really say the date but let's say you know within the next few months um the so that's something that we've been asked about forever basically has been like a type language server you're referring to or the type checker both both yeah okay the because the language is out there right they're they're all out there oh yeah we did an alpha release we did an alpha release and we do have companies using it in production.

1:11:09We just haven't gotten to the point where we recommend it for use. Okay. So the type checker slash language server, like it's one thing. Yeah. They're the same thing. It's called TY. Gotcha. Yeah. And it's, it's a little bit like TypeScript in the sense that like it's a command line tool, but you can also run it as a language server. Gotcha. Yeah. The other things that we get asked about a lot in the open source are testing, like a test runner. That's kind of an interesting one for me um a lot of people actually really like py test which is like a very common a very popular probably the most popular python test runner and so i think i would need to think hard about like why could we build something that's a significant improvement over py test like it has to meet some bar of like it has to be much better hopefully than alternatives otherwise why would anyone use it or switch to it um and the other another thing we ask about a lot although it's a bit more niche is like documentation tooling, which is not, not super glorious, but it is a big part of, it is again, something that Rust does very well.

1:12:14It's also highly appreciated by the Python community, right? It is. It is. Yeah. I think the thing is like the thing that's a little challenging is that the user base for that is slightly smaller because it's mostly oriented around maintainers and people who publish libraries. Most people are using libraries and not writing libraries. So, but again, this is all just about prior, obviously we would do everything in the world if we could. But ultimately everything has to be prioritized. There's sort of like a thing that is a little bit more pie in the sky that like, we do not have any plans to do this, but it would be cool if we had the, if we could, which is, um, our own Python runtime.

1:12:57So like actually trying to make Python itself faster or different in, in, in different ways. Cause right now we don't, we actually do our own builds of Python that we distribute. Um, and it has a bunch of modifications versus CPython, but those modifications are really in the build process. And, um, they're all motivated by this same idea, which is we want to be able to pre-build Python for you that you can then unzip and run. Because CPython itself, like CPython main, doesn't really support that for technical reasons. Basically, a bunch of absolute paths get encoded in the binary when you build Python.

1:13:33Is it different? Like it's statically linked or it's like different sort of... We do statically link things, but ultimately, the main problem is that CPython, when you build it, at least on Linux and macOS, encodes a bunch of absolute paths. And so we have a project called Python Build Standalone, which the core idea there is we build it, and then you can literally just download, unzip it, and run it on any machine. It makes it relocatable. You can move it around your machine, etc., etc. So it's basically patches and changes in CPython to enable that. But we don't change anything about runtime behavior.

1:14:06And so, again, we do not have plans to do this, which I have to be really, really explicit in saying. if you were going to though however what would yeah just what uh what a big list that you just described though i mean that to me would be like just overwhelmingly daunting well this makes me think about the dreaded gill right like if you i would imagine if you did do this runtime it would not be written in python or c because well the gill the gill is is potentially not long for this world yeah i don't know if you've been following that okay but yeah they're free threaded now you know yeah free yeah at least you're not supposed to call it no gill no gill was the original name for it but now it's called free threaded the idea so in 3.13 or before 3.13 they accepted sort of provisionally accepted a proposal to remove the gill and um in 3.13 there's a separate build a python that has no gil um and then the idea is eventually that will become the default but right now there's kind of a split world how's that work with uh legacy python out there though you know it's good for future but what about the past um as in python code that is written in a way such that it assumes the gil exists uh well maybe take this as my imposter system here not writing a lot of python but if i'm writing python uh i suppose against a version that supports the no gil method then that's probably just fine but if i'm if i've got code that's legacy that's written in you know python but against older versions am i still at risk of the issue of the gil i suppose so you you possibly are and that's part of why they're doing this incremental transition whereby also like if you try to install like a numpy for example again just going back to numpy like something that has native code it has to they have to build a special variant for no gill for for free threading so basically all the libraries have to add support for this and like audit their code and make sure that they like work in a no gill world so like especially the extension modules especially have to like explicitly go through a process of adding support for this.

1:16:24So it will take some time. And that's also why it was like provisional acceptance and kind of like something that got staged in. But I guess a cool thing for us is like, we've made it really easy to install the NoGil version. Sorry, I'm not the free threaded version of Python because I like NoGil better personally, but I know me too, but you know, it's, that doesn't always work out the way we want. It's a spade called a spade, right? I'm like, there's no gill. I didn't really participate too much in that conversation, at all, I guess, in that conversation. But I think the concern was that a lot of people don't know what the gill is.

1:16:55And so they wanted something that was descriptive, also in a positive way, rather than something, not as in like negative sentiment, but just in terms of describing what it is rather than describing what it isn't in a way. I like free-threaded, because it just reminds me of, you know, Freebird, you know? Yeah. I just feel like, I haven't thought of it that way, but I guess I could. Or used to have, I used to hold a lighter up at the concert. Now it's a phone, yeah. But now it already holds their phone up anyways. Yeah. Free threaded, free bird. Yeah, so we actually have this guy on our team named Carl Meyer who's like super amazing.

1:17:28And he worked, before this he worked at Meta. Meta has a fork of CPython called Cinder. And it's sort of a performance-oriented fork. It is open source. But it's not really open source in the sense that people run it outside of Meta. um it's just sort of open source in the sense that the code is open source and they use it as a reference um but cinder was this performance oriented fork largely i if i understand correctly built with instagram in mind because instagram is all python instagram is this big very high obviously very high volume application and so they did a bunch of things in cinder to try and make python faster or i guess make python faster not try i think they did make python faster and it had some very interesting ideas they tried to upstream some of them so for example Cinder added lazy imports so like in Python imports are all eager so when you run like import whatever at the time that Python interprets that import statement it goes in and like parses all the code and actually executes all the code and that cascades down so basically when you start up your application if all your imports are at the top level you kind of like import the world and that can lead to like slow cold starts and a variety of other problems.

1:18:43And so Cinder added support for lazy imports. And then they tried to get that upstreamed a few times and it failed. But we have a person on our team basically who worked on Cinder and he worked on Cinder's JIT, which they did a bunch of interesting stuff to try and make Python's JIT compiler faster. And so basically we have people on the team who understand how to work on the CPython interpreter, but I don't think that we're at the point where we so you're saying there's a chance i'm saying there's a chance no no i don't really want to i mean for me it's like i sort of look at these things from a few perspectives one is like it's good to be a little bit naive um because otherwise if you're not like a little bit naive you just like won't try anything hard um because it's just too easy to say like well a bunch of people have tried it like of course it can't be done um right so i like being a little bit naive but at the same time you also have to have some like humility and be like okay a bunch of people have tried this why didn't they succeed and like why could you succeed where they didn't so right you kind of have to thread the needle i think a little bit between like being incredibly arrogant about being able to solve any problem and being like a huge naysayer who just says like well i can't possibly be made better especially while there's lower hanging fruit like you have you have a list of things that you're currently prioritized which arguably i assume you would argue this is higher value for less work, right?

1:20:05Like it's lower hanging fruit than that particular fruit up there. Cause that one's way up high. And so maybe you could do it, maybe you should do it, but clearly right now you're, you're focused on other things. Yeah. Yeah. I mean, I think maybe when you raise your next round, well, I come back to the why, I mean, like on this subject, I come back to the why. So you mentioned like the being naive. I think that's true. There's been some efforts with prior art to to you know do some version of a runtime i think there's even like rust python out there i think dropbox had one that made it faster but they abandoned it so like there may be some maybe sadly to say it like there's dead bodies out there that you have to sort of like navigate like maybe we shouldn't go there because it's already been tried before but coming back to a why and you mentioned being you want to build in the open you want to incentivize your company to build the open.

1:20:58And so I can just come back to that. Why? Like if hypothesize with us for a moment, if you did do something like this, what would be the why? How would you quantify the why from a business owner, CEO, founder, investors, all the things like, how would you prioritize or think about the why of writing a runtime for Python in Rust? Right. I think that's probably one of the reasons that I don't know that we do it is like the, well, so if I think generically about that question, um, in terms of like the business strategy, it's like the open source, like ignoring the Python runtime for a second and just thinking about our existing tools, the existing tools that we build to give us a couple of things.

1:21:43So one is they give us like a lot of distribution. So, um, you know, we're building a registry and like, we have all these people that use UV. And so, um, we have kind of a natural audience of people who maybe want to try the registry. Um, also intimately linked to that is also brand. Like I, I actually think a lot about brand. Um, I think brand is maybe a little bit of like a, everything around like developer marketing and brand is kind of like seen as like slightly dirty if you're like an engineer, because it's not technical, but like, I actually think brand is like incredibly important. And, and for us, it's like, you know, we built rough.

1:22:19And then when we came out with UV, people were like, Oh, they built rough. So like, this might be good. I should give it a shot. And then we see that kind of, I view that as kind of compounding. Like I want to like earn users trust and prove that we can build great things. And so that all accumulates in brand, which again, ties back to distribution. It's like, if we build a registry, people hopefully think, okay, that will probably be good because these people built these other good things. The other things that gives us our, I think we have interesting like technical advantages across the stack in a few different ways.

1:22:49So like with the registry, for example, I actually want to like pull in our type checker in some interesting ways. Like I want to be able to do things like detecting like SEMVR and compatibilities, like within the registry, like understanding if a new version of a package comes out, like can you upgrade like without having to like, or are there breaking changes that affect you or like security scanning? Like if a vulnerability comes out and a package and we know that you're using it and we have like a really good understanding of your code, like we should actually, we might actually be able to tell you like if whether you're affected or not.

1:23:23So like, for me, it's also about trying to compound these like horizontal, like technical advantages across the tools by like bringing those things together. I think for the runtime, it's like, if you think about the why, the why would be like user impact. And, but like, it doesn't necessarily enable us to do a lot of things that we otherwise couldn't do at least right now, unless we built it with specific technical ideas in mind. Like maybe we decided, okay, I'm just making this up on the spot. it's really not something I've thought that much about, but it's like, okay, we want to build a version of Python.

1:23:54It's like, like maybe we really want to focus on like Wasm or something. I don't know. Maybe we're like, we have use cases where we're on like Wasm to be like, like we want to run this like on the edge, like in the CDN or something. And we're like, we're going to go all in on like that idea. So we'd have, I think we'd have to have some idea that basically enables us to do and offer things that we otherwise couldn't offer. Distribution is a really good reason. It is a good reason. I think, you know, more UV out there means more Python out there. more python means more uv users yeah i mean i do think also like if i i not to be too like full of you know full of myself but it's like i do have to think a little bit too about like how do we make sure that python keeps growing because that's important to like that's important to us and so if there are like big existential problems in python like if we thought packaging was an existential problem or something uh then it's like okay let's try to solve packaging so that Python keeps growing, right?

1:24:48So there is a little bit of that too. I don't think the runtime is, I'm not suggesting that the runtime is in that position. I'm just saying that

1:24:58there are benefits for us in helping grow Python. And so if there are things we think we can do to help grow Python, those could be worth doing, even if they're not connected to a concrete product offering that we charge money for. Again, I'm not suggesting that the interpreter or the runtime is in studies. I think that's actually in a very good state. Or just hypothesizing about, I think, you know, learning from the past to save the future from itself. I mean, we're just doing what Rust is doing. I'm just saying in terms of things we choose to work on and why they're worth working on, one of them, one of the considerations is just like, how do we help grow Python and like make Python more popular and bring more people into Python?

1:25:32One more question on this. Maybe, maybe too far, but I don't think so. You tell us, Charlie. And the reason why, so yeah, I think, so if you're concerned with somebody being offended because we're hypothesizing about a future that doesn't exist and if it should exist because you have business interest and vested interest in Python growing, I think that's silly to get upset with that. So if that's you, chill out for a second. Do what you can given how you've improved other Python tooling and to the degree that you have improved that tooling. If you did undertake a runtime, what benefits do you think you could deliver just by nature of what you've done already with Rust tooling for python besides just simply speed like enumerate specifics if you could i think there are things again we're just we're just speculating here just speculating i think there are things that would be interesting to consider changing around like how um this sounds small but sort of like how environment discovery works um so like right now like basically i guess the way i'd put it is take things that actually happen in UV run and see if you could make them part of the runtime is maybe a way to put it.

1:26:47So if you're in a project and you run Python, run that in the context of the project as opposed to just trying to find some global Python interpreter. Basically trying to make Python more, the runtime more environment aware and project aware, I think would be something that's kind of interesting that we could do. So trying to smooth out some of what we see as the traps that users run into. I mean, I think we would, I'm sure we would initially be drawn in by performance if we thought we had ideas that we could pursue there. But again, like there are plenty of people working on CPython runtime performance.

1:27:26And, you know, I don't think, I think there's maybe actually like a slightly different, like the thing that Bun is doing, which is like maybe interesting, but also maybe like potentially a trap, like kind of remains to be seen not for users but just in general is like they're building out a pretty large standard library i guess standard library is probably the right word so like in their standard library they actually have like probably get a bunch of this stuff wrong like i think they have like an s3 client i think they have like a redis client i think they have a like a database client that understands like mysql and sqla and like they have like all this stuff So the idea is like, you can just like work with Bun and like import all those things and you don't have to worry about going and finding third party implementations and they're all like natively implemented.

1:28:16I think there is something interesting there. I think there are down, there are absolutely downsides to that, but I think there's something interesting to that, which is kind of providing like a trusted, if you can build a strong enough brand and, and, and build good enough implementations, providing kind of trusted implementations for all these things that people need in building modern applications. I think is kind of interesting. But again, I don't know that we would ever do that. But the idea of trying to provide really good implementations of all these things that people commonly need, first of all, to provide better implementations that are faster and also reduce the surface area of things they depend on, I think is kind of interesting.

1:28:56You could potentially do that, by the way, without actually forking the CPython runtime. But I do think it's kind of neat. I think it's an interesting direction. Let's take a moment to reflect on brand. because you mentioned it as something that you think is important and that a lot of software people don't necessarily think about. I'm a fan of yours. I think specifically speaking to astral.sh, I think it's a nicely designed website. I appreciate that you have bucked the trend of going, following linear down the road of like dark mode everything. I like that there's some brightness going on. Talk to us about brand, how you think about it, why it's important, by the way, the font.

1:29:36is really sweet. I'm not sure what that is, but that your Y is really cool looking and the G's are nice too. So, uh, you've got some taste in my opinion, or at least we share tastes, you know, there's no accounting for taste, but yeah, whether they're good or not. Yeah. We have similar tastes at least. So I think they're good because they align with mine, but yeah, talk about brand, why it's important, how you think about it, how you attack it. Because in my opinion, that's another thing that's setting UV and astral apart. And it's kind of one of those things that you don't think about right away.

1:30:03It just is there. And so your thoughts. Yeah, definitely. I mean, I think like, I don't really explicitly think in terms of like developer marketing, but like when I first started, like when I first released UV, I was trying to just explain to people as quickly as possible, as succinctly as possible, why they should care about this project. And so the read me for me, like the top of the fold of the read me had to capture that. It had to capture like, why is this interesting? And I remember when I did the launch too, I had like a little graph that was just like a benchmark graph of like uv rough versus like a bunch of other things and like i think that graph was like very important for like conveying to people the significance of like what's happening so like for for communicating to developers communicating to anyone really it doesn't matter who like developers or not it's like you have to assume that you have basically like no like you get like no attention like if you write a blog post for example you have to be thinking in terms of uh most people they might read the headline and they might read the tldr and they might look at the one image at the top but they probably won't read any of the text some people will and it's important to care a lot about what it says but like you have to be thinking in terms of how do i explain to people why they should care about this as quickly as possible so like even just by thinking about that and productionizing it i think you'll as an engineer you'll probably be doing more than a lot of small.

1:31:30Also, by the way, caveat before we get into the actual interesting stuff, you definitely don't have to care about any of this. If your goal is not to make your project very popular, like you can just build stuff and publish it and not care about this at all. And I think that's totally cool. But if your goal is to get people to use your thing and care and then follow along, you know, I think this stuff matters a lot. A lot of how I think about brand too. Like it's very holistic. So like when people come to our repo and like they file an issue or like they ask a question in discord or something, like I would always view those moments as like, I have a moment, I have an opportunity here to like make a friend or like win a fan or something, or when someone who's going to support the project.

1:32:16And so like you try to compound that over time. And so when people would come in, first of all, when I was starting the project and anyone would come found an issue, I would just be so excited that they cared at all. And I would kind of just focus on how do I give these people a great experience? And over time, it becomes, even if I'm going to say no to what they're asking for, how do I make sure that they have a good experience? Like as in they feel heard and respected and they understand why I said no. And we've just focused on that a lot. Like we try to be really responsive in the open source and we try to like give people a good experience.

1:32:48And it takes a very long time for that to have an effect. But like compounding over years, I think it's had a huge effect on like our open source community and like how people view the project. And you have to take a very long-term view towards a lot of these things. But again, that's all connects to me to brand. Like brand is not, like it is the visual identity of the company, but also it's like, what do people associate with it? And I want people to associate with us what I hope is true, which is like, we want to be good, responsible, approachable open source maintainers who are demonstrating responsible stewardship for these projects and that people can trust us.

1:33:26It takes a lot to keep this up too. Doing the open source, even just trying to be really responsive in the open source is a huge investment of our time. We could probably have the whole company just maintain the open source and build nothing new and that would still be full-time work for us. But it's also like with everything we release, we want to like maintain the quality bar that we have. You know, I think maybe actually a good example of something that we've tried to put into our brand is like we try to fix things really quickly. And so even if we release something that's broken, we'll fix it really quickly.

1:33:59And that actually I think has become a really helpful part of our brand because if something's broken, we fix it quickly. And then it gives people more trust that like if something breaks, we will fix it quickly. If we ship something that's not finished, you know, we'll fix it quickly. so i think i just take kind of a pretty long-term view towards a lot of these things and i try and think really hard about like if i were a user what would i need to hear what would i need in order to use this thing on the visual brand we worked with you know some designers like do the initial branding and i actually showed them a bunch of examples of sites i didn't want to be like i didn't just show them positive examples of things i thought were interesting i also showed I obviously won't name any of these companies, but I just showed them companies where I was like, these to me feel very derivative.

1:34:49Vercel and Linear have really amazing brands in design. But then so many companies have tried to just be Vercel or Linear. And I was like, I actually want to do something that's pretty different. It should still feel professional and well done, but I want it to be a little bit distinctive. and so there it's very much intentional i think that it looks a little bit different than a lot of other developers that's one of the things that grabbed me because as somebody who's steeped in the industry as adam and i are and we see lots of company websites lots of open source product websites you know there is this uh what used to be the old bootstrap effect right like all you could tell you saw a bootstrap website well now it's like you can tell when you see a VC backed open source, you know, website.

1:35:37Cause it's like, they're basically derivative. I mean, not all of them are linear. I think started at all Vercel does have amazing work done. And so a lot of that is just like, well, those look good. I'm going to copy that. And I got no problem with that. Like if there's more important stuff to do, fine, go ahead and do that. But I've been waiting for a turn in the trend. Like who's going to come out and be different. And so I'm just applauding you for that reason. Yeah, no, I appreciate it. Yeah. I look like, I don't know, like Sentry is kind of an example here too, where it's like, they have a very different brand.

1:36:06Yeah. Sentry does have a very distinctive brand. And like, some people don't like it. Some people love it. Like, I mean, like PostHog would maybe be another example. They have like a totally crazy brand. They do. Their website. Did you see their redesign? Their website is crazy right now. I did. It's like an in-browser. But they really lean into it. It's like, it's everywhere. Yeah. It's like, they're, they're like real world advertising. Like everything is like. Right. Well, you said it. I love it or hate it. Like those are two strong emotions, right? Like you're going to remember it. Like I knew exactly what you were saying when you said century and when you said post hoc.

1:36:36Right. And whereas there's lots of them where I'm like, I can't remember what that brand was, but anyways. Yeah. I mean, I think it's been interesting for us too, to like try to figure out how to kind of like connect our open source to the brand. Cause there's like, I think there are actually a bunch of people who don't realize that like our tools are connected or that there's like a company behind this work. And so it's been kind of interesting for us to think about like how to, how to like communicate that to me. Like over time it happens, but like, we definitely have people who are like surprised to learn that like rough and UV are related, for example, or that there's like, or don't know that there's like a company behind these things.

1:37:10And so those are like sort of separate challenges, but that comes up too. one thing i go back to and it just stems from the things y 'all are saying is like most like those those websites that are not to be named they're they're beautiful but they generally suck in some way and the reason why i think they suck in some way and really by the main thing is like if you land on it it's really hard to understand what they do it's some sort of like pie in the sky marketing pitch rather than something as succinct and just like compressed as next gen python tooling and i think that's like that's the promise you were delivering i think that's that's the thing that i think is challenging with a lot of these markets and i evaluate a lot of them too because we work with a lot of different brands to by way of understanding who they are so that we can take their message and help them communicate to our audience in a way that isn't marketing, but it's a story of who they are, why they built what they built, who uses it, and how they benefit from it, how they, the audience may also benefit from it too.

1:38:20Too often, I'm just like lost in my journey, my personal journey, because that's my job is who are you? Why do you exist? Why should I always care? And how can I help you tell our audience in a way that respects them as developers, respects them in terms of their time, and helps them truly learn and be educated about that tool, that company, that thing, that service. Yeah. I spent a lot of time just figuring, like, what do you do? And your homepage doesn't always, not yours, but the proverbial your. Yeah, yeah, yeah. Often just misses the mark. It's like, you know, bento box this and sliding thing there.

1:38:55And it looks really beautiful, but it's like, can you please just show me the tool? How does it work? How am I going to use it? And I think that's the challenge. I mean, I think the other thing that I found is like, I couldn't, I can't really like outsource like voice, like all the copy on the site. Like I like did myself and it's like, cause I just think a lot about, I guess just cause like I've spent my whole career as like an engineer and like, I'm not like, I know what it's like to like land on those sites. And I know what it's like to like when people speak to, especially to like engineers or technical audiences in a way that feels like authentic and a way that feels like inauthentic.

1:39:36And so, yeah, I mean, I guess the trade-off is I spend so much time on like any public messaging, like, like the PYX announcement blog post, or even like the Twitter thread, like none of that stuff is like off the cuff. That stuff's like, I'm spending like a week, like writing a draft, throwing it away, getting feedback like writing a draft throwing it away so like i yeah i spend a lot of time on like basically on like our public messaging and the things we say and i've sort of just accepted that like that's just something that takes me personally a long time and like i have to go through a bunch of drafts and i have to like have a few chances to look at things with fresh eyes which means it takes time because i need to like step away from something for a day and come back and read it and like so anyway i guess my point is i don't my point is just that it takes a lot of time and um it's hard to i think it's hard to fake and it's hard to outsource yep totally agree well we've kept you here a long time we appreciate you chatting with us it's been super fun yeah we've gone in a lot of different directions i appreciate all the great questions and all the interest in letting me talk about some fairly obscure technical things um that's fun yeah that's what we do here yeah that's what we're all about that's the good stuff yeah yeah we enjoyed it for sure yeah i've learned more about python and python packaging over the past two years than really than anyone should know so like whenever i can find people to listen i'm like very happy to chat about it well pyx is what's next astral.sh that's a-s-t-r-a-l dot sh slash pyx yes go there check it out it is the next step in python packaging doing the wait list there you go if someone no don't brew install don't brew install curl install uv yeah curl curl install uv yeah nice install uv however you want but you should use it yeah come on it's great the right way very good thank you charlie for sharing your story awesome yeah thanks for having me take care

1:41:43so charlie and his team are experimenting with pyx as a money-making product we're also experimenting with changelog news to make a little money we're playing with the idea of adding a classifieds section to the news it would have a maximum of five listings per week that appear both in the newsletter and in the podcast audio they'd be super brief headlines only and linked to a url of your choice if you'd like to put your startup your passion project your big idea, your event, your whatever in front of changelogs classy, well-to-do audience of hackers. Fill out the form that's linked in your show notes and in the chapter data.

1:42:20Thanks for listening and thanks to our partners for sponsoring fly.io and depot.dev. All right, that is all for now, but we'll talk to you again with our old friend Feras, all about NPM and those supply chain attacks on Friday.

1:42:49Thank you.

1:43:16Game on.