Most of my experience is with mypy and TypeScript. If your Python code relies a lot on dynamic dict objects instead of classes you'll have a rougher time. You

Most of my experience is with mypy and TypeScript. If your Python code relies a lot on dynamic dict objects instead of classes you'll have a rougher time. You have to use `TypedDict` which is not very expressive and syntactically verbose. This could be considered a good thing since you'll be pushed to use things like `NamedTuple`, `dataclass`es, or (a third-party extension) `attrs`. Most JS/TS code is probably using plain objects rather than `Map`s. The TypeScript syntax for expressing object types is extremely expressive, though annoyingly `Object.keys` and `Object.entries` are not precisely typed (For legitimate soundness reasons. Object types are "inexact", whereas in Flow you can express both "exact" and "inexact".) mypy supports union types, but not intersection types, unlike TypeScript. The closest you can get is creating a `Protocol` (i.e. interface) that extends multiple `Protocol`s, but this can be cumbersome. mypy's generics are strictly worse, both syntactically and expressively. In mypy you can express both co/contra-variance explicitly, whereas in TypeScript variance is implied by the readonly-ness of an object's properties and variance of its methods. Both mypy and TypeScript have `Any`/`any` types, but only TypeScript has the safer `unknown` type. You can kind of use `object` in mypy for this purpose. Both have a "bottom" type, "NoReturn" and "never", respectively. mypy has decent support for classes and subclass type-checking. TypeScript doesn't truly understand sub-class relationships nor even prototypal inheritance. Both are very configurable in terms of the strictness checks, but mypy's flags are more poorly documented and it requires more work to increase the level of strictness. Enabling "strict" in TypeScript enables most of what one would want. Anecdotally, I would say TypeScript has better control flow analysis. With mypy you have to cast a lot more often. The TypeScript ecosystem is much stronger. Most new packages have types as do major packages (located in DefinitelyTyped repo). Python's typing ecosystem is fairly poor. There are barely any packages in Typeshed and a lot of new packages are still untyped. TypeScript has a dedicated team at Microsoft working on it with a public roadmap and milestones, though big features only come around one or twice a year. Python's type ecosystem is more design by committee. A lot of conversation happens over mailing lists, monthly video calls, and a yearly conference. Since there are multiple Python type checker implementations, there isn't a single unifying vision. The core mypy team is employed by Dropbox, who has them spending most of the time migrating the giant monorepo from Python 2 to Python 3. The TypeScript team is fairly decent at fixing true bugs between releases, but a lot of "bugs" are really feature requests that tend to become long-standing Github issues. On the other hand, last I checked, there are still some long-standing bugs in mypy that haven't been fixed (as not to spread FUD, I will say that they tend to be very edge-casey and more for power users). Note that there are multiple type checkers for Python at this point with varying capabilities, but they share the same syntax and basic types since they're built into the language runtime. I expect Pyright (also from Microsoft) to come out ahead as more people start using the Pylance VSCode extension. mypy's editor/IDE support is not great, based on my VSCode experience. I haven't tried it with PyCharm.