152 karma · joined May 20, 2015
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.
I didn’t know about the Rust-based Hack checker— that’s really cool!
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
Feature toggles enable some additional cool stuff like partial/incremental rollout and A/B testing, which really pay dividends.
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.
* 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."
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.
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 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 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.
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.
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!