My understanding is that the relationship is a lot more complex than "types = faster code". Types are often necessary for highly efficient code, yes, because the allow you to avoid lots of indirection and just give the hardware the raw numbers and instructions that it wants. But they aren't sufficient - you can't just have types, you also need to guarantee that those types are always the correct ones (i.e. that when I tell you it's an int, it will never be a string). In practice, the performance gains you get from using types are matched by the performance losses from having to validate them.

You can solve this by restricting What's possible significantly (you see this, for example, in RPython and Cython, where static types are used more effectively, but come with significant metaprogramming restrictions). But at that point, you're losing a lot of the value of a dynamic language. One of the big reasons that Typescript works so well here is that it has all sorts of escape hatches, so that you can write mostly correct Typescript code, but if you need to write something completely dynamic, you can always just define the arguments and return types and cast everything else to `any`. This is why, even though Cython exists and is much quicker than Python, it tends to only be used to speed up specific sections of code, with the rest of the codebase being dynamic Python glue.

The other side of this is that there already is a solution to performance issues in dynamic languages, and that's JIT compilation. Javascript is consistently one of the faster languages for lots of web tasks, and that's in no small part due to the significant effort put into optimising V8 and the other JIT runtimes. The best thing about JIT compilation is that you don't need to write the types at all, because the type information can be read at runtime. Theoretically, you could incorporate type hints into the optimisation process, but this probably won't give as much good information as actually running the code and seeing what types pop out.

Of course, the other side of this is to ask what the value of type hints are in the first place. I think a lot of Python developers are used to things like Cython, where types almost exclusively refer to the underlying data formats (i8, i32, u64 etc), but the biggest value to type hints and tools like mypy is not just defining struct layouts, but describing a program's behaviour at a higher level - for example, declaring that a variable can be one of these two types and ensuring that the developer never forgets that. Or defining a closeable resource like a file handle that can't be used after it's been closed. Or making sure that the developer handles each case of an enumeration and doesn't miss anything.

The types that are useful for those sorts of things tend not to be so useful for optimisation purposes, but they are _very_ useful for ensuring that code is semantically correct.

It already can be used for development, IDEs such as PyCharm perform quite effective live type checking based on type hints.