From a tooling point of view, I love hovering over a function name and seeing the types of its parameters. PyCharm supported that, using what I consider to be ugly and janky docstring comments, but now every editing environment can provide that information.
From my experience type annotations in python are actually more reliable than types in Go.
My belief is that it is a bit harder for IDE to determine which structs and interfaces should be changed, due to Go using "duck typing" (or more correctly called structural type system).
The mypy uses nominal type system (similar to what you're used in C++, Java etc) by default but it also allows to implement duck typing in places where you need it through Protocols.
Overall the type system is more powerful than the one in Go[1], it even includes generics =)
Slightly unrelated, but when working with Go, I feel like the type always gets in my way. Go typing (similarly to Python) is strict and that's great, but Go trying to be low level it implements different sizes (int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64, float32, float64) it doesn't do implicit conversion like C, but it also doesn't implement generics, and stdlib only implements functions for one of the type. That means if you use anything else than int, int64, float64 in your program you'll be in a lot of pain and will be constantly casting the types back and forth.
Having programmed in Python (with type annotations) and now at my current job in Go, I love Python.
Typelessness is the bane of Python. The community would be wise to finally take it seriously instead of keep pretending that type checking wouldn't fix whole classes of the bugs and lead to safer software, higher productivity, and overal better dev experience.
Python typing still lags behind, and my python code is the scarier for it.
Also -- one gamechanger for me has been the addition of an IDE as the go-to environment for programming in strongly typed languages... having an IDE that "gets" the language you're coding in, and its types, has allowed me to eschew a huge number of my "todo" statements altogether -- as I'll add a signature / typename where I'm going to use it, and the compiler won't let you do anything until you've actually done what you asserted you were going to do.
"TypeScript is better because I'm required to run the transplier"
If you believe that type checking is necessary, you won't have problem running mypy.
Also TypeScript has a transplier, because there was no other option, browsers use JavaScript and don't understand TypeScript so the conversion is necessary. Maybe that won't be needed in the future, but it is needed now.
The TypeScript workflows happens to include this amazing process where auto-complete and other features work on non-TS libraries/code for no other reason than someone decided to take the time to provide type information on something that otherwise wouldn't have it. In a repository/workflow that is easy for any developer to easily tap into.
This is amazing.
How did you jump to "TS is better" or some silly thing like that?
TS build pipelines almost by default don't let developers build/commit code if a type definition isn't followed. This is a HUGE workflow step that isn't common with Python and type hinting. It makes a big difference. There is no Python equivalent of MyPy "headers" or type information for countless third-party libraries.
I use flake8/Black as part of my Python development experience, but it still doesn't compare to what the TS community has been able to pull off.
> This is amazing.
The same thing I observe in Python and PyCharm.
> TS build pipelines almost by default don't let developers build/commit code if a type definition isn't followed. This is a HUGE workflow step that isn't common with Python and type hinting. It makes a big difference. There is no Python equivalent of MyPy "headers" or type information for countless third-party libraries.
I don't think I understand, could you give me an example. I don't see how types can work if no type information is provided.
With Python + PyCharm, the default mode is to allow developers to exclude and ignore types and code will still run, no matter how many orange/red markers are in PyCharms gutter. To change that mode, you need to consciously decide to add something to your workflow that will impede you if something is wrong e.g. git hooks to run linters, flake8, black etc.
With TypeScript, the default mode is to stop the developer in their tracks - the TS compiler will fail, and you can't run code (generated JS) that doesn't exist. Types are not optional, unless you make them explicitly so (which is still providing a type).
> I don't see how types can work if no type information is provided.
TS can still import native JS code... given that it has a TypeScript declaration file [0]. Many popular libraries offer one now, but many more do not. The community came together and created DefinitelyTyped [1], where 10k contributors have made 65k commits to provide TS declaration files for over 5,200 libraries spanning countless versions/releases.
This means a TS developer can import JS code that doesn't have 1st-party TS support, but does have 3rd-party through DefinitelyTyped.
[0] https://www.typescriptlang.org/docs/handbook/declaration-fil...
You've missed the point entirely. The whole point is that TypeScript benefits from compile-time type checking, which is performed by TypeScript's transpiler.
Python's type annotations are just that: annotations, which can/have no effect.
The types you define in TypeScript you similarly define in Pythin, they just call them annotations, and there's an option to reference them at runtime, but mypy doesn't work at runtime (perhaps that's where the confusion is from?)
you can add them if you need it but it shouldnt be a center piece , what should always come first is the feature / tech spec.
Python has a great type system aswell its objects all the way down. And you can mix and match how you see fit. If you have identified that type checking is crucial part of the tech spec as a sanity check or otherwise you can import type checkers(ie mypy) with a very focused api to solve that problem.
And in my opinion type obsession obscures the techspec rather than clarifying it , and places a large burden when the question of changing the spec comes. The simple cognitive load of keeping track of all the int's which need to be made to str's can drain you and make you loose site of the functionality.
You don’t have to do any typing to consume some of its benefits; someone else can pay that cost for you. You don’t even have to be aware that TS exists.
I never thought of it this way, a very interesting insight.
TS has introduced an entirely new type (pun intended) of FOSS that isn't even code, it's just header files to let you know what the inputs/outputs of things are.
I too was sceptical before using it and Python or the community does not enforce it. But it is indeed useful.