alt Hacker NewsIf AI writes your code, why use Python?
Comments
Read the first few comments and surprised I didn’t see it, but training data. The voluminous amount of Python in the training data.
I could write in brainfuck with ai, but I presume, wouldn’t get the same results than if going with python.
My follow up question: with AI now, why care about a lang until you need to?
Not just for LLMs, but in general if code is produced automatically by a tool and isn't going to be a hundred percent proofread and tested by humans who could have written it manually, it's always better to use the safest possible language so that the compiler can catch most of the errors. So yeah, Rust or OCaml are good candidates. Performance is also a good point but it's a secondary issue in my opinion.
Yea I take the step a bit further, why bother Rust ? Just go write assembly or better the executable bytes... You see ? Readability is very important :)
Why Python? Because I have written it for 10+ years, know how to debug it and I can smell it within 10 seconds of the agent writing code if it does something that is going to end in a huge foot gun. With any other language, not so much; I would need to relearn a lot. So I am going to be preferring python; where even with the speed that AI crams out code, I still feel somewhat in control. If I did this with Go or Rust, then it would feel more like "vibecoding" than AI assisted programming, just yolo the whole product.
Bit off topic but why in the world are people still posting on medium? The reading experience is abhorrent; I couldn’t even finish reading this article before a full screen popup literally blocked the sentence I was reading.
Is there some incentive I’m not seeing?
Other correctly point out it does matter what language the code is in since the human does sometimes need to read and understand it.
But also, I suspect the article is just wrong. "The hard languages got easy first" isn't true in practice and the impressive examples given are not representative or as magical as the poster makes them out to be.
The takeaway might be right in the end, but the post isn't right in the beginning.
Python has a much more mature ecosystem than Rust, especially for AI/ML stuff. I ran into a rust crate that purported to do a certain ML algorithm but did not do it correctly. I managed to write a replacement with Claude though.
I do think enforcing correctness at the type system level is a good idea for AI, which is why I often choose languages like C# and Rust over Python. However, for some things Python is definitely the correct tool for the job.
I use a mix of both to try and leverage their advantages.
Rust in most cases, especially for back end.
Python when it's low risk (say monitoring dashboard or similar API heavy) or plays to python strengths (e.g. ML/AI - everything ML seems to be python).
> Go delivered most of the performance benefit at a fraction of the engineering cost. The biggest JS/TS shop on earth picked a harder, faster language for its flagship tool, and they did it because the effort calculus changed under them.
IME very few people think Go is harder than TS or JS - TS is quite complex and JS is a footgun range.
JS got popular for nontechnical reasons and TS is an attempt to make lemonade out of it.
You can of course use any language but here is my advice: you should use the language that you know best to make your life as uncomplicated as possible when you want to understand what the LLM was creating.
Remember, you are the judge whether the code is OK and if you use assembler you might get really performant code, but can you trust it?
Of course it might be a good incentive to learn rust or go. Or challenge yourself to learn something really cool like LISP, COBOL, FORTRAN, APL or J. (just kidding...)
just my 2 ct...
> A shipped app, in a language nobody on the team knew
Great! Let's look back on this not too far in the future.
So you are not going to review code? So you are not going to modify code? How many cases that AI Can always modify code correctly without human input?
It's strange to me that this blog post was written in English. If AI is available, why aren't we all communicating in Lojban? [0] It's an obviously superior language. What does it matter that many people already communicate in English and much of computing depends on that language? AI doesn't care about that. Plus, if you ever need to edit Lojban without AI, you should be able to pick it up in a few weeks, right?
The lumping together of Typescript with Python is a mistake. Typescript is much faster (mostly due to engine investment), is much saner, has more expressive types, and generally has better ergonomics for the backend than Python.
AI's are really good with Python. Quick turnaround. Easy to read. Tons of training data/examples. Many of the same reasons we wrote Python before.
Another benefit to using Python, is if you subscribe to writing/vibing a throwaway version first, a Python version is 100x better than a spec.
(Disclaimer: I teach Python and AI for a living and am doing a tutorial at pycon this week, Beyond vibe coding. Am also using other languages as there are times when Python isn't appropriate)
IMO, just use the language your know it well. It might be a little bit off topic, if you are going multiple platforms development now, such as backend, ios and android, will you go native now? or use cross platform languages? :D
> Nicholas Carlini, a researcher at Anthropic, orchestrated 16 parallel Claude agents to write a production C compiler in Rust.
No he didn't. The compiler is bascially useless as it produces vastly inferior code than gcc/clang.
If you're working with an agent to write code, you want it in the most quickly-readable format possible. That's generally Python, although YMMV. I want to be able to skim and zoom in on parts of code that might need attention. This makes it easy.
If the code were written in Java, I'd have more to read. If it were in JavaScript, I'd be slower following the calls (although the type system might catch issues more quickly - not a problem in my experience). I think Python is a good choice.
Funny, along the same lines I asked an AI to write some wasm text. It was ridiculously bad and I had to intervene heavily to get something working as intended.
Many here propose replacing Python with more performant, but less familiar languages - mostly Rust, Go. But I find the argument that the AI - HUMAN interface is the most important. A simple version of this is “no, stick with Python if that’s what you know”. A more interesting version is “use this new found AI leeway to move up the abstraction level”, “try something more expressive and human oriented”, “make a DSL and parser that suits the domain (and focuses the AI)”. Despite being a minority language, Raku is ideal for these aspects (esp with built in Grammars and general kitchen sink repartee) and works surprisingly well with most popular LLMs.
For now it’s the exact same reason why you’d use Python when you’re writing by hand: so the code is more easily readable/editable by humans who are more likely to know Python than something like Zig. But I understand the point the post is trying to make, I don’t think we’re there yet.
One underrated advantage of using Python or Typescript is that AI agents can inspect the code of installed dependencies.
This means you don't have to muck around with supplying the right documentation for each version of each dependency, or worry about hallucinated interfaces (at least with the latest models).
In the past you'd have to dig through a foreign codebase manually to figure out why a documented interface for a dependency is not working as expected, but frontier models automate that quite well.
Why stop at getting AI to write Rust? If everything is vibe coded and code is no longer reviewed, get an LLM to devise its own ultra terse, super dense language intended solely for minimal token use and speed.
/s... sort of
Is there a blocker that would prevent future AI to write perfect assembler (for n architectures) in 1st pass?
I'm sure there are plenty of caveats and breaking points, but if we do adhere to the claim that an LLM coding tool is a nondeterministic sort of compiler then it really does make sense to pick the most performant language available. Obviously there are caveats of libraries and native advantages of various languages. I've been doing stuff in C++ for the past month or so and the only slow down from the language choice is compilation time.
Well, I'd still want something I can read...
Asking Clodex to build me a hello world web backend in Rust, Go, Python: Python is read with great ease. Go is fine too, a bit verbose but still ok. Rust hurts my eyes.
I'd settle with Go for this use case.
My experience is that there's a correlation between powerful type systems and the property that once your program compiles, it's correct. Compiles == correct is rarely true in C or JavaScript. It's often true in Haskell and Rust. TypeScript is somewhere in between C and Rust.
There's a niche available for a language which is relatively easy for a human to read, but with a very powerful at the expense of difficult to use type system. The language would let you make all sorts of assertions whose meaning are easy for the human to see, but to compile would need to come along with correctness proofs. The language is meant to be written by AI, which can battle the compiler, and write the proofs, but then read by humans who can verify that the AI wrote the program they wanted and/or direct the AI to make changes.
Kind of my fear is that the industry and dev community will ignore new frameworks, languages, architectures etc because the LLM aren't trained on those new things.
For example low level converging to Rust, web frontends to something like React etc.
Actually, I do use compiled languages for this reason. Even Opus 4.7 and GPT-5.5 will leave unassigned variables lying around in Python code of sufficient size. If you've got sufficient testing you'll exercise all paths, and I imagine a good prompt would ensure adding testing with coverage to see that it does happen. However, I do not have (yet) such a system but using Go/Rust helps a lot because the compile phase actually helps detect correctness issues.
My other problem with most of the other ecosystems: ts/npm, python/uv, rust/cargo is that they all have build-time scripts that are controlled by others that execute automatically. This is a real problem because the LLM will just install things and proceed to send your home directory through a juicer. I feel a bit of a paranoiac now doing this, but I have a script that launches a podman container with just the source directory and a binary directory loaded (for caching) which compiles everything.
I know there's some sequence of steps I can take to protect myself, but if the LLM accidentally uses pnpm to run dev build scripts when I had the right config on npm or whatever, I know I'm screwed. So now I do all these shenanigans with Rust (to the extent that I vendor old deps sometimes). So the ideal language to me now is one with very few of these footguns and sandtraps which has a tight iteration loop.
This post resonates. I recently built a little web service to scratch an itch I've been having and after discussing the options with Claude we settled on Go, and honestly it's been fantastic. Highly performant, native threading, dead simple to deploy with containers. And I don't even know how to read or write Go.
Really controversial but my honest opinion: That's because programming languages, and its natural language counterpart, too, are nowadays increasing and more likely in becoming a political tool, rather than itself being a tech tool.
I observed this through observation of the attacks to Rust due to the huge presence of LGBT people.
Now while I'm pretty much straight myself, I don't reject LGBT people and don't want to partake in identity politics.
I just want things that works no matter what background you have, yet there are some people attacking Rust because of its inclusiveness nature.
And just like Linux is being perceived as nerdy and geeky and "gaming socks ready", the tokenization of things, and there attaching political meanings to it, are quickly coming to everything, so perhaps I'm too general here as well.
Let's say it is not political, but definitely adding more meanings to its technical origin and nature
Because there is no negatives, only positives.
I can maintain the Python code myself and I can execute it everywhere.
If I let my LLM write in Rust then when things break I am out of luck. Also Rust needs to be compiled which means I can't just share the code as freely.
So he includes Go in a list of languages that apparently makes development slow and have “a build system that fought you” and then says python was the solution for all that. I think he got it backwards. I have found the Python build system horrific and broken by default while Go just works.
I know a couple languages fairly well: C, Perl, Python, Bash. I never formally learned Go, but as a test of AI coding, I started some vibe coded projects in Go. It worked very well: the code is minimal, there's few dependencies, and it compiles down to a static app. But most importantly, I can actually read the Go code and understand basically what it's doing. I can also use LLMs to critique the code if I'm uncertain. The big benefit of Go is the simpler language and "batteries included" standard library. This leads to fewer dependencies and less lines of code, which improves overall AI output. In theory, AI should be able to write better code faster in Go than in another language like Rust.
Python does have a much larger ecosystem of course, so with Go you have to develop from scratch what already exists in Python. But for smaller projects, you can also have an AI write a clean-room implementation in Go of some project in Python. So you aren't necessarily locked into one ecosystem anymore.
And in my experience, you don't even need to know the language. I have a co-worker who's basically not a programmer, but got multiple implementations of applications working sooner than our dev teams doing it by hand. You should be a coder so you can architect and orchestrate the coding, but 'language' isn't a barrier anymore.
>Smaller languages like Zig, Haskell and Gleam don’t have the same quality when AI-generated (for now).
GPT 5.5 writes good haskell.
I think the author misunderstands what is good about Python.
One of the big strengths of Python is legibility: most developers find it easy to read and understand.
If you are planning to have humans verify the code you're using in production, to confirm it implements your intent, the readability of the code you are producing is important.
Performance is valuable, but for a lot of code, performance is less important than correctness and ease of verifying it.
If you are imagining your codebase being one where nobody but Claude reads the code, you might as well do Rust for the better performance. But I don't think a lot of organizations are doing that.
This seems sort of like asking whether a chatbot should answer you in English or Japanese. Obviously, it should use whichever language you understand. If you understand Python best, why not write code in Python?
But on the other hand, maybe you could learn some other programming language, particularly with AI help. If that's what you wanted to do anyway, it seems like a good time to learn.
Rust is the way!
Bullshit article. AI is not meant to be a black box, you just spit at it and it'll generate you a whole app and you don't even understand a single line. That WILL eventually fail. There was an article here some time ago where someone described it pretty well "use AI as autocomplete on steroids". Therefore, use any language you can actually debug well and know well and use AI as a tool, not as your replacement. And don't use it to port your electron app to rust if you don't know rust, Jesus.
To put it simply, Python feels recoverable when something goes wrong, but Rust often feels like solving a compiler puzzle. Honestly, I still do not really know how to handle lifetimes properly.
When I use AI to help with coding, there is almost always a point where it gets stuck and I have to solve the problem myself. If I were using Rust at that point, it would be much more painful.
I know Rust has a very strong reputation in the community, but to be honest, I find it a difficult and frustrating language to work with. I would use it when I truly need systems-level performance, but for most high-level work I would rather use Python, because I can move much faster. In most projects, that level of raw performance is not actually necessary.
> You used Python or TypeScript because[…]. because Rust, Go, C++, and many more would give you 10–100x the performance, but you paid for it: […] a build system that fought you.
I would argue I spent more time fighting the TypeScript build system than Rust’s.
But up until recently I only used either just often enough to never remember what magic configuration needed to go in my tsconfig.json and package.json to get TypeScript to work.
Python is incredibly readable too. I can scan through LLM Python changes in minutes instead of hours of other languages.
Lately I just have Claude build most things in Rust, it's really amazing. I tried Go, but I found it wasn't as good--Rust really does to me feel like Python. That said, it still struggles with the same class of errors of building complex systems. I've tried using TLA+, Alloy, and other things but haven't found the trick yet. The best I've found is reimplementing all external systems in memory and e2e testing everything extensively, without reimplementing the tests become unusably slow, and Claude can rewrite huge surface areas with ease--it's somewhere between mocking and literally just reimplementing the external systems.
I build all my projects with Rust and Typescript (https://github.com/brainless). I had started learning Rust around 2023 but was progressing very slow. Since I left writing (or even reading) code line by line about a year ago, I build exclusively with Rust and Typescript. API types are generated from Rust. All my projects have a shared-types folder with a utility to generated Typescript types. I have a template that I use for each of my projects: https://github.com/brainless/rustysolid.
I am from a Python background (11 years or so), PHP before that and C/C++ in college days. Rust works very well with coding agents. The amount of code in training data may be less but I would rather have the agent fight the compiler. Given that OpenAI and Anthropic seem interested in Rust, chances are that there is a ton of synthetic code generated with Rust.
Two things to consider: - When reading generated code, which programming language would be the most readable to you? - Which programming language guides AI to write correct code using language features or guardrails?
There you will find your answer.
"The Python ecosystem is increasingly a Rust ecosystem wearing a Python hat"
If anything this is a reason to keep using Python.
Well don't ask us. If AI writes your code, why not ask it? You could probably make it write a whole article for ya.
One obvious reason is Python's extreme readability, it has often been described as being as close to executable pseudo-code as one can get.
If you're using an LLM to write code I think the rules would be
1. Use a language you know really well so you can read it easily, and add to it as needed.
2. Use a language that has a large training set so the LLM can be most efficient.
3. Use a language that is easy to read.
If your language has a small training set or you don't intend to do much addition or you don't really know any language that well or are restricted from using choice 1 for some reason, 2 and 3 move up, and python has a large training set and it is easy to read.