Readit Newsz1mm32m4n commented on Migrating 300k LOC from Flow to TypeScript medium.com/tech-quizlet/n... · Posted by u/rgoldfinger
There have been a few posts like this, and the discussion always seems to focus on plain JavaScript vs TypeScript. I'd like to see some talk about Flow vs TypeScript instead. We have what I'd call a medium-sized project (~30k loc) written with Flow and TypeScript's superior tooling is indeed attractive enough that we too have been thinking about making the switch.
Having used both, there are a few features in Flow that I'd miss. I think classes being nominal is a good approach and the ability to declare new nominal types is useful. Otherwise Flow's type system is structural, like TypeScript's. Function parameter type inference is also very nice feature, so I can make simple module- or function-local helper functions without needing to specify the parameter types explicitly. Having a syntax for specifying parameter variance allows for a more sound type system in some areas.
Performance has historically been pretty bad but it's been getting better with every release. The tooling has also seen some improvements after Facebook nuked their own Nuclide-editor project and moved on to endorsing Language Server Protocol and VSCode. It's still far, far behind TypeScript, though. It's also a bit worrying that the community seems to be getting smaller, not bigger, with posts like this popping up.
Ironically, one of the easier ways TypeScript has been able to work quickly is by skipping the type inference Flow does. It’s a trade off. The Flow team was advised that this approach would have performance problems early on in the project, and opted to focus on type system features first and perf second.
z1mm32m4n commented on Migrating 300k LOC from Flow to TypeScript medium.com/tech-quizlet/n... · Posted by u/rgoldfinger
The important parts here are (1) that they remained metrics driven and (2) that they focused on repeatability.
1. Both TypeScript and Flow are gradual type systems. They both explicitly allow escaping the safety and coverage of a type system, either to allow easier interop with existing JavaScript packages or to allow existing JavaScript codebases to incrementally adopt types. So there are always holes in which errors are reported, regardless of whether they had to silence some explicitly or not. By measuring the extent, they have a yardstick against which they can drive further type adoption.
2. Repeatability is the only way to do large code migrations. Write the steps in a script, run it, find the bugs in the script, fix the script, and repeat. With 300k lines of code no doubt they have dozens or hundreds of people committing daily. So a script is the only way to sneak in during off-hours, get something in that doesn’t race to conflict with someone else, and land the change. A long running, manually crafter branch here would not work—it would effectively operate as a fork of the codebase for the entire duration of the migration, with all the downsides that a fork entails.
Kudos to the team; this is a very impressive feat!
While I agree with the message, in the sense that I think IM combines the worst of both worlds, I try not to get too attached to my opinions on how we should communicate. I rarely have any say in that, and I try not to get worked up about things I have no control over.
However, it does seem (and the article doesn't stress this but I think it's important) that there are simply TOO MANY different channels of communication. Figuring out which channel that communication came through on, in order to find it, is a problem. Since getting rid of email seems impractical, as does getting rid of face-to-face, IM seems like the best one to drop.
But again, who care what I think? No one. In this case, I try not even to let me care, and save my energy for battles I might possibly win.
> I rarely have any say in that, and I try not to get worked up about things I have no control over.
This hasn't been the case in my experience. I joined a new team about a year ago, and the predominant mode of discussion was Slack + IRL discussions.
Over time, I started writing docs (in Dropbox Paper, but if you want to use Google Docs feel free) and shepherding conversations to happen in those docs. @mention people into a thread to ask for their thoughts. Remind people that you have an ongoing doc to take a look at during standup.
Over time, it's possible to change team norms. But it's a slow process, and it's important to remain receptive to the experience other teammates are having too.
> IMs occupy this weird spot between face to face conversation and a nice well-written email.
IM is great; It occupies the perfect spot where the conversation is real time but the parties don't have to immediately answer. Having 30 seconds to think in between each interaction sounds trivial but it has a _massive_ impact on the quality of the interaction.
Exactly. I can't imagine providing intra-company support over either email or IRL.
IM lets me take a second to understand someone's question, maybe run some command or look up some docs, and then get back. When answering IRL, there's always the pressure to definitively answer the question, because they went through all the effort to actually take up time together. It's hard to say, "I don't know; I'll have to dig in deeper."
And turn around time on email for questions like "Why doesn't this thing work" sounds like an easy way to get blocked for half a day.
One of the appeals of email is asynchronicity—I can compose a well-reasoned proposal, and give my team time to compose a well reasoned counter-proposal.
But after more than a handful of rounds of this, it breaks down. Long email threads are impossible, especially ones that I wasn't originally participating in, but then got cc'd into. There's no easy way to skim and get a summary of the current state and where the heated bits of the proposal are.
That's why I like Dropbox Paper instead of email for these kinds of discussions. Threads spin off of a highlighted snippet, so there's always context to the discussion. Discussion in threads gets resolved, and the doc gets updated to reflect the decision—this means the doc is always canonical when someone new first reads it.
Email will never die because it’s so universally versatile. But specifically for intra-team discussions and decision-making, I'm convinced we can find (and already have found) better solutions.
Typescript (with stellar adoption), native type annotation support in Python, Sorbet, PHP 7, Elixir + Dialyzer, ...
I wonder why there isn't a popular gradually typed language that natively allows writing both dynamic and type-safe code, allowing quick prototyping and then gradual refactor to type safety.
I guess in part because it's a big challenge to come up with a coherent type system that allows this, the bifurcation in the ecosystem, and often a somewhat leaky abstraction. Eg in Typescript you will often still run into bugs caused by malformed JSON that doesn't fit the type declaration, badly or insufficiently typed third party libraries, ....
Google's Dart is the only recent, somewhat popular language (only due to Flutter) that allows this natively - that I can think of right now.
I do think such a language would be very beneficial for the current landscape though, and projects like this show there is a clear need.
Edit: just remembered another option: Crystal. Also Julia, as pointed out below.
https://julialang.org/
The first three selling points on their home page are Fast, Dynamic, Optionally Typed.