undefined

points

[-]

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"

by vovavili18 hours ago|

parent|

[-]

The biggest winner from AI indeed appears to be Rust.

by pjmlp14 hours ago|

parent|

[-]

3GL code generation is only a transition step until models get more mature for direct machine code generation.

AI needs formal verification, not a borrow checker.

by Retr0id20 hours ago|

prev|

[-]

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.

by tweakimp20 hours ago|

parent|

[-]

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?

by jerf19 hours ago|

parent|

[-]

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.

by LtWorf19 hours ago|

parent|

[-]

Pypy is really fast. Have you tried it?

by anthk19 hours ago|

parent|

prev|

[-]

RustPython it's pretty mature.

by skeledrew18 hours ago|

parent|

[-]

Not at all.

> RustPython is in development, and while the interpreter certainly can be used in interesting use cases like running Python in WASM and embedding into a Rust project, do note that RustPython is not totally production-ready.

- https://github.com/RustPython/RustPython

by Yossarrian2219 hours ago|

parent|

prev|

[-]

You could try having it rewrite parts of the hot path into Rust with PyO3.

by skeledrew18 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.

by mahboi10 hours ago|

parent|

[-]

There's so much Python code that uses numpy etc but still ends up having some hot part in Python that's nontrivial to translate to something faster. Same reason people get frustrated with the GIL.

by lemagedurage20 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.

by Retr0id19 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.

by samus18 hours ago|

prev|

[-]

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.

by pjmlp19 hours ago|

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.