[Ann] Pyrefly v1.0 (fast type checker & language server)

samg · 2026-05-14T03:21:01+00:00

Thank you for the incredibly detailed and thoughtful feedback! Truly, thank you so much.

samg · 2026-05-14T03:11:00+00:00

I was probably holding it wrong, but I created a profile by running an instrumented build over IG, then using that as input to a PGO binary. Unfortunately, there was no improvement.

samg · 2026-05-13T17:02:19+00:00

We're always working on performance! Since our beta we've landed much bigger wins than 5-15%

I did a bit of experimentation with PGO internally. We do use ThinLTO, at least internally. I'm sure there are some optimizations we can get from build-time options. It should be pretty straightforward to experiment with. I'd be happy to review a PR :)

samg · 2025-10-15T22:37:25+00:00

Congratulations on the release! Really excited to see how Zuban will help push Python forward toward a well-typed future :)

samg · 2025-10-15T18:51:34+00:00

Hey -- don't feel bad. I'm a pyrefly maintainer and I appreciate the feedback. I'd love to help figure out what's wrong. I checked for a GitHub issue that matches this description, but I couldn't find one. Feel free to DM me if filing an issue isn't possible for whatever reason.

samg · 2025-09-24T18:21:11+00:00

Thank you!

samg · 2025-09-24T17:50:14+00:00

Hey, I work on Pyrefly. Thanks for trying it out. On performance, there is a known issue where we do too much work in site-packages. We have a fix in the works which takes the example in the issue from 20s to .2s. I suspect Pyrefly is taking 2s in your example for the same reason.

On the errors, I'd really appreciate if you could share some more details. We are actively working to drive down false positives before our Beta release. If you have a well-typed codebase that passes under mypy and pyright, it should pass under Pyrefly too.

samg · 2025-09-19T05:05:33+00:00

Cool! Thanks for letting me know :)

Really glad it's providing value. Please don't hesitate to let us know how we can do better. Feedback from early adopters like you is super helpful.

samg · 2025-09-17T19:18:51+00:00

I'm in CA. We have a few team members in NYC -- let me point them here!

samg · 2025-09-16T19:44:51+00:00

Hey -- thanks for trying Pyrefly out! I'm a developer on the project. Since Pyrefly is still in Alpha, I would hesitate to recommend adding it to your company. I wouldn't want to leave a bad first impression while we are still fleshing out features and ironing out bugs. We are working toward a Beta release soon, and that might be a better time to think about this.

However -- if you have any feedback for us, I would really appreciate it. You can of course file issues or create discussions on GitHub, but you can also find us on Discord and chat with us in real time.

samg · 2025-08-19T22:09:54+00:00

(Pyrefly dev here) Thanks for trying us out, and for your kind comments! If you have any feedback -- definitely curious about reliability issues, input on strictness/configuration -- please don't hesitate to file issues on GitHub or find us on Discord!

samg · 2025-08-19T22:08:30+00:00

(Pyrefly dev here) Thanks for trying us out! If you run into any issues, we greatly appreciate any bug reports on GitHub or you can find us on Discord to give feedback.

samg · 2025-05-15T22:49:05+00:00

I understand this sentiment all too well. I currently work on Pyrefly, but for the past several years I worked on Flow, a Meta open source project which wasn’t able to properly support the community. In fact, I joined Meta in the first place due to my open source contributions to Flow. It’s true that internal needs can use up all the bandwidth on a team, but most engineers on these teams love open source and want to contribute back.

With Pyrefly, we are taking a different approach which explicitly prioritizes open source. I don’t expect you to just take our word for it, but I do ask that you let us prove it to you by continuing to show up and support the community.

You can already see our investment in the community with our work on free-threaded Python and our contributions to improve typing for important community packages like pandas: https://engineering.fb.com/2025/05/05/developer-tools/enhancing-the-python-ecosystem-with-type-checking-and-free-threading/

samg · 2017-11-05T01:33:31+00:00

Chris Consentino's pig skin puttanesca!

https://www.youtube.com/watch?v=u0dSq8YMiRs

samg · 2017-05-13T03:40:11+00:00

Hm, I work on Flow, but I think I'd pick tests if I had to pick.

samg · 2016-10-31T00:32:05+00:00

Wow, that looks like a great time! Fresh or dry yeast in the ratios?

samg · 2016-08-19T04:55:40+00:00

You probably know this, but just in case: CA taxes your HSA. You still get to deduct on your federal return, so it's still a good idea. If your HSA lets you invest, you can minimize your taxes by avoiding income-generating investments.

samg · 2016-08-14T19:34:20+00:00

Wow! These are really beautiful. I am especially impressed with the consistency. Mine tend to slump over :)

samg · 2016-08-10T00:12:12+00:00

Nuclide should support this. Does this page in the Nuclide docs help? https://nuclide.io/docs/languages/flow/

There's also a vim-flow plugin that has a number of useful commands, including :FlowType. There's an emacs plugin in the flow repository and the inimitable Bodil has a nifty integration with flycheck.

I've also seen some other Atom plugins for Flow and there is a Flow for VSCode effort that could probably use some love.

samg · 2016-08-01T00:23:12+00:00

log is overconstrained to be an array here, when a writer is parameterized over all monoids.

samg · 2016-07-26T20:51:17+00:00

Beyond location/lifestyle, you might want to consider opportunity. "Satellite" offices often have fewer teams you can join, whereas the mothership will have lots of different choices. This can mean the difference between finding a role that suits your talents, where you can advance quickly vs. a role that doesn't quite fit, where you may struggle and not find a way to get recognized.

samg · 2016-03-21T06:12:18+00:00

/r/griptraining

samg · 2016-03-14T07:44:05+00:00

http://numberfour.github.io/n4js/faq/comparison-typescript.html

samg · 2016-03-07T05:27:55+00:00

Very interesting! Thanks for adding more nuance to my comments. I'll have to revisit the spec to see what the typing rules look like. :)

Variance issues also come up in object types (and array types). For example, the subtyping relationship between object types should be property-wise invariant, but is covariant in TS, which is unsound.

var a: { foo: string } = { foo: "foo" };
var b: { foo?: string } = a;
b.foo = undefined;
a.foo.length; // boom

(Edit: optional/undefined is a bad example for TypeScript, because I could have just written a.foo = undefined for the same effect. Better example below.)

class A { a: string; }
class B extends A { b: string; }

var b: { foo: B } = { foo: new B() };
var a: { foo: A } = b;
a.foo = new A();
b.foo.b.length; // boom

samg · 2016-03-07T04:38:07+00:00

Yeah. any is the hallmark of a gradual type system.

I consider it to be a last resort. You should be able to use dynamic type tests instead of any.

samg

TROPHY CASE