We use it extensively but are migrating away from it at Uber. Its strictness is a double edged sword, it often trips people up with checks that are pedantic bu

We use it extensively but are migrating away from it at Uber. Its strictness is a double edged sword, it often trips people up with checks that are pedantic but not fully sound. For example, TS will gladly accept that `if (typeof foo.bar === 'string') doStuff(foo.bar)` narrows down `foo.bar`'s type to string. Not so with flow... because Javascript supports getters and Flow's type system isn't strong enough to keep track of what is a getter and what isn't. So it will nag about it maybe not being a string, even when it isn't warranted (which is like 99.9% of the time this happens). There's also a long standing bug where await doesn't unwrap a Promise type in some cases. Perhaps the biggest pain is the ecosystem. There's no tool to generate libdefs and the ones in flow-typed are often crap or non-existent, so people stub things all the time. Another sore point is lack of transparency wrt project direction. It's a Facebook-first project and it shows. Things break between patch versions. One really bad side effect is that it's essentially impossible to make semver guarantees for libraries when the type system breaks if the consumer project uses a different version of flow or even simply different configurations. For us, migrating from earlier versions to flow's Types-First architecture is such a monumental task that we actually decided that migrating our 10+ MLOC monorepo to Typescript would be cheaper. Also despite the claim of higher strictness, it can still lie to your face. One time, I had to submit a fix to flow-typed of all projects because the maintainer did a refactor to fix a type checker nag and accidentally broke the runtime in doing so.