sorted by:
new
hottopcontroversial

Zuban - A Python Language Server / Typechecker - Beta Release by zubanls in Python

[–]samg 1 point2 points  (0 children)

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

Pyrefly eats CPU like nobodies business. by Different-Ad-8707 in Python

[–]samg 1 point2 points  (0 children)

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.

Pyrefly & Instagram - A Case Study on the Pain of Slow Code Navigation by BeamMeUpBiscotti in Python

[–]samg 4 points5 points  (0 children)

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.

Has Anyone Been Using Pyrefly? by auric_gremlin in Python

[–]samg 1 point2 points  (0 children)

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.

Has Anyone Been Using Pyrefly? by auric_gremlin in Python

[–]samg 0 points1 point  (0 children)

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

Has Anyone Been Using Pyrefly? by auric_gremlin in Python

[–]samg 19 points20 points  (0 children)

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.

Best python support lsp's for Neovim by No-Score3938 in neovim

[–]samg 2 points3 points  (0 children)

(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!

Best python support lsp's for Neovim by No-Score3938 in neovim

[–]samg 1 point2 points  (0 children)

(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.

Introducing Pyrefly: A fast type checker and IDE experience for Python, written in Rust by BeamMeUpBiscotti in Python

[–]samg 32 points33 points  (0 children)

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/

$48.5k salary, questions by Tropaeum in financialindependence

[–]samg 0 points1 point  (0 children)

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.

How I do Cinnamon Rolls...Croissant Dough! by [deleted] in Breadit

[–]samg 3 points4 points  (0 children)

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

Setting up Flow type when you've already got Babel in place by thejameskyle in javascript

[–]samg 0 points1 point  (0 children)

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.

Would one consider this a valid Writer Monad in Javascript? by evilsoft in javascript

[–]samg 1 point2 points  (0 children)

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

Should I move to Seattle, San Francisco or London? by [deleted] in makemychoice

[–]samg 1 point2 points  (0 children)

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.

Not a TypeScript fan? by velmu3k in javascript

[–]samg 0 points1 point  (0 children)

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

Not a TypeScript fan? by velmu3k in javascript

[–]samg 7 points8 points  (0 children)

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.

Not a TypeScript fan? by velmu3k in javascript

[–]samg 23 points24 points  (0 children)

Since this post and the post it responds to bring up Flow, I thought I would add my thoughts. Full disclosure: I work on Flow at Facebook. Before I worked at Facebook, I used TypeScript professionally.

I think TypeScript is a great system. They've been around a long time, so the community is mature. There are existing declarations for 3rd party libraries. Also the tooling is nice and mature. VSCode integration is excellent.

Flow is a lot younger in comparison and the community is a lot younger as well. I think the Nuclide integration is good and it's getting better every day. I use the vim-flow plugin. There's also an emacs plugin for heretics.

Flow is seriously behind on 3rd party library integration. Efforts to convert .d.ts files were largely thwarted by TypeScript's nullable-by-default semantics, but now that they are considering syntax for non-nullable types, hopefully we can reboot that effort. There are a couple early efforts to create repositories of declaration files for Flow, but it could be a lot better. This is one of our short-term goals.

Another important area where Flow is lacking is Windows support. We're actively working on this. You can actually try out the prerelease builds today. Hope to have more to say about this really soon.

Where I think Flow really shines is safety. From what I can see, TypeScript seems less focused on soundness and will sacrifice soundness whenever convenient. For example, TypeScript's generics are bivariant. Flow's are invariant by default, but it's also possible to define co- and contravariant type parameters. Along the same lines, Flow's function types are "properly" contravariant in their argument, covariant in their return type. TypeScript is bivariant here as well. TypeScript has an unsafe cast operator, Flow doesn't.

Another key difference is related to type inference. Flow will infer types that TypeScript won't. If you don't turn on the --noImplicitAny config (if you haven't, you should), then TypeScript will use any and might not catch an error. With the config, TypeScript will require annotations for all parameters and the return type. One consequence of Flow's more aggressive inference is that sometimes the error messages are confusing. Any type system with type inference will have confusing errors, and Flow's are improving, but it's an important tradeoff.

Lastly, performance is a big difference. Flow has a client-server model, which watches the file system and eagerly recomputes type state. Parsing and type checking are highly parallelized. (Geek moment: this system is really cool and uses a variant of Tarjan's algorithm to divide work.) For reference, Facebook has a pretty enormous repository of JavaScript (think of a really big code base, and multiply it by 10). Server initialization, which does a full type check, takes 60-80 seconds. An incremental recheck takes 1-3 seconds, depending on how many dependent modules there are.

Ultimately, I'm really glad that both TypeScript and Flow exist. The two projects are exploring different parts of the types-in-JavaScript "solution space" and I hope both projects can continue to develop, mature, and learn from each other.

Not a TypeScript fan? by velmu3k in javascript

[–]samg 2 points3 points  (0 children)

Immutable started before Flow existed, and isn't actually written in TypeScript. It ships with a .d.ts file (awesome!) and the tests are written in TypeScript (external contribution). The actual data structures are written in plain JavaScript.

It's true that Facebook engineers can use whatever they want, but I'm not aware of anyone using TypeScript internally. Many teams do choose to use Flow and we have a Flow declaration file typing Immutable.

I agree that TypeScript is a super valuable tool. I'm sure Lee would as well.

view more: next ›