Supercharging Python Tooling – An Interview with Charlie Marsh

Introduction and welcome

[00:00:21] Tim: Hi everyone, welcome! This is Charlie Marsh from Astral and, uh, you, Charlie, have been building something I find slightly incredible. So this is my perception of, of, of what you’ve done. You thought, oh look, I’ve got this linter ruff that’s suddenly going to make the life of Python developers 50 to 100 times better?

And then, Oh, it’s like, by the way, we’re just going to bring out <href=”https://github.com/astral-sh/uv”>uv, hire some of the best Rust programmers in the world to create this amazing company. We have adopted this Rye thing as well, which is kind of like adjacent to that. And now you have made the lives of millions of Python programmers dramatically better.

Like what a gift to the world.

Ruff’s origin story

[00:01:11] Charlie: Thank you. Um, no, I, uh, I, I really appreciate that. I mean, I, I don’t know if I would, um, say such nice things about myself, but, um, I appreciate you saying them. Um, I think, uh, I love working on tools, um, because it’s such an amazing, like, platform for impact. And, um, you know, originally when we were, when I started working on ruff, I, It was really fun, but like no one was really using it.

Um, and I got, it was very gratifying, you know, in some ways and maybe not in others. And now, um, you know, we’re kind of at the point now where, you know, if we ship a really big improvement to ruff, um, It immediately goes out and impacts, you know, a very large portion of the entire Python ecosystem. Um, and new capabilities and new, new powers start showing up in your editor, right?

And like new workflows become possible. So, um, I love working on tooling, um, and I think the idea, That, um, we get to kind of keep in a compounding way, make Python better and better and better is really one of the big drivers of, of like why I am working on this stuff and why all the people on the team have joined too.

[00:02:16] Tim: Python seems to be going through, I’d say, somewhat of a renaissance or renaissance. Uh, the, uh, with like Python 3.13 [that] has just been, uh, has landed with sub-interpreters and no GIL. And it just feels as though there is, has been this, a reaction to say static typing with mypy, for example, originally, and that being pulled into the language.

And now with tooling such as your own, you have, uh, Essentially, this compounding effect, that’s a really interesting way to express that. Why, why did you think that you could do something different than what had already happened? Because when Ruff was being created, there was already Pylint. There was already probably, I think Black was also, was quite prominent.

[00:03:15] Charlie: Yep. Yeah.

[00:03:16] Tim: And you thought, you know what, we could do better. Yep.

[00:03:20] Charlie: Ya, I think, um, you know, one of the big drivers for me, um, in, in working on this kind of tooling was, um, I was seeing a lot of what was happening in the, the web ecosystem and the JavaScript ecosystem. And I think there are like a couple of interesting.

Things, you know, properties that the web ecosystem has and things that happened in the way web ecosystem that led to this, but, um, they, there’s just been a, um, a lot of innovation and investment in, in web tooling. Um, and, you know, and people complain about things like, oh, my node, node_modules is too big.

Right. But like, um, uh, there’s just a lot of people working on web tooling, um, and doing really interesting things in it. And, um, you know, I think a lot of that comes from, like, uh, React and TypeScript being these two, like, hugely successful projects that had big corporations behind them, and that, like, attracted a lot, it became very cool, at least in, like, my world, I don’t know, it became very cool to, like, work on web tooling, whereas I think when I was, like, in college, maybe, I think like front end was like not as, um, it didn’t seem as like hardcore, right?

It was like the trope, um, whether it’s true or not. I started my career doing front end.

[00:04:37] Tim: That’s, that’s pretty close to being a designer, you know, like, gosh, is that even real engineering?

[00:04:44] Charlie: Yeah. And it turns out it like really is, and it’s actually very hard and complex. And there’s like a lot of super interesting work to do.

Like I’ve spent a lot of my career doing front end actually. Um, but it was interesting to me because there were just all these, all these people going in and like, everyone’s kind of working on innovating and building tooling. Um, and, and, you know, the other thing I noticed there was. They, in web, they just ran into a lot of problems, like a lot of performance, especially like local driven and development driven performance problems, um, quickly.

So like apps got bigger, and you have like, bundling and transpilation and minification, like all these things going on. So like, things are getting slower, and so people started to build like, Faster and faster tools. And in particular, they started to build tools that were not written in JavaScript. They were like, okay, we’re going to build like foundational tooling in different languages to enable everyone who’s working in JavaScript.

Um, and the first example I always think of there is like esbuild, which was written in Go. Um, Now there’s like a whole proliferation of tooling that’s written in like Rust and Go and Zig in in the web in the web ecosystem And so I kind of like saw all that stuff happening in web and I was like looking at Python And I was thinking like why isn’t this really is there a reason that it can’t happen in Python?

I guess would have been the question and it was um You know, it was a time in my life when I was kind of trying to figure out, I’d sort of, I’d left my job and I was kind of trying to figure out what I wanted to work on next. And, um, uh, you know, one of the big pieces from that too was I, um, I wanted to get better at Rust.

That was like an honest, a very honest motivation for starting to work on Rust.

[00:06:22] Tim: Yeah, I, I, I relate to that very heavily. I, uh, sometimes say the reason I wrote Rust in Action was to teach myself Rust

[00:06:32] Charlie: Yeah, exactly. I mean I

[00:06:34] Tim: Like take on some big audacious goal

Learning Rust

[00:06:37] Charlie: Yeah, and I think I wouldn’t recommend this for everyone. But like for me, I think I kind of needed to like build something from scratch.

Um, and you know, in my previous job, like we had a big Python monorepo and we started to move towards like a hybrid Rust Python, uh, monorepo over time. So, um, and it was, but I did not introduce that. It was one of my coworkers, brilliant, engineer named Colin Fuller, um, and he was like, I think we should start building some of our, like, performance critical services, uh, in Rust, also get like a lot more platform portability, much easier for us, because we were also writing, we were also writing software that we needed to run, um, like on Windows machines in particular, because we had a wet, we had a wet lab and we were building software for scientists, so we needed to run, to write, you know, code that could be very portable.

And then, uh, on the server, we were like downloading like many terabytes of images and we had like a lot of performance critical routines we were doing there. So Rust turned out to be like a really good fit for us. And the Rust Python interoperability story was also very good. So we were using Py03. So we were writing all this stuff in Rust, exposing it.

over py03 on the Python side. So from, from the Python perspective, we were kind of just like, you know, calling, calling functions and under the hood, it was all written in Rust. Um, and so that was like my first brush with Rust. Um, and the thing is like, you’re at a startup and you have like so many responsibilities, so like, I never really learned Rust in that setting.

Like I was always, you know, I was going in like making contributions and fixing issues, but I was just trying to get in and out as quickly as possible. And like the Rust paradigm is just, um, I mean, I continue to believe like the learning curve for Rust is very high, especially coming from Python. Like most of my career, by the way, like, I mean, professionally, I mean, the closest thing I’ve done professionally is like I wrote Java for a year, right?

But most of my career has been like Python and TypeScript and I’m not like a I’m not a systems programmer by background at all. So it was just a lot of new very new ways of thinking for me. I found like again coming back to why I started talking about this in the first place is that Like, one of the reasons I wanted to build Ruff was like, I think I need to learn Rust.

And I think to really learn Rust, I need to build something from scratch. And the way that I like to learn is just by doing. Um, and, I just know, you know, and then I just spend a few days like, banging my head against the wall trying to understand. The borrow checker, you know, and like I was working with an AST, like tree structures are like particularly, I guess, like, I don’t know about annoying, but like, you know, it can be a little bit more challenging.

And so I just spent a lot of time trying to understand lifetimes and trying to understand what am I doing? And, um, uh, you know, I think like at some point, I think like the, one of the first levels of like Rust, one of the first milestones I saw in myself was, I knew, um, I wrote some code and I actually knew it wouldn’t compile. And I knew why. And like, I didn’t really know how to fix it, but I knew what the, I knew what the error would be. Like, that’s like a one level of understanding, which is like, you don’t quite know like what the solution should look like, but like, okay, I know what I’m doing here is not right. And I like, I, I know why.

[00:09:51] Tim: I’ve heard that, I think, in a different context, which is that, um, one of the really big distinguishing characteristics between someone that is, I’d say, let’s say an intermediate or, you know, starting, very few people would be comfortable to say that they are expert Rust programmers. I think that’s probably the case.

[00:10:08] Charlie: Yes, I would absolutely not say I’m an expert Rust programmer.

[00:10:10] Tim: Um, and, but one of the indicators of someone that has proficiency is that they are much faster at diagnosing and like remedying errors. Um, it’s not to say that they actually have. They write fast, or sorry, write better code straight away, it’s just that when they encounter problems they, their brain is slightly more attuned to the signals that the compiler is going, or it’s like something kind of seems a little bit iffy with the control flow here, and so I think that the borrow trigger is going to complain.

Yeah. And so that’s, that, that it’s interesting to see that, that come through. I was wondering, and I don’t want to put you on the spot too much, but how do you explain lifetimes? Like if someone comes to say, Oh, I’m a TypeScript developer, I’m interested in Rust, but I’m really, these things don’t make any sense to me.

[00:11:16] Charlie: I feel like my answer to that would actually be like I Won’t I won’t actually answer the question because I don’t know if I’ve ever actually had to …

[00:11:26] Tim: Okay.

[00:11:26] Charlie: …but I think but one thing I’d think about with Rust and maybe I’ll try and tie us back to an answer is like I do think that that if you I think if you just like dive in to like expertly written Rust or expose yourself actually to like too much of the language, I actually think it’s like not that helpful like I wrote just an example like I wrote so much Rust code before I actually used even like Box<_>.

[00:11:58] Tim: Yeah.

[00:11:59] Charlie: Like you can just write like a lot of and if you you know If you get dropped into Rust code something you see like, okay, I got like box sure fine Then I’ve got like Rc and I’ve got Arc and I’ve got like RefCell and like you kind of get exposed to all this stuff. Um, even like lifetimes like you can get pretty far explicit lifetimes at least like you can get pretty far without like actually using any explicit lifetimes.

Um, and it, it’s funny because I think if you see all that stuff like If you see like Rc and, and I mean it’s fine to like use this stuff, sure, but like sometimes you see things and you’re like, okay, I have a problem in my code and like I kind of Google, uh, you know what, what the problem is. It’s like, I need to be able to mutate this. Um, I don’t know what’s a good example. It’s like, I need to be able to like mutate this thing without marking it as mut. Right? And so then people are like, Oh, like you should use like RefCell, right? Like blah, blah, blah. But, and like, that actually might be right. But often when you hit problems in Rust, I find that you’re thinking about that. You’re actually thinking about the problem in the wrong way. Like, like someone else should own the data, right? Or like the, or like it should be passed in in some other way. And so I found that like, it was actually helpful for me to like, ignore a lot of that stuff and like, and it’s not like I was like that smart about it, but I was like, It was helpful for me to, like, ignore some of that stuff and, like, try to, try to, like, uh, force myself to learn things without reaching for some of those more advanced tools, um, in order to learn, to learn Rust.

[00:13:31] Tim: Totally agree with you. There is a very, I find this, one of the other things is that you encounter an issue and you sort of had this decision paralysis, it’s like, well, how do I fix this? And maybe pausing and thinking about how the code is structured and saying, well, actually we want one unique place that has responsibility for cleanup.

[00:13:54] Charlie: Right, right.

[00:13:55] Tim: And how do we enable that? Like how we could use a fancy smart pointer or we could tweak our code. And, um, yeah, I, I, I like that idea actually of saying, don’t be intimidated by, um, the very advanced stuff that’s, you know, at like the 99th percentile. Actually, you could probably stay in the 50th percentile for a long time.

[00:14:23] Charlie: I think you can. Yeah. And like, and in the context that you’re writing code in, like, I don’t know, I’ve become like allergic to a lot of things from working on ruff. Like, I’m very allergic to cloning. Like probably too much, you know what I mean? Like now, like we have ruff and we have UV now, which is like a, it’s sort of like a pip alternative. It’s a Python package installer, um, and resolver, uh, written in Rust. And like in UV, a lot of the dynamics are really different because there’s like way more IO. Um, like we’re downloading packages and like zipping, right. And like blah, blah. And so like cloning is actually like, not nearly as much of a big deal.

Um, whereas in rough, if we’re, if we do like a lot of, a lot of cloning or a lot of allocations in a hot, in a hot path, like it immediately shows up in all the performance profiles, like it’s very obvious. Um, and so like ruff kind of trained me in a certain way. Um, and it’s funny because now I work on UV and like I have people on the team who are like complaining about all the lifetimes They’re like you should all just be RC or like blah blah blah or like we should just clone here or like blah blah And like they’re actually they’re actually right. Like I think I have like over rotated on some of the things I learned from working on ruff But it’s been interesting but like yeah again, I think Like, you can clone your way out of problems if you’re learning Rust, right, as a way to get yourself to move along, I think, sometimes. Um, and maybe the expert level solution lets you avoid some of those allocations, but like, often it won’t really matter.

Khan Academy and its engineering culture

[00:15:54] Tim: Sure. Hey, I was wondering if we could segue slightly back to, uh, your career and some of the things that you did beforehand, because there’s an overarching suspicion that I have. I’ve got a couple of assumptions about the kind of person that you are. Um, so the, uh, and I just want to essentially either validate that, um, Because it seems like a lot of the decisions that you’ve made have been very centric, uh, very, you’re, you’re, you, correct me if I’m wrong, but you worked at a health science, uh, machine learning startup for diagnostics. Um, and, uh, before that you worked at the Khan Academy.

[00:16:42] Charlie: That’s right.

[00:16:43] Tim: And that implies to me that you’ve had other people at the front of mind for a long time. And, and I don’t want to be too prejudiced against, uh, so I’m gonna, and, but you, I saw that your undergraduate at least is at Princeton, but you probably made a deliberate choice not to do grad school.

Was that correct?

[00:17:07] Charlie: Yeah, that’s right. Yeah.

[00:17:10] Tim: So do you want to talk me through …

[00:17:11] Charlie: …that career path and why I made these various decisions? Yeah. Yeah, yeah, of course. Um, well, I, uh, I interned at Khan Academy, um, after my junior year of college and, um, that, uh, that experience was just really, really good.

[00:17:32] Tim: Cool.

[00:17:32] Charlie: And so, um, uh, you know, I wanted, it was, it was pretty clear to me that I wanted to go back and join full time, but I think the things that made that, um, uh, a really appealing decision to me, you know, one was, um, I try and a lot of these career decisions, um, around impact.

So what are things I can do to have a significant positive impact on, on people in the world? Um, and uh, Khan Academy is something that I had used, um, you know, a lot. It was really helpful for like, for my own education. Um, and so the opportunity to go and work there in terms of like impact, you know, was really, um, really appealing to me.

Um, you know, the other pieces to it were, um, Khan Academy, um, had a really, really strong engineering team and engineering culture. And so like most of the things, like, I think. Khan Academy is where I learned, you know, at least for one definition, like what it means to be like a great software engineer.

Like, I don’t think it was necessarily me at that point in time, but like I got to work with a lot of really amazing people.

[00:18:35] Tim: I can’t believe that you are not a person who believes that they were, you know, a 10X developer, um, in their very first gig.

[00:18:43] Charlie: I think I was a good, I think I was a good software engineer, but I was also pretty young, right?

And I was also learning and everything was new. But like, you know, the, just the quality of people.

[00:18:52] Tim: So what’s it like, the culture? So you said they have a strong engineering culture. Is it 100 percent remote? Is it all, uh, in a building?

[00:19:00] Charlie: This is a while ago. This is like 2015, 2016. So it’s a while ago at this point.

But at that point in time, it was about a third remote. The rest was in Mountain View in California. Um, and there were just some really, yeah, some really amazing people who kind of anchored a lot of the culture, like, um, like Ben Kamens, who is the VP of engineering. And then he went on to found the company that I joined after Khan Academy, which is how I got, how I got sort of roped into, um, that, which is, you know, we can talk about that too.

Um, uh, uh, John Resig, who’s like the creator of jQuery, um, still at Khan Academy, I think, um, Craig Silverstein, who was like the, The first employee at Google and then joined, he’s just like, it’s incredible. Software engineer, um, Sophie Alpert, who was like for a long time, the number one committer to react outside of Meta and then joined React and manage the React team eventually.

So it was just like a very, very high quality group of people. Um, and there was a lot of, um, emphasis just put on, on, you know, on the culture. And I think I, I think everything from like our career development guide. I just learned so much by looking at like what is this company value and like what are the traits that someone has that demonstrates that they are, for example, a senior engineer?

Like what does it mean to be able to own? What is, what is this concept of ownership that people keep talking about? And it just really helped me understand, um, uh, you know, the, the, uh, I had a lot of role models, I think, is what I’ll say, and I had, it was a very good setting for me to kind of grow and, and, and, and learn how to be, um, a better software engineer and not just technically, but in terms of taking on more ownership and being, um, growing my maturity, um, my ability to execute on large projects.

Um, but I worked..

[00:20:41] Tim: Software. Oh, sorry, excuse me.

[00:20:44] Charlie: Was just gonna say I worked like all over the stack there because I started I started doing like mostly doing front end. We were like a really big React company, which is I guess everyone is now sort of but like that was a little bit less the case at the time.

You know, I did like I worked on our first like iOS apps a bit. I did like a year of Android, too.

[00:21:04] Tim: Oh, which is where you would have done Java.

[00:21:05] Charlie: Yeah, exactly. Yeah. And then, and then our, our backend was all Python and we were like, we just had like a huge Python code base. Um, uh, and so I kind of got exposed to, you know, all those different uh, parts of the development stack.

Um, which, so for me, it was like kind of the perfect place to be an engineer starting out my career and, and I still lean on a lot of the things I learned there about like being a, being a great and productive engineer, um, today, especially as I’m looking at, like, how do we define our own culture as a company?

Founding a technology company based on trust

[00:21:35] Tim: Yeah, I mean, that must be quite intimidating because it’s a significantly different set of skills, essentially being asked to be the senior leader, especially in a small company. And you’re founding this from the east coast of the United States, outside of Mountain View.

[00:21:54] Charlie: That’s right, yep.

[00:21:55] Tim: Most people are building software companies outside of Silicon Valley.

So, do you have any, you know, like, pearls of wisdom, or any bits and pieces for people that are kind of, maybe at a four to nine people, you know, like sub 10 individual company that are growing healthily to really set that foundation for like the next 10 years.

[00:22:21] Charlie: So for us, um, yeah, I’m based in New York. Our team is nine full time, um, including me.

Um, and no, like no two people live in the same state. Um, and outside the US, no two people live in the same country. So like we have about half the teams in the US, half the team is, um, is, uh, international outside the US. Um, and we span time zones from, Pacific through to, um, IST, like, uh, Bangalore would be the furthest.

So like, it’s a very large range of time.

So…

[00:22:58] Tim: I’m sure your accountant is very happy with you.

[00:23:01] Charlie: Yeah. Um, it has that, I think it’s sort of like the least of the challenges, but yeah, that is, that is one of the challenges. Um, I mean, I think for us, like the main thing that the main things I focused on are one, um, we’ve grown this team very deliberately.

So like, um, you know, I think in March of last year, uh, that was when I first hired anyone apart from myself. And we grew, I hired two people, like in March we grew from one to three. And then from, from March, so over the past, you know, a little over a year, we grew from like three to nine and, you know, it was incremental, right?

It was like, One month we had four, and then two months later we had five, and then a few months later we had six. Um, and, you know, even like three to six to nine, those are all like really different companies. Um, yeah, and so everyone’s like, you know, some people are rolling their eyes being like nine is not a big company, but like, if you were three, then like suddenly nine just, you know, like a lot of the processes that you put in place when you were three like don’t work anymore.

Um, and so, being flexible about how you change, like how you work, I think is really important. Um, yeah, I think one of the main things that we’ve tried to focus on, especially being a distributed company, is, um, uh, And it sounds cliche, but I’ll give some examples. Like, I think in order to work effectively, like, asynchronously, You have to have a team that really like trusts each other a lot.

Um, and my favorite example of trust or a very concrete example of the thing that we try to do is like, If you’re reviewing someone’s pull request and you think it’s close, but you want some things to change, like approving it with feedback rather than like leaving comments or requesting changes is like a way more effective thing to do.

Um, because it can save like a whole day in turnaround time, because imagine you get some comments, then you go to sleep, they wake up, they address the comments, you wake up, eventually you approve it. They’re asleep then they wake up and merge it. Right. So like, But that requires trust, like you have to be able to trust and have good norms and establish norms around, if I give feedback.

First of all, I know that they’re actually going to look at it, take it seriously. They don’t have to address it, but I can trust that if they don’t, they will at least consider it and have good reasons for, for not addressing it. And they will tell me why. So like trying to build a culture that’s really based on trust, I think, I think if you like have a culture that’s really based on distrust, um, or, uh, or not, or, or at least not based on trust, the alternative is very bad.

[00:25:32] Tim: Yeah. The alternative is unhealthy, right?

[00:25:34] Charlie: And also I just think way harder. Like, it’s hard to work asynchronously effectively, um, you have to be able to trust people to like make good responsible decisions and also be respectful of, uh, you know, the feedback you give and, uh, and, and your own opinions. So, um, that’s been a really important thing for us.

[00:25:53] Tim: That is a very hard thing to maintain and it’s much harder when you, if you don’t start in the right place. And I can speak from my experience of working at a very large company. When essentially individual teams or individual departments are almost at war with each other because of the way that the metrics work.

Essentially, you lose a lot of faith that the people outside of your sphere of influence have your interests at heart. Whereas it’s nice to know that Our colleagues really care about the product. We really care about our customers and our users. Uh, so that’s, that’s really positive. One of the other things though, approving with comments, I like that approach, but I did have one instance in my career when people had one, I suppose, yeah, I guess we call him my manager, uh, engineering manager, let’s say he would always approve.

But sometimes it would be like a tacit, like a very like, but this needs to change. And I was of the opinion, I was like, actually, if you need significant refactoring, I would rather that you hit the changes required button because that like sets me up with this mental model of, oh, okay, so that’s fine. You’re being honest with me. Um, that’s another way of, um, Uh, I, I think respecting the protocol and like, not being afraid. I like rejection is a very, very, like, I don’t think I’ve ever had a PR explicitly said someone said no to, but, um, this does not make, but

[00:27:39] Charlie: I mean, if you’ve contributed to open source, you probably have at some point, but yeah, no, I don’t.

It’s much more likely that your patch is just going to sit there for a long time.

Building a company in public

[00:27:53] Tim: Um, so do you want to talk me through the relationship with VC funding and open source? Because this must have been something you’ve thought about personally. And, um, I’m, I’m, I’m really interested in your take.

[00:28:08] Charlie: Yeah, totally.

Can I react to the thing you were saying before though, quickly before we…

[00:28:11] Tim: Oh, sure.

[00:28:12] Charlie: Yeah. So I think like, um, a few things on the, like, it’s actually helpful when people request changes, like that general theme. Um, first of all, yeah, definitely. Like, I think there’s a lot of, um, implicit norms that get like established on a team.

Um, and I, I think if you, if someone puts up a PR and, you know, There’s actually like important like discussion or dialogue to be had about some of the core decisions, then you should not approve it But part of it is like well, like you should you should signal that like hey, this is what I’m thinking about blah blah Sometimes it can be a sign of process failure I think if you like get to a PR and there’s like a significant disagreement about design Sometimes it depends like what the PR is supposed to be and what you’re trying to accomplish with it But but but another part here is like If you’re gonna build a culture that’s based on trust, like, you start with a certain level of trust, but then it needs to be, like, built up over time.

So, like, you sh part of it is, like, we assume good intent and we assume trust to start. There are things you can do to, like, lose people’s trust, and there are things you can do to, like, build people’s trust up further, and so, you know, early on, like, we might, um, start with a certain tolerance or a certain level of, like, we’re gonna prove this with feedback, or, like, we’re gonna, let’s have some discussion about blah, blah, and, like, use some of these as learning opportunities, um, but, but I guess for us it’s, like, start from a high degree of trust and try to, like, build it up over time, and when we see people lose trust, then try to figure out ways that we can restore it.

[00:29:40] Tim: Yeah, sure, because I guess trust tends to neutral over time with like a lack of intervention. I can see that happening on both angles in relationships where there might have been a significant disagreement, well one of the You know, common patterns is that people will essentially not talk to each other for a couple of months and then be able to come back.

It doesn’t work so much in an organizational setting, but, um, Are you actively looking for signals that trust is being maintained between? Your stuff. I mean, I don’t probably, I don’t want to peer too much into the company, but, um, that, that would be kind of interesting.

[00:30:22] Charlie: I do. Ya. I mean, I look at like, I mean, the funny thing is, right, that, like, we’re remote. So like most of our, like almost all of our activity and interaction, um, I mean, a very, very large portion of it is like fully public. Um, because we don’t have, we have one private Git repo and it’s our company website and everything else that we do is public, right? And, um, we developed UV, that was a private repo from like October to February and then we released it.

But like the whole Git history and all that discussion, everything is there. Um, and then, uh, so like a lot of what we do is just like fully public. And then, um, you know, all of our internal communications, they’re private to outside the company, but you know, it’s all public within the company. Um, so like, uh, because we’re distributed, it’s just like, there’s a lot of visibility into like what, how, how people are engaging and, and all that.

Um, and you know, I look at, I, I, I think like being a leader, a lot of it’s like trying to pick up on small signals. Right. So like looking at how, and not in a way where I’m like snooping on people, but like, okay, when people engage in a PR, like what’s going on, like someone requested changes or like, was that reasonable?

Like, how do I think about that? And then, um, or like, are they treating these different people on the team fairly, or like, did this person, uh, take this feedback well? And, and, and so I do like look at all that stuff and I think about it and I talk about it with people on the team. Um, and then I guess the other piece, it’s a little bit different, but like, I don’t know, sometimes I try and do things, maybe this is stupid, but like, sometimes I try and do things to like exhibit behaviors that I think are good, um, yeah.

[00:32:08] Tim: Yeah, look, I think modeling is important, right? As long as it isn’t you attempting to project something that doesn’t exist. And it strikes me that you’re actually projecting, you’re exhibiting the way that, you know, some idealized state, potentially, but, um, but that’s, that’s okay. You can create. You’re not going against the grain, really.

You’re just kind of reinforcing. It’s interesting to hear that, you know, sometimes you will go and read the comments, and I think this is really important whenever I’ve supervised or met with people, or even when I’ve gone for a promo, promotion. I’ve had feedback at like interview loops. It’s like, oh, no, no, we’ve, we’ve looked through your interactions and they’re really, really positive.

So that’s, uh, a really good sign for us that you’ll be a good fit for the team because when there are changes that you’d like, you’re very, uh, tactful. And so that’s, um, so just, just a hint, I suppose, to everyone that, um, Being thoughtful and mindful of the way that our messages are, you know, that has an impact that essentially can last longer than your tenure at the company.

[00:33:23] Charlie: Um, yeah, yeah, totally.

[00:33:25] Tim: The git, the git history is gonna be there for a while. . Um…

[00:33:29] Charlie: Ya. Ya.

Static typing in Python codebases

[00:33:32] Tim: So the machine learning company that you were at, you wrote a blog post in 2022 talking about mypy.

[00:33:40] Charlie: Oh, yeah. Yeah.

[00:33:41] Tim: And uh, and static typing. So this is obviously, so we’re sort of several years down the track. So you started interning, I guess, 2015, um, by, by 2022, you had become a senior engineer with a lot of, with sort of incubated, let’s say within, uh, this context of lots of very significant role models.

And now you, you are building, uh, a very important product and you really want to make sure that your code is robust. And so what was your main message in that blog post?

[00:34:18] Charlie: Um, so yeah, so that originated, yeah, after Khan Academy, I worked at a company called Spring Discovery. Um, so drug discovery and diagnostics company, um, all based on computer vision.

So we were like taking very high resolution pictures of cells and then trying to train, um, models on them to understand what happens when you introduce drugs or add viruses or whatnot um, and in that context I was maintaining a lot of our software infrastructure machine learning infrastructure data infrastructure.

So we just had Um, a lot of Python, uh, because we were doing scientific computing and so all our infrastructure was also Python, um, and we were a pretty small, like, core engineering team, like, uh, you know, like the, let’s say the company as a whole was like 25 to 30, the sort of, um, computational team, which was like software engineering, data science, machine learning, was like eight.

And like two of us were basically responsible purely for infrastructure and the rest were in some, were either like machine learning researchers who were writing, who were building some of their own infrastructure, but, uh, they were either machine learning researchers or data scientists, right? Whose questions were to, uh, leverage data to make discoveries and answer questions.

So we were. We were building a lot of infrastructure for them and we were building infrastructure for, um, like the wet lab scientists who would then look at all the data that we generated and, and again, try to answer questions like which drugs are most promising on X or Y axes. Um, so we were a small team trying to do a lot and like the main way that we got a big lift was, was tooling, right?

It was like static typing was like a big part of it. We had, um, at least by my standards, a pretty large and extremely heavily typed code base, and that enabled us to to, um, I mean, Python typing, we talk about it a lot. There’s like a lot of opinions on it. Um, at least in that context, it, it enabled us to do a lot of refactors that otherwise would have been completely impossible.

[00:36:08] Tim: So you made the claim, I don’t, not so much the claim, but that you. had probably the most strict, you set MyPy to be as difficult as possible for your developers for a code base that was roughly 300, 000 lines of code, give or take, let’s say. And so that’s a significant amount of code maintained by a pretty small team. And you decided to run, do Python, let’s say on hard mode and you would disallow any, for example,

[00:36:42] Charlie: Yeah, yeah, yeah. So like the any type, yeah, we didn’t allow that. Um, uh, and it’s, it’s very hard to, yeah, it’s, I, who knows if that claim is true. It’s probably not, but like we had a very, we had basically, we had a very large Python code base that was extremely strictly typed.

Um, and, uh, you know, that blog post really was about the, it’s sort of a common theme with some of the Python tooling, which is that, and it’s one of the reasons really, probably the primary motivation for starting to work on ruff was that, um, the tooling just really struggled to scale with the systems that we were building.

Um, and in ruff, you know, I think ruff has since actually grown to … have a lot of other value propositions that aren’t just performance, some of which were intentional, some were unintentional. Um, but, uh, but performance was really like the big one that we started with. Um, the unintentional, I think you’re reacting to this idea of like, some of them are unintentional, like, rough bundles a lot of tools together.

So like sometimes when we see people adopt ruff, they might replace like 20 or 30 dependencies, like individual tools, um, because in Python, um, the, the tooling landscape is, is very fragmented, um, I guess fragmented is kind of pejorative. Um, there are lots of different tools that people kind of compose together to get to their end user, their end experience.

You know, there are different linters. The linters have lots of plugins. Import sorting is a separate tool. Code formatting is a separate tool. Type checking is a separate tool. There are separate tools for like modernizing your code. Um, there’s just like a lot of different tools that people tend to chain together.

And in Ruff, we ended up. Basically bundling all that stuff together. So it’s like one tool that you download and install and learn and exposes all those capabilities. And that was sort of an unintentional thing because it was very hard to build a plugin system. Like early on, I was like, I don’t really know like how to build a plugin system here.

It’s just like, there are, it’s actually a pretty interesting design space of like, how can you build a plugin system? For a tool that’s written in Rust. And there are actually a lot of interesting options there and we may do it eventually. But early on, I was like, I don’t really know how to do this. So like, but this project wants to use my tool and they need this functionality.

So I’m just going to build it into the tool. And like, we ended up, we kind of ended up bundling a lot of this stuff by accident. It became a very big part of the value proposition because especially for small projects, maybe they don’t care at all about performance. But like the idea of being able to greatly simplify their toolchain is really useful.

So, um, that was something that was a little bit unintentional, but has become a big part of what we’re trying to do, which is like a lot of, we want to simplify a lot of the tooling by bundling things together. Um, and it’s similar for packaging, like packaging again, Um, for any one thing you want to do in Python, there’s like 10 different tools you could use and you might need like three or four of them.

And you have to figure out like which ones and you have to understand. We don’t need to talk about Python packaging, but it’s, and again, it’s a similar thing where like we want to ship like UV, like right now I would say it can comfortably replace like three or four things. Like instead of three or four separate things, you can just use UV.

And like, we want to like expand the scope of the number of things it can do so that it’s more of a self contained experience. Um, but that was a funny thing to realize over time was, um, we started from this position of it’s hard to build plugins, so let’s just implement everything ourselves. Um, and that turned into a feature.

Invading Python with tools written in another language

[00:40:08] Tim: So how do you introduce a tool to an ecosystem without coming across as trying to invade.

[00:40:19] Charlie: Yeah, that’s a really good question. And actually something I’ve been, I’ve been very grateful or like, I don’t know, I feel lucky, I guess. Like the Python ecosystem in general has been very welcoming to, like, our work and the stuff that we’re building and it definitely didn’t have to be that way. Like I could also see a world where people were, really, there was a lot more pushback and people were a lot more upset.

And in particular for me because like I haven’t really been like part of the Python ecosystem. Like I’ve been average Python consumer, right? I was like writing a lot of Python code, but like, I’m not reading the enhancement proposals. I’m not on the Python forum. Um, I’m not like a contributor even to any like Python. This is before I started on ruff. Like I wasn’t like contributing to open source even, right. I was like average passive consumer of open source and of Python.

That is the vast majority of people. Yes, it is the vast majority of people, um, which is something that I have to kind of remind myself of over time because now I’ve, now I like know a lot of people in the ecosystem and I’m like way more plugged into what’s going on and I’m a lot more of an expert in the standards and, and things like that and you have to, you have to like remind yourself that like most people do not come from that, um, perspective.

Like I wouldn’t have known, I didn’t know the difference between like a built, I didn’t, I didn’t know the difference between a built distribution and a source distribution in Python, like until I started working on that stuff.

Um, so anyway, but, um, I, it’s been interesting to come into that ecosystem as a little bit of an outsider, um, uh, uh, you know, someone who I didn’t really know, like many of the people or whatnot.

Um, you know, I think a few things that we’ve. We’ve also tried to do, um, One, um, We’ve tried to build things that are, like, relatively composable and that you can use, um, in sort of a piecemeal way. Like, they come together in a holistic, as a holistic tool. But, like, in ruff, we have, like, for example, a linter and a formatter.

And, like, there’s a lot, you can use just the linter or just the formatter. And there’s a lot of people who use ruff as just a linter or a formatter and then they, um, they use some, they use black, right? Or they use a different, or they use pylint alongside ruff.

And so part of it has been like trying to make clear and also be part of an ecosystem where like, we’re not necessarily trying to like cannibalize those tools.

Like we spend a lot of time interacting with the people who work on black and we talk a lot about preview style and like what style changes should we make and like sometimes we report bugs. Sometimes we fix bugs right in black. Um, Similar for pylint like a lot of people use pylint with ruff and so we have a good relationship. You know we sponsor someone who works on pylint and like we have a good relationship with the tool and like That’s helpful for both tools because we can build a better experience.

So, you know part of it is like Uh, and again, it’s similar with UV and like with Pip, like we’ve talked with the Pip people a lot and like the projects have pretty different goals.

And I think it’s great that there could be multiple viable installers in Python and that the standards and the specs evolve enough to make that possible. Um, and so, uh, you know, I think, I think part of it is like, I don’t really view it necessarily as zero sum. And, um, I, I see us more as like part of an ecosystem of tools and, you know, obviously I want us to build the best thing.

Like, otherwise, I don’t know why work on something if you don’t want it to be great. But like, but, um, you know, I also recognize that like all those tools are used by like, also used by like millions of projects. And, um, a lot of people who use our stuff also use that stuff. Right. And like, I want to make Python as a whole better.

So I don’t know, that’s some of how I think about this, but, um, yeah. You know, I think I think part of it too is just like Be like just genuinely just like being a nice person. I guess. I don’t know like I Think like I just I’d

[00:44:17] Tim: Right, right. Come in there and say, “Hey, you need to use this. You’re all wrong.”

[00:44:23] Charlie: Yeah, no, I I just try and like, you know, I hope we build great things and I try to just let them like speak for themselves and obviously I add try and advertise our work in various places, but I Try pretty hard not to make it about Highlighting flaws and other tools and try to make it a lot more about highlighting the things that we do And, um, overall I’ve been, I’ve been really happy with that and I’m happy with the collaboration that we’re able to have with people in the ecosystem.

[00:44:50] Tim: Fantastic. Do you want to, I noticed that, oh, sorry, uh, uh, I allowed us to slip away from one of the questions.

[00:44:57] Charlie: Can we go back to the VC? Can we go back to talking about VC Venture? Yeah. Yeah. Okay.

[00:45:01] Tim: Yeah. Yeah. That’s right. And it’s like, Yeah. I’m, I don’t want to push on this, but it’s something that I’m kind of curious about.

[00:45:10] Charlie: I was going to bring it. I was going to bring it back up. Yeah. But I wasn’t sure when.

[00:45:14] Tim: Yeah. Yeah. No, no, no. Now let’s, um, let’s, let’s, let’s go there.

Building a commerical company with venture capital

[00:45:17] Charlie: Yeah. So I think like part of it, you know, for me early on when I decided to like start a company and raise money around it, um, I just knew, I guess there were a few, like, Yeah.

You know, I didn’t necessarily have like a huge master plan written out in my head. Um, the things that I knew were like, If we raise money, I would know how to use it effectively. Um, as in, there was a lot, there was just like a huge amount of stuff for us to do. And the early adoption of the tooling had demonstrated to me that people really wanted it.

Like, we were like this, You know, we had projects like SciPy, right? And like, like really like long tenured projects were adopting a tool that was very much like alpha. And so I was like, there is a, there is a strong desire for this kind of tooling. Like I know that we can, um, build great, hopefully great stuff that people will really want to use.

Um, and you know, I knew that if I was going to keep working on it full time, or sorry, if I was going to keep working on this tool and achieve the goals of the tool, it had to be full time. Um, Like, it was just too much work for it not to be. Um, and, uh, you know, and further, I had this idea in my head for, like, things we could do if we built this tooling, right?

And this is where it comes back to, like, building a business, is like, if we build this, you know, this great tool chain, like, and what kind of positioning does that give us to build and sell commercial services that integrate with it really well? Um, and, you know, when you start a, a company, especially a venture, again, you don’t have to necessarily have everything figured out, but you do have to have a vision for what you’re trying to, what you’re trying to achieve. And for us, it was like, uh, and is, we want to build, um, you know, this high performance unified Python tool chain in Rust. And then we want to use that, um, uh, that to sell you kind of like the natural next thing you need when you’re working with Python. So it could be all sorts of different things, right?

Could be like package hosting and registries could be CI CD integrations could be deployment and hosting. Like I just saw all these opportunities where if we built this really amazing tooling layer, then for people who are already using our tooling, there’s a lot of problems we could solve by integrating with that tooling and integrating across them, like, okay, we’re your linter and your package manager and all these different things.

Um, You know, I think for me, like the way I view it is, um, we, like we want to build all this great tooling and that requires investment. And so we need to build a sustainable business around it. I think a couple, one interesting thing about this company, which is a little bit different than a lot of other open source companies for better or for worse is like the traditional business model for venture-backed companies in open source is you often build, uh, you have some sort of thing that needs to be hosted and then you charge people, you then you host it and people pay you money for that and then you sell other enterprise services on other enterprise features on top of it.

We actually like don’t fit that model. Um, uh, it’s not like, I mean, I think you could imagine like what a hosted ruff is like, I could probably like, you know, I could sketch something out, but it doesn’t, it’s not really like what people are doing with the tooling.

Um, you know, it’s not like we have a piece of database software and then we’re going to host the database for you and sell the hosting.

So, um, I actually think, I mean, it’s good and it’s bad. It’s bad because there are fewer companies that I could point to. I can point to some, but there are fewer companies I can point to that follow. What we were trying to do. But I think it’s, I think it’s good because it means that at least from my perspective, I think we’re really incentivized to like build out the open source in a very holistic way.

Um, and, uh, you know, we’re not like, we don’t suffer from a lot of the same licensing issues, I guess, that people follow in that model where you’re a little bit disincentivized. I guess I don’t want to like talk bad about any of those companies, but it’s like, sometimes you’re kind of distant. The incentive alignment is not perfect.

I think it’s the alignment of incentives and that’s why they’re very imperfect. And for us, I want to have the incentive structure such that we build the open source. Our goal is for it to grow as much as possible. Um, you know, ideally, you know, if I, put on my CEO hat, ideally it becomes, um, you know, a funnel for you, for paying customers, right?

So we know all these people are using our stuff. We build and sell services that integrate with it really well. And then our incentive structure is continue to build out the open source. Ideally make it really popular. Ideally make it something that companies can use. Um, and then use that as a mechanism to attract customers and people who will pay for our stuff.

Um, so that’s, that’s the incentive. I care a lot about like the incentive structure and like that is the incentive structure I want to have.

I do think, um, I think there’s like some, you know, some like challenges around, um, they’re not really that different from other open source projects, I guess. But like, you know, we have a team of nine people who are working full time on this stuff. Um, and we also want it to be a project that has, um, Ideally, I would like to get our products to a point such that they outlive the company.

Like that is not true today, for sure.

Um, like we don’t have, we have no one on who… We have no one with commit access to the project that doesn’t work at the company, for example, and like a healthy, sustainable…

[00:50:32] Tim: May I raise a hypothetical? Which is, let’s say, the Python Software Foundation says, look, ruff is now so important that we’re going to, to … We’d like you to assign copyright to us. Uh, and essentially the funding model is all, is kind of the same, but you are now the primary, … We’re the owners of the software. We have in some sense control, but you, your team now has the most knowledge of it. Does that make any sense?

[00:51:09] Charlie: Um, like do I understand the situation or is this, or do I think, do I agree that that would be a good outcome?

[00:51:17] Tim: No, no, no, no, no, no, no. Like, no, I don’t even know if there is a question there, but it’d be interesting to hear how the software project could outlive the company.

Presumably that would mean giving it to some other shepherd to kind of, you know, Or something else to kind of maintain.

[00:51:37] Charlie: Yeah. Yeah. I think there are like some other projects that have done a really good job of this that I look to as role models. Like one is, um, confusingly similarly named, but Astro A S T R O in the web and the JavaSc[ript], in the web ecosystem, let’s say, um, like they just have a really good governance structure in my opinion, at least.

Um, and you know, for example, Uh, you know, there, there are roles, there’s like a sort of a hierarchy of roles, and when you join the Astro Technology Company, you’re just like slotted in somewhere in that hierarchy, and like people who don’t work at the company could be above you, or you know, or below you, based on the contributions that they’ve made in open source, um, and there are like sort of clear guidelines for how you move up or down in that hierarchy, um, and, and, you know, and they have like, they have an OpenCollective.

So like they have like, they have corporate sponsors and other people can donate to the project. And then those funds are used to support, oh, they, those funds cannot go to employees of the Astro company. They’re used to support open source contributors, um, uh, you know, events for the project, et cetera, et cetera.

So they just, in my opinion, at least like they’ve thought about it a lot and put a lot, it’s very hard to do that effectively. It takes like a ton of work, especially when you’re doing like a million other things. Um, but, so I have a lot of respect for it and like, that’s kind of what I want to build to over time.

Um, but, but we’re certainly, we’re definitely not there yet.

One thing that Charlie really enjoyed learning

[00:53:00] Tim: Now I want to respect your time, but also I want to see if I can suck out some of, uh, your knowledge. And there’s one sort of final kind of question that I’ve got, which is: Was there a part of developing Ruff that you really relished in, from like a technology or data structure kind of problem.

Um, was it, you know, if you were to like think, well, actually that was, you know, when you started out, it was really fun and interesting kind of intellectually engaging. Uh, what was that like? And, and, and could you explain that?

[00:53:40] Charlie: Yeah, totally. I mean, I think like for me, I’d never really built anything like a linter before.

Um, and so. Like a lot of the initial infrastructure around like semantic analysis was really interesting. So, um, you know, when, when I first shipped and the first ruff release supported a pretty small number of rules, but I wanted to make sure… It was really a proof of concept.

But I wanted to make sure that it could support some fairly sophisticated rules. So, like, unused import detection, for example.

That requires like, um, a fair amount of semantic analysis, like, you need to be able to identify, basically, you need to be able to identify which imports are used and which are not, so you need to be able to resolve references, you need to be able to deal with, like, shadowing, like someone imports something and then assigns to a variable with the same name, and then that variable is used, right?

I mean, it’s like, basic stuff when, from the perspective of the programmer, but from a perspective of program analysis, as in the Python, the end Python programmer understands a lot of those rules and understands whether an import’s used or not, but like, from the perspective of program analysis, it just required a lot of things I had never really seen or done before.

Um, uh, a lot of that stuff I learned by reading other codebases. Like, open source is pretty amazing because you can just go look at how people solve certain problems. Um, and, and so like the PyFlakes codebase, which was the, uh, um, uh, where we, a lot of the rules that they have are rules that we then implemented.

Like, I read that really thoroughly in trying to understand, like, how do they deal with bindings? What are the different representations that they used? And, like, that model has evolved substantially over time, especially as I’ve brought people into the team who are, like, have a lot more experience than me at those kinds of problems, and, like, we’ve evolved that semantic model.

Um, but that was a really cool thing, like, being able to do program analysis in that way.

Um, I also, maybe another thing that was really rewarding for me in a slightly different way. Um. We… when we started working on the formatter, um, it’s a very interesting set of problems, um, around code formatting and, um, uh, one of the first two people that I hired, uh, his name is Mika, And he worked on, um, he’d worked on a Rust-based formatter for JavaScript before and he brought in a lot of knowledge around, kind of like, the right way to do that, um, and adapting it to Python and some of the quirks of Python.

And so, like, working on that and seeing, um, some of the things he did for performance, some of the things that were just, like, hard problems to solve, like comment association, is like so hard. Um, like how do you, like, yeah. I would say like 75 percent of the challenge of the formatter is comments. Like the basic code formatting is not, I mean, it is hard. Um, but like comments are like so much of the complexity. Because, anyway, it’s not necessarily interesting, but

[00:56:46] Tim: Where should you put them?

[00:56:46] Charlie: Yeah, where do you put them? Um, and they can go basically anywhere. Um, and so the chain formatting, you can put comments between basically any two tokens.

So like, not quite, but like almost.

Um, so it just creates like a real explosion of cases that you need to handle. Um, yeah. But the basic rules of like, how do you figure out?

Is it a leading comment? Is it a trailing comment? What node should it be associated with? Is it part of the, you know, if you have a comment on the first argument of a function definition, is it part of like the function definition or is it part of the argument?

Um, you know, and there’s just a lot of, like, understanding the rules around that was very, it was really interesting. It became painful over time, but it was very interesting.

Hiring people smarter than you

[00:57:24] Tim: Extremely. You snuck in something else in there, which I thought was really, really nice, which, um, you know, essentially once you decided to build a compiler company, you brought in experts and then you were able to benefit from others’ expertise.

And I think one of the hard, or like the big challenge when you move from solo to a small team, and then as your team grows, is that you need, you start hiring people that are better than you.

[00:57:56] Charlie: Yeah. That’s good though. Yeah.

[00:58:00] Tim: And, uh, 100 percent it’s good. And it just kind of reinforces that idea of trust, which, um, which is extreme.

[00:58:08] Charlie: Yeah. I mean, well, maybe just last thing I’ll say really quick is like the biggest, like starting a company, like it’s, um, Sorry, the bigger evolution, the bigger change in my life was not like starting a company, it was actually like hiring, hiring employees and people to work there. Because like, when I started a company, like, yes, I’m putting some things on the line, but it’s just me.

And then when other people join, like, Yeah, it just becomes, um, you know, suddenly the responsibility like goes far beyond yourself. Um, and so that to me was the biggest change was like bringing on other people on the team, and, you know now having a responsibility to them as well. Um, so anyway, yeah, uh, it’s it’s it is an amazing vote of confidence to, like… Have people come join you on what you’re doing.

Um, and I think we’ve built, um, a team that’s like so much better than I ever could have imagined. Like we’ve just tracked, we’ve just been able to, um, hire some really incredible people, but it’s also, yeah, for anyone out there who’s considering starting a company, it is also a lot of responsibility, right?

It’s other people’s entire lives, um, or sorry, or their livelihoods, I guess would be the right word.

Um, but yeah, anyway, so maybe, uh, I don’t know, a somber note to end on or an energizing note, right? I don’t know.

[00:59:30] Tim: Yeah, no, I think, like, it’s, it’s, it’s, it is an energizing, um, note and it It is important to me that senior leaders at even small companies are aware of the responsibility that they have for the employees.

I think that, um, Yeah, it is people’s livelihoods. And as, uh, as someone also at a very similar, oh, you know, I’m actually at a much earlier stage in my, my own business, really. Um, I can definitely empathize with how, for me, it’s sort of tight, slightly terrifying, this idea of do we bring people on? Um, because You know, I’ve got X months of, uh, let’s say four to four to six months of runway personally that I’ve been able to, you know, and it’s like, but what if that runs out?

What happens then? Um,

[01:00:30] Charlie: Yeah.

Connecting with Charlie

[01:00:31] Tim: Anyway, I, um, I’m just, uh, so thrilled that you’re able to share an hour or so with me today, Charlie.

I am curious, how should people connect with you? Um, follow Ruff, follow the company.

[01:00:46] Charlie: Yeah. The best of the best is on Twitter/X. Yeah, it’s just @charliermarsh. Um, and that’s where I’m, that’s where I’m most active.

Um, and, uh, but otherwise on GitHub, I mean, to the degree, it was not quite, I don’t know if I would describe GitHub as a social network, but you can follow me on GitHub. Um, uh, but yeah, the best, the best is on X.

[01:01:08] Tim: Superb. Okay, fantastic. Hey, thanks again. And, uh, I, uh, I’m going to be watching you very intently online.

[01:01:15] Charlie: Yeah, thank you so much for, um, uh, for having me on, for reaching out, for setting this up. It was super fun for me too.