> "At Scarf, we started doing all new API work in Python."
Start the countdown timer for how long it takes them to discover that was a mistake.
Nothing to do with Haskell, but good grief, LLMs do not in any way, shape or form save you from the deep, unfixable problems with Python.
At the very least you need all the static checking machinery like Ruff, Pyright, and hefty unit tests that take the place of typechecking if you don't want obvious failures to only show up in production.
I had this recently with an ML training pipeline, where Python is essentially forced on us. A dynamic error occurred after 17 hours of training - something that a real type system could have easily caught.
The solution that the LLM came up to prevent this in future was a complicated Enum-based system that just made me wish I could use a real programming language.
Unfixable errors? Why unfixable? Python is Turing complete. I can see difficult to fix, but not unfixable. LLMs lower the bar to refactoring code mistakes.
What would be your goto for the ML training pipeline?
I have the impression that Python basically wins by default in those spaces due to the lack of many good libraries in other languages (except for, like, C++).
But curious if this is just a very outdated view of the world
Yeah Python seems like a bad choice. LLMs seem to write low quality Python compared to Rust, presumably because there is a lot more low quality Python in their training sets than there is for Rust.
It is a win win situation, they get to write a new blog post about doing a Python to Rust rewrite.