Python 3.14 is here. How fast is it? • Hacker News Board

Re: Python 3.14 is here. How fast is it?

#501

Post by robertlagrant » Fri, Oct 10, 2025, 4:46 PM UTC

nadermx wrote: post #10

Tangential, but I practically owe my life to this guy. He wrote the flask mega tutorial in what I followed religiously to launch my first website. Then right before launch, in the most critical part of my entire application; piping a fragged file in flask. He answered my stackoverflow question, I put his fix live, and the site went viral. Here's the link for posterity's sake https://stackoverflow.com/a/34391304/41802…

The other answer to your question there is why Flask is so good. One short file and you have a backend and a frontend!

Re: Python 3.14 is here. How fast is it?

#502

Post by Too » Fri, Oct 10, 2025, 4:54 PM UTC

ActorNightly wrote: post #356

didip wrote: post #21

Every time I hear news about Python language itself, it sadden me that, in 2025, PyPy is still a separate distinct track from mainline Python. That said, I wonder if GIL-less Python will one day enable GIL-less C FFI? That would be a big win that Python needs.

I don't understand why C FFI is that popular. The amount of time it takes spent to write all the cffi stuff is the same amount it takes to write an executable in C and call it from python. The only time cffi is useful is if you want to have that code be dynamic, which is a very niche use case.

You write the ffi once and let hundreds or thousands of other developers use it. For one off executables it rarely make sense.

Mixing the use with other libraries provided by the Python ecosystem is a another scenario. Do you really want to do HTTP in C or do you prefer requests?

Re: Python 3.14 is here. How fast is it?

#503

Post by Razengan » Fri, Oct 10, 2025, 4:57 PM UTC

feoren wrote: post #82

amelius wrote: post #27

I hope it doesn't get stuck at 3.14, like TeX. https://www.reddit.com/r/RedditDayOf/comments/7we430/donald_...

You hope it doesn't ? > [Donald Knuth] firmly believes that having an unchanged system that will produce the same output now and in the future is more important than introducing new features This is such a breath of fresh air in a world where everything is considered obsolete after like 3 years. Our industry has a disease, an insatiable hunger for newness over completeness or correctness . There's no reason we can't…

> This is such a breath of fresh air in a world where everything is considered obsolete after like 3 years.

I dunno man, there's an equal amount of bullshit that still exists only because that's how it was before we were born.

> Code is just math.

What?? No. If it was there'd never be any bugs.

Re: Python 3.14 is here. How fast is it?

#504

Post by lunias » Fri, Oct 10, 2025, 5:33 PM UTC

ActorNightly wrote: post #488

lunias wrote: post #452

Earlier quoted context omitted.

This has always confused me... is Python really that much better at rapid dev? I work on a Python project and every day I wish the people that started the project had chosen a different language that actually scaled well with the problem rather than Python, which they likely chose because it was for "rapid dev".

You can run Python processes in parallel for "scaling". Youtube and Uber run python backends. This is cheaper than developer time per hour.

Sure, there's multiprocessing, but historically no multithreading (relatively recently there is the free-threading interpreter). Each of those processes / threads will also execute slowly compared to most other languages. But we agree Python is not performance oriented... I'm just curious why people think it's a good trade-off when I suspect that writing the same code in say, Java, will take roughly the same time, be easier to maintain (compiler assisted refactoring, type safety, etc), and execute faster.

Re: Python 3.14 is here. How fast is it?

#505

Post by mixmastamyk » Fri, Oct 10, 2025, 5:43 PM UTC

IshKebab wrote: post #202

mixmastamyk wrote: post #153

Earlier quoted context omitted.

It’s not painful, that’s the point. You have a working prototype now ready to port. (If the destination language is painful perhaps, but don’t do that.) I recently ported a Python program to Rust and it took me much less time the second time, even though I write Rust more slowly per-line. Because I knew definitively what the program needed. And if even that is too much optimizing the Python or adding Cython to a few…

I have also ported a Python program to Rust (got a ~50x speedup) but this was a smallish program, under 10k lines of code. Porting larger programs is rarely tractable. You can tell that because several large companies have decided that writing their own Python runtimes that are faster is less effort (although they all eventually gave up on that as far as I know).

Could happen with any language. The well-known Spolsky piece was about a C++ to C++ rewrite if memory serves. Blaming repeated poor decisions on a prototyping/glue language is yet another instance. Luckily there's lots of options today to dig out of them.

Re: Python 3.14 is here. How fast is it?

#506

Post by tomas789 » Fri, Oct 10, 2025, 5:49 PM UTC

I like the Rust being there. It is a reality check to keep the numbers in perspective. (C, C++ or something like that would work too)

Re: Python 3.14 is here. How fast is it?

#507

Post by feoren » Fri, Oct 10, 2025, 5:59 PM UTC

ants_everywhere wrote: post #312

feoren wrote: post #82

Earlier quoted context omitted.

You hope it doesn't ? > [Donald Knuth] firmly believes that having an unchanged system that will produce the same output now and in the future is more important than introducing new features This is such a breath of fresh air in a world where everything is considered obsolete after like 3 years. Our industry has a disease, an insatiable hunger for newness over completeness or correctness . There's no reason we can't…

> There's no reason we can't be writing code that lasts 100 years. Code is just math Math is continually updated, clarified and rewritten. 100 years ago was before the Bourbaki group.

> Math is continually updated, clarified and rewritten

And yet math proofs from decades and centuries ago are still correct. Note that I said we write "code that lasts", not "programming languages that never change". Math notation is to programming languages as proofs are to code. I am not saying programming languages should never change or improve. I am saying that our entire industry would benefit if we stopped to think about how to write code that remains "correct" (compiling, running, correct behavior) for the next 100 years. Programming languages are free to change in backward-compatible ways, as long once-correct code is always-correct. And it doesn't have to be all code, but you know what they say: there is nothing as permanent as a temporary solution.

Re: Python 3.14 is here. How fast is it?

#508

Post by feoren » Fri, Oct 10, 2025, 6:06 PM UTC

sacado2 wrote: post #411

feoren wrote: post #82

Earlier quoted context omitted.

You hope it doesn't ? > [Donald Knuth] firmly believes that having an unchanged system that will produce the same output now and in the future is more important than introducing new features This is such a breath of fresh air in a world where everything is considered obsolete after like 3 years. Our industry has a disease, an insatiable hunger for newness over completeness or correctness . There's no reason we can't…

> There's no reason we can't be writing code that lasts 100 years. Code is just math. Imagine having this attitude with math: "LOL loser you still use polynomials!? Weren't those invented like thousands of years ago? LOL dude get with the times, everyone uses Equately for their equations now. It was made by 3 interns at Facebook, so it's pretty much the new hotness." No, I don't think I will use "Equately", I think I…

> Mathematical notation evolved a lot in the last thousand years

That is not counter to what I'm saying.

    Mathematical notation  Programming Languages.

    Proofs  Code.

When mathematical notation evolves, old proofs do not become obsolete! There is no analogy to a "breaking change" in math. The closest we came to this was Godel's Incompleteness Theorem and the Cambrian Explosion of new sets of axioms, but with a lot of work most of math was "re-founded" on a set of commonly accepted axioms. We can see how hostile the mathematical community is to "breaking changes" by seeing the level of crisis the Incompleteness Theorem caused.

You are certainly free to use a different set of axioms than ZF(C), but you need to be very careful about which proofs you rely on; just as you are free to use a very different programming language or programming paradigm, but you may be limited in the libraries available to you. But if you wake up one morning and your code no longer compiles, that is the analogy to one day mathematicians waking up and realizing that a previously correct proof is now suddenly incorrect -- not that it was always wrong, but that changes in math forced it into incorrectness. It's rather unthinkable.

Of course programming languages should improve, diversify, and change over time as we learn more. Backward-compatible changes do not violate my principle at all. However, when we are faced with a possible breaking change to a programming language, we should think very hard about whether we're changing the original intent and paradigms of the programming language and whether we're better off basically making a new spinoff language or something similar. I understand why it's annoying that Python 2.7 is around, but I also understand why it'd be so much more annoying if it weren't.

Surely our industry could improve dramatically in this area if it cared to. Can we write a family of nested programming languages where core features are guaranteed not to change in breaking ways, and you take on progressively more risk as you use features more to the "outside" of the language? Can we get better at formalizing which language features we're relying on? Better at isolating and versioning our language changes? Better at time-hardening our code? I promise you there's a ton of fruitful work in this area, and my claim is that that would be very good for the long-term health and maturation of our discipline.

Re: Python 3.14 is here. How fast is it?

#509

Post by igouy » Fri, Oct 10, 2025, 6:08 PM UTC

DonHopkins wrote: post #451

CuriouslyC wrote: post #215

Earlier quoted context omitted.

As someone who was a hardcore python fanboy for a long time, no, no it won't. There are classes of things that you can only reasonably do in a language like rust, or where go/kotlin will save you a crazy amount of pain. Python is fine for orchestration and prototyping, but if it's the only arrow you have in your quiver you're in trouble.

At least Python doesn't have an extremist "100% Pure" ideology like Java, and instead (like TCL and Lua) it's been designed from the ground up for easily integrating with other languages and libraries, embedding, and extending, instead of Java's intolerantly weaponized purity and linguistic supremacy. Reasons why Sun and Java failed: Strategy over product. McNealy cast Java as a weapon of mass destruction to fight Mi…

Sun and Java failed ?

Please share your example of what succeeded (maybe just spell out the last paragraph).

Re: Python 3.14 is here. How fast is it?

#510

Post by igouy » Fri, Oct 10, 2025, 6:12 PM UTC

pansa2 wrote: post #455

1vuio0pswjnm7 wrote: post #326

Only tested against NodeJS and Rust What about Lua and LuaJIT

I did some recent testing that showed both Lua and LuaJIT-joff (its interpreter-only mode) to be about 2x faster than Python. Both PyPy and full-on LuaJIT were about 10x faster. Years ago, I even found Ruby to be faster than Python. This was back in the Ruby 2.0 / Python 3.5 days - I'd be interested to know if it's still the case.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...