4 ms·
I don't think typing is the main obstacle to Python performance, otherwise it wouldn't be that much slower than JavaScript. In fact, there are several alternati
by breuleux 5y ago
I don't think typing is the main obstacle to Python performance, otherwise it wouldn't be that much slower than JavaScript. In fact, there are several alternative interpreters that are much faster, but they entail incompatibilities with popular packages. Static typing cannot fix this.
Now, my dream would be for Python to actually enforce type annotations at runtime when they exist. Maybe add some kind of syntax to avoid doing it when it's expensive, e.g. `list[nocheck int]`, but for the love of god, enforce it, otherwise I feel like I'm just peppering my code with limp suggestions that only stand if some third party package can find all paths that lead to them, at which point I'd rather use a true statically typed language where the whole system doesn't look and smell like a janky afterthought.
- vlovich123 5y agoYou can’t compare to JavaScript as most JavaScript runtimes have a JIT. You’d have to compare against PyPy or something like that but it hasn’t seen anywhere near the amount of performance attention like any of the browser JavaScript engines. Finally, CPython is very old. That means it made decisions around multithreading it still has to live with to this day whereas the JavaScript implementations have always been single threaded and added multithreading much later (learning from the experiences of other languages making the transition). Dynamic typing is part of the problem but you’re right that it’s not the whole thing.
- codewiz 5y agoAs far as I know, all JavaScript interpreters and JIT VMs are also single-threaded (web workers aren't real threads because they can't directly share memory with the main thread).
- remexre 5y agoexcept via SharedArrayBuffer?
- vlovich123 5y agoWeb workers are real threads in the sense that they map directly to low-level threads (+ shared memory via SharedArrayBuffer which was only temporarily disabled due to Spectre). The bigger thing is that the Python runtime has a GIL because that's kind of how you solved the problem when multiple cores started becoming mainstream in the 90s. The Linux kernel had a similar GIL. It's an easy way to technically support running in a multi-threaded environment while reducing maintenance issues at the cost that you can never use more than 1 core at a time. JS runtimes don't have this problem because the runtime support layer is almost non-existent & there's no multi-threading support at all (indeed, V8 by itself comes with almost no JS APIs - there's a clear delineation between language runtime & "app runtime"). Service workers is extremely thin & works on channels instead of shared memory, further simplifying the design. The JS GC is typically written to support concurrent multi-threaded operation to minimize the "stop the world" phase runtime whereas Python's cycle detector needs to stop the world due to the GIL. These are all small decisions that add up.
- zohch 5y agoBut what other statically typed languages enforce static type constraints at runtime?
- girvo 5y agoWhile it's definitely not quite the same idea, Typescript supports run-time type predicates that inform the type system. https://www.typescriptlang.org/docs/handbook/2/narrowing.html#using-type-predicates https://www.typescriptlang.org/docs/handbook/2/narrowing.htm... function isFish(pet: Fish | Bird): pet is Fish { return (pet as Fish).swim !== undefined; } Which I've found extremely useful
- de_keyboard 5y agoFlow types (for JavaScript) can be complied into run-time type-checks. Properly statically typed languages do not need run-time checks because the compiled code is already proven to be valid by the type-checker.
- zohch 5y ago> Flow types (for JavaScript) can be complied into run-time type-checks. Okay, so there are some, though flow is pretty obscure, and flow-runtime (which is the part which does this AFAICT) is even more obscure. I don't think this is a popular feature. > Properly statically typed languages do not need run-time checks because the compiled code is already proven to be valid by the type-checker. If you want that, just enable strict mode for mypy. And if you want to interface with code that is not stirctly typed, just use runtime type checks, which will inform the static type system: foo: Any = untyped_code() assert isinstance(foo, MyClass) # after this mypy will treat foo as instance of MyClass. Same can be done with other types of checks also. So if you want runtime type checking that informs the type system, you have it. I certainly don't want runtime checks for what the type system has already checked for me.
- IgorPartola 5y agoI was just looking at runtime type checking. Apparently the reason nobody does it is because of the roughly 30,000% slowdown compared to not doing it. I e said it before and I’ll say it again: runtime type checking saves you from the case where you pass None instead of an actual object but not much else. How wrong would your program have to be to pass an instance of Animal instead of an instance of BankAccount? And how quickly would it error out with “giraffe does not have an attribute routing_number”?
- umanwizard 5y ago> my dream would be for Python to actually enforce type annotations at runtime when they exist Does any mainstream language do this? For sure most don't, even statically-typed ones. I'm all for enforcement of types, but why does it need to happen at runtime?