| ▲ | tweakimp 6 hours ago |
| Sad to read this. I had hoped that with the advance of AI capabilities, features like this could be prototyped, tested, implemented and shipped even faster. And I was really looking forward to see performance gains for my favourite language. Where do we go from here? Microsoft did not continue to finance the Faster CPython project and the current speed gains are good, but not what we hoped. |
|
| ▲ | Eji1700 5 hours ago | parent | next [-] |
| A biased opinion as I dev in F#, but it strikes me that AI is going to play best with functionally pure languages (strongly typed, no side effects, whatever we call that these days)? F# is on the softest side of that, but letting the compiler tell the AI "nope, here's why" seems like a huge win in saving cycles and time. The downside at first was simply, "how many examples of F# are there to learn from", and early on it showed, but I think that's been long overcome. And F# is obviously NOT the best example since it's both "soft" on functional purity and niche. I imagine something like haskell is probably doing even better, although I've yet to check that at all (not that I can code haskell but I haven't looked at anecdotes or anything). I realize this doesn't really help anyone who's grown to love python, and there's surely no perfect language, but just like how the web catapulted javascript, I see a future where the answer isn't "use AI to make python better" so much as "what already works super well with AI, and does it ease the user adoption" |
| |
|
| ▲ | Retr0id 5 hours ago | parent | prev | next [-] |
| At this point if you have a python codebase where perf is an issue, the "AI-pilled" answer is to rewrite it in a faster language. |
| |
| ▲ | tweakimp 5 hours ago | parent | next [-] | | But I want to continue to understand the code. I dont know Rust (maybe AI can teach me?) and if I let Claude rewrite my current 50k LOC project in Rust, how can I understand what is happening and how can I work on it and think it further? | | |
| ▲ | jerf 4 hours ago | parent | next [-] | | Rust is not your only option. Nor is it automatically the best option, though it is certainly a solid option for a certain set of requirements. Go is a pretty decent match for a Python rewrite; superficially it seems like you're giving up a lot but under the hood they're philosophically more compatible than meets the eye in a lot of ways. But any static language that you have some other local reasons to prefer is going to blow its socks off in terms of performance. And "blow its socks off" is just for the naive translation of a conventional Python code base over to a new language. If your codebase is amenable to threading and can take advantage of multiple CPUs somehow, the result may blow Python's socks off twice over. The problem is that Python just isn't going to go fast. There are some languages that may have had more resources poured into them to make them go faster in absolute terms, like perhaps Java. But I don't think there's a single language that has had so many ways of trying to make it go faster given so much effort over so many decades. It's really time to call it... if you have Python code and it's a performance problem, if one of the many many many different solutions aren't adequate for some reason, Python is not going to get any faster than it is today and you're going to have to move off of it. If you need high performance code, Python is simply not the right answer and you're going to have to skill up. Or accept what you have, which you'll have to decide if that's a viable option. If it's fast enough I don't advocate switching casually. But if it isn't, there isn't a realistic prospect that you're going to wake up in a year or two to a 30x-faster Python. I wasn't terribly convinced by that claim back in the early 2000s, but it hadn't really been tested yet. It has been tested now. | | | |
| ▲ | Yossarrian22 4 hours ago | parent | prev | next [-] | | You could try having it rewrite parts of the hot path into Rust with PyO3. | |
| ▲ | skeledrew 3 hours ago | parent | prev [-] | | There are already many solutions to the performance issue from which you can pick. You don't need to understand the C in numpy to use it for example. And I'd say it's highly unlikely that you have a use case that, if it's applicable, isn't already addressed. Like it's generally pointless to optimize language performance for code that's doing a lot of network operations, because network lag will always dwarf such optimizations. |
| |
| ▲ | lemagedurage 5 hours ago | parent | prev [-] | | It's already typical to call into a native library with Python bindings for performance critical work in Python. Even Pydantic's validation runs in Rust code. | | |
| ▲ | Retr0id 4 hours ago | parent [-] | | This works well if there are obvious hot spots that can be easily isolated, but sometimes the perf issues are more uniformly distributed throughout a codebase. |
|
|
|
| ▲ | samus 3 hours ago | parent | prev | next [-] |
| Mature projects simply don't like large unexpected code drops if it is not made clear beforehand what the blast radius is and how it is going to be maintained. On top of that it seems that the performance gains weren't as expected and require further invasive changes. Implementation effort has never been what has held these efforts back. LLM helps with squirting out code, but the hard tasks are benchmarking, profiling, community engagement, knowledge management, and dealing with the hard questions such as whether the change is actually worth the additional complexity. These concerns won't go away even if we give up on human developers being able to grok the code and instead completely relying on LLMs for coding. |
|
| ▲ | pjmlp 4 hours ago | parent | prev [-] |
| We pick languages that embrace machine code like Julia, Mojo, Common Lisp, Scheme, and stop calling libraries that are written in C, C++, Fortran, Rust, "Python Libraries", when they are thin bindings. Clearly the community doesn't want PyPy, GraalPy, or even a CPython JIT. |
