Comment by skeledrew
3 hours ago
> slowness of Python based software
I know of very few cases of this. For the most part I find the "slow" to be in the network/IO things. Unless one is doing heavy matrix math or something similar in pure Python, which I'd seriously question.
Some people write full blown desktop software in Python, and then get amazed how fast it flies when rewritten into a compiled language.
This sounds like my experience switching from conda to uv. The speed seriously blew my mind, and sometimes still does today. But then I think about the tradeoffs: I've encountered issues with uv-packaged Python because they've optimized the heck out of it, like a few months ago I was working with tkinter and things were failing hard on ways I couldn't understand, then I switched to conda for those projects and... things just worked. Also package management isn't a thing that's regularly run, so while it's blazingly fast, it really doesn't have much effect on overall dev time. If it was just about speed, I would've stuck with conda, but uv offers a lot of actual valuable features and simplified some of my flows, so it's now my main Python project manager and conda kept as fallback.
It's essentially the same re regular desktop software. The performance for a particular bit may be nice, but it really doesn't impact the overall experience as one can only move at a certain speed as a user, and there are still those other bottlenecks. Like with my current project that's using Flet, the UI is extremely snappy and a joy in every way, but the networking bit (using iroh, which is implemented in Rust) has been a constant pain that I have to keep returning to. The speed of Rust is doing 0 to help anything, and I feel like it would've been less painful if iroh was actually implemented in Python as then I could dig into the source to see what's up and tweak to fit my circumstances, instead of dealing with essentially an immutable black box.