Just recently I heard that they can donate to “typed languages” too, a donation to one language does’t preclude other donations, and given their cash injections they have a few $1.5m’s to spare.
For any programming really, but I think Python got big due to
a) the huge influx of beginners into IT,
b) lots of intro material available in Python and
c) having a simple way to run your script and get feedback (same as PHP)
I say that as someone urging people to look beyond Python when they master the basics of programming.
Python has a terseness that is hard to rival. I think that was a major selling point: its constructs and use of whitespace mean that a valid Python program looks pretty close to the pseudo-code one might write to reason out the problem before writing it in another language.
Python type hints are static - at the moment, they are advisory only, but there is an obvious route forward to making Python an (optionally) fully statically typed language by using static type checking on programs before execution.
For a lot of the business world, code flexibility is much more important than speed because speed is bottlenecked not on the architecture but on the humans in the process; your database queries going from two seconds to one second matters little if the human with their squishy eyeballs takes eight seconds to digest and understand the output anyway. But when the business's needs change, you want to change the code supporting them now, and types make it much easier to do that with confidence you aren't breaking some other piece of the problem domain's current solution you weren't thinking about right now (especially if your business is supported by a team of dozens to hundreds of engineers and they each have their own mental model of how it all works).
Besides... Regarding performance, there is a tiny hit to performance in Python for including the types (not very much at all, having more to do with space efficiency than runtime). Not only do most typed languages not suffer performance hindrance from typing, the typing actually enables their compilation-time performance optimizations. A language that knows "this variable is an int and only and int and always an int" doesn't need any runtime checks to confirm that nobody's trying to squash a string in there because the compiler already did that work by verifying every read and write of the variable to ensure the rules are followed. All that type data is tossed out when the final binary gets built.
It's true; mypy won't make your Python faster. To get something like that, you'd want to use Common LISP and SBCL; the SBCL compiler can use type assertions to actually throw away code-paths that would verify type expectations at runtime (introducing undefined behavior if you violate the type assertions).
It's pretty great, because you can run it in debug mode where it will assert-fail if your static type assertions are violated, or in optimized mode where those checks (and the code to support multiple types in a variable) go away and instead the program just blows up like a C program with a bad cast does.
I'd say most of us who prefer Python (a pretty significant number given it's the most popular language out there) don't care that much about performance, as today's machines are pretty fast and the main bottlenecks aren't in the language itself anyway. What we care about is usability/friendliness so we ourselves can iterate quickly.
If your code is talking to an LLM, the performance difference between rust and python represents < 0.1% of the time you spend waiting for computers to do stuff. It's just not an important difference.
Why is this getting downvoted... it is true. Also it is true that dynamic languages (like Ruby ;) and Python) are more efficient with tokens, like significantly then types like C, C++ or such. But Javascript and Typescript are using twice the tokens of Ruby for example and Clojure is even more efficient, obviosly I would add.
AFAICT Python basically is a [statically-]typed language nowadays. Most people are using MyPy or an alternative typechecker, and the community frowns on those who aren’t.
> Most people are using MyPy or an alternative typechecker, and the community frowns on those who aren’t.
That's not like a widespread/by-default/de-facto standard across the ecosystem, by a wide margin. Browse popular/trending Python repositories and GitHub sometime and I guess you can see.
Most of the AI stuff released is still basically using conda or pip for dependencies, more times than not, they don't even share/say what Python version they used. It's basically still the wild west out there.
Never had anyone "frown" towards me for not using MyPy or any typechecker either, although I get plenty of that from TS fans when I refuse to adopt TS.
I think in the case of TS, it's more that JavaScript itself is notoriously trash (I'm not being subjective; see https://www.destroyallsoftware.com/talks/wat), and TypeScript helps paper over like 90% of the holes in JavaScript.
Python typed or untyped feels like a taste / flexibility / prototyping tradeoff; TypeScript vs. JavaScript feels like "Do you want to get work done or do you want to wrap barbed wire around your ankle and pull?" And I say this as someone who will happily grab JS sometimes (for <1,000 LOC projects that I don't plan to maintain indefinitely or share with other people).
Plus, TypeScript isn't a strict superset of JavaScript, so choice at the beginning matters; if you start in JS and decide to use TS later, you're going to have to port your code.
> Never had anyone "frown" towards me for not using MyPy or any typechecker either
I’ve seen it many times. Here’s one of the more extreme examples, a highly-upvoted comment that describes not using type hints as “catastrophically unprofessional”:
Generally you only get frowned at if you're not using type hints while contributing to a project whose coding standards say "we use type hints here."
If you're working on a project that doesn't use type hints, there's also plenty of frowning, but that's just because coding without a type checker is kind of painful.
It's a pretty nice best-of-both-worlds arrangement. The type information is there, but the program still runs without it (unless one is doing something really fancy, since it does actually make a runtime construct that can be introspected; some ORMs use the static type data to figure out database-to-object bindings). So you can go without types for prototyping, and then when you're happy with your prototype you can let mypy beat you up until the types are sound. There is a small nonzero cost to using the types at runtime (since they do create metadata that doesn't get dropped like in most languages with a static compilation step, like C++ or TypeScript).
I can name an absolute handful of languages I've used that have that flexibility. Common LISP comes to mind. But in general you get one or the other option.
> It's a pretty nice best-of-both-worlds arrangement
It’s also a worst-of-both-worlds arrangement, in that you have to do the extra work to satisfy the type checker but don’t get the benefits of a compiled language in terms of performance and ease-of-deployment, and only partial benefits in terms of correctness (because the type system is unsound).
AFAIK the Dart team felt this way about optional typing in Dart 1.x, which is why they changed to sound static typing for Dart 2.
Just recently I heard that they can donate to “typed languages” too, a donation to one language does’t preclude other donations, and given their cash injections they have a few $1.5m’s to spare.
For any programming really, but I think Python got big due to
I say that as someone urging people to look beyond Python when they master the basics of programming.
Python has a terseness that is hard to rival. I think that was a major selling point: its constructs and use of whitespace mean that a valid Python program looks pretty close to the pseudo-code one might write to reason out the problem before writing it in another language.
I doubt that this is the selling point. Imho it is nothing special compared to Haskell, F# and the likes.
3 replies →
Python is a typed language. Perhaps you were trying to say something different?
Is it static or dynamic? Whatever rust is that python isn’t.
Rust is static. Python is optionally static.
Python type hints are static - at the moment, they are advisory only, but there is an obvious route forward to making Python an (optionally) fully statically typed language by using static type checking on programs before execution.
2 replies →
They clearly meant a statically typed language. Yes Python is Strongly Typed, but I think we all knew what they meant.
Types are best, period. Whether they are native or hints doesn't really matter for the agent, what matters is the interface contract they provide.
I don’t get this argument because if we put the effort to get it typed, we don’t get one of the best benefits - performance.
The best benefit depends on your problem domain.
For a lot of the business world, code flexibility is much more important than speed because speed is bottlenecked not on the architecture but on the humans in the process; your database queries going from two seconds to one second matters little if the human with their squishy eyeballs takes eight seconds to digest and understand the output anyway. But when the business's needs change, you want to change the code supporting them now, and types make it much easier to do that with confidence you aren't breaking some other piece of the problem domain's current solution you weren't thinking about right now (especially if your business is supported by a team of dozens to hundreds of engineers and they each have their own mental model of how it all works).
Besides... Regarding performance, there is a tiny hit to performance in Python for including the types (not very much at all, having more to do with space efficiency than runtime). Not only do most typed languages not suffer performance hindrance from typing, the typing actually enables their compilation-time performance optimizations. A language that knows "this variable is an int and only and int and always an int" doesn't need any runtime checks to confirm that nobody's trying to squash a string in there because the compiler already did that work by verifying every read and write of the variable to ensure the rules are followed. All that type data is tossed out when the final binary gets built.
But that's not the argument here. Python type hints allow checking correctness statically, which is what matters for agents.
7 replies →
So add mypy to your pre-commit
Or ty: https://astral.sh/blog/ty
Damn… ok, I’ll try it
All this but none of the performance benefits.
It's true; mypy won't make your Python faster. To get something like that, you'd want to use Common LISP and SBCL; the SBCL compiler can use type assertions to actually throw away code-paths that would verify type expectations at runtime (introducing undefined behavior if you violate the type assertions).
It's pretty great, because you can run it in debug mode where it will assert-fail if your static type assertions are violated, or in optimized mode where those checks (and the code to support multiple types in a variable) go away and instead the program just blows up like a C program with a bad cast does.
2 replies →
I'd say most of us who prefer Python (a pretty significant number given it's the most popular language out there) don't care that much about performance, as today's machines are pretty fast and the main bottlenecks aren't in the language itself anyway. What we care about is usability/friendliness so we ourselves can iterate quickly.
If your code is talking to an LLM, the performance difference between rust and python represents < 0.1% of the time you spend waiting for computers to do stuff. It's just not an important difference.
4 replies →
For vibe code, since it's not important whether the output works, JavaScript is even better.
Why is this getting downvoted... it is true. Also it is true that dynamic languages (like Ruby ;) and Python) are more efficient with tokens, like significantly then types like C, C++ or such. But Javascript and Typescript are using twice the tokens of Ruby for example and Clojure is even more efficient, obviosly I would add.
It's not incorrect, but in the context of the given Hacker News submission it reads as "why fund Python at all?"
AFAICT Python basically is a [statically-]typed language nowadays. Most people are using MyPy or an alternative typechecker, and the community frowns on those who aren’t.
> Most people are using MyPy or an alternative typechecker, and the community frowns on those who aren’t.
That's not like a widespread/by-default/de-facto standard across the ecosystem, by a wide margin. Browse popular/trending Python repositories and GitHub sometime and I guess you can see.
Most of the AI stuff released is still basically using conda or pip for dependencies, more times than not, they don't even share/say what Python version they used. It's basically still the wild west out there.
Never had anyone "frown" towards me for not using MyPy or any typechecker either, although I get plenty of that from TS fans when I refuse to adopt TS.
I think in the case of TS, it's more that JavaScript itself is notoriously trash (I'm not being subjective; see https://www.destroyallsoftware.com/talks/wat), and TypeScript helps paper over like 90% of the holes in JavaScript.
Python typed or untyped feels like a taste / flexibility / prototyping tradeoff; TypeScript vs. JavaScript feels like "Do you want to get work done or do you want to wrap barbed wire around your ankle and pull?" And I say this as someone who will happily grab JS sometimes (for <1,000 LOC projects that I don't plan to maintain indefinitely or share with other people).
Plus, TypeScript isn't a strict superset of JavaScript, so choice at the beginning matters; if you start in JS and decide to use TS later, you're going to have to port your code.
3 replies →
> Never had anyone "frown" towards me for not using MyPy or any typechecker either
I’ve seen it many times. Here’s one of the more extreme examples, a highly-upvoted comment that describes not using type hints as “catastrophically unprofessional”:
https://www.reddit.com/r/Python/comments/1iqytkf/python_type...
1 reply →
Generally you only get frowned at if you're not using type hints while contributing to a project whose coding standards say "we use type hints here."
If you're working on a project that doesn't use type hints, there's also plenty of frowning, but that's just because coding without a type checker is kind of painful.
1 reply →
It's a pretty nice best-of-both-worlds arrangement. The type information is there, but the program still runs without it (unless one is doing something really fancy, since it does actually make a runtime construct that can be introspected; some ORMs use the static type data to figure out database-to-object bindings). So you can go without types for prototyping, and then when you're happy with your prototype you can let mypy beat you up until the types are sound. There is a small nonzero cost to using the types at runtime (since they do create metadata that doesn't get dropped like in most languages with a static compilation step, like C++ or TypeScript).
I can name an absolute handful of languages I've used that have that flexibility. Common LISP comes to mind. But in general you get one or the other option.
> It's a pretty nice best-of-both-worlds arrangement
It’s also a worst-of-both-worlds arrangement, in that you have to do the extra work to satisfy the type checker but don’t get the benefits of a compiled language in terms of performance and ease-of-deployment, and only partial benefits in terms of correctness (because the type system is unsound).
AFAIK the Dart team felt this way about optional typing in Dart 1.x, which is why they changed to sound static typing for Dart 2.
1 reply →