4 ms·
> TS tooling blows Flow out of the water, though This is the dealbreaker. Building Flow in OCaml was a mistake, full stop. I'm not convinced the level of soun
by ng12 7y ago
> TS tooling blows Flow out of the water, though
This is the dealbreaker. Building Flow in OCaml was a mistake, full stop.
I'm not convinced the level of soundness we're talking about is important except for the people who like to wax philosophical about PL theory. TypeScript has never been "unsound" in a way I actually care about and I would argue if you get caught up in a soundness issue you're already doing something completely crazy.
- mirekrusin 7y agoIt's true that ocaml has different contribution entry profile. The only "issue" here is that flow being a js tool, naturally would attract more js contributions, but that's it. You can't say ocaml itself is not fit for purpose because this kind of tool is pefect use case for ocaml. It would be interesting to see flow rewrite in flow itself thought.
- ng12 7y agoIt being written in OCaml is why the tooling is poor. TypeScript integrates perfectly with most build tooling (e.g. Webpack) because it's just JavaScript like every other tool. To run Flow everything has to be shelled out to an external bin which adds a lot of flakiness and manual configuration if you want to integrate it with your build config. I understand OCaml is great for writing meta languages (ha) but it's bad for the end user.
- mirekrusin 7y agoMaybe, but personally I don't use any tooling at all, just raw js with types in comments and npm test as `eslint . && flow check && jest`.