Hacker News new | past | comments | ask | show | jobs | submit
mountainriver | on: Python 3.15: features that didn't make the headlines
Same, I’m not sure how Python survives this outside of machine learning.

All of our services we were our are significantly faster and more reliable. We used Rust, it wasn’t hard to do

prodigycorp | parent | next
the funny thing is that everyone, including myself, posited that python would be the winner of the ai coding wars, because of how much training data there is for it. My experience has been the opposite.
tyre | root | parent | next
I felt the opposite, because Python isn’t a great language. It won because of Google, fast prototyping, and its ML interop (e.g. pandas, numpy), but as a language it’s always been subpar.

Indentation is a horrible decision (there’s a reason no other language went this way), which led to simple concepts like blocks/lambdas having pretty wild constraints (only one line??)

Type decoration has been a welcome addition, but too slowly iterated on and the native implementations (mypy) are horribly slow at any meaningful size.

Concurrency was never good and its GIL+FFI story has boxed it into a long-term pit of sadness.

I’ve used it for years, but I’m happy to see it go. It didn’t win because it was the best language.

zabzonk | root | parent | next
> there’s a reason no other language went this way)

Except of course for those that did, Haskell, Fortran for example.

bonesss | root | parent
F# as well, and that tends to exist in parallel with some degree of C# written by the same devs… the indentation enables cleaner, smaller, simpler code function by function.

It’s pretty ok in Python, but meaningful indentation is amazing with a proper type system and compiler. Clean, consistent, efficient, and ensures working code is easily read and standardized.

I’m unaware of anyone accepting improperly formatted C# as ‘done’, and would reject any such PR out of hand because of the potential for legibility issues to hide bugs. So: if it were done when 'tis done, then 'twere well it were done by the compiler to save line noise.

groundzeros2015 | root | parent | next
I’m always baffled when language complaints come down to syntax
Ringz | root | parent
That’s exactly how I think, too. But at the same time, I like indentation in Python, because I would logically indent in every other language as well. In fact, I find all those semicolons and similar things at the end of each line completely redundant (why should I repeat myself for something the compiler should do) and I hate them. And that’s despite having experience with Modula and 10 years of C++. But when I look at Rust, I find the syntax simply awful. From an ADHD perspective…
smallerize | root | parent
Lambdas are intentionally kneecapped in python because Guido van Robson doesn't want to make a functional language. (As in "functional programming", not that it doesn't work.)
ciupicri | root | parent
Guido van Rossum didn't oppose functional programming, but he wanted to keep the language (and the interpreter) simple.
rplnt | root | parent | next
AI benefits from tools to verify its halucinations. That's much easier in a typed and compiled language. Then have a language that can't be monkey patched at runtime and the confidence increases even more.

If you mean "easy to get something out of it" then yeah, it's great.

dkersten | root | parent | next
Typescript wins in terms of training data IMHO, by which I mean that the training data is large enough that AI does great with TS, and the language is (IMHO) superior to Python in many ways.

I personally now use a mixture of Typescript and Rust for most things, including AI coding. Its been working quite well. (AI doesn't handle Rust as well as TS, in that the code isn't quite idiomatic, but it does ok)

CuriouslyC | root | parent
It turns out that volume of training data isn't the most important thing. Elixir beats Kotlin and C#, which beat pretty much everything else. Kotlin is probably the sweet spot for most things.
dkersten | root | parent
Not the most important thing, but it certainly helps.
lexicality | root | parent | next
a lot of the training data is either for python 2 or just generally very low quality
stuaxo | root | parent | next
The quality issue doesn't seem unique to Python.

The versioning issue I've seen across libraries that version change in many languages.

I don't tend to hit Python 2 issues using LLMs with it, but I do hit library things (e.g. Pydantic likes to make changes between libraries - or loads of the libraries used a lot by AI companies).

bigfudge | root | parent
I’ve found recent Claude to be much better in this regard. I think a lot rests on the quality of the harness and the work behind the scenes done to RAG up to date docs or search for docs proactively rather than guessing.

I also don’t have issues with quality of Python generated. It takes a bit of nudging to use list comps and generators rather than imperative forms but it tends to mimic code already in context. So if the codebase is ok, it does do better.

prodigycorp | root | parent
That could be it. I still see LLMs fail a set of static typing challenges that I created a couple years ago as a benchmark. Google models still fail it. I wonder if the lack of typing in a lot of the training data makes python harder to reason about?
lsbehe | root | parent
The tons of python code would be great training data if there was any consistency across the ecosystem. Yet every project I've touched required me to learn it's unique style. Then I'd imagine they practically poisoned half the training set because python2 is subtly different.
LtWorf | parent
You can test on the device directly, without needing to recompile to try something.