211–220 of 579 posts
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.
[flagged]
I'm thankful they included a compiled language for comparison, because most of the time when I see Python benchmarks, they measure against other versions of Python. But "fast python" is an oxymoron and 3.14 doesn't seem to really change that, which I feel most people expected given the language hasn't fundamentally changed. This isn't a bad thing; I don't think Python has to be or should be the fastest language in th…
I've been writing Python professionally for a couple of decades, and there've only been 2-3 times where its performance actually mattered. When writing a Flask API, the timing usually looks like: process the request for .1ms, make a DB call for 300ms, generate a response for .1ms. Or writing some data science stuff, it might be like: load data from disk or network for 6 seconds, run Numpy on it for 3 hours, write it…
> You could rewrite that in Rust and it wouldn't be any faster.
I was asked to rewrite some NumPy image processing in C++, because NumPy worked fine for 1024px test images but balked when given 40 Mpx photos.
I cut the runtime by an order of magnitude for those large images, even before I added a bit of SIMD (just to handle one RGBX-float pixel at a time, nothing even remotely fancy).
The “NumPy has uber fast kernels that you can't beat” mentality leads people to use algorithms that do N passes over N intermediate buffers, that can all easily be replaced by a single C/C++/Rust (even Go!) loop over pixels.
Also reinforced by “you can never loop over pixels in Python - that's horribly slow!”
Earlier quoted context omitted.
> There's no reason we can't be writing code that lasts 100 years. Code is just math. In theory, yes. In practice, no, because code is not just math, it's math written in a language with an implementation designed to target specific computing hardware, and computing hardware keeps changing. You could have the complete source code of software written 70 years ago, and at best you would need to write new code to emulat…
Given how mature emulation is now why couldn't that just continue to be possible into the future?
seems loved languages such as python & ruby (ZJIT | TruffuleRuby) have been getting a lot performance improvements lately. of course JS with v8 kickstarted this - followed by PHP. so for majority of us folks use what you love - the performance will come.
Earlier quoted context omitted.
> I would say the REPL too but until very recently it was extremely shoddy Can you elaborate? I've been using the Python REPL for more than two decades now, and I've never found it to be "shoddy". Indeed, in pretty much every Python project I work on, one of the first features I add for development is a standard way to load a REPL with all of the objects that the code works with set up properly, so I can inspect them…
Very obvious example - you can't paste code containing blank lines. Another example: navigating this history is done line by line instead of using whole inputs. It's just bare minimum effort - probably gnu readline piped directly into the interpreter or something. I think they did improve it a lot very recently by importing the REPL from some other Python interpreter but I haven't upgraded to use that version yet so…
That is more or less how the REPL originally was implemented. I think there's more under the hood there now.
I still don't think what you describe qualifies as "shoddy". There are certainly limitations to the REPL, but "shoddy" to me implies that it's not really usable. I definitely would not agree with that.
Earlier quoted context omitted.
Except uh, nobody uses infinitesimals for derivatives anymore, they all use limits now. There's still some cruft left over from the infinitesimal era, like this dx and dy business, but that's just a backwards compatibility layer. Anyhoo, remarks like this are why the real ones use Typst now. TeX and family are stagnant, difficult to use, difficult to integrate into modern workflows, and not written in Rust.
> the real ones use Typst now Are you intentionally leaning into the exact caricature I'm referring to? " Real programmers only use Typstly, because it's the newest !". The website title for Typst when I Googled it literally says "The new foundation for documents". Its entire appeal is that it's new? Thank you for giving me such a perfect example of the symptom I'm talking about. > TeX and family are stagnant, diffic…
It might not be the best tagline, but that is most certainly not the entire appeal of Typst. It is a huge improvement over Latex in many ways.
Earlier quoted context omitted.
That's because you're doing web stuff. (I/O limited). So much of our computing experience has been degraded due to this mindset applied more broadly. Despite a steady improvement in hardware, my computing experiences have been stagnating and degraded in terms of latency, responsiveness etc. I'm not going to even go into the comp chem simulations I've been running, or that about 1/3 the stuff I do is embedded. I do st…
As a java backend dev mainly working on web services, I wanted to like python, but I have found it really hard to work on a large python project because the auto complete just does not work as well as something like java. Maybe it is just due to not being as familiar with how to properly setup a python project, but every time I have had to do something in a django or fast api project it is a mess of missing types. Ho…
Do any of these tests measure the new experimental tail call interpreter ( https://docs.python.org/3.14/using/configure.html#cmdoption-... )? I couldn't find any note of it, so I would assume not. It would be interesting to see how the tail call interpreter compares to the other variants.
Earlier quoted context omitted.
I feel like I’m having a stroke.
You should hear the Dutch say "yah-vah-shchkript" with a throat clear and spit take.