samwgoldman (u/samwgoldman)

samwgoldman commented on An Update on Pytype github.com/google/pytype... · Posted by u/mxmlnkn

rhaps0dy · 6 months ago

I've heard of `ty` too but recently I learned about Pyrefly, which is not in pre-production alpha, and is also Rust: https://pyrefly.org/

Is there a good reason to avoid using Pyrefly?

samwgoldman · 6 months ago

(Pyrefly dev here) As another commenter mentioned, Pyrefly is still in alpha. Sorry we don't make that more clear!

While we are in alpha, and there are plenty of open issues we are still working through, I think Pyrefly is actually pretty usable already, especially for code navigation.

samwgoldman commented on An Update on Pytype github.com/google/pytype... · Posted by u/mxmlnkn

denis- · 6 months ago

I have a medium-sized codebase that is all green when running mypy with the strictest configuration possible.

Pyrefly spits put around 200 errors for the same codebase.

Most errors are related to SQLAlchemy.

samwgoldman · 6 months ago

(Pyrefly dev here) Thanks for trying it out! If you have any feedback or bug reports, please don't hesitate to file issues on GitHub or find us on Discord. We have some open issues for SQLAlchemy (like [1]). I'm definitely curious to hear if there are any gaps from your perspective, having an already strictly-typed codebase.

1. https://github.com/facebook/pyrefly/issues/954

samwgoldman commented on Pyrefly: A new type checker and IDE experience for Python engineering.fb.com/2025/0... · Posted by u/homarp

lucas_membrane · 9 months ago

I just tried pyrefly on a project that really needed it. It complained about an assignment of a new value to a global int variable within a function, even though the function contained the 'global' statement that should have made that OK, I think. I know that globals and assigning to them here and there are problematic for real good software, but I am surprised that Pyrefly is stricter than python on something that I don't see as a type- checking issue. But it did find a decent list of other problems that I haven't finished working my way through.

I had gotten so messed up trying to put together a quicky hobby-type program to create a data structure of perhaps a hundred data items in various overlapping and inter-related hierarchies, tuples, dicts, and lists akimbo, that I gave up on it about 10 days ago. I hypothecated that bondage and discipline might be the way to control the confusion, so I'm rewriting, using SQLite for the dataflow from function to function, lots of little tables and no optional fields. Can anyone opine on whether that is a sensible option?

samwgoldman · 9 months ago

Thanks for trying it out! If you run into any blockers, please let us know by filing a GitHub issue or sending us a message on Discord. Pyrefly is still alpha software, so bugs are expected, but your feedback is extremely valuable as we work to squash them.

samwgoldman commented on Pyrefly: A new type checker and IDE experience for Python engineering.fb.com/2025/0... · Posted by u/homarp

muglug · 9 months ago

At Slack we have an internal Rust-based Hack typechecker that’s about 20% faster than the OCaml one (we use both)

Did you see better speedups over Pyre? Aka did I leave stuff on the table…

samwgoldman · 9 months ago

Hack is quite a bit more optimized than Pyre was, but Pyrefly is at least 10x faster than Pyre on the IG codebase.

I didn’t know about the Rust-based Hack checker— that’s really cool!

samwgoldman commented on Pyrefly: A new type checker and IDE experience for Python engineering.fb.com/2025/0... · Posted by u/homarp

lacker · 9 months ago

I'm a little worried on behalf of the "Python Language Tooling Team" at Meta, because uv has been so popular, and I wouldn't be surprised if ty wins out in this space.

So watch out, or this will become like Atom or Flow, an internal competitor of a technology that is surpassed by the more popular external open source version, leaving the directors/vps muttering to themselves "It's too bad that this team exists at all. Could we get rid of them and just switch to the open source stuff?"

Perhaps just something for the manager (Aaron Pollack?) to keep an eye on....

samwgoldman · 9 months ago

Hey Kevin, we overlapped for a bit during your time at FB when I was working on Flow. Nice to hear from you!

I’m working on Pyrefly now, but worked on Flow for many years before. For what it’s worth, we are taking a different approach compared to Flow and have explicitly prioritized open source and community building, something I know we both care a lot about.

Of course, nothing is guaranteed and we’ve seen plenty of volatility in bigco investments to infra lately, but I do believe we’re starting this journey on the right foot.

Cheers, Sam

samwgoldman commented on OCaml 4.03: Everything else blogs.janestreet.com/ocam... · Posted by u/yminsky

fsloth · 10 years ago

"- you want a build system that doesn't suck"

This is a very surprising claim. Do you have any examples how Ocaml specifically induces systems built on it to suck?

samwgoldman · 10 years ago

I don't think that's what was meant, but rather that ocamlbuild sucks. It's not the best.

samwgoldman commented on Feature Toggles martinfowler.com/articles... · Posted by u/okfine

xorcist · 10 years ago

Architecture people tend to speak in trivial examples. Swapping out an algorithm with a backwards compatible one? Good for you! It doesn't matter how you do it because it's the most trivial example one could think of. (A more realistic example would be new functionality that touches large parts of the code base, or compliance with a new API that the payment processor switches that has more data on every payment as it crosses our systems.)

I never understood why some people are scared of branching. It seems to work pretty well for Linux development. Is your project really that much more complex? As long as you merge continously from upstream, you're golden. What's the problem you're trying to solve, exactly?

I _do_ have some reservations against #ifdef-sprinkled code. And it's not an unlikely scenario that your feature toggles turn into something very similar, if conditions change and maybe they're not that temporary anymore.

samwgoldman · 10 years ago

I think the calculus changes when you consider teams with 1000s of programmers committing 100s of changes per day. Keeping feature branches up-to-date can pretty quickly adds up to a lot of time and creates a lot of friction for refactoring/cleanup-type changes.

Feature toggles enable some additional cool stuff like partial/incremental rollout and A/B testing, which really pay dividends.

samwgoldman commented on Ask HN: What's your favorite online course? · Posted by u/sidcool

samwgoldman · 10 years ago

I haven't taken many online courses, but here are my favorites (notice a trend):

Andrew Ng's ML Class - This makes the list because it is incredibly useful. I didn't have much background in the field and this class is a practical survey of ideas. Not a ton of depth, but exposes you to a lot of information gently.

Daphne Koller's PGM Class - This was the most rewarding. I banged my head on a lot of this material, but it was an incredible feeling when things started to click. That I was able to complete this class is a testament to Dr. Koller's excellence as an educator.

Dan Jurafsky's and Christopher Manning's NLP Class - This class was the most fun. I thought the exercises were incredibly well designed. Unlike the first two courses, the exercises were a lot more interesting. For ML and PGM, you mostly know when you have the answer and you are rewarded with 100%. NLP assignments are based on how well your system generalizes, which made me try harder to improve my systems, and helped me enjoy the course.

samwgoldman commented on Goodbye CoffeeScript, Hello TypeScript blog.heapanalytics.com/go... · Posted by u/matm

jiaweihli · 10 years ago

TypeScript supports disjoint unions: http://blogs.msdn.com/b/typescript/archive/2015/09/16/announ...

The two real pain points (among those you mentioned) of TypeScript are bivariant function parameters and structural classes, since they lead to potentially unsound code that compiles.

samwgoldman · 10 years ago

The link you provided doesn't seem to show disjoint union support. I'm talking about this: http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html

samwgoldman commented on Goodbye CoffeeScript, Hello TypeScript blog.heapanalytics.com/go... · Posted by u/matm

chimeracoder · 10 years ago

> I'd appreciate to add some Flow type annotations. Typescript looks great but it's still not JS.

The Flow type annotations are almost identical to Typescript. There's one edge case around one of them requiring a space before/after the colon and the other not, but I can't remember what it is. I just tried running one of the Flow examples through the Typescript playground and it worked fine[0].

The biggest differences between Flow and Typescript are how you run the build system (`tsc` versus the Flow server) and the file extension you put on the file.

[0] http://www.typescriptlang.org/Playground#src=%0A%2F%2F%20htt...

samwgoldman · 10 years ago

While the type annotation syntax between Flow and Typescript are mostly identical (this is intentional), there are a bunch of differences between them:

* TypeScript allows unsound casting, Flow doesn't. These casts are very practical, as you might know more than the analyzer. Flow takes a stricter position here, which is a theme.

* Function are bivariant w.r.t. their parameters (which is unsound) in TypeScript, but contravariant in Flow. Again, this is an intentional, practical choice, but Flow emphasizes soundness.

* TypeScript asks users to add annotations in scenarios where Flow will infer types. TypeScript will infer any (there is a "no implicit any" option).

* Classes in Flow are nominal (interfaces are structural). Classes are structural in TypeScript.

* Flow adds no additional runtime syntax to JavaScript; TypeScript does (enums, for example). Flow does support some ES2016 features (async/await, object spread), but generally holds off on experimental features (stage < 2).

* Flow has a couple interesting features absent in TypeScript, like disjoint unions. I suspect/hope both systems will converge on useful features like this.

* TypeScript treats null as a bottom type, but Flow uses explicit "maybe types."