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?

If AI writes your articles, why use brain?

> A shipped app, in a language nobody on the team knew

Great! Let's look back on this not too far in the future.

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.

Isn’t the answer usually - because the same ai said python is the right language for it?

Honestly I am in the exact same boat thinking why I don’t write in C if Claude is writing it. However I chickened out thinking if support for ml model or llm based flows doesn’t exist in c then it will be time consuming to go to python then.

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?

Better question is why use any code? Generate random functions and select based on measuring the distribution of output of these functions against metrics of interest. A pure black box of instruction that is more performant than any verbose code or algorithm we could come up with, because all we select for is performance above all. Directed evolution essentially of the codebase, generated through mutation and selection, just like everything else on planet earth.

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

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.

Yeah, last year I discovered that AI writes better rust than C, so I switched to rust and it made some quick good code that it couldn't do in C.

But when I wanted to optimize and edit and reorganize bthe code it was difficult, so I did a rewrite in C and it was lighter and faster and simpler and less headache.

C for humans, rust for AI.

AI/ML stuff: Python

Personal: Rust/Go based on criticality of being able to glean code quickly, or memory usage, etc

I had agents code up an app for me in Swift a while back and the entire experience was so much better than your typical Python experience. The agents took full advantage of the compiler and static typing. There were far fewer bugs than expected.

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)

I still use TypeScript because I know it best. When AI makes a mistake, I can find the bug much faster. For me, the speed of writing code doesn't matter as much as the speed of fixing it.

Claude writes java pretty well, and faster than Rust. It's a great middle ground for some projects. I've switched back from Rust to Java for some things.

I don't know why you would use Python at all except for small iterative projects. If you hate java for some reason, there's Go...

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.

Really agree. Python is popular because it's easy for human to implement. But now if the coder becomes AI, then Rust would be preferable for agent, just like Python for human. In addition, it brings better performance.

Because AI creates unmaintainable messes in any language, and ergonomic ones help humans clean up.

As others have said, the main benefit with Python over Rust is library support especially with ML features. The other gap as I see it with Rust is the lack of native flexible UI support. The nice thing about Rust though is it can serve as a very fast and stable core for an app and offload specifics to TS and Python as their strengths allow, so you get the best of all worlds.

My current goto for desktop apps is Tauri, which give us a rust backend and TS fronted (usually React). Local ML features can be easily loaded as a python sidecar. Production bundling can be a little challenging but it seems to work well so far.

Sidenote: Golang is also an amazing language for LLM use, I generally do most of my "infra" stuff in Golang over Rust, but either work fine most of the time.

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.

Didn’t Tencent do a study comparing AI performance across about 20 languages showing that Elixir was the top performer?

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.

I think it is an interesting question what kind of programming language one needs for an era of agents. It is clear that the programming language that was designed for humans is not necessarily the best for AI-driven software development. I guess the qualities one would want is some formal correctness guarantees, high performance. A question is whether this language is Rust or it is possible to design a better new language.

Because LLMs fuck it up near-constantly and I need to review it

This idea is already being taken to the next step in labs; why generate code?

When I run a game I don't care of the dev used C or whatever. Only programmers care about the syntactic representation.

I need the machine code/byte code patterns/geometric/color gradient data.

Eventually Python will be what you see on screen but no cPython interpreter program as we know it will be running

The model will have an internal awareness of the result to return without running an actual REPL

https://dev.to/zijianhuang/prompt-to-ai-generated-binary-is-...

Assuming you are thinking about software architecture and looking under the hood, you are likely to be reading much more code than before. Python is really nice on the eyes and you can easily get a good grasp of what the code is doing. Plus, it's dynamically but strongly typed, so what you see in the code is usually what you get.

I think the rule of thumb is to use the tool that is right for the job and that you are going to be able to understand the output.

So you have a chance to be able to read the absurdly barroque code AI produces.

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.

Great question. And I don’t think that Python, Ruby and PHP have a good answer. Scripting languages cater to human weaknesses. The 10-100x perf cost was never really worth it but now it’s impossible to justify.

Python is rather a UI for human logic comprehension. A mathematical notation of logics. Not a code to drive computer.

And prompt does not replace that.

I have been wondering on a similar thing; am looking for feedback:

There are many existing, often mature, third-party software libraries or solutions that a new project could use but which hide the internals, including how the data is organized behind the scenes*. Vibe-coding for the specific project requirements, instead of using the pre-existing third-party libraries, is now becoming a feasible option. The latter may be simpler (no features beyond the actual need), more flexible (easier to add new needed features), and the data/model behind could be more accessible.

Looking for feedback on pros/cons and experiences along this.

* I care for the data as it is can be longer-lived than the code itself.

Thanks.

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'm still not sure. Would love thoguhts on this.. but in this new ai world we are in... is it better to go fullstack typescript? or go with proven mature frameworks? .net, ruby, django, etc? Seems TS is moving fast but maybe its time to not reach for the shiny object and stick with proven tech? or in 5 years will we regret it?

If you're using GenAI, you should go through the process of selecting an optimal tech stack for each solution, but also take into consideration that Claude and other services probably the most knowledge of python, javascript, and typescript with go, rust, java, and c# following closely behind. Consider what you're building and what elements of the tech stack is optimal for your problem-space.

I don't know rust at all and I've built three applications using it with Claude because it has speed and correctness built-in.

I use Typescript for 90% of the things I build. For web development I've used a number of tools, but mostly react, nextjs, or raw html/css/js. But if I were building an enterprise application I'd consider my team and whether opinionated (Angular) was optimal over flexible (React).

Each project should consider its own optimal tech stack.

The ideal language for AI coding:

1. Type safety as basic guard rails that LLM output is syntactically and schematically correct

2. Concise since you have to review a lot more code

3. Easy to debug / good observability since you can't rely on your understanding of the code. Something functional where you can observe the state at any moment would be ideal.

4. A very large set of public code examples across various domains so there's enough training data for the LLM to be proficient in that language

5. A large open source ecosystem of libraries to write less code and avoid the tendency for generated code to bloat

It's basically all the same things you look for in general. I think TypeScript scores high here but I'm curious if anyone knows of a language that fits these criteria better.

I assume this is why things like PyO3 are popping up? If so, sort of a fascinating way to compartmentalize new rust code into legacy .py code in lieu of a refactor, or at least, a way to do a staggered refactor and eat the elephant in bites :)

Devs still have to maintain this code, the Python devs can definitely get the LLM to write (some kind of) Rust, but when it goes wrong and you hit the wall with the LLM then they can will have to learn Rust which might take a while, this sounds like a bit of a project risk.

For me, whether it's AI or my own handcrafted artisanal code, the choice of language comes down to what has the least friction. This means I turn to vite/react for a lot of frontend requirements, and that the backend will be in nodejs or python, because those are easier for me to debug than writing an equivalent application in C++ or Rust.

The article applies to a narrow case of a totally green field application that's going to be completely vibecoded. This is the only case where you reasonably can be indifferent to what the language is, and so you can abandon familiar Python and go with unfamiliar Rust. (If you _are_ familiar with Rust, the point of the article is moot.)

This "fair weather development" approach feels very risky if that application is going to be exposed to any serious usage. There WILL be a situation when things break and the AI will be powerless to fix it (quickly) without breaking something else in a vicious loop. There WILL be a situation where things work fine and tests pass with 3 concurrent users but grind to a complete halt with 1000 because there is something O(N^2) deep in the code. And you NEED a human to save your day (which requires also proper architecture for that to be possible in the first place). If you don't plan for this, and just hope for the best, then you are building nothing more than a toy. And if you plan for this, then it matters again what the language is, and whether your team is proficient in it.

Or maybe I too old fashioned or too behind the state of the AI art...

For the utilities I write it is faster to iterate without having to compile. When I get to the point where I'm done adding changing features, and performance is an annoyance I can always ask the AI to "rewrite this in Go". (I've never gotten to that point.)

Because I can understand and edit that code by hand if I need to.

So I can fix it when it breaks. I don’t understand anyone shipping real code without human review.

Give it 2 years, the ‘Blame the AI ‘ incidents will increase. Like an unfaithful partner you’ll always return to it

https://arxiv.org/pdf/2508.09101

tldr 2% average point lost on Rust compared to python, gap vary by model, go has a better upper bound but opus had it 3% below python.

benchmark is a bit old but research on why is there, article is just vibes

1) python is one of the foremost trained upon languages

2) it's practically verbose, not technically

3) it resembles pseudocode

4) batteries included shortcuts a lot of work

all of these reasons are a boon for LLM work.

I stay for the libraries

This point only makes sense if you ship AI code without reviewing it. And if you're shipping AI code without reviewing it, you're going to run into much bigger problems than Python performance limitations.

Clojure is better. REPL + immutable defaults.

1) I still have to comprehend it.

2) The corpus for the sort of applications I build is likely larger for Python than it is for C++ and Rust. Bigger corpus == more training data == better generated code.

3) The bottleneck in the applications I run aren't in the execution of the code; they're in the database/network latency.

4) I don't get anything extra for pushing Rust or C++ over Python.

I dislike Go but I have to admit, it's a great language for AI generated code. Simple enough, it compiles quickly and it performs meh-well enough for most applications.

One of the reasons I dislike Go is because it's easy for most engineers to write really low grade code with it. But AI agents would probably not write the best code in any language anyway, so not much is lost.

you still need to look at the code oneday so id say c++ still would be a preferred target language even for ai. i know i hear a lot about rust but im still getting the idea its a niche language overall. i know people love it and point out its advantages, but sometimes good enough is good enough (i.e. c++)

Also easier to ship a binary like a cli

A somewhat contrarian/pessimistic view: The hardest thing in any future of LLM generated code is going to be the verification step, and especially types of verification that require humans which are going to be the most expensive.

Therefore the "best" language is going to be whatever makes it easiest for humans to detect bugs, bad design, or that the "wrong thing" has been developed.

The LLMs just churns out non-idiomatic slop in any language.

It doesn't matter if the 800-line if statement is able to use pattern matching.

There's been a lot of progress on making coding agents able to solve problems when they can easily evaluate in a closed loop, we desperately need something similar for controlling complexity and using relevant abstractions.

One thing to consider:

The (well-known) Sapir–Whorf hypothesis (if dont know it, look it uop) is often invoked for natural languages, but there’s a pretty direct analogue for programming languages: the language you "think in" during solving a problem biases which abstractions and idioms you reach for first.

If you force an LLM to first solve a problem in a highly abstract language (Lisp, APL, Prolog) and only then later translate that solution to C++ or Rust, you’re effectively changing the intermediate representation the model works in. That IR has very different "affordance", e.g.

- Lisp pushes you toward recursive tree/list processing, higher‑order functions and macro‑like decomposition. (some nice web frameworks were initially written in LISP, scheme, etc...)

- APL pushes you toward whole‑array transforms, point‑free pipelines and exploiting data parallelism. (banks are still using it because of perforance)

- Prolog pushes you toward facts/rules, constraint satisfaction, and backtracking search. (it is a very high abstraction but might suit LLMs very well)

OK, and when you then translate that program into C++/Rust/python, a lot of this bias leaks through. You often end up with:

Rule engines, constraint solvers, or table‑driven dispatch code when the starting point was Prolog.

Iterator/functor pipelines and EDSL‑like combinators when the starting point was Lisp.

Data‑parallel kernels and "vectorized" loops when the starting point was APL.

In principle, an LLM could generate those idioms directly in C++/Rust. In practice, however, models are heavily shaped by their training distribution and default prompts. If you just say "write in Rust", they tend to regress towards the most common patterns in the corpus (framework‑heavy, imperative, not very aggressively functional or data‑parallel), even when the language would support richer abstractions.

By inserting a "thinking" step in a different paradigm, you bias the search over solution space before you ever get to Rust/C++. That doesn’t magically make the code better, but it does change which regions of the design space the model explores.

Same would also be true for python which is already a multi-idiomatic language. So it might be a good idea to learn a portfolio of different languages and then try to tackle a problem with a specific language instead of automatically using python/go/rust because of performance.

Something to consider...

p.s. how would a problem be solved when the LLM would have to write it first in erlang? Is it the automatically distributed?

p.p.s. the "design pattern" of the GoF comes automatically to my mind, which might be a good hint to the LLM to use.

As always, "it depends."

I'm using coding tools to build a complex media-intensive application. The approach I'm taking is to build a _reference implementation_ in Python, which is in its design specifics, constrained to use patterns which transliterate into the actual deployment targets (iPadOS/MacOS/Web).

Why start with Python?

Because I can read it, reason about it, and run it, trivially, which are Good Things for the reference. I intend to have multiple targets; I'd rather relate them to a source of ground truth I am fluent in.

For what I'm doing, there is also a very rich set of prior art and existing libraries for doing various esoteric things—my spidey sense is that I'm benefiting from that. More examples, more discourse.

I'm out of the prediction business and won't say this is either a good model for every new project, or, one I will need in another N months/years.

But for the moment it sure feels like a sweet spot.

Ask me again though, after the reference goes gold and I actually take up the transliteration though... :)

Why use any general programming language at all? Just write it in assembly or binary. Skip the middleman bro

a) Python (and Node) comprise the largest training set for all the models, so you are likely to get way better accuracy, especially with local models

b) Python code is easier to introspect, and set up test harnesses around. And also extend in agentic frameworks

c) LLMs are really good at translation. I can give it python code and it can translate it into C.

Let's go through some of the arguments, in no particular order:

> Klabnik vibe-coded a new language in Rust, therefore Claude + Rust = Good.

I argue the inverse -- Rust, being an ML-family language, is well suited for parsing, and language design (I know! Shocker!). In more moderate translation -- ML-style languages are good for parsing, interpreting and compiling code. Claude is not the magic here -- ML is.

I would also add that I've had decent success vibe-coding+human-coding Haskell (contrary to the article). My experience is that if I can hand-write a rich set of types (blessed be IxMonad), I can throw Claude to fill in the blanks for the implementations. If I can design the data structures that make the program tick, bridging them is something Claude is awesome at. Again, no surprise -- it's intern-level work.

The key distinction between C, Zig and Rust is that Rust is designed around types. C and Zig are more memory-oriented -- they really see most of your program as flat memory and you can kind of shoehorn a little bit of data layout in that flat memory. While this offers a large amount flexibility, this philosophy isn't well suited for proving out correctness. But again -- this doesn't mean they don't have a spot.

When I was a junior at Tesla, I used to joke that senior staff had a VMs in their heads, because that's really how you analyze C programs -- you try to execute it in your head, with interesting inputs, but that's about it. Claude's head-VM is quite fuzzy and often makes errors.

With Rust, if you design your type system, you prevent yourself from making dumb mistakes. Swap out "yourself" with Claude here and it's the same story.

I've yet to see Claude design really nice type systems, fwiw.

But the point is -- Claude is the enemy of beauty and correctness -- it's up to the SWE to design a type-system which will prevent it from doing so. To be clear, I obsess over type-systems personally, but that's not the only way -- incredibly rich, comprehensive, huge type systems, fuzzing, Antithesis, proptesting are all things you can do to minimize the impact of slop, and those are all valid things to do.

---

> Code is not written by humans therefore it doesn't matter that you don't know Rust.

Wouldn't say this was explicitly stated, but I definitely smelt this undertone throughout the article. If you don't understand the language you're reading, how can you understand whether the code in front of you is correct or not? If you have a systems engineer sitting across you to clean your PRs up, you can pass that responsibility onto them, but what about when they give their two weeks?

If all you know is Python, chances are you're going to make better software in Python than in Rust. Stick an `Arc<Mutex<T>>` everywhere and chances are your code will be slower, as a matter of fact. Use If you want to learn Rust, please join us! But if all you're trying to do is vibe-code better code -- do it in the language you know and can actually debug when shit hits the fan.

---

> Anthropic C Compiler

It is impressive that Claude is awesome at taking existing code and rewriting it, this is certain, but I'd like to repeat the exact same rhetoric that many have given -- rewriting =/= original authorship. Awesome, we have a C compiler, but we already had one, and we just rewrote it? Seems like a little bit of wasted electricity.

To build on top of this, I am really happy that Bun is exploring Rust, and the Claude rewrite is truly impressive, but quite surprising at times, preserving strange anti-patterns (my name being said anti-pattern, teehee): https://github.com/oven-sh/bun/blob/ffa6ce211a0267161ae48b82.... It's hard to determine why Claude decided this -- I assume a really strict input prompt.

Do note that the current stage of that PR is much better than what it was at the state of that commit, and obviously Jarred isn't merging blind slop, but that is still human-driven by someone who has an understanding of their product.

My bet is actually that _rewrites_ of already-functioning, well-tested code, are likely to be more common as time progresses. I think that's what Claude is really awesome at, and I think Claude can often achieve 80-20 improvements through rewrites. Again, Claude alone will not be a silver bullet -- it won't generate data-oriented programs if the source material wasn't data-oriented. It won't optimize for cache coherency, if the source didn't, but moving from Python to Rust alone, with more-or-less the same code structure, you're likely to see improvements by virtue of common operations being memory-coherent and avoiding the GIL and so on.

---

> A C compiler written in Rust used to be a graduate thesis. It isn’t anymore.

Come on, this is disingenuous -- a simple C compiler is a 1-day long project. LLVM is a graduate thesis (and for good reason). Copy-pasting prior-art is academic dishonesty and Claude does a lot of that.

---

For transparency: I work with Noah.

EDIT: Wanted to add that not a single line of my comment was AI generated.

MISSION

FUCKING

ACCOMPLISHED

Perl might just be the most token efficient language