(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.
(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.
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.
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.
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.
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.
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."
One particularly relevant feature of Flow is that it does its type checking in a server. It watches the file system and incrementally rechecks automatically when files change. With this setup, "running" the type checker is actually just querying the server, which returns very quickly.
My approach to tight budgets is simple. There are just two rules:
1. Get to something that works ASAP
2. Always work on the most important thing
Once you have something that works, you can run out of money and still have created value. I don't tend to call this a MVP, but the idea is the same.
Working on the most important thing is hard, because it requires that you and the client/stakeholders communicate often and well.
If you can get this right, you shouldn't need to worry about the budget other than wholesale feasibility. (You still need to evaluate whether you can do the project at all.) Once you have something working, you just keep improving it until the cost outweighs the benefit of more work, then you're done.
This is bound to be a controversial opinion, but I fall down strongly on the side of time and materials billing, as opposed to fixed budget (FB). I don't hold this opinion as a way to cover my own ass, but I actually think it's the best deal for my clients as well.
1. Fixed budget projects are also fixed scope (unless you're a masochist), but in literally 100% of projects I've worked on, we refined the idea as we developed it. In a FB project, now you get to do the change request dance. In a T&M project, you can adjust priorities fluidly.
2. FB projects are a weak guarantee in practice. Once your consultant's billable rate drops to $0, what do you think happens? You are the lowest possible priority. Either your changes/fixes never happen, or they're made hastily. If you're working with a larger firm, your project is now in the hands of the most junior employees.
3. FB projects are an excuse for poor communication. Clients will take the simple dollar value as an excuse to check out until the money runs out, then be disappointed when the end result isn't exactly what they had in mind. You need to show your work as you build it, gather feedback as you go, and adjust priorities.
4. T&M puts both parties on the same team, working together to build the best product. FB is too adversarial. The client tries to get as much possible stuff, because their cost is fixed. You are constantly pushing back, defending a hopefully well-defined concept of "the scope." Guess which kind of relationship gets more accomplished?
I could go on. But TL;DR, you should charge for maintenance and it should be the same way you charge for the rest of it: by the hour/day/week.
I have quite a lot of experience using migrations in Rails, and over time I've become just incredibly suspicious of "down migrations."
I have never once been in a situation where I needed to use one, and even if I did, I'd have some reason to hesitate. Let's say everyone on my team wrote one, and they even tested the "down then up" process to ensure it applied (on their machine), unlike the normal "up" migration, that migration code was probably only executed in a single environment with test data.
And even given those two ifs (1 - a down migration exists and 2 - it was tested anywhere), the darn things are still annoying and time consuming to write.
I would much rather write another "up" migration in the event that I needed to roll back a change. I guess that would be "rolling forward" a change.
All that said, my sphere of influence is pretty small. Has a down migration ever saved your skin? What am I not considering?
I really admire Netflix's ability to put together developer documentation for their open source projects. I think it reflects well on their engineering culture.
I was similarly impressed when I was reading the documentation for Hystrix, which seems to share some functionality with Falcor, like request batching and caching.
The path syntax is very readable and obviously plays to JavaScripts strengths as a dynamic language. However, I would gladly pay the cost of more cumbersome syntax to recover static analyzability through a tool like Flow or TypeScript. With Observables in particular, the ability to track the type of the value inside the Observable is really convenient.
I've been really interested in this architecture since Jay Kreps' blog post on it. One part that I'm less clear on is how this fits in with request-response style communication between, say, a Web browser and a Web server.
In a simple Web-app-writes-to-DB scenario, it's easy to read my writes, but with a async log processing system, how am I supposed to organize my code so I can read my writes and respond with useful information?
Maybe the solution is to eschew request-response entirely and have all requests return 200, then poll or use two-way communication?
Alternatively, I could have my log-appending operation return a value indicating the position in the totally-ordered log, which I could pass to the query interfaces as a way of indicating "don't return until you've processed at least to here." Does anyone do that?
Am I totally off base here? I'd love to hear from anyone who is using these kinds of systems today.
For sure, tooling is an area that will get better over time. I am quite happy with the very simple vim-flow, but TypeScript's tooling and overall ecosystem (tsd/definitelytyped) is a lot more mature.
TypeScript is great, but you might look again at flow. ES6 features are being added (I'm adding let/const support) and many already exist. Import/export (incl. types) are in, fat arrow syntax, destructuring, shorthand syntax for objects.
I get the most value of Flow through statically typed React component props, which is usable today with both `React.createClass`-style and `React.Component`-style components.
In my experience, Flow will infer much more about "plainly" written JavaScript than TypeScript, which will fall back to `any` unless code is annotated.
A small example, function types are contravariant in the negative position in Flow, but bivariant in TS—much weaker!
TLDR, if you haven't looked at Flow recently, look again!
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.