flow

rst part: Many of them won't be solved (too hard, too much work, too many issues overall). You have to change your coding style and write in a way that the type checker can actually help you with. Also, it's easily possible to end up with types that are far more complicated than the code they are supposed to describe. I spent more time working on the types than on the actual code. What makes it worth it is that one, I get some control over the code other people write using my library, if I insist they too use the type system I can prevent them from misusing the API to a degree. Two, those other people also includes myself in future incarnations. Three, refactoring can be significantly easier, if you have good types the checker will tell you all the places you missed changing. So overall, at least for my situation, mostly for writing a library with few external dependencies (so I don't need the more or less unreliable external type definitions) that the business heavily relies on in many products, adding the very considerable additional effort is worth it. Still, I very much disagree with all the enthusiasm. The type checkers are software trying to understand software, and that software that it's attempting to check is not just an already complex dynamic language, but in addition on top of it is people's code that comes in a million styles. Those type checkers can be valuable, but they are far (very far) from perfect, and they come at a considerable price (mostly in the time it takes to create and maintain the types, I think the additional step to remove type annotations for production code is pretty insignificant in comparison).

// Rest<T> should be equal to Diff, because TS doesn't have exact types type ElementType<T, K extends keyof T> = T[K] // PropertyType in unnecessary, because T[K] works for everything // Note that this is variadic - "Args" is an array of arguments type Call<F, Args extends any[]> = F extends (...args: Args) => infer B ? B : never // This works for both objects and tuples. type ObjMap<T, F> = { [K in keyof T]: Call<F, [T[K]]> } // I couldn't figure out how to implement Class<T>, but you can access the type of a class instance with // typeof ClassName.prototype // $SuperType and $Subtype are not documented, so I can't try to replicate them. // TypeScript doesn't have existential types, but you can emulate them within the type system, or avoid them using e.g "infer" // Discussion and encoding https://github.com/Microsoft/TypeScript/issues/14466#issuecomment-338045331 I don't agree with your statement about TypeScript's design. Before ES6 TypeScript _was_ quite different from JS, but for the past 3 or 4 years it has followed modern JS very closely. The flavor of JS it supports is fully compliant with ES2018, and the ONLY feature with codegen impact it has in addition to modern JS and JSX are enums - which compile down to simple object literals. [1] https://www.typescriptlang.org/docs/handbook/advanced-types.... [2] https://github.com/Microsoft/TypeScript-Handbook/blob/master... [3] https://github.com/facebook/flow/blob/cf03c08109014c4503a392...

em - it is not unheard of that issues are closed merely because they've been lying around for a few months without any updates (definitely happens for Flow). I prefer the approach of Flow, but I think the actual developers are not present at all on Github, most answers come from other users. There are very few actual solutions to issues that are raised. The list of issues grows ever larger. Flow does make progress, and it's not even bad. Every 10-15 days we get a new release and I'd say the progress is quite okay. What went really well the last 12 months was IDE integration for Flow in the case of Jetbrains Webstorm (for TS the situation always looked good), as of now, latest Webstorm version, it's actually usable. I still get too many Flow server crashes though, which may be due to my platform (Windows 10), not sure. However, it's now automatically restarted most of the time. A TypeScript anecdote: I filed an issue that a "Member" closed as "works as intended" after a few comments back and forth (but it was clear right away that this would be the end). I filed it again - this time Anders Hejlsberg himself responded and acknowledged the issue (it was kind of fundamental and not just something unimportant), and it got fixed. So here too you need a bit of luck to get through to someone who actually understands the subject well enough (including knowing when they don't understand it, if that first guy had just stopped handling my issue it would have been fine). But that's the price of using a popular large project, so this is not a complaint - just an anecdote, okay? What I do get for myself after following the two type systems for well over two years is that there are LOTS of restrictions. Just read some of the issues in both Github repos, it's really interesting. I find the whole situation very unsatisfying. It is clear - when you actually use it heavily for a big project for a longer period - that a type system on top of Javascript is very difficult to maintain. LOTS of unsolved cases and issues. You definitely have to adapt and use only the subset of Javascript and the type system that works. I validate an object manually and I still have to do an "any" cast in Flow because Flow does not recognize that my `if` statement secures the type. Or I have to insert such `if` statements even though from the context it is perfectly clear what I get there. For example, any inner functions, e.g. when using map, filter, reduce, loses the type if you use a variable from the outer scope. Or you have to use a lot of additional `const` for object properties even though you don't change the object - but the type checker is not intelligent enough to recognize that. You definitely write different code - and while that may seem okay there are plenty of cases where it really is objectively unnecessary, but you have to do it to satisfy the type system. On the bright side, once you get your code all "type system ready" you really do find bugs - even if it's just a few. Also good is that I now get much better autocompletion suggestions in the IDE. There's a reason why I (as project head) still insist on us using Flow even though I say "WTF?" often enough. It does cost a significant amount of time though - a very significant amount. I've been willing to do it because of the kind of project, which is going to be a very low-level building block for later larger projects, so it is worth spending a lot more resources on getting it right compared to a project that's on a top layer, on which nothing else depends. Still, overall I have very mixed feelings and I see the type checkers (both TS or Flow, or any other that could be written) on top of a language that doesn't have types as a kludge that does not look like a long-term solution. There is too much friction between the language and the type system.