The article makes a convincing argument that Haskell compilation is too slow for the fast code generation of AI. But python?
I have yet to experience a RHEL major version change that did not blow up all my tiny simplistic python scripts. I see the following options for using python: * run inside the container it was developed in * build your own python interpreter and environment and libraries and never use python pieces from the OS (i.e., act like a container without using one) * keep different versions of the code for different OS versions and use AI to rewrite all the code for the new OS version
Start to consider third party dependencies, and none of those feels tractable without an AI assist.
I've dabbled in C device driver code and kernel version differences were my only problem, not C. My perl scripts never break. My bash scripts rarely break. My dabbling in erlang didn't suffer from language version differences. My little elisp hasn't broken. Only python has inflicted this level of version pain. I have a colleague who says java has the same version pain as python, and from what I've seen from Jenkins maintenance he may be right, but I don't have colleagues who want to read java code, so I haven't written my own.
uv is solving these problems for the kind of things Scarf is developing.
never use system python, always use virtual envs. (a bad answer, but agents do remove the setup boilerplate). UV does relatively completely solve this but it's a big dependency to take so understand why people don't rely on it