Thanks climate change for extending the season for up to two additional months per year. That's two more episodes of nasal gymnastics and impromptu throat clearing symphonies. What a treat.

If I get wind of an upcoming open source release, I can't help but inject myself into the process. This episode is one of these occasions as today is the day Meta is releasing Pyrefly as an alpha, a type checker for Python written in Rust. If you've been listening to this podcast for a while or just followed Meta's open source efforts for Python, you may already know about Pyre, another type checker for Python.

Without pre-empting the interview or the obvious question of why another type checker is needed, it's clear that Python is absolutely dominating the machine learning space. More code doesn't just mean higher requirements for type checkers, but also an increased focus on ensuring that developers using the language have the best experience possible. To discuss how they made Pyrefly so much faster than its predecessor, why they chose Rust as the language for it, and the surprising challenges you'll find when building a type checker for Python, I have Maggie, Rebecca, and returning guest Neil joining me.

So, without further ado, let's dive into the interview.

Meta is a truly polyglot company. While it's true that a lot of backend code is written in HACK, that is by no means the only language you touch outside of our mobile apps, it's certainly not the only one our DevEx teams care about when ensuring that people have a delightful experience and can move fast.

Today, I have a trio on the podcast that will talk me through the latest improvements they have made and are releasing as open source for type checking Python. Maggie, Rebecca, and Neil, welcome and welcome back to the Meta Tech podcast.

Neil: Thanks very much.

Pascal: All right. Before we actually dive into the topic, I'd like to give you a chance to actually tell the audience a bit about yourself.

Rebecca, can we maybe start with you? How long have you been at Meta, and what did you do before Pyrefly?

Rebecca: Yeah, I have only been at Meta for 9 months. I joined last July. Before that, I was at Google for about eight years, and actually, I was also working on Python type checking there.

Pascal: Amazing.I love how you can bring kind of knowledge from other companies over, and given that it's being open source, what we are going to be talking about, hopefully, it will even make its way back again.

So, Maggie, what about you?

Maggie: Yeah, I've been at Meta for 6 and a half years, so I've been on Pyre for the majority of that time, but I've also worked on the HACK Language team and on a program called Data for Good, and before that, I was just at sort of a handful of small startups

Pascal: Fantastic, and Neil, I can't remember when the last time was you were here on the podcast, but it was definitely about Buck2, and it was in April. It was either one year ago or two years ago, and time has lost all its meaning for me, but please remind the audience who you are.

Neil: I think it might have even been three years ago, actually. I've now been at Meta for about six years, and before that, I spent about a decade in various finance companies.

At Meta, I've worked on the Buck2 build system, bits of CL and testing, and I've been working on the Python type checker for about as long as Rebecca's been with us, so for about nine months now.

Pascal: Which feels like exactly the right time to release something out into the world. But let's talk a bit about your team. So what is the name of your team and what does it do?

Neil: I think our official team name is the Pyre team, but we are really about using the Python type system to increase reliability and productivity.

So, at Meta, we have a large amount of code in Python, so you've got all the AI stuff, PyTorch notably, and you've got products like Instagram, which are primarily driven around Python. We want the developers who are using that to have a better time, be more productive, and produce more reliable systems.

Pascal: So, let's talk a bit about the history of typing in Python.

I think I said on one of the previous episodes we've had about Python that the last time I touched it, which feels like a lifetime ago, it was still completely dynamically typed, and nowadays, when I open an editor here internally, pretty much all of it has type annotation. So, when did this entire process of typing Python start?

Rebecca: Yeah, changes to Python are usually made through Python enhancement proposals called PEPs. The type system was first introduced with PEP 484 all the way back in 2015, when we're still on Python 3.5. In fact, a lot of people are still on Python 2. But it's changed a lot over the years, and it keeps evolving with more PEPs.

In 2023, we actually formed a Python typing council to take the type system in a deliberate direction. Yeah, it keeps improving.

Pascal: And what is the state of typing specifically at Meta at the moment? Is there some sort of enforcement that you have to write types when you write Python now?

Maggie: So, the answer to the question is that it depends. If you are in Instagram, you are almost certainly writing completely typed Python. You will get errors if you don't add annotations. Very hard not to type your code in the Instagram code base.

In FB code, it's a little bit different. A good chunk of it is typed, but the enforcement historically hasn't been as strong.

Pascal: Right. And FB code, I guess, is... How would we best define it? I haven't thought about this before. But it's some sort of sub repository where you find all sorts of helpers and services. And it's a bit of the wild west.

Is that a good way to describe it?

Neil: It's a lot of the background services and DevTools live out there.

Pascal: Before you created Pyrefly, you created PyOS, which has been out there for a while and people can download and use today. What was the original motivation behind building your own type checker?

Maggie: Yeah. So, we had two main motivations for a Python type checker at Meta. So, the first one was that the current type checkers sort of out in the market at that time were not fast enough for the sort of scale of the code bases that we had. So, if you're asking an engineer every time to make a Python change to sit and wait for 10 minutes for it to type check, it becomes kind of a bottleneck.

And the other reason was that we wanted to build a security tool that used static analysis to find security vulnerabilities in our code base. And so, that was kind of the initial motivation for Pyre. And then in August, some of the sort of decisions that we made with those motivations in mind made it so that we decided to rewrite it to be Pyrefly.

So, it was originally based on static analysis work. So, it did things quite a bit differently than you might expect a type checker to do. So, you used a preprocessor to strip out complexity in the Python language, but then that meant that we sometimes had worse errors and less connection to the original code.

And it was written in OCaml, which was pretty fast, but meant that it was really hard to get it working on Windows. It used a fixed point for loops. So, there were just a bunch of kind of smaller issues with it that to fix, we would have needed a major refactor.

So, a rewrite was kind of the right decision for us.

Pascal: Were there any particular measurable aspects of this rewrite that you had in mind that you were targeting? Because I still feel like it's probably a fairly tricky sell to make when you want to rewrite something that is out there in production is working well enough, probably, for most of the engineers that are out there. So, how did you kind of underline the decision-making?

Neil: When we first wrote the PyreFly, it was for a much smaller audits.

Python was used, but not heavily used. As time has gone on, Python has become the dominant language in AI, perhaps even the exclusive language in AI. So, the value of Python to the company has kept increasing, and Pyre just wasn't able to keep up, both with the scale, but also people are looking for a much better experience when there's a lot more people.

There were some very specific things like Pyre doesn't run on Windows, whereas PyreFly does, but there are also things like we thought we could get a 10x speed up, at least. We thought we could provide an idea experience alongside a static type checker. So, there were quite a lot of things where it was not measurable, but qualitative experience, really kind of Maslow's pyramid.

We wanted to go from kind of adequate to delightful, and we didn't think we could do that with Pyre

Pascal: Honestly, that is much better than what I was thinking the answer would be, because quite often you find yourself in the situation where you need to prove large investments like these with hard numbers, but instead you're actually going this kind of qualitative angle and say, like, here are things that we can do to improve the user's day-to-day experience while working on Python. It's wonderful that we can make decisions based on these factors.

Neil: Yep, no, it required a lot of trust from people in management and from the team, but we all felt it was the right thing to do, so we did it, and it seems to have worked.

Pascal: And now we have PyreFly. So, how does it differ from Pyre, but also the other alternative tools that are out there in the type checking space, like Pyrite and Mypy?

Rebecca: So, yeah, as you mentioned, there are several different Python type checkers already, and the reason we wanted to build a new one is that the type system is a lot more mature than it was back when most of these type checkers started.

We have a typing specification. There are a lot more features. It lets us sort of design better up front for what we know that we need to support, and we can also build and learn from the lessons of all the other fantastic type checkers already exist.

Also, multi-threaded natively, which is part of the reason we're much faster, and PyreFly is different in that it's written in Rust.

Pascal: Oh, let's talk a bit about Rust. So, why did you choose Rust as a language?

Neil: So, I guess we were looking to write a fast type checker that, you know, runs fast for the users and was also fast to develop.

So, our first preference would have been Python, because it's really nice to dogfood these things, but unfortunately Python just isn't quite at the speed we want for these kind of tooling.

Looking around, Rust is type safe. It's got great support for multi-threading. It's very fast, but very safe for the developers. So, that seemed like a nice trade-off, and we've had great success using it in other projects, like Buck2. There was also an awesome parser available from Astral, the Ruff parser, which really gave us a great head start.

We didn't have to build a Python parser, and it had all the ranges and information on it that we could possibly want, and it's worked out very well in practice. So, we've managed to use the strengths of Rust to get a kind of fearless concurrency, safety, but also fast development. So, most developers don't need to know that it's Rust and don't need to know all the details of the borrow checker and everything, but in small places, we can really leverage it to get very fast performance.

So, we can type check some modules in milliseconds, typically, which obviously would be very hard with an interpreted language like Python.

Pascal: I like the fearless aspect you talked about when it comes to concurrency, because in most languages, I'm kind of terrified of it. It is so easy to have a deadlock, and I only noticed this once it's in prod and actually received some millions of requests per second.

Neil: I would say I've spent a reasonable amount of time debugging deadlocks in PyreFly. Deadlocks, so Rust guarantees you that you won't get race conditions, but it actually doesn't you won't get deadlocks. So, deadlocks tend to be the one thing we do end up debugging quite a lot of.

Hopefully, they're all gone now.

Pascal: Well, we will see. But when we talk about Rust, that's certainly one aspect of the performance boost that you're getting when you're migrating from Python, because it's just being kind of closer to the middle, at least for now, until the JITs maybe make some additional advancements.

But what architectural decisions did you make to make PyreFly as fast as it is now?

Neil: So, I guess one of the central ideas we had was, we were quite worried that with the amount of concurrency we want, hundreds of threads, you could spend a lot of time doing thread contention. So, instead of making our kind of building block, say the expression or the statement, we've made our building block for type checking the module. So, we will typically type check an entire module, and if anything in that module changes, we'll just throw away the entire module and recheck it from scratch.

So, that means that we rely on the fact that Rust is fast single threaded, and we rely on the fact that actually we don't get much thread contention. So, you don't have to worry about all those kind of weird cases around caches and all that stuff that get really complicated with threading. So, I would say that really helped make us fast.

And the other thing is that computers have got a lot of CPUs. So, by being able to exploit all those CPUs, that again gives us a performance boost that maybe even if you go back five years would have been less true just being able to throw CPUs at the problem.

Pascal: Yeah, that's true. And I guess this is probably not too dissimilar from Pyre, which was created with large code bases in mind, but how do you deal with the incrementalism behind it? How do you kind of maintain the state?

Neil: Well, we have a fairly complicated object called state that indeed stores basically a map from each module to the type results. So, I guess the interesting trick there is when we recheck a module, if none of the interfaces change, so nothing that it exposes out of the world, we don't have to invalidate anything downstream. So, normally if you were doing a dependency graph, you would mark something as dirty and then transitively mark the things that it depends on as dirty.

What we do is we instead go, oh, well, like, probably it's fine. We type check it. And if it is fine, we can stop. And if isn't fine, then we'll go and mark the things dirty. So, that's one of the performance tricks.

Pascal: How is the kind of acceptance of foreign languages in the Python community? We've seen it in JavaScript, for instance, or TypeScript, that a lot of the tooling has recently been kind of rewritten in Rust as well.

What is it like in Python? Is Rust already an accepted member of the language community?

Rebecca: That's an interesting question, because I would say a few years ago, the conventional wisdom would be if you want to write a popular Python tool, do it in Python. That's how you get the contributors, whatnot. But we've seen some notable exceptions to that.

You know, PyRite is written in TypeScript. Ruff is written in Rust. And I think, you know, just these tools that have come before us have shown that the community is pretty accepting of tooling written in other languages.

Pascal: Fantastic. And one more, I'm not even sure if I can call it a language, but something I saw in the repository was a Wasm crate for Pyrefly, which was delightfully small. I think it's like 50 lines of code, which have some bindings.

What are you using that one for?

Neil: So, on the Pyrefly website, Pyrefly.org, we wanted to have a sandbox so people could experiment with what experience they were going to get from the type checker, but also where people could make it very easy to reproduce bugs. And also, we use it for reproducing bugs. And the best experience for a sandbox in the browser is very much running using the Monaco editor, which is the same one that underpins VS code, written in JavaScript TypeScript, combined with Wasm to call out to the PyS services so you can do it all in your browser and we don't have to worry about servers or anything.

And yeah, as you say, for 50 lines of Rust, we can just put some JavaScript foreign function interfaces in, compile the existing library with our hundreds of dependencies into Wasm and ship it in the browser where it just works seamlessly. It was kind of mind-blowing that it works.

Pascal: Yeah, that sounds magical. Did you have to adjust any of these additional dependencies that you had or did they already all work out of the box with a Wasm compilation target?

Neil: I think for two of them, we had to adjust them. I think it was the tar library timestamps was wrong on our particular flavor of Wasm, but not on another flavor of Wasm. And I think the zested crate needed a few tweaks, but yeah, it was remarkably seamless.

Maggie: It's been really helpful for debugging. Is this a type issue? Why doesn't this type check kind of questions as well?

Pascal: Amazing. So if I wanted to swap out one of my other type checkers for Pyrefly today, for the myriad of reasons you've given me why that would be helpful, what is the upgrade experience like? Should I expect millions of new type errors coming my way or what does it look like?

Maggie: We're working to kind of make this as seamless as possible.

I think one of the things, if you are going to spend three weeks upgrading a tool, that's probably too long. So how do we sort of shorten the timeframe, make it easier for you to move from maybe Mypy or an older type checker to Pyrefly? So we are working on tooling that will convert your existing configuration scripts into something that Pyrefly can consume. So they probably won't be one-to-one, but it can get you 80% of the way there.

And the other thing that we have are scripts that will auto silence any errors that do pop up and kind of remove any error suppressions that are no longer needed. So one of the differences between different type checkers is that they will error kind of at slightly different locations. So your error type ignore comments might have to move, but we have tooling that can handle that for you.

Pascal: That sounds great. And I guess this is not entirely altruistic for the open source community, but if we want to swap out PyF for Pyrefly, I guess you also wouldn't want to be sitting there and going through many, many, many errors and fix them by hand.

Maggie: It was really selfish motivations for me.

Yeah. And then also, sometimes if you update a new library or you update to a new version of your type checker, you have the same problem where you suddenly have a bunch of new errors. So having a way to sort of automatically silence those, give you a little bit of time to come back and fix them, maybe write a code mod to do it

Yeah. It's super helpful.

Pascal: What kind of errors can people expect? Are you still seeing errors where you can no longer infer a type that was there previously? Or are you getting stricter in enforcing something? Is a certain kind of bucket of errors that people can expect to see when switching from one to the other?

Maggie: So I think one of the main, I'll let sort of Rebecca and Neil jump in here too, but there are a couple of sort of philosophical differences between the type checkers that you can turn these off.

So Mypy won't type check a function body unless there is a return annotation on the function. By default, Pyrefly will. So just turning on Pyrefly, you might be type checking way more code.

That is one of them that we do have a configuration option to kind of mimic the original behavior, just to help you on board. Yeah. And then I guess Neil and Rebecca can talk a little bit more about the differences in the sort of like core type checker.

Pascal: Do you want to jump in? What other differences exist between PyreFly and the alternatives?

Neil: I think there were a lot of places in the spec where there's some level of ambiguity as to exactly what it means. So for example, if you have an inarm, you can set an underbar value member.

It isn't clear exactly how many things that applies to. There are things like the conformance test suite, which I think approximately encodes PyRight's behavior that we've been working with. But even there, there are things where we seem, it doesn't seem quite the right behavior.

But then the other thing is, you know, this is early software, so there are still bugs, which probably accounts for the vast majority that most people will come into at the start. That said, we're working hard to squash them as we find them.

Pascal: Perfect. Rebecca, anything to add?

Rebecca: Yeah. I guess being on intentional difference is it's maybe a big one relates back to what Maggie was talking about in terms of PyreFly will type check your unannotated code and it will do its best to infer types for it. And I know PyRight also does some of that, but we really try to take this as far as we can, say no matter what type of typing your code is, we try to give you a delightful experience.

Pascal: Speaking of experiences, what can people expect right now when they want to run PyreFly? Is this currently something that you type into your terminal to run it or is an editor integration? Are there plans for it? What does it look like?

Maggie: Yeah, we currently have a VS Code integration that you can download and install into your VS Code editor. And you can see squiggles, we have go to definition, we have autocomplete, and we're working pretty quickly through a lot of IDE features.

Pascal: What about a language server or LSP? Is that on the roadmap?

Maggie: We do have an LSP. I believe that is what is powering the majority of our VS Code extension.

Pascal: Fantastic. So the NeoVim people can probably build something to satisfy their needs as well.

Neil: We've actually had one open source user already grab the Pyrefly from the repo and use it for NeoVim and they've contributed back some documentation on how to do it.

The NeoVim people should be happy out of the box.

Pascal: Wonderful. So what is the state of Pyrefly at Meta as of today?

Neil: So a few users are using it to try it out.

And in fact, all of our team is using it as their default experience. But the vast majority of users aren't yet in production. We are experimenting with some code bases, more looking at bringing down the number of errors and making sure the performance is as fast as it can be for them.

The particular thing that we're most proud of is that we've managed to get to the point where we're type checking 1.8 million lines of code per second. So there are some projects that used to take 14 minutes to type check that are now down to more like five seconds. And this completely changes the ballgame.

Like it goes from being something you do on CL and you get annoyed at to something you do interactively on every keystroke kind of thing.

Pascal: Yeah, we talk a lot about shift left here and often it's a bit of a meme, but this is one of the clearest examples, right? This is something that you're moving from a step far away from your actual developer experience and actually writing the code to right there at your fingertips.

So I heard that one of your aims is to make Pyrefly a more open source friendly project than Pyre was.

So what are your goals with this?

Neil: I mean, I think there's some aspect where this is a selfish goal. So inside Meta, we have a lot of open source projects like PyTorch and many of our AI research is open source. So if we want to serve their needs, we actually need to have a product that is available open source as well, because they're likely to just use the open source variant of it. That makes sure our desires align with the open source communities to a large extent. Beyond that, it's just about providing a good open source experience. I mean, maybe Rebecca can talk more to this.

Rebecca: Yeah. So in terms of open source experience, there are, I guess, sort of two things we're working toward. One is we do sort of want to be opinionated in the sense that you start using Pyrefly and out of the box, you have, you know, like a good default, a pretty good experience.

But then for those Pyre users, we also want to be highly configurable. We've seen with, you know, like other type checkers, like Mypy, you know, like with different flags you can use to tune strictness and depending on the patterns in your code base, you may want some sets of errors, but not others. So we're really working towards making it so you can tune Pyrefly like that.

Pascal: Right. I think a lot of people always think about open sourcing a project of kind of moving it into a different folder and hitting the release button. But in reality, I have worked on a bunch of these efforts.

It's usually much harder, even if you start a project from scratch like this one with the aim of open sourcing it in the end. Can you talk a bit about the challenges that you've experienced while open sourcing or preparing to open source Pyrefly?

Maggie: Yeah. I mean, we did move it into a new directory and we put it on GitHub.

So we're done. No, I think that there are a lot of moving pieces for open source. I think one of the challenges that we want to make sure is that you have a really smooth upgrade path at Meta.

I usually do a lot of the Pyre upgrades for everyone on Pyre. So in open source world, we want to make sure that those processes are well documented, that they work really well. And if you have a question, you can find an answer to it.

Our GitHub is, you know, easy to navigate. The readme has everything in it. And making sure that it makes sense to someone, no matter their level of familiarity with type checking.

I think one of the challenges really has been we have a team that's worked in type checking for years and kind of figuring out what different, you know, what is a beginner going to look at and find on this website, what is someone who's an expert in Python type checking going to look for? Making sure we have something for whether you are adding types to your project for the first time, you're migrating from another type checker, you're starting a project from scratch, and making sure we have the information that you need and the tools.

Pascal: Amazing. Ignoring the open source challenges for now, were there any particular challenges that you found tricky or exciting even to solve when working on Pyrefly?

Neil: I think we all came from different backgrounds.

So what surprised each of us was different. Like the difficulty in building in things like invalidation was surprising to those of us who hadn't worked on build systems before. To me, the thing that really struck me was that the when you write a dot in Python to select an attribute on a class, the code behind that is furiously complicated with overloaded decorators, the MRO flattening of a class.

It really is much deeper than I had first expected. So yeah, lots in the complexity of Python, it isn't a simple language to type.

Pascal: Definitely sounds like a good challenge. Maggie, do you have an example as well?

Maggie: Yeah, I think I've been in sort of a meta bubble for quite a while. And one of the sort of core philosophies of Pyre 1 was that we were opinionated and there's only really one way to do things. So when I started looking at how do we make this sort of a configurable type checker, I was really surprised at how many different configuration options there are out there for different type checkers.

But I think it's probably from what Rebecca said, it's kind of these type checkers have been built on a changing spec. And so you have to add the configuration options to sort of deal with that as well. So figuring out the balance between being opinionated and configurable was interesting.

Pascal: That sounds tough. So even design decisions that you regret in the previous version and then put behind a feature flag to disable them and move people on to the new better world is something you potentially still need to reintroduce into this version because some people may have never flipped the switch. So if people want to try out Pyrefly for their Rhyme projects today, how do they get started?

Rebecca: So yeah, Pyrefly is very much still under development.

You can expect rough edges, but we do have a website at pyrefly.org. As we mentioned, there's a sandbox there you can try out. You can pip install it today. Just expect bugs, report them on our issue tracker.

And there's also that VS Code extension I already mentioned that you can test out.

Pascal: Fabulous. So what's next for Pyrefly?

Neil: I mean, so the big thing coming for us, hopefully, is lots of open source users who presumably will show up with lots of open source bug reports, which hopefully we will then fix.

And as we do get more users, we'll presumably improve the quality of Pyrefly.

Maggie: Yeah, I think we're also hoping to sort of formally launch on some of our larger code bases. And then something I'm really excited about is you get a type checker to Pyrefly up and running.

And then there's the question of, and then what? And internally, we have a bunch of code mods and different tools that we can use. And I would love to bring some of that expertise and those tools to the open source community.

Rebecca: Yeah, continuing on the theme, I guess, of sort of giving back to the open source community. One thing I am excited about is, you know, you run a type checker on projects internally at scale. You learn lessons and collect some data that you might not otherwise get.

And, you know, I think we can, like in terms of like suggesting type system features and just improving and typing with that knowledge.

Pascal: Well, I can't wait to check it out for myself. I've had a lot of fun just going through some untyped Python internally and throwing the old upgrade command, I think, on it that infers a bunch of types for you.

And then you can just at your own pace, go through the remaining comments and fix the type annotations. But it can still sometimes be a little slow. So I definitely would love to have a speed up and automatically checked function buddies, even if they weren't correctly annotated.

So, Rebecca, Maggie, and Neil, thanks so much for working on Pyrefly and congratulations on the open source launch.

Maggie: Thanks.

Pascal: And that was my interview with Rebecca, Maggie, and Neil. By the time this episode airs, Neil and a colleague of his will have presented Pyrefly at PyCon 2025. Depending on how quick the conference team is with releasing videos, there will either be a link to it in the show notes, or you will have to consult your search engine of choice if you're in for more Pyrefly content.

We are releasing this episode a bit earlier than usual in the month, so it's available alongside the blog post. But that also means that I legitimately do not know right now who the next guest will be. If there is a topic that you've always wanted to hear about from inside Meta, this is your chance.

Tag me on Threads where the podcast is @MetaTechPod or slide into my DMs on Instagram. Even if you don't have any ideas, do get in touch like a listener Anthony recently did to tell us how the podcast helped him prepare for interviews as an Android engineer and where he first learned about Flippa. If you want to make my day like Anthony did, then you know how.

But that's it for another episode of the Meta Tech Podcast. Until next time, stay type safe, toodaloo.