As someone who doesn't really work with neither JS or TS, the proposed JS type system looks superficially very similar to TS.
Is this "backporting" TS to JS or is there something else I'm missing?
Is this "backporting" TS to JS or is there something else I'm missing?
Originally Mypy was supposed to be a Python superset, like TypeScript, but instead its variable annotation syntax was adopted as Python syntax. It has been an interesting journey for Python, with a lot of ups and downs. Type hints, for all their productivity and bug-safety benefits in most cases, still feel like a bolt-on feature that requires developers to change how they write code, and in many cases favors less-performant idioms and/or extra boilerplate compared to un-hinted Python. Whereas TypeScript has a lot more freedom to mess with how things work, because it's a superset that compiles to JavaScript and not actual JavaScript.
So it's somewhat surprising to see this proposal for JavaScript, because the TypeScript model always seemed better in hindsight than the Python model! But maybe it's just a "grass is greener" situation.
[0] https://devblogs.microsoft.com/typescript/a-proposal-for-typ...
Seems like a very reasonable proposal to me.
It is quite similar to Python's type hint system. Python's is kind of rubbish because there are multiple competing type checkers with different semantics and most people use the crap one (Mypy). I can't see that being a problem here - essentially everyone uses Typescript and it's very good.
idk, I wouldn't go this far. Mypy is slow, but it's probably the most correct, and it allows for configurations pyright refuses to. For instance, the maintainers won't add an option to allow variable redefinition/shadowing, seemingly because they don't understand the difference between a variable and a binding (https://github.com/microsoft/pyright/discussions/2441). As for Pyre, last I checked it had a lot of false positives that Mypy doesn't.
Besides all that, some people want to use a checker that isn't exclusively developed by a huge company (Microsoft, Google or Facebook).
In contrast Pyright seems to get pretty much everything right, even really subtle things, and if it is really a bug then the guy that maintains it is insanely good at fixing them. Seriously check out how many open/closed issues there are.
As for variable redefinition, Python stupidly doesn't prescribe semantics so it's perfectly valid for it to behave like that. Definitely arguable which way it should go and I think for clarity it's much better to use different names anyway. It's not because they don't understand anything.
Mypy has way crazier behaviours anyway, e.g. implicit making types optional. Different behaviour depending on the syntax used to add types, etc.
That's probably true of most code :P
>Definitely arguable which way it should go and I think for clarity it's much better to use different names anyway. It's not because they don't understand anything.
I agree it's debatable which behavior is better. The reason I claim a lack of understanding is because of a comment (albeit likely a flippant one) one of the maintainers made in the issue I linked:
>When a variable or parameter has a declared (annotated) type, it's the job of a type checker to validate that all values assigned to that variable are compatible with the declared type. This is how type checking works in all languages that I'm familiar with.
This just isn't true; many strongly-typed languages allow variable shadowing, especially within lexical scopes. Some, like Rust, even allow rebinding within the same scope.