z1mm32m4n

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.

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!

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

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.

It’s even nicer in Haskell because not only does do-notation make code look clean, await is a function, not an operator.

Want prefix await? Go for it!

    res <- await $ foo bar

Want postfix? You can have that too!

    res <- foo bar & await

Being “just a function” means it composes with everything else in the language, something the Rust languages designers have held in high regard when designing this.

(But I also fully appreciate the design constraints that prevent Rust from using “just a method” or ”just a macro”)