That's a completely different thing though. Python <> Nim is nothing like JS <> TS. And who cares about the syntax if you're using a completely different language, you can pick any typed language at that point.
In the abstract we have Psalm for PHP which I think is likely to eventually get rolled into PHP’s native type system. It’s so robust the major IDEs haven’t fully implemented it yet.
It doesn’t turn PHP into Haskell or anything but huge swaths of bugs are eliminated.
As other mentioned, Python has already some tools around strong typing.
However they aren’t as extensive as TypeScript is to JavaScript. The community is also not much into types so you don’t have collections like Definitely Typed.
But the need exists and I guess it’s a matter of time until a tool becomes as popular and complete as typescript.
https://github.com/python/typeshed is Python's equivalent of DefinitelyTyped. I'm not 100% sure why it's not more of a popular thing the way DefinitelyTyped is; I think there might, to some extent, be different attitudes around the appropriateness of having third-party typings for packages, when the actual maintainer of the package isn't interested in providing first-party ones.
typescript isn't about saving a js project. its best when you get it at the beginning. where you can provide hints to your debugger and have type checkers that catch bugs proactively. you can just as easily any your way out of all the benefits.
Sorry if I'm being pedantic, was just responding to OP's phrasing of static typing being a "need" despite JS and Py having come so far without it. I'd say it's situational at best, and "you can turn it off" is probably TS's best feature.
If you're starting with TS, you can't really tell if it's useful or just a chore. I started a large Node project that a teammate moved to TS, saying the same thing about any that you did. I thought it'd be like Rust where it figures out the type for you, but no, any spreads. We replaced all those with explicit types, and I was writing fresh code in TS, but I realized it wasn't preventing any bugs that our integration tests wouldn't catch. It was just wasting my time with verbose types for things like SQL result rows that you could obviously tell were fine from the context. The other guy spent a ton of time fixing our build/deployment for TS, something that's taken lightly until you actually do it.
The project was pivoted for unrelated reasons, and I was left alone with it. I finally took it back to JS when I reached my last straw with TS, finding that it breaks the built-in Node profiler. Overall my velocity improved going back to JS. If TS were truly useful in that scenario, it'd be worth its weight for the reduced bugs that cost time to fix, but it wasn't.
It's true that python has support for typing, and I do find that mypy helps produce better python code.
But I think a meaningful issue is that python's rich ecosystem of datascience and ML tooling often is at odds with meaningful type annotations. Roughly, you can end up with signatures that indicate that a value is a DataFrame or an ndarray or whatever, but there are a bunch of implicit assumptions on what columns are defined, or what how the shapes of two ndarrays line up, etc. It's easy for a codebase to end up paying the upfront cost of providing annotations, but without actually getting an improved ability to reason about or refactor code.
19 comments
[ 0.26 ms ] story [ 56.0 ms ] threadhttps://mypy.readthedocs.io/en/stable/index.html
Plus there are compilers which can make faster code if you add static types
https://cython.readthedocs.io/en/latest/src/quickstart/cytho...
https://docs.pydantic.dev
It doesn’t turn PHP into Haskell or anything but huge swaths of bugs are eliminated.
However they aren’t as extensive as TypeScript is to JavaScript. The community is also not much into types so you don’t have collections like Definitely Typed.
But the need exists and I guess it’s a matter of time until a tool becomes as popular and complete as typescript.
If you're starting with TS, you can't really tell if it's useful or just a chore. I started a large Node project that a teammate moved to TS, saying the same thing about any that you did. I thought it'd be like Rust where it figures out the type for you, but no, any spreads. We replaced all those with explicit types, and I was writing fresh code in TS, but I realized it wasn't preventing any bugs that our integration tests wouldn't catch. It was just wasting my time with verbose types for things like SQL result rows that you could obviously tell were fine from the context. The other guy spent a ton of time fixing our build/deployment for TS, something that's taken lightly until you actually do it.
The project was pivoted for unrelated reasons, and I was left alone with it. I finally took it back to JS when I reached my last straw with TS, finding that it breaks the built-in Node profiler. Overall my velocity improved going back to JS. If TS were truly useful in that scenario, it'd be worth its weight for the reduced bugs that cost time to fix, but it wasn't.
But I think a meaningful issue is that python's rich ecosystem of datascience and ML tooling often is at odds with meaningful type annotations. Roughly, you can end up with signatures that indicate that a value is a DataFrame or an ndarray or whatever, but there are a bunch of implicit assumptions on what columns are defined, or what how the shapes of two ndarrays line up, etc. It's easy for a codebase to end up paying the upfront cost of providing annotations, but without actually getting an improved ability to reason about or refactor code.