340
Software is slow because of bad design, not slow languages
(www.seangoedecke.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 23 Oct 2026
340 points (95.9% liked)
Programming
28990 readers
189 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
Python is dog slow, but if your tests are taking 10 seconds to start (not even run!), then something is catastrophically wrong with your setup. For comparison, for one of my projects, it takes a total of 12 seconds to run nox on a clean slate, which involves setting up venvs for five major versions of Python, installing the package and its dependencies in each, and finally running the 1500 test test-suite five times
It wasn't my project. Afaict it's a standard pytest setup with the Litestar framework (unused in my tests) and an in-memory mock Postgre transaction with like five records per test, so choose for yourself which part of this is 'catastrophically wrong'. However, I can indeed agree that most of it is trash.
Same approach with dozens upon dozens of tests worked snappily as heck in PHP, haven't yet tried it with my beloved Lua.
Then its the Test environment that is slow, not Python.
It is, yes. But I also commented on Lua vs Python, and if you even try to time them, Lua scripts will be finished before Python starts up. Lua is so fast that people mostly don't bother making libs for it in C, the fucking interpreter is quick enough for folks to skip any kind of compiling and just write libraries in the interpreted language. Oh, didn't I mention? The startup thing is with the interpreter, without any kind of bytescript, JIT and such.
In the same vein, the K and Q languages and the KDB+ database by Arthur Whitney are so goddamn fast at array processing that they're used in banking for decades despite their extremely inscrutable syntax that would shear any Python programmer's head clean off. They just stay in the cache at most times. And they are also interpreted, not compiled at any time.
Python suffers from the same shit as Java, it has to initialize hundreds of objects before the main program even starts, and then it creates hundreds more. Neither Lua nor JavaScript do that. PHP does to some extent, but the fucker is so fast that it can recreate the entire runtime context on every single request and then drop all of it afterwards, and it's still quicker than Python.
The use case for Lua is very different from Python. It's not directly comparable, as Lua is barebones.
Lua is directly comparable to Python, as it's incredible at quasi-interactive scripting. Python actually fits better when startup time doesn't matter, while a Lua script can start and finish a dozen times before a Python process just turns on.