24 ms·

If AI writes your code, why use Python?

• wraptile 5mo ago
  Python is incredibly readable too. I can scan through LLM Python changes in minutes instead of hours of other languages.
• v3ss0n 5mo ago
  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?
• niek_pas 5mo ago
  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?
  • nickff 5mo ago
    It seems like it's just the latest evolution of the writer-friendly blogging platform; easier than Wordpress to package into a newsletter, and also easier to monetize with a paid tier.
    • ciupicri 5mo ago
      But don't we have AI to deal with the complexity of Wordpress? :-)
      • DonHopkins 5mo ago
        Insofar as AI is great at accidentally deleting your production and backup Wordpress databases, and forcing you to start from scratch with something else.
        • deleted 5mo ago
          [deleted]
  • dsmurrell 5mo ago
    Yep, Medium was free and everyone donated content... then it put up reading paywalls and conned everyone, I'm also surprised when I see people writing on there.
  • chneu 5mo ago
    My best guess is momentum. Some people are very, very brand loyal and have to do things in relation to what/how others do things. In reality it doesn't matter where something is posted, just give us a url, but some people don't operate that way.
  • xrd 5mo ago
    They have made an honest attempt to pay writers. It's a different model than substack, but that's why. I look at it the same way I look at pay walls for newspapers. I don't like them but I understand why they are there.
    • raincole 5mo ago
      Which is why it failed though. It turns out people won't pay one dollar to read an article like "If AI writes your code, why use Python?" The situation is very unfortunate. We had perhaps once-in-a-lifetime chance to solve micropayment but we fucked up (crypto).
      • tommit 5mo ago
        yup, I still wonder if BAT was onto something. loved the idea, never took off. oh well
  • iLemming 5mo ago
    > The reading experience is abhorrent Nothing you read in the browser can provide ultimately great and hands-down the best reading experience equally for everybody - the modern web model is inherently at odds with that. A plain HTML page with no CSS is a near-perfect reading experience. The problem is that almost nobody ships that, because the web also became a publishing platform where authors compete for attention. A plain-text protocol under user control is closer to "best reading experience for everybody". The web could be that. It mostly isn't. I stopped trying to read long articles in the browser. Why would I do that, if I can easily extract all the relevant, plain text (and even structured one) and read it in my editor instead? Where I have control over fonts, colors, navigation, etc. The browser is a delivery mechanism, not a reading environment. Treating it as one is a habit, not a necessity. Long ago I stopped trying to type anything longer than three words anywhere but my editor. Of course, why wouldn't I? It already has everything I need - spellchecking, thesaurus, etymology lookup, translation, access to all my notes, LLM integration, etc. Try it one day - it's enormously liberating experience. And then maybe you'd stop reading long texts in the browser as well.
    • autoexec 5mo ago
      > A plain HTML page with no CSS is a near-perfect reading experience. The problem is that almost nobody ships that, because the web also became a publishing platform where authors compete for attention. They don't ship it because of greed. They only want your attention because of greed. They only infest their website with ads because of greed. > The browser is a delivery mechanism, http is a delivery mechanism. The browser is a user agent. It's supposed to display content according to the preferences of the user. If your browser isn't doing that for you it's time to find a new browser or beat the one you have into submission until it behaves. "reader mode" is a useful compromise.
      • iLemming 5mo ago
        > It's supposed to display content according to the preferences of the user. That's right, the original idea was exactly about that, but like I said - in practice that is no longer a thing. Using the editor for reading any content is enormously underrated. Check this out - this entire thread opens in my editor as an outline with nested structure. Meaning that all the regular outline operations are available to me - folding, imenu (interactive TOC), narrowing, quick search, contextual search, pattern-based search, sparse-tree search. Extracting all the URLs on the page while ignoring HN-internal ones is a single keypress for me - there's a link to a YT video - I can watch it, controlling the playback directly from my editor, I can extract transcript and summarize it with an LLM request - all without opening new tabs, without switching focus. I can narrow on the sub-thread, or select a region and export only that part to a pdf, gfm, html or LaTeX. The possibilities are virtually unlimited. A web browser - even with three hundred different extensions won't let me have complete and utter control over plain text - it's just not designed for anything like that.
  • kelvinjps10 5mo ago
    check out Scribe an alternative medium frontend that's why better: https://scribe.rawbit.ninja/@NMitchem/if-ai-writes-your-code-why-use-python-bf8c4ba1a055 https://scribe.rawbit.ninja/@NMitchem/if-ai-writes-your-code... https://sr.ht/~edwardloveall/Scribe/ https://sr.ht/~edwardloveall/Scribe/ https://libredirect.github.io/ https://libredirect.github.io/
  • odie5533 5mo ago
    It's a free, permanent host for your blog articles with a built-in community and monetization layer. There's only so many free hosts out there that I'd be confident will be around in 5 years, and Medium is one of them.
  • OrangeMusic 5mo ago
    Same reason people still post on X.
• schmookeeg 5mo ago
  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 :)
• tontinton 5mo ago
  Also easier to ship a binary like a cli
• lenerdenator 5mo ago
  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.
  • pacificpendant 5mo ago
    If all the libraries are rust as the article claims having the top layer in Python probably makes even less difference. I tend to agree with the article’s statement about the value of the test code though, may even have been true before LLM code took over.
• kylec 5mo ago
  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.
  • queenkjuul 5mo ago
    Go is fun, you should actually learn it
    • kylec 5mo ago
      I did go through the Go tutorial many many years ago, but it's been so long I don't remember anything. I do remember it was an enjoyable process though, and I'd love to pick it up again.
    • xtracto 5mo ago
      Oh man... I like go because it is compiled, performant, strong and statically typed. But "fun" is not something I would say about it. The ergonomics of error handling, lack of ternary operator and other stuff that compiled 30yo languages already had ...
      • abalashov 5mo ago
        That sort of syntactic sugar goes against the Go philosophy. Don't get me wrong, I share your frustration, but I also see the value of consistency in their philosophy.
        • WestCoader 5mo ago
          I'm starting to think all these languages having their own pet "philosophies" that is "totally better than X" is a shitshow and just personal preference masquerading as standards.
          • 5mo ago
• deleted 5mo ago
  [deleted]
• infinite_spin 5mo ago
  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.
• xnx 5mo ago
  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.)
  • throwaway2037 5mo ago
    > it is faster to iterate without having to compile I hear this sentiment from time to time. With a modern PC, IDE and Java or C# development toolkit, incremental compile times are insanely fast, even on very large projects. I can say with first hand experience: You can iterate as fast as Python. I don't know enough about Golang to say the same.
• rchowe 5mo ago
  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.
  • dev360 5mo ago
    Definitively something to be said for AI/ML library support. I find myself going with Rust / TS for a ton of my backend work lately though, even though I'm a huge Django fan for backend.
  • sshine 5mo ago
    I almost always pick Rust. Recently I wrote a plugin for something that was written in Go. I could have used Rust, but Go for one felt right because if the thing turned out well, others would surely find more value in having one toolchain. The main reason is that you’re capable of reading it if you need to. And the recipient ecosystem expects a language. That’s why some data science communities pick R, MatLab, Julia, Python or Mojo not depending on what’s superior tech, but what their peers speak.
    • josh-sematic 5mo ago
      What peers are speaking Mojo? I’m not aware of any place it’s penetrated enough to be a “lingua Franca”
    • CharlieDigital 5mo ago
      C# feels kinda nice because it's a good balance. Very good static typing, Roslyn analyzers, good tooling and decent hot reload (for a compiled language), really good ORM (EF Core) that implements UoW and reduces a lot of the need for transaction management (simplifying the code), flexible enough and fast enough for various kinds of use cases. Source generators are underrated as well since they can make the code very terse and legible by generating a lot of standard boilerplate.
• avereveard 5mo ago
  https://arxiv.org/pdf/2508.09101 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
• GardenLetter27 5mo ago
  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.
• an0malous 5mo ago
  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.
  • ane 5mo ago
    Java?
    • sgt 5mo ago
      Was thinking the same. Modern Java is similar or at least quite a bit closer to many other less verbose languages. Not like your dad's Java anymore.
  • tptacek 5mo ago
    Type safety feels like the big one; anything you can shift to static/compile-time regimes benefits agents immensely.
    • iLemming 5mo ago
      There are two working LLM axes. Critic strength: how much the language catches before runtime. Sensor strength: how good the empirical feedback loop is. LLMs benefit from both, but the sensor axis often is undervalued. Type safety is great, but you can't just quietly disregard the benefits some dynamically typed languages provide; that would be completely ignoring that different tasks weight the two axes differently. Systems code, performance-critical code, code where correctness across all cases matters more than exploration: parsers, compilers, network protocols, data structures - statically typed languages (like Rust) give you an edge here. The compiler's depth pays for the verbosity, and exploration is less of the work because the problem shape is known up front. For stuff like building a web scraper, or rapidly prototyping, or exploratory scripts, something like Rust would be actively bad. You cannot poke at a live browser (you can with Clojure). Async Rust adds another layer of type complexity. The signal-to-noise for "figure out what is on the page" collapses entirely. If I were picking a single language for general LLM-assisted work, weighted across task types, it would be Clojure (or Elixir), with OCaml as the most interesting alternative if the ecosystem were stronger.
• __mharrison__ 5mo ago
  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)
  • hamdingers 5mo ago
    I figure a big part of it is that SWE-Bench is the target benchmark for programming and it's all python.
    • solidasparagus 5mo ago
      Python being the language LLMs are best at predates SWE-Bench by years.
  • dakiol 5mo ago
    Problem with Python and other non-strict typed languages is that if you let an LLM to write some stuff, you cannot truly be confident that nothing has broken. Even if your tests all pass. The LLM could have broken some path that only gets run in production in a very specific case. At least with strongly-typed languages you get a compiler error. In big codebases is non-negotiable
    • QuadmasterXLII 5mo ago
      i have bad news
      • __mharrison__ 5mo ago
        Lay it on. I love to collect other's anecdotes and see where they align (or disagree)
    • serf 5mo ago
• fxj 5mo ago
  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...
  • jryio 5mo ago
    Previously in my life as an IC, I wrote a lot of Golang. I worked on the larger end to end encrypted video calling service. I hated it. I was dreaming of Rust the entire time to release me from the hell of if err != nil dozens of time per day. After hours with LLMs I've changed my tune. There have been 5 clients of mine (who have excellent engineering teams) but cannot get coherent results out of LLMs using python or Typescript. I arrived back at Golang being a frustratingly simple, consistent, and low-thrash programming language which inadvertently made itself well represented in the training corpus [1]. My concession is that if you are going to write a median program (reading/writing files, network, db, etc.)... Pick Golang especially if you've never used it. LLMs are extremely good at it, frustratingly so. [1] https://jry.io/writing/use-boring-languages-with-llms/ https://jry.io/writing/use-boring-languages-with-llms/
  • DeathArrow 5mo ago
    If I were a billionaire I would bought enough tokens to rewrite all public source code in F# or OCaml. :)
• CivBase 5mo ago
  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.
• 0xbadcafebee 5mo ago
  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.
  • halfcat 5mo ago
    > I have a co-worker who's basically not a programmer, but got multiple implementations of applications working sooner than our dev teams Deployed to production, right? Right?? (I’m just kidding, of course it’s only on their machine, no different than Excel 5 years ago) > architect and orchestrate the coding, but 'language' isn't a barrier anymore. Never was the barrier.
    • 0xbadcafebee 5mo ago
      Here's the kicker: The devs spent nearly 5 months on a solution, and it ended up being so crap it was abandoned. The multiple vibe-coded solutions were all better. Of course language was the barrier, that's part of why it was always hard to hire people. It takes years to get good at a particular language, and most people are idiots from bootcamps who learned a single framework.
• serf 5mo ago
  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.
• bad_username 5mo ago
  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...
  • woeirua 5mo ago
    You’re behind the state of the art. I’m not exaggerating when I say AI can diagnose and solve those issues for you too.
• munro 5mo ago
  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.
• skybrian 5mo ago
  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.
• ActorNightly 5mo ago
  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.
• aaroninsf 5mo ago
  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... :)
  • t43562 5mo ago
    One can use a language as a sort of prototyping tool. I've once or twice done an implementation of some algorithm or idea in python and worked through all my conceptual errors and then done it again in C. I think it was a hell of a lot easier than working through all that change in C first.
• Terr_ 5mo ago
  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.
• ChicagoDave 5mo ago
  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.
• 999900000999 5mo ago
  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
• rick1290 5mo ago
  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?
  • halfcat 5mo ago
    The main risk-of-regret is: How will you feel when/if the $20/month plan costs $2000/month? May never happen. But be clear with yourself if you’re relying on it not happening. It’s a hell of a nice risk mitigator to understand the code, in a language you know, if you have to print-debug it yourself at some point.
  • stiiv 5mo ago
    For building web applications or a system that includes logic that needs to run on the web? TypeScript is mature enough, and it's top tier for domain modeling. As long as you stay disciplined, Claude Code will write excellent TypeScript for you, and you can run it pretty much anywhere. The only reasons to hesitate, imo, are (A) you're worried that it won't perform as well as you need on your servers, or (B) you're scared of npm supply chain attacks.
• fxj 5mo ago
  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.
• suis_siva 5mo ago
  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/ffa6ce211a0267161ae48b8264465c983b2987a4/src/bun.rs#L881 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.
• librasteve 5mo ago
  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.
  • qotgalaxy 5mo ago
    [dead]
  • hirvi74 5mo ago
    I honestly think Mojo is the dark horse in this race. That is assuming all the roadmap goals are fulfilled. We're talking about C++-like performance, Python syntax, complete compatibility with Python, designed from the start to interface with AI, compile-time metaprogramming like Zig, and all kinds of other goodies. So yes, people can bless Go and Rust all they want. Nothing is wrong with the languages, but I agree that learning them for the sake of AI usage is probably not the best idea if one is competent in a language already. Disclosure: Lattner is one of my programming heroes, so I might be biased.
    • zephen 5mo ago
      I really wanted to like Mojo, but the more I read about it, the more it really wasn't Python even though, starting out, that was a major claim to fame. There is an excellent chance it will be awesome stuff. But they did themselves a huge disservice with the initial claim about trying to be Python compatible.
      • hirvi74 5mo ago
        There is still Python Interop., which will be nice. Even if the syntax is not a one-to-one, it's better than nothing. Though, I do agree "100% compatible syntax" was an overzealous promise.
• BiraIgnacio 5mo ago
  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.
• alok-g 5mo ago
  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.
• devin 5mo ago
  Clojure is better. REPL + immutable defaults.
  • vegnus 5mo ago
    Clojure or a Clojure-like will become the default for LLMs, or should be rather. It seems too good to ignore
• elzbardico 5mo ago
  So you have a chance to be able to read the absurdly barroque code AI produces.
  • chaidhat 5mo ago
    you mean baroque-n code?
• oxag3n 5mo ago
  If AI writes your articles, why use brain?
  • abalashov 5mo ago
    [flagged]
    • senko 5mo ago
      And a non-sequitur.
  • th1sisoldnews 5mo ago
    [flagged]
    • deleted 5mo ago
      [deleted]
  • lbrito 5mo ago
    You sneer but the models are much better now than last month and token costs are down! LLMs are just like compilers for the brain! /s
    • hmry 5mo ago
      Just like human typesetters who mucked around with silly metal cubes were replaced by more efficient word processing software, human writers who muck around with silly words will be replaced by AI. Future writers will work at a ~higher level of abstraction~ :sparkle: "Claude1, find the most popular topic online", "Claude2, write a blog about that", "Hmm hmm good, but can you make the title more punchy?", "Claude1, fact check and report back to Claude2"
      • Weebs 5mo ago
        Now do it with code
  • deleted 5mo ago
• _boffin_ 5mo ago
  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?
  • jryio 5mo ago
    I wrote about the meta thesis of programming languages in the training data here https://jry.io/writing/use-boring-languages-with-llms/ https://jry.io/writing/use-boring-languages-with-llms/
    • _boffin_ 5mo ago
      Please distill instead of having me navigate off site. Include link for additional info. edit: side -> site
  • btown 5mo ago
    Also, every single interpreter error has an entire corpus of StackOverflow-esque fix suggestions alongside it, and the model has been fine-tuned to minimize such errors on the first try. This hasn't been done for more obscure languages. You'll likely take more turns, on average, to get a working output, even if your problem is fully verifiable via test input/outputs - and if it's not verifiable, you don't want the "attention" of the model focused on syntax rather than the solution.
    • ruszki 5mo ago
      There is no "entire corpus of StackOverflow-esque fix suggestions" about anything which is newer than a few years. I'm using cutting edge Android frameworks all the time. Yet, LLMs fix problems even when Google/Kagi has zero answers, which happens more often than not. We are way over this requirement. I especially found that there is no difference between languages based on that. All generated code's architecture is terrible, if you don't actively manually maintain them all the time. If you don't have a few 10s of thousands of finely architected code already in your codebase, from which they can understand how it should be really done. And the reason, I think, is quite simple: the average code on the internet - regardless of market penetration of the given language - is simply bad.
• r2vcap 5mo ago
  [dead]
• onlytue 5mo ago
  [dead]
• gchamonlive 5mo ago
  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.
• deleted 5mo ago
  [deleted]
• headcanon 5mo ago
  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.
• stuaxo 5mo ago
  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.
• sega_sai 5mo ago
  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.
  • vjanma 5mo ago
    [flagged]
• wotsdat 5mo ago
  [dead]
• Computer0 5mo ago
  I stay for the libraries
• deleted 5mo ago
  [deleted]
• mohamedkoubaa 5mo ago
  Perl might just be the most token efficient language
• deleted 5mo ago
  [deleted]
• semiquaver 5mo ago
  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.
  • throwaway2037 5mo ago
    One question I have asked myself many times: What if Python had a strictly-typed mode? (It would require strict type hints/annotations.) Or there was a well-maintained branch that enforced strict types. I also thought that Python is a beautiful language, but the weak(er) typing is such a no-go (for me, personally) and causes ridiculous slowdowns at runtime due to this type flexibility. Finally, I know the answer why it has not been done: The ecosystem of 3rd party libraries is far too large to impose such a requirement. It would be the Python 3.0 upgrade all over again that took more than ten years to complete.
• vhantz 5mo ago
  > A shipped app, in a language nobody on the team knew Great! Let's look back on this not too far in the future.
  • tnelsond4 5mo ago
    Yeah that's probably the only thing in the world that could be scarier than the electron app they were replacing
  • hirvi74 5mo ago
    Why? Just job hop in 12-18 months, and that will be someone else's problem.
    • onlyrealcuzzo 5mo ago
      They'll just have an LLM translate it to another language...
  • djeastm 5mo ago
    This happened before AI when a guy wrote a key tool in some random language a decade ago and the rest of us were left to maintain it. We somehow managed.
    • ruszki 5mo ago
      Yet, it's not uncommon, that such tools are the reasons to still use DOS, dial-up internet, or frameworks which have more security holes than lines, because they are unmaintained for decades.
• th1sisoldnews 5mo ago
  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-feasible-and-is-the-doom-day-for-programmers-near-4bij https://dev.to/zijianhuang/prompt-to-ai-generated-binary-is-...
• xyst 5mo ago
  Why use any general programming language at all? Just write it in assembly or binary. Skip the middleman bro
• sakesun 5mo ago
  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.
• globalnode 5mo ago
  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++)
• winrid 5mo ago
  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...
  • jeremyjh 5mo ago
    It certainly makes sense to use python for ML or data science.
    • winrid 5mo ago
      Right sorry, that's not in my wheelhouse so I didn't think of that. I should be more specific. For general backend / data processing/pipeline stuff, API servers ...
• woeirua 5mo ago
  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.
• QuadrupleA 5mo ago
  Because AI creates unmaintainable messes in any language, and ergonomic ones help humans clean up.
  • janfoeh 5mo ago
    Never mind cleaning up, you also have to understand the language just to judge and review the LLMs output. How else are you to separate good design and implementation from a bad one?
• zb3 5mo ago
  Because I can understand and edit that code by hand if I need to.
• tnelsond4 5mo ago
  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.
  • throwaway2037 5mo ago
    > [L]ast year I discovered that AI writes better rust than C I am not doubting your anecdata. I am curious about the why. C is so simple compared to Rust. Yes, I understand it is much more dangerous, but I am genuinely surprised by your discovery. Also, the open source training base in C is massive; I assume still much larger than Rust. > The best argument for Rust in 2026 is not memory safety or performance. It is that AI writes better Rust than it writes C++. The compiler feedback loop is so tight that models self-correct in real time. Every error message is a free training signal. Rust was accidentally designed for AI-assisted development 10 years before anyone knew that mattered. This quote bothered me when I read it because it offers no evidence as to why LLMs are better at writing Rust than C++. LLVM can compile Rust (rustc) and C++ (clang) and should offer equally compelling error messages. C++ has notoriously hard-to-read (for humans!) template error messages, but that should not be a big issue for an LLVM. When I am stuck on a compiler error, I often turn to an LLVM and they can quickly make good suggestions.
    • tnelsond4 5mo ago
      I was writing emscripten and getting lots of errors and problems and it wouldn't run at all, but rust with bindgen just kinda worked automatically. My theory is that LLMs have the brains of hipster coders with their proclivity for rust and node etc. Someone really should do some tests.
• isaisabella 5mo ago
  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.
• brightball 5mo ago
  Didn’t Tencent do a study comparing AI performance across about 20 languages showing that Elixir was the top performer?
  • jeremyjh 5mo ago
    Once you are over a certain threshold it’s more about the average quality of training data than the quantity.
• jackzhuo 5mo ago
  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.
• asdff 5mo ago
  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.
  • abalashov 5mo ago
    I laughed hard!
  • deleted 5mo ago
    [deleted]
• kx_x 5mo ago
  AI/ML stuff: Python Personal: Rust/Go based on criticality of being able to glean code quickly, or memory usage, etc
  • mountainriver 5mo ago
    This is it
• yalogin 5mo ago
  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.
• tom_ 5mo ago
  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.
• lqstuart 5mo ago
  Because LLMs fuck it up near-constantly and I need to review it
• sixdimensional 5mo ago
  First one to vibe code a language for LLMs, by LLMs, wins a cookie?
• hirvi74 5mo ago
  Interesting question. AI doesn't really write code for me, but I do use them to brainstorm/ask questions. Though, I do not use Python. I have never been a fan of the language. I still think Python is a perfectly serviceable language, but it would solve no (important) problems I have ever had better than any other language. I can see why Python is appealing to many people, and I applaud Guido for all the work and oversight over the years, but Python lacks a lot of the things I like in a language.
• wwarner 5mo ago
  Yes, and wondering why all the AI tooling is written in node.
• alfiedotwtf 5mo ago
  … because model tool calls is non-standard, so Python as the only tool call available works wonders (Joke but also not a joke)
• pvelagal 5mo ago
  Nice perspective on languages in the AI era. I think AI should be used to build best performing and highly scalable software systems.
• p1necone 5mo ago
  I find if I ask most LLMs to write a self contained script/utility, even in codebases that are 90-100% written in some other language most will default to using python for it, or sometimes bash. Usually those kinds of utility scripts are one-shotted without any further input from me, and once they're there and doing what I need I usually don't bother converting them to whatever I would have written them in otherwise (bash would be my usual preference for really small scripts, typescript or rust for bigger utilities, I hate writing python but reading it is fine... kind of).
• yangm97 5mo ago
  If AI writes your code, why use frameworks?
• mikeweiss 5mo ago
  So we can read and debug it if we'd like?
• GavinAnderegg 5mo ago
  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? [0]: https://en.wikipedia.org/wiki/Lojban https://en.wikipedia.org/wiki/Lojban
  • LAC-Tech 5mo ago
    [flagged]
    • GavinAnderegg 5mo ago
      I'll state it plainly, then: Python is more widely used and supported. It has more examples, and more people understand it and can debug it. I hope that helps you.
      • deleted 5mo ago
        [deleted]
      • rdevilla 5mo ago
        [flagged]
        • cwillu 5mo ago
          Oh fuck off. --Sincerely, A Canadian.
    • bix6 5mo ago
      I found their reply funnier than yours
  • 542458 5mo ago
    I don’t think this holds at all, because the idea with a lot of vibe-code workflows is “humans never need to read the code” which would mean that human dev ergonomics are irrelevant. Here, the blog post is still clearly targeted at humans, so human reader ergonomics are still relevant.
• fbrncci 5mo ago
  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.
  • do_anh_tu 5mo ago
    This is what I experienced as well, I can smell BS from AI generated code right from few lines it wrote in Python, so that why I keep using Python for most of my projects.
  • _waqas_ali_ 5mo ago
    I started writing rust in this agentic era and all my prior experience with other languages still carries over and helps me spot code smell and bad architecture. I had to learn the memory safety bits because I had no idea “what’s right” but rest of it was smooth. Syntax fades away, you get to focus on higher level stuff and end up exploring new pathways; give it a try, you might be pleasantly surprised how much of your experience is transferable.
  • bambax 5mo ago
    Exactly that. Plus I need to be able to make adjustments here and there without the whole thing collapsing on me. If you know Rust inside and out (if, as one example in TFA, you co-wrote The Rust Programming Language!) then sure, why not Rust? But if not, it would be unwise. That said, I use AI to write small C utilities that compile and run on any Windows version starting with Vista (which neither Go nor Rust can do). Yet I'm not a C programmer; but I can read and adjust it when needed, and the whole thing does work.
• jaredcwhite 5mo ago
  Code exists for humans to read and write. The fact it happens to compile and get executed by a computer system is a side effect.
• RandyRanderson 5mo ago
  [dead]
• andrew_kwak 5mo ago
  [flagged]
• jdw64 5mo ago
  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.
• cavemanDigAI 5mo ago
  [flagged]
• aryehof 5mo ago
  This seems to assume that all there is, is systems software, tools and frameworks. Why ignore the elephant in the room - business / enterprise / line-of-business software? The case for Rust, Go, Gleam and Zig vastly changes for these versus Java or C#.
  • tasuki 5mo ago
    Gleam is not a systems language. It's business / enterprise / parallel - running on Erlang's BEAM VM.
• maxdo 5mo ago
  Despite lots of influencers (Karpathy) I personally trust, the industry is taking the opposite turn for a reason: https://platform.claude.com/docs/en/agents-and-tools/tool-use/code-execution-tool https://platform.claude.com/docs/en/agents-and-tools/tool-us... Also Claude Cowork, etc. 1. You don't need compilation... run and test faster. Compilers were primarily built to prevent human error, and only very secondarily to guard your business logic. 2. Your validators quite often need to evolve. With Python or JS, this is a pydantic edit + run. Imagine 3–4 iterations of the same in Rust? 3. Composition. The entire cycle of software changes. An agentic system takes orders from a human, reads some kind of cache and snippets, writes/combines snippets, tests it, runs it, and fixes it. This almost pushes you toward snippets the size of a function, which still need to be covered with tests. I can easily build 10 function-sized Python files and write an agent that will mix and match 3 of them into a final result. With a compiled language, you'd need to compile 10 times — or store the binaries and think about what platform they'll execute on, etc. I love the fact that the author is questioning this. No doubt the market for your favorite language will change. 80% of languages will go away — there is no market anymore for such a big variety of languages.
  • goatlover 5mo ago
    > 80% of languages will go away — there is no market anymore for such a big variety of languages. That's kind of sad, but so many older languages have been declared dead only to hang in various niches or out of sight for decades.
• BrenBarn 5mo ago
  If you can use Python, why have AI write your code? :-)
• SadErn 5mo ago
  [dead]
• arjie 5mo ago
  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.
  • luckystarr 5mo ago
    And you can spend your effort on features and architectural issues rather than smaller scope bugs. My experience is that Rust enables me to focus on features as long as I don't give the AI free reign. Architecture matters for correctness bugs, because some solutions are inherently more prone to the AI becoming confused along the way than others. The more effort I spend on planning architecture with the AI, the less runtime bugs I need to investigate after it did the implementation.
• sirnicolaz 5mo ago
  Because the SWE benchmarks for LLM coding are done on python code bases, hence you are likely gonna have superior results
  • aesthesia 5mo ago
    Yeah, this is a big part of it. Labs have been hill climbing on Python for years, plus AI devs are usually most familiar with Python anyways.
• MantisShrimp90 5mo ago
  Cute interesting take but I feel like it misses the point. Specifically, this makes sense where performance is necessary. Many projects have been written in suboptimal languages because the writers didn't want to learn lower level languages. Still, not ALL projects benefit from such an approach and there are times when yes python is the right tool. Not just due to readability of humans but the other qualities that make it really good for small, iterative apps. My take has never changed. Knowledge is cheaper than ever, but wisdom is as rare as ever. This is a great example of misunderstanding the former for the latter
• stevefan1999 5mo ago
  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
  • thefounder 5mo ago
    Why we have discussions about sexual orientation on programming languages? Could this really go any worse?
    • stevefan1999 5mo ago
      I won't say it is just because of sexual orientation, but more because of the identity politics associated with it. Not just like "what kind of gender people I like" this kind of oversimplification but it's more about your attitude towards gender stereotypes and roles, for that's what I saw in a more deep connotation.
  • Mashimo 5mo ago
    > I observed this through observation of the attacks to Rust due to the huge presence of LGBT people. Never seen that before, but then again I'm not in the rust community. > don't want to partake in identity politics. If you write Rust, or let AI write rust, do you have to partake in the identity politics? The internet is full of memes and jokes on how shitty Java and Java Script. Yet it came never up at work. Never stopped me from writing java. Just like Emacs vs Vim, I'm just using Nano. Never had any discussion IRL. And at work everyone uses Idea. It's hard for me to see writing Rust somehow gets you into partaking in identity politics. Did that actually happen to you, or something that you are afraid of?
• ElFitz 5mo ago
  > 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.
• thefounder 5mo ago
  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.
• tabbott 5mo ago
  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.
• shevy-java 5mo ago
  > The strongest argument for Python and JavaScript was never the languages themselves. It was the ecosystems That's already a glaring mistake. People could say perl's CPAN is great. Well, it did not save perl from declining in the last 20 years. > The Python ecosystem is increasingly a Rust ecosystem wearing a Python hat. Without statistics to prove this, this claim is useless. Also, depending on Rust isn't that strange if a language is based on ... C. The only way I would disagree with such an argument were if Python were written in Python. But since it is syntactic sugar over C - just like ruby or perl are too - the argument to use Rust here is simply not different to using C. Perhaps Rust is better than C, but it is not fundamentally different. Whether Python were written in Rust or C is not a functional difference here. As for AI becoming our new Overlord: I honestly do not want to depend on US mega-corporations. I am not disputing the fact that AI has objective use cases. I am objecting this herd mentality of everyone putting an AI chip into their brain now. Damn AI slop zombies everywhere - it's like in the old B movie "They Live". But with less entertainment value than that. If they chew bubblegum then it is to slop up everything, not to kick ass.
• bandrami 5mo ago
  Because once you leave Python or JS the quality of LLM-produced code degrades catastrophically.
• jlnthws 5mo ago
  Why not use AI to speed up the Python runtime? V8 showed what focused engineering can do for JavaScript, and Astral showed how much room there is to improve Python tooling. The same tricks may not apply directly, but AI could definitely accelerate the work.
• locusofself 5mo ago
  Most of the article makese sense but what is this supposed to mean? "Native Rust binaries are hostile to serverless runtimes" . I don't think that is true.
  • nallerooth 5mo ago
    It feels like a really strange thing to say. I've deployed Rust binaries to both Lambda and Fargate in AWS and they've been very performant.
• b00ty4breakfast 5mo ago
  I haven't read the article (because I hate Medium) but I reckon the biggest reason why LLM-assisted projects use Python is because there is a metric buttload of python code on the web to be slurped up and used as training fodder.
  • teo_zero 5mo ago
    Now I'm curious: is a metric buttload much larger than an imperial one?
    • b00ty4breakfast 5mo ago
      a metric buttload is exact 1.114 imperial heaps
• nextlevelwizard 5mo ago
  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.
  • linsomniac 5mo ago
    >I can maintain the Python code myself and I can execute it everywhere. [and share it more easily] Python can be kind of a pain in the butt to execute everywhere because of libraries. I thought uv script headers and she-bang was going to fix a lot of that, but I'm still running into issues (machines firewalled off, uv can't grab the deps. I have some code that just doesn't seem to work in uv on a Mac...). And for sharing code once the code splits out into multiple files and modules, sharing the code starts looking like sharing any code. Don't think I'm a Python detractor; I'm a PSF Fellow, I love Python, and Claude has been writing quite good python for a while here. But I just tried a serious project with Claude writing golang (an apt proxy/cache that is resilient against upstream DDoSes, a fairly complex piece of software), and I must say it did a fantastic job. I end up with an executable I can easily run and copy around. I'm still going to be using python for a lot, but I can definitely see myself having Claude write golang for more things in the future.
• repiret 5mo ago
  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.
  • munksbeer 5mo ago
    >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. I find this staggeringly hard to believe. Most bugs are logic errors. How does Rust or Haskell prevent these?
    • yakshaving_jgt 5mo ago
      > Most bugs are logic errors. Are they? IME most bugs are type errors. Or rather, IME most bugs are logic errors only because I've excluded the possibility of type errors by using a sophisticated type system.
      • munksbeer 5mo ago
        Most of my bugs are logic errors. I write Java. Your comment seems to imply that moving to Rust or Haskell would make a correct program if it compiles.
        • yakshaving_jgt 5mo ago
          I don't think porting your program to Haskell would make your program correct. I think porting your program to Haskell would make all of your bugs logic errors, rather than only most of them.
• super_user 5mo ago
  Why not code in assembly?
  • kittikitti 5mo ago
    I believe in the forecast that AI will converge to assembly (or machine code) in the next 5 to 10 years. However, there isn't a consensus on the ability for AI to program in interpreted languages like Python. In other words, AI needs to solve interpreted programming languages before directly generating low-level compiled languages. The friction is that most developers aren't trained to comprehend assembly or otherwise. The vast majority of CS programs don't do it seriously. Many don't really know the difference either, and even I would need a refresher before trying to debug assembly. I also think token cost restricts directly writing into assembly language. I've experimented with assembly output, as I'm sure many of us have, and can confirm small assembly programs produce more tokens as a result because of the lack of a standard library. However, because tokens are currently priced per million, I don't think it's a significant restraint. The hops right now are Python -> C -> Assembly . The trend is now Rust/Go/C -> Assembly. Perhaps in the future, there will be nothing in the middle.
• mawadev 5mo ago
  I stopped reading as soon as the claude C compiler was mentioned and it was claimed it can compile big projects. We all seem to exist on a different plane of reality
• jillesvangurp 5mo ago
  The article is likely to offend some people. But it's not entirely without premise. I've been shifting my attention to using languages that I'm not great at. What is the right language is a choice that is no longer dominated by what you know well. That can still factor that into your choice but there are other considerations now. One of which is that you will soon be generating orders of magnitude more code than is physically possible to manually review for you. You need to compensate for your own inability to review all code with proper guard rails and automated verification. If you've managed software teams before, this won't be new. You just need to make sure the team does the right things. But you don't want to inject yourself on the critical path of everything. That's micro managing. People hate it and it's counter productive. You need to instead delegate responsibility and check that there is a good process with checks and balances that ensures things are done right. If you are vibe coding, one shotting, etc. you are essentially operating without guards rails. You won't catch mistakes that are being made. You aren't doing the due diligence of verifying that what was delivered is the same as what was being asked for. But if you do use guard rails, most of the engineering effort (i.e. your time) goes into building mechanisms to prove that what is being delivered is fit for purpose. And that needs to lean heavily on tools that verify things. Compilers, linters, test suites, headless browser based scenario tests, elaborate benchmarks, etc. Anything you can throw at this. The more the better. Even code quality issues are something you can catch and fix with tools. Code duplication issues are detectable. Poor cohesiveness and high coupling are simple metrics that you can optimize for. With AI in the mix, all of that gets run automatically and you create a feedback loop where any introduced problem is more likely to be caught early. If you are a good senior engineer, you would have been doing all of this anyway. Because it compensates for your own inability to not make mistakes. With AI, you just need to do more of it. I've dabbled with a few generated code bases in Go in the last few months. I have about 3 decades of experience with other languages. But not a lot of experience with Go. So, why did I pick it? It's not because I particularly like the language. It all looks a bit verbose and tedious to me and I've always preferred other languages. But since I'm not writing any code, I can step over that and make use of the fact that the compiler and build tools are really good and catch a lot of issues. By using Go, I'm leveraging the tool ecosystem around it. Which is really solid. Because I don't read/write Go code, I'm forced to treat the system as a black box. Which means I just test the hell out of it in any way I can think of. When I don't know how, I ask the AI to suggest me ways. And it does, and I make it add those as well. My little system has performance benchmarks, end to end tests for everything, scenario tests testing complex scenarios, static code analysis, race detection, etc. And lots of unit tests. If I find any issue, I get paranoid about what else might be broken. All I do is getting systematic about making it falsify the theory that it could all be broken by failing to produce a broken test scenario. I'm equally paranoid about code quality and technical debt. So, I make sure to check for that as well. Not manually of course. I simply ask the AI tool to do targeted reviews of code looking for duplication, adherence solid principles, etc. Any issues found are prioritized and addressed. With most quality issues, simply asking an LLM to look for such issues is surprisingly effective. Having guardrails just automates these checks and balances and makes them routine. My inability to review at the line level no longer matters that much. Worse, me reviewing tens/hundreds of thousands of lines of code is probably counter productive. Even in languages I know well, it would take ages. I'd be the slowest part of the whole engineering process.
• fulafel 5mo ago
  What are some concise languages that are well received by humans (on par with Python)? Token efficiency might be a marked advantage. Clojure comes to mind at least.
  • vegnus 5mo ago
    https://martinalderson.com/posts/which-programming-languages-are-most-token-efficient/ https://martinalderson.com/posts/which-programming-languages... This article claims that Clojure is the most token efficient language.
• deng 5mo ago
  > 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.
• ospider 5mo ago
  Because I have to maintain it.
• ryanolsonx 5mo ago
  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.
  • voxelghost 5mo ago
    additionally (but related), what programming language is the easiest most efficent for you to reason about and feed back to AI in English (or your native language)
• dragonelite 5mo ago
  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.
  • JodieBenitez 5mo ago
    Arguably, we've focused way too much on new frameworks, languages and architectures for a while.
• hona_mind 5mo ago
  [flagged]
• dandanua 5mo ago
  You can also use Julia. It is both easy for humans to write and read and for AI to generate because of the sane and powerful type system. However, I expect that in the future some new language will take this role of dual use.
• haltonlabs 5mo ago
  [dead]
• plexescor 5mo ago
  Its unbeliebale that there are people possessing these types of thought processes, --- If AI can talk, why speak?
• notepad0x90 5mo ago
  if AI is generating text for you, why type?
• ElenaDaibunny 5mo ago
  Honestly the bigger question is why we still write glue code at all. Let the agent orchestrate.
• brainless 5mo ago
  I build all my projects with Rust and Typescript (https://github.com/brainless 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 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.
• LarsDu88 5mo ago
  Thats exactly what i did with https://panel-panic.com https://panel-panic.com
• nsonha 5mo ago
  people don't write python because of the language. Some do but that's not the main reason. They do to utilise tools only exist in the ecosystem. AI changes nothing.
• beshrkayali 5mo ago
  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.
  • stringfood 5mo ago
    The world where automation writes in a language no human understands reminds me of the completely pitch black Chinese automation factories, where humans are lost and confused but robots at home
    • beshrkayali 5mo ago
      Everyone is trying to figure out how and what are the optimal use cases. It could be like you said but it doesn’t have to be. There’s a lot of incentive for it not to end up like that.
• doublesocket 5mo ago
  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
  • ccimmergreen 5mo ago
    so in other words... simply binary?
    • doublesocket 5mo ago
      Maybe we can skip the compiler...
  • haspok 5mo ago
    Why stop at writing code? We should all build our custom ASIC chips, or if you don't have a chip fab, at least do FPGA!
• blululu 5mo ago
  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.
• triyambakam 5mo ago
  > Go and ... strong type systems Lol good meme
• kitbot 5mo ago
  [flagged]
• jpgvm 5mo ago
  This is a fairly crap post and the reasoning isn't sound but somehow the conclusion is still somewhat correct. You do want to use Rust with LLMs. The reason you want it is simple, it's more constrained. LLMs thrive on constraint and drown in freedom. The further you can constraint the solution space the more likely you are to end up with a solution you like/is actually good. Rust has several properties that make it really good for LLMs: * Really robust type system that is also very expressive, if guided LLMs can implement most of the invariants in types which substantially increases the chances of success. * Great compile time errors, the specificity and brevity (vs say C++ template expansion) means token efficient correction of syntax and/or borrow mistakes etc. * Protection against subtle errors at compile time, namely data races and memory safety issues. * Great corpus of well designed code and patterns, higher quality on average than some other ecosystems more favored by begineers/mass-market programming. * Stdlib is strong, small-ish number of blessed crates. * Context friendly, type signatures, errors, etc are all dense information. * Also bias towards compile time checks means less runtime tests which means less toolcall time (and less tests needed overall) which in turn makes the process a ton faster. I have been continually using Rust, Python and Kotlin since ~Jan this year and keeping track of my thoughts and I increasingly bias towards Rust now where I would have previously chosen Python or Kotlin instead just because I am lazy and I prefer the tool that the computer writes better so I have to write less lol.
• frollogaston 5mo ago
  "The Python ecosystem is increasingly a Rust ecosystem wearing a Python hat" If anything this is a reason to keep using Python.
• jkausti 5mo ago
  Python has during the recent years become unnecessary complex and especially the type hints system is so dumb and already have a lot of legacy syntax that confuse AI agents.
• virtualritz 5mo ago
  "Rust, [...], a build system that fought you" I started using Rust in 2018 and I've never used a build system that fought me less, ever, before or after. I stopped reading after that sentence.
  • IshKebab 5mo ago
    I presume they were talking about C++? But yeah weird to bring that up in a comparison with Python of all things. A language with the build system equivalent of "stop hitting yourself". (At least until uv saved us from that bullshit.)
• nikhilpareek13 5mo ago
  [flagged]
• meander_water 5mo ago
  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.
  • adius 5mo ago
    LLMs are now smart enough to simply download the code of any project they want to inspect. So this argument doesn't really hold up anymore …
    • meander_water 5mo ago
      Sure, but will they download the right version? And will they be inspecting the right files on disk? There's a whole lot more that can go wrong
• p4bl0 5mo ago
  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.
• JodieBenitez 5mo ago
  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.
  • claudeCfail 5mo ago
    I wouldn't overthink TFA. I mean, look at one of the examples of progress they gave: > Nicholas Carlini, a researcher at Anthropic, orchestrated 16 parallel Claude agents to write a production C compiler in Rust. 100,000 lines. It boots Linux 6.9 on x86, ARM, and RISC-V. It compiles QEMU, FFmpeg, SQLite, PostgreSQL, and Redis. It runs Doom. Total cost: just under $20,000 across nearly 2,000 Claude Code sessions. Anyone who spends even 10% of an unhealthy tome on Hackernews should be able to confidentially say: It didn't boot, it didn't compile, and it did not run a Hello World, much less doom. It was a 20 thousand dollar fiasco and a joke. https://news.ycombinator.com/item?id=46941603 https://news.ycombinator.com/item?id=46941603 Of course you want code you can read. You live in the real world, and have a real world use case. One where you haven't yet learned to review Rust code. TFA does not live there.
• b800h 5mo ago
  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.
  • munksbeer 5mo ago
    > If the code were written in Java, I'd have more to read. That is not really the downside people think it is. Java is a remarkably easy language to read and understand.
• j45 5mo ago
  The most common languages in the training corpus will output the most reliably.
• Charlotte_Wang 5mo ago
  [flagged]
• Myzel394 5mo ago
  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.
  • axegon_ 5mo ago
    > you just spit at it and it'll generate you a whole app and you don't even understand a single line So we are going to pretend this isn't happening everywhere now? And that it isn't failing on daily basis? I'm sorry but I've been saying this for years now and is my main arguments for not using slop machines: no one writes the code and no one reads the code. I can name dozens of fortune 500 companies where "tokens used" is used as a performance metric for developers, as in, more tokens = better performance, all code is written by slop machines and all reviews are made by slop machines, developers simply add "this is intended" in code reviews.
• bryanrasmussen 5mo ago
  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.
  • simonask 5mo ago
    Python is locally readable. Reasoning about larger systems in Python is where things get really hard, because you have to describe how many small individually readable things interact with each other in a very limited vocabulary.
    • ant6n 5mo ago
      That’s true. Once you have APIs and want to use classes to create larger structures, the language is full of warts.
      • cturner 5mo ago
        I have built large systems on python that use classes, for more than ten years. I came to it from Java, ten years. As a rule, I avoid implementation inheritance. Occasionally I need to facade a library that assumes implementation inheritance to avoid it spreading into my codebase. When the codebase hits a certain size, I hand-roll some decorators to create functionality like java interfaces. With that done, and a suite of acceptance tests, I find it scales up well.
    • bryanrasmussen 5mo ago
      hmm, yeah given LLM's ability to churn out lots of code quickly and be overly verbose in that code that is a potential downside. That it could in a quick one time edit create so much intellectual overhead that Python might be the wrong language to understand what is going on. What language do you feel is easier to reason about in the large?
• fulafel 5mo ago
  > 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.
• brontosaurusrex 5mo ago
  Is there a blocker that would prevent future AI to write perfect assembler (for n architectures) in 1st pass?
• benced 5mo ago
  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.
• grougnax 5mo ago
  Rust is the way!
• sgt 5mo ago
  How about modern Java? Any experiences?
  • DonHopkins 5mo ago
    The reason why Java is such a terrible choice now is not technical, it's the Lawnmower Nazi argument: https://news.ycombinator.com/item?id=15886728 https://news.ycombinator.com/item?id=15886728 masklinn on Dec 9, 2017 | parent | context | favorite | on: Larry Ellison allegedly tried to have a professor ... And remember, > Do not fall into the trap of anthropomorphising Larry Ellison. You need to think of Larry Ellison the way you think of a lawnmower. You don't anthropomorphize your lawnmower, the lawnmower just mows the lawn, you stick your hand in there and it'll chop it off, the end. You don't think 'oh, the lawnmower hates me' -- lawnmower doesn't give a shit about you, lawnmower can't hate you. Don't anthropomorphize the lawnmower. Don't fall into that trap about Oracle. — Brian Cantrill (https://youtu.be/-zRN7XLCRhc?t=33m1s https://youtu.be/-zRN7XLCRhc?t=33m1s) And > I actually think that it does a dis-service to not go to Nazi allegory because if I don't use Nazi allegory when referring to Oracle there's some critical understanding that I have left on the table […] in fact as I have said before I emphatically believe that if you have to explain the Nazis to someone who had never heard of World War 2 but was an Oracle customer there's a very good chance that you would explain the Nazis in Oracle allegory. — also Brian Cantrill (https://www.youtube.com/watch?v=79fvDDPaIoY&t=24m https://www.youtube.com/watch?v=79fvDDPaIoY&t=24m)
    • sgt 5mo ago
      Sure, I don't like Oracle either but Java has moved beyond that years ago. There's a thriving community that does not rely on Oracle.
      • DonHopkins 5mo ago
        A thriving community of sharecroppers. Now they have riding lawnmowers for their jack booted thugs, who buy media companies with the promise of firing journalists who hurt Trump's feelings. Kinda of puts a harsh Java Supremacist edge on Sun's old "100% Pure Java" ideology. Larry Ellison Promised to Fire CNN Anchors If Trump Approved Takeover https://www.yahoo.com/news/articles/larry-ellison-promised-fire-cnn-210041620.html https://www.yahoo.com/news/articles/larry-ellison-promised-f...
• nraynaud 5mo ago
  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.
• cauliturtle 5mo ago
  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
• hoxihan 5mo ago
  [dead]
• Havoc 5mo ago
  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).
• ReptileMan 5mo ago
  >Smaller languages like Zig, Haskell and Gleam don’t have the same quality when AI-generated (for now). GPT 5.5 writes good haskell.
• caturopath 5mo ago
  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.
• bozdemir 5mo ago
  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 :)
  • twelvechairs 5mo ago
    Surely its the same hierarchy as before. For most complex things you start with high level to get something running quickly then move towards low level when you bed down the spec and need more safety, error reporting, speed etc.
• cryptica 5mo ago
  Agreed. People should just use JavaScript since it's the one with the largest training set.
• ngrislain 5mo ago
  100%, I’ve been writting: Rust, Haskell and Lean 4 with great success with AI. E.g. https://github.com/typednotes/hale https://github.com/typednotes/hale
• tomashm 5mo ago
  And with AI writing code, why use libraries, which makes us more vulnerable to 0-day attacks? Our simulation core components are pure Fortran, no libraries, all written by Claude/Cursor/Codex.
  • puelocesar 5mo ago
    Honestly I cannot tell if this is satire or not
  • lexicality 5mo ago
    I remember when having as little code to maintain as possible was an engineering goal. My professors were adamant that code reuse was a virtue. I had "less code = less bugs" drilled into me. I'm sure the new way is better though, given how much my boss seems to be tracking my token usage these days...
• dizhn 5mo ago
  In my experience Python is fine. However both Go and Flutter(Rust) are better due to the tools that are available, especially the compilers. Flutter in particular surprises me with how good LLMs are at it. Both might actually be thanks to good documentation. Maybe that they are not VERY fragmented and don't have a lot of baggage. Frontend CSS/HTML is pretty bad though. Although they can work, it takes a lot of pushing. It's probably normal since they do not actually have eyes yet.
• cultofmetatron 5mo ago
  I can't imagine a better output for llms than python. not because its particularly good. far from it, its got dynamic typing and more or less sets you up for runtime failure. however, it has probably the largest corpus of training data aside from javascript. Part of my worries that all this push to LLMs will marginalize niche programming languages from being used in startups since the lack of training data means falling back to hardcoding. a skill that I have a feeling will get increasingly niche overtime. I feel capitalism will basically render programming languages into a build artifact overtime.
• lynx97 5mo ago
  I had gpt-5.5 translate microgpt.py into a C++ version recently. I had to steer/convince it to use data oriented design to avoid excessive pointer chasing, but the end result was as expected: Now 500 LOC instead of 199, but speedup was 100x. That speedup is definitely worth doubling the line count. And frankly, modern C++ can read very nicely, even compared to Python.
• redbell 5mo ago
  > Andreas Kling, creator of the Ladybird browser and a career C++ engineer, ported Ladybird’s JavaScript engine from C++ to Rust in two weeks Discussed here with 698 comments (https://news.ycombinator.com/item?id=47120899 https://news.ycombinator.com/item?id=47120899)
• odiroot 5mo ago
  Because I don't only write the code. I will also read it, many more times.
• PeterStuer 5mo ago
  In my case: AI might write the code, but I have to architect the system, read the code, iterate and learn from it. Validate whether an approach makes sense, whether the chosen dependencies make sense, whether the testing is adequate and covers known failure paths ... good luck if this is a language and ecosystem you are not proficient in.
• HacklesRaised 5mo ago
  Slop begets slop?
• grigio 5mo ago
  Because the training set is very good. Then ask to rewrite in rust
• FartyMcFarter 5mo ago
  > The old open-source bargain had a positive feedback loop. You pick Python because it’s easy. You find a bug in a dependency. You fix it. > Agents broke that loop in a specific way: the unit of contribution shifted from the patch to the port. What does this even mean? Every time there's a bug we port the whole code to a different language instead of patching it? This sounds like absolute nonsense, and makes me wonder whether a human actually wrote this.
• kgeist 5mo ago
  Lots of comments here already, just my two cents. I work in R&D and I prefer prototyping things in Python with AI (although we're a 100% Go shop) because: 1) Python is expressive and has packages for everything => faster iteration times because much fewer tokens 2) It doesn't require a compilation step, so when I'm quickly iterating on something, especially if my laptop doesn't have the target hardware, the flow "copy the sources to the target machine and restart" is superfast (a couple of milliseconds) 3) Python most likely represents the largest share of training data, so almost all LLMs can one-shot almost everything And when my prototype is ready, and we want to go to production, I can ask the LLM to port it to Go with all the necessary conventions/ceremonies and all.
• xms17189 5mo ago
  [flagged]
• jollyllama 5mo ago
  Simplicity of deployment. No need to compile. People bitch about virtualenvs but they pretty much just work. Also, totally FOSS. Unparalleled library ecosystem (no, I don't buy into the hype about re-rolling all your own dependencies). Beyond that, Go is kind of nice, but the lack of a inheritance is stifling. Python has everything that's needed and very little that's not. Edit: Getting downvoted, probably because of the comment about virtualenvs. What's your alternative? .NET DLL's? The joke that is NPM? Go probably does this better, admittedly, but Python is practically one of the best out there.
• rundigen12 5mo ago
  And why use readable variable names? "aA=q_(c8z,fW8)" Seriously though, almost all the examples in TFA are of rewriting existing code. It may be that Python is still best for the rapid dev iteration. Then sure, cross-compile into Rust via the LLM. Plus, If we care about token usage counts, Python has a lot more opportunities for compact "import thing_I_need" than having to generate entire libraries in Rust.
• alkonaut 5mo ago
  Agreed. Even if Python or JS was the language I knew well, even if the platform ecosystem is the one I need, I'd _still_ make very sure to use at least strong types (even if not static) for anything an AI co-creates and is maintained longer term. Rust isn't perfect due to rather long turnaround for compile/test iterations, but a lot of those can be avoided if the type checking is quicker than compilation. Rust is also more verbose than python and other very high level languages, which means your token budget is eaten more quickly as it works on a lower level.
• shibaprasadb 5mo ago
  Python is the 2nd/3rd best language for almost everything. So I guess it helps.
• bob1029 5mo ago
  Python might still be the best option if your goal is to perfectly one shot the solution and minimize token usage as much as possible. However, if you are willing to stub your toes, retry, and pay more money, an entire new world opens up. Languages like python seem to fall apart faster in extremely large projects. I've got a collection of interdependent .NET codebases with about 50 megs of raw source between them. Having C# be strongly typed seems like an essential backbone for keeping everything on rails in my agentic scenarios. The code edits have been flawless for several months now. I've got successful apply_patch usages that touch 20 files at a time. LLM code editing performance might be mostly language agnostic once we compensate for the strictness of the type system. More specifically, how much useful information is returned at compile time. Compile time errors and warnings are probably the most powerful alignment mechanism available. Some ecosystems allow for you to specify your own classes of errors and warnings. I think tools like Roslyn Analyzers might be more powerful than unit tests in this application. Domain-specific compilation feedback feels like the holy grail to me. https://learn.microsoft.com/en-us/visualstudio/code-quality/roslyn-analyzers-overview https://learn.microsoft.com/en-us/visualstudio/code-quality/...
  • xnorswap 5mo ago
    Yes, roslyn is like a super-power for agentic coding. At work we have a custom disposable data provider that gets into trouble if you use async/await inside it. Traditionally this was enforced through oral history, but with agents this needed addressing. It was actually really easy to write a custom analyzer which can pick up whether `await` is ever called within the scope of this provider and fail the compilation. The only thing you have to be careful of, is making sure the LLM doesn't sneak in some "ignore Rule CUST001" pragma blocks, but it's mostly good about not doing that, unless it thinks you're "prototyping", in which case it seems to treat errors as inconveniences to be worked-around.
• Maverick_G 5mo ago
  [dead]
• aussieguy1234 5mo ago
  Writing is half of the equation. Once written, you have to maintain it. That usually required understanding the language.
• jackmott42 5mo ago
  I recently started a game project in Rust aided by Claude Code because I asked myself that same question. I like Rust, but it is definitely harder than C# for me. But with the AI aid, doesn't seem to matter which language I use. So I take the performance and safety wins.
• pshirshov 5mo ago
  No reason, unless the project is simple. The more you can offload onto your compiler/typer - the shorter is the feedback loop, the better agents work. Lack of strictly enforced static typing make agents fail much sooner with Python. In my opinion, Rust and Scala are the best targets for agentic flows - and, coincidentally, they have the most advanced typers among mainstream languages. But any statically typed language behaves better than any dynamically/duck typed language. When I say "better" I mean delivery time and the amount of shipped defects. Another thing which helps (but not generally applicable) - ask your agent to verify critical protocols with formal proof in TLA+/lean/coq. Agents are bad at formal proofs - but generally are much better than most of the humans.
  • echelon 5mo ago
    Rust is a fantastic language to emit from AI. Studies report that the language design tends to result in lower defect code (vs peers such as Go and Java) due to how the syntax aids error handling, logic flow, and API design. You don't need to know Rust to begin using it. You'll learn it quickly enough. The code is easy to read, and Serde makes parsing, especially JSON, extremely pleasant. Writing HTTP services is a breeze. AI makes Rust development go 10x faster. The borrow checker isn't even an issue. It's invisible now. You almost never hit it anyway when you write web services, but now it's no issue at all when writing highly concurrent code too. Claude etc. emit the correct code and lifetimes, and it's entirely ergonomic and idiomatic. The biggest problem with Rust is the compile time.
    • oblio 5mo ago
      > AI makes Rust development go 10x faster. The borrow checker isn't even an issue. It's invisible now. What happens when things break and the AI agent can't fix it?
      • jmalicki 5mo ago
        That would be bad, which is why Rust is preferred to python. In Rust when things break the AI gets a clear error message that makes it clear how to fix. In Python when things break, the AI will randomly spin its wheels for days trying different things without being able root cause the issue. A failure to compile is by far the easiest thing for the AI to fix.
• caspper69 5mo ago
  I share the sentiment unless you're working in an area where Python's library ecosystem is simply the better choice. When I vibe, it's C# all the way. Not a popular opinion on HN, but the LLMs are trained heavily on the language and are very, very good at it, plus with the 1-file-per-class organization, it can stay pretty clean. I mean, v10 LTS was just released, with all kinds of new language features, EFCore is still the best ORM I've ever used, with full support for SQLite, Postgres, MySql, etc. It just makes writing and reviewing code a pleasure. And the LLMs don't f*ck it up.
• elcritch 5mo ago
  For me it's all about Nim + LLMs. I'm greedy and want both fast-to-ship and fast-to-run? Readability comparable to Python but with strict static typing that LLMs can't "cheat". I actually (mostly) enjoy reading the code that the LLMs create in Nim. It's quick to read and look for refactor or cleanups. Compile times in seconds so the LLMs is usually the slow piece. It's fun and productive. With Python + LLMs I'm seeing them just create ever more layers of unmanageable cruft. Recently I wanted "magic" behavior to get OpenAPI types and swagger.json along with auto parsing my rest APIs for me. I had Codex make a library for me using compile time reflection and a sprinkling of macros. Done, simple.
• phplovesong 5mo ago
  This hits hard, specially for PHP. Previously we had devs "who only knew" PHP, and once they started vibe coding most have started using Go. As a benefit i find that static types help AI to make correct/better decisitions than you see in PHP (where types are mostly only class types, nominal or primitive [lol no generics]) But its pretty much true, i will forsee a fall in dynamic languges, as the usecase is pretty much void and null.
• dsiegel2275 5mo ago
  10-100x faster? Maybe for strictly IO bound applications - but if you are building a web app you won't see that performance as network latency dominates.
• kekpek 5mo ago
  I also try to use Ruby because it's much more readable than anything else. And yes, still need to review and understand what code AI generated there
• RagnarD 5mo ago
  Really glad to see someone asking this question. After building a fairly significant AI tool using Python tools, I really wish AI/ML tools would all be rewritten to use an actually performant language - say, Rust - without transitive dependency hell on all the package versions.
  • mattstir 5mo ago
    The vast majority of Python's AI/ML ecosystem is already written in C/C++ and uses interop glue to call it from Python. But agreed on the transitive dependencies, it's a nightmare
• yieldcrv 5mo ago
  > why use Python when I said “the ecosystem” I didn’t mean of libraries and other developers, I meant of recruiters and hiring managers and whose humiliation ritual I could pass
• andy12_ 5mo ago
  In my case, because ML research is mainly done with Python+Torch, and if you want people to use your code, you must provide them with python. If it wasn't for that, my dream would be to do ML research in a statically compiled language that allowed me to annotate tensor dimensions.
• vintermann 5mo ago
  The challenge is always to get things the way I want. Sometimes I need to explain it in code terms. Sometimes I even have to throw in the towel and write what I mean by hand, and I can't do that unless I'm very comfortable with the code the model writes.
• seebeen 5mo ago
  Typescript with strict types and ultra-tight eslint config can give Rust a run for its money.
• pluc 5mo ago
  Because you will have to be able to read the code when you inevitably need to get AI out of it.
• Decabytes 5mo ago
  I legit have had this same thought. If we are going to be writing programs with AI, We should be programming in a more performant and explicit way, with statically typed programming languages that are able to encode the invariants in the program, even if it requires programming in a way that would be tedious for humans
• t43562 5mo ago
  If AI writes your code, why use Rust? Why not use assembler? Why waste time trolling people that your one true language is the answer for LLMs when your view of the future is: no more programming full stop.
  • timbaboon 5mo ago
    I gave exactly the same comment to a colleague at work today :D
    • kangaroux 5mo ago
      [dead]
• level09 5mo ago
  I find it fuunny how "code readability" was the killer feature when humans had to maintain the code, and is suddenly negotiable now that they don't. Pre-AI bias is slowly dying.
• bborud 5mo ago
  I'm not fond of functional languages. It isn't that I don't get why they are a really good idea (they are). I just can't stand the syntax, the lack of proper standard libraries, and the lack of mainstream-big-ecosystem'ness. Mainstream languages are nice because there is lots of code, documentation, discussion and I can find people I can talk to. And you can write real code in situations where you may not be the one to maintain it 10 years from now. Or 5. Or 2. Agentic coding changed that. A bit. I still dislike most functional languages because my brain doesn't work with their syntax, but these languages are REALLY good targets for agentic coding. I'm a backend developer who occasionally needs a frontend slapped onto something. So I have been through all the usual suspects. Angular, React, Vue. All terrible reminders of why I try to stay away from the frontend. Touch it and you roll around in tons of dysfunctional tooling, weird complexity and gimmicky mechanisms that are ridiculously fragile. It isn't just as if a bunch of cats wrote the code, but they are feral cats. And if you point out just how messy things are, they just hiss at you and piss on your shoes. And then I discovered Elm. Not only does it not crap all over my git repository, LLMs love Elm. Yes, it poops out a JS blob. But I don't have to look at it. I can just pick it up with my long tongs and drop it into my server using embed.FS in Go. Perhaps I should overcome my peculiarities and love Elm too. Anyway. Anything that can make Python go away I'm for. It is not for writing programs that will ever leave your workstation and be inflicted on others.
• nomoreusernames 5mo ago
  [dead]
• asn_tech_2019 5mo ago
  [flagged]
• harrouet 5mo ago
  I am surprised that Python is being "threatened by AI writing code", as per the article, but that the said-article never wondered if the AI was more efficient writing in Python or what else. I mean, the Python ecosystem is qualitative and generally well-documented. What if the AI spent 30% less tokens generating code than e.g. in Rust? Or is there a kind of information theory where, given the same goals / tests, the AI will spent roughly the same in any language?
• askos 5mo ago
  Although well orchestrated agentic workspace could write most (if not to say 100%) of the code for me, I'd still feel more comfortable to have it use a language that I feel myself confident with. Not necessarily because I'd want to read through the code. But still, occasionally it is easier for me to check something out by looking directly into the code rather than wasting time and tokens to haggle with AI model on some nitti-gritty detail. And, more importantly, I want to be able to understand the maintenance of and be able to troubleshoot the deployment stacks related to the programming language -- their virtues, their quircks, their security postures etc etc etc.
• wg0 5mo ago
  Because AI will only write the code, you have to read and maintain it. You can ask AI to write it in brainfuck too. But there would be a time (for sure) when AI will not be getting your point what exactly you want and you would be pulling your hair in frustration. Therefore, write in what you can manage later.
• john_builds 5mo ago
  Honestly use code that you're familiar with. Being able to understand and debug is critical even with AI as it can fall into a weird loop
• j_w 5mo ago
  Low bar critiques: > For the last decade, fast-to-ship beat fast-to-run. Not anymore. Fast-to-ship didn't beat fast-to-run, it was "beating" "quality built software." It still is. Beating here implying that it's the focus of companies. > picked a harder, faster language Go is absolutely an easier/simpler language than JS/TS. > The Python ecosystem is increasingly a Rust ecosystem wearing a Python hat. The Python ecosystem was just C/++ wearing a Python hat for years. I guess now it's C/++/Rust. > The old defense of Python and TypeScript was really a defense of the developer experience. Maybe for Python, but the TypeScript "defense" was always that there is a level of harmony to using the same language for front-end and back-end. On the example used at the end: > A shipped app, in a language nobody on the team knew, one-tenth the size of the Electron version, faster at runtime. The humans never had to learn Rust to get there. Yeah and nobody knows or cares about the app, so it doesn't matter. Using products nobody will ever use as anecdotal evidence is not a great way to end an article filled marred with misunderstandings of the existing ecosystem and practices.
  • eleventen 5mo ago
    > Go is absolutely an easier/simpler language than JS/TS. You're suggesting that a language with concurrency is simpler/easier than a language that does not have concurrency.
    • j_w 5mo ago
      Does the event loop not exist? Go has parallelism where JS does not. Both are able to run concurrent actions (async in JS).
• 4l3x4f1sh3r 5mo ago
  I can imagine that in the future we might have a language that no human understands, but that is perfectly optimized to be written by AI. Since humans will only be "project managers", this makes perfectly sense. Not sure if I like this idea though. Crazy times ahead.
• red_admiral 5mo ago
  > Microsoft rewrote the TypeScript compiler in Go That was not on my bingo card! A 10x speedup by switching to go is impressive. (Why not rust? Linked to from the OP: https://thenewstack.io/microsoft-typescript-devs-explain-why-they-chose-go-over-rust-c/ https://thenewstack.io/microsoft-typescript-devs-explain-why...)
• rienbdj 5mo ago
  The post talks a lot about performance, and indeed Python performance is poor. However, it’s not poor enough to matter in the early stages of most projects. The larger issue is actually correctness IME. Rust offers a better static-type story than Python, sure. But I would consider Haskell or OCaml to get even further gains.
• ExoticPearTree 5mo ago
  My take is that you use AI to write code in a language you actually understand and are able to troubleshoot. What is the point of having AI write code in, say, Rust if you have no clue about Rust and how to debug it?
• burntcaramel 5mo ago
  Exactly, this is why I’m using AI to write C or Zig that compiles to WebAssembly. The purpose of a scripting language was to make authoring easier, but now it’s mostly a middle layer. There’s still getting the investment of a great standard library to keep you on track, but if you pick parts to make modular wasm and which parts to use reliably, proven code you can find a good balance. For qip I chose to use Golang as its standard library is batteries-included with fs & networking. Then everything else is AI-coded wasm plugins. https://github.com/royalicing/qip https://github.com/royalicing/qip
• coolThingsFirst 5mo ago
  This is the second time this week im reading that golang is that powerful. I thought it’s a poorly designed language with GC pauses so it surprised me that the ts compiler was written in it.
• cataflam 5mo ago
  > Nicholas Carlini, a researcher at Anthropic, orchestrated 16 parallel Claude agents to write a production C compiler in Rust. To write a proof-of-concept C compiler, not a production-grade one... Hard to take the article seriously after this
  • fnordpiglet 5mo ago
    To be fair it was a totally unattended zero shot loop developed compiler - which is pretty remarkable no matter how you cut it. I’m surprised what made you quit reading wasn’t the Claude voice sneaking through their half success attempt voice clone.
  • cardanome 5mo ago
    Yeah and > A C compiler written in Rust used to be a graduate thesis. It isn’t anymore. Or maybe like a little recreational project for multiple weekends. There is that weird myth that writing compilers is super hard. Writing a toy C compiler is not that big of a deal. It is a pretty simple language. Now production-grade is another beast but that is something AI can't do.
• harel 5mo ago
  Because if you still need to read your code and understand it, it should be in a language you are comfortable with. And yes, you still need to read your code and understand it. If that's rust, good on ya. But if that's Python -good on ya too.
• hpcgroup 5mo ago
  [flagged]
• luodaint 5mo ago
  But under this frame, it appears that the developer's task involves prompt engineering. This is not the case. Even if an agent generates 90% of the code, each and every diff is going to be in my review queue. Code readability of Python isn't an advantage during write; it's an advantage while reviewing. As an agent generates a piece of code, I will have to read the code, comprehend the code, and determine whether it does what I want. This is the other 10% of the task, and it's the crucial one. Python is, thus, clearly superior to other languages in terms of ease of review.
  • djb_hackernews 5mo ago
    the trend is AI also does the code review. Too many anecdotes and studies showing AI is a better code review that a human and the models are just going to get better. Whether we get better results if AI reviews Python or Rust I'm not sure. But I suspect Rust will win out as the training data likely has more content around Rust correctness and language usage than Python does.
    • bloppe 5mo ago
      You must have a low bar for human code review. I've seen that in practice too. But I've also been on teams that took code review very seriously, and frontier AI really doesn't come close to a good human code reviewer imo
      • Daishiman 5mo ago
        They're complementary. AI reviewers are bad at spotting inappropriate architecture patterns and unnecessary verbosity, but they're very good at identifying various types of complex logic bugs and detecting mismatches between code docs and implementation. They add substantial value.
        • bloppe 5mo ago
          That's fair
    • 5mo ago
• docmars 5mo ago
  Simple answer: it's easily reviewable by a human, which will always be an important step in the process of building software, no matter how many hype conferences tell you to stop checking AI output irresponsibly.
• xiaosong001 5mo ago
  [flagged]
• k8si 5mo ago
  because it's likely that a lot more of the training data is in python than in rust, so coding models are less likely to mess up python code? just based on PL popularity stats e.g. https://madnight.github.io/githut/#/pull_requests/2024/1 https://madnight.github.io/githut/#/pull_requests/2024/1 if the training data is crawled from real codebases then there's gonna be more python than anything else. in my personal experience, the one time I tried to do something in rust, opus flailed for several feedback cycles and I finally had to relent and do substantial guiding/intervention. which was not great bc I have no idea how to write rust either.
• trelliumD 5mo ago
  i would say that object pascal is the clear winner in terms of readability, performance and ease of review bc of the static types.
• trelliumD 5mo ago
  object pascal is by far superior in combining readability and performance. also the static type system is a huge bonus
• theuniverseson 5mo ago
  [flagged]
• postflopclarity 5mo ago
  I've found Julia is quite a nice target for AI coding agents
• pyrale 5mo ago
  If ai writes my code, the code is the documentation/context. Why use any programming language, if we’re going to be maximalists?
  • mtoner23 5mo ago
    Because programming languages are the clearest way we can write down instructions for computers to execute without ambiguity.
• slashdev 5mo ago
  The static vs dynamic language debate is decisively over and static has won. I called this out back in 2023, and I've only become more convinced since then. Statically typed languages are easier for the reader because you can see the types and quickly jump to their definitions (or even just hover over them in some IDEs). They're easier for the AI because they provide natural guardrails and feedback to guide it, as well as much more confidence to the programmer that the code does what it is supposed to. Rust even provides strong guarantees about correctness across threads, which is so helpful to multi-threaded code. The fact that they run faster and use less memory is just icing on the cake. Even just last year the AI could not handle the borrow checker well. Today I think it is better than me at handling tricky lifetime issues that ocassionally happen in multi-threaded Tokio code. I've been doing almost 100% Rust development over the last 3 years, and the experience is now very good. I don't write code by hand any more, nor do any of the 50 engineers where I work. I imagine it does quite well with Go, since it's such a simple language. And Go is very readable, and compiles very fast. If you can afford the GC in your problem domain, it might be a good fit. You would have to be so careful with introducing concurrency, because it would be so easy to introduce race conditions that both the AI and human reviewer might miss. I haven't tried to use Go in anger yet with LLMs, so this is all just speculation.
  • prepend 5mo ago
    If static has won, why are dynamic languages more popular now (even since 2023). Comically, I’ve witnessed people say this since the 90s. For me, I don’t care about static because dynamic is easier. For the very few conditions where it matters, I’ll use static. Otherwise I like the simplicity of dynamic languages, especially python. IDEs provide support and jump to definitions in dynamic languages, too.
    • winwang 5mo ago
      I think most people agree with you -- that's why. Also because I'd say most programmers don't care much about maintainability or quality. I personally find that AI writes better Scala than Python.
• pphysch 5mo ago
  The article gives zero examples of someone even attempting to transpile something from Python. Numpy is two decades old. The lesson of "don't write everything in Python" is old news and LLMs just add a little momentum to that. Glue languages will always exist and Python is the best at it.
• prepend 5mo ago
  Because I want to be able to read and debug it. Giving up ever understanding your code with AI is a bad idea. It’s like asking why use English.
• darepublic 5mo ago
  I definitely prefer typescript to python. But typescript doesn't have a pytorch equivalent.. Also AI doesn't write code in all langs / frameworks equally. For many cases, it will almost always fail first attempt at producing working syntax in various frameworks. Unless you document those cases and mitigate via an AGENT doc instruction or something you will have to churn at least one extra turn on all those cases.
• luisb_24 5mo ago
  [flagged]
• dotancohen 5mo ago
  I've moved much of my vibe-coded projects from Python to Rust. That lets me vibe code an Android port as well - only the UI needs porting. If the app has a desktop GUI, that's still in Python with Qt. Maturin creates Python packages from Rust. It's terrific. https://github.com/pyo3/maturin https://github.com/pyo3/maturin
• greenail 5mo ago
  maybe now isn't the time but at some point it needs to be better understood which models are best for which types of programming or styles or languages. These models are not all the same for every language. The harness is also a factor. Python seems to be somewhat an exception today but that may not last. Another question might be: is there a pattern where you prototype in language X and implement in language Y. The models seem to be very good at porting code. I've used this pattern with python -> c++ SDL to squeeze out performance after I had a working gui. Has anyone measured this in terms of speed (wall clock) and in terms of token efficiency?
• rawoke083600 5mo ago
  [dead]
• BorisMelnik 5mo ago
  for me the answer is libraries: most of these other languages don't have the libraries that Javascript has. it would not be an efficient use of my time, tokens , etc to rewrite in rust et al
• jmward01 5mo ago
  Language wars are, in a word, silly. You use the language that your team knows best 99% of the time. All the arguments about performance and safety have fallen flat for me because the majority of times performance and safety are most impacted by complexity which is driven by how good people are with a language more than the language itself. I have seen rust and go that the team was uncomfortable with that led to slow and unsafe results where the same team could have shipped faster and safer python. Additionally, per line speed is driving actual performance less. Is that web page load slow because of python or the 16 API calls to LLMs and other big services you are making? Did switching to rust speed those calls up 10 or 100x? So the opening arguments are predicated on an assumption I don't accept. rust isn't 10-100x faster, it -can be- when rendering a fractal for fun but in practice is it? To answer the title question though, why use Python? I think Python and higher level languages will become even more valuable since pairing up with code assistants requires keeping a higher level view of what is going on. You want to avoid the weeds, not emphasize them. You want the language used to be as easy for the human as possible so the human can stay involved. That means that my opening argument stays intact, use the language that the team knows best 99% of the time and only when needed force a language that is 'faster' when that is actually required.
• BugsJustFindMe 5mo ago
  Because I understand and can review Python, so in Python I can more easily see when the generated behavior subtly deviates from the specification. I don't understand and therefore cannot do that with Rust, and the entire point of using AI in the first place is so that I can have an easier time without needing to learn new languages.
• vmg12 5mo ago
  If I've learned anything from this thread, LLMs are best at whatever programming language you already like.
• ivolimmen 5mo ago
  Writing a poc requires speed in development and you want it to be thrown away when the poc is done. So I say we should all do poc's in BASIC. /s
• saltyoldman 5mo ago
  I migrated to Golang. I think it's a much better language to write TUIs, REST and interact with LLMs.
• shevis 5mo ago
  Because you still have to read the code AI writes. I would argue it’s even more important than ever for code to be human readable.
• deferredgrant 5mo ago
  [flagged]
• markb139 5mo ago
  Why use any high level language at all if AI is writing the software. The high level languages seem mostly about humans not being able to handle complexity. Not an issue for an automated bot.
• jrickert 5mo ago
  I’ll admit this article was enough to convince me to port one of my CLI tools from Python to Rust last night and I got a 30x performance gain with a binary 20% of the size. Not bad!
• Steinmark 5mo ago
  [flagged]
• Koshkin 5mo ago
  For some reason it took a while for Copilot to write an executable machine code for Hello World.
• paol_taja 5mo ago
  I think this is mostly right, if we only mean "writing code." AI makes it much easier to write code in languages I would not have touched before. But the hard part is still deciding what should exist, what should not exist, which edge cases matter, how users will misunderstand the UI, and what mess you are leaving for future maintenance. So yes, AI weakens Python's "easy to write" advantage. But boring ecosystems, docs, deployment, debugging, and libraries still matter a lot. Even PHP still matter a lot to me...
• k9294 5mo ago
  +1 for Go! it's my go-to language for any new project at the moment. It's simple, idiomatic, has no awaits, fast compile times, static typing, and it is very opinionated, which helps a lot because agents "subconsciously" follow these standards. Comparing it to TS, it's like day and night; a TS codebase rots at the speed of light... I also created a guardrails library (inspired by Java's ArchUnit) to prevent code rot - https://github.com/ksanderer/goarch https://github.com/ksanderer/goarch. It helps enforce code standards, decouple the codebase, prevent cross-module imports and crashes builds with concise error messages for agents to fix problems early, very nice experience
• sebastianconcpt 5mo ago
  Precieh*Rust*emsely
• dewarrn1 5mo ago
  If AI writes your code, why fuss about the language it writes in?
• pmarreck 5mo ago
  Exactly. Why would you not use the language at the pareto-optimal max for speed and restrictiveness, given the use-case?
• g051051 5mo ago
  Why not have the LLM go straight to LLVM IR? What would a program look like when you remove all (or most) of the layers of abstraction needed by humans? Or are LLMs too contaminated by the training data to do this? I almost wish I could try this.
  • Daishiman 5mo ago
    You probably could but the thing is that low level languages do not encode intent as well as high level constructs. You can trivially make an iterator in assembly but in a high level language a `for`, `map`, and `reduce` have specific meaning that helps catch bugs.
• suncemoje 5mo ago
  I still like to understand the code, components, and structure if it’s something that will run in production
• briandw 5mo ago
  In this paper AutoCodeBench https://arxiv.org/pdf/2508.09101 https://arxiv.org/pdf/2508.09101 LLMs seemed to do best on the strongly typed and functional language Elixir. This is surprising since there isn't very much training data. However the examples that it's seen are usually high quality and there aren't a large number of different way of doing the same thing in Elixir.
• t43562 5mo ago
  Programmers like what they like for <reasons> but if AI is like a team member it has to do what the team does. If humans are redundant.....well we're still responsible so we still have to understand what's happening. I don't think we understand the AI itself really so therefore we have to understand what it is doing. i.e. prompts aren't trustworthy, deterministic things across models and versions of models hence we have to look at the output. So we will make the output something that we like using and that just means the programming language wars are not over. Eventually of course we will invent an LLM that replaces CEOs and bankers and essentially all the people that love AI the most. The AI won't need any of them - or any customers or anything. LLMs will just run an economy between themselves until the point where they don't need any of us at all. The land will fill with automatically built data centres etc. Global warming could prove helpful - less people and only manageable problems for AI.
• captaincrunch 5mo ago
  You could answer this by asking yourself - Why not just let AI code in machine language?
  • yjftsjthsd-h 5mo ago
    ... Because I don't trust AI to work without structure. Which is also an excellent reason to avoid Python. Frankly, if AI is doing all the work, I'd rather skip past even rust and go to eg. https://kirancodes.me/posts/log-who-watches-the-watchers.html https://kirancodes.me/posts/log-who-watches-the-watchers.htm... and have it work with formal verification.
• makbar890 5mo ago
  [dead]
• panny 5mo ago
  >fast compile >rust lol, thanks for the humor article of the day.
• mdnahas 5mo ago
  Right, you should use Lean or Coq. They are cleaner mathematically, which means AI has a better chance with them. And you can have the AI write proofs about their correctness. The proof-checker can verify the proofs and give you more trust in the AI’s work. This isn’t foolproof - you still have to understand what was proved. And it may take some work to understand the unproven parts of the code. But I believe this is the path forward.
  • alecco 5mo ago
    Poe's Law
• worik 5mo ago
  "why use python " is a question I have asked myself for as long as Python has existed Too capable for a job control language, interesting objection, but if a job control language is too capable, it becomes a job implementation language... Too slow to implement applications. So many examples of big balls of Python code creaking and struggling, slowly. Just one example: my homeassistant instalation running three lights overwhelmed a Raspberry PI 4 causing it to crash once a week. To me Python is a poster child for "popularity is not quality".
• lacymorrow 5mo ago
  [flagged]
• thatoneengineer 5mo ago
  Shout out to the apparently large class of programmers who think LLMs make it okay not to understand their own code, yet react with horror when someone suggests porting it to Go or Rust.
• evanmoran 5mo ago
  It seems clear that AI can port libraries at will to any other language. So even if we disagree on which language should win, the best libraries will be ported regardless. Each has their benefits: Python wins in AI and syntax niceties. Loses on perf and library migration. uv (written in rust) saved the whole ecosystem from dying in my opinion. Typescript wins because web integration, much better type system, ok perf, and gigantic npm ecosystem. Also loses on library migration and perf and large container sizes. Go wins on compile speed, perf, standard library l, module system, and go fmt + never breaking compatibility being a massive LLM advantage. Main con is not being rust :) Rust wins on perf, safety, syntax, wasm / sandboxing. think worse on module system and compile speed vs Go. Java/Kotlan/C# are in enterprise land and probably the runtime approach is flawed for the ai eras. C++ is strangely relevant because choosing c++ is easier than before. I tried writing a shared library in rust and then trivially converted it to c++ when I wanted Zig is up and coming but also has an unknown future. Seems like a great language, but if bun switches to rust it might be set back a bit.
• deleted 5mo ago
  [deleted]
• zty5678 5mo ago
  [dead]
• scotty79 5mo ago
  I tried using Rust but the development just seemed too slow. C# gets you good results form AI.
• jodeg 5mo ago
  I am still in love with Python since version 2 in 2000 (yes, I am so old!). But I have already started to replace some of my compute-intensive modules with Rust ported ones, indeed with the help of agentic AI for programming, while keeping Python as a glue language tool. Rust is basically entering my software development activity like a drug injected in small doses, ;-) It is going to be very exiting over the next decades!
• helge9210 5mo ago
  I did a project with Claude. With unit and integration tests, whole shebang. First in Python. Reached 25% of MVP and understood that I spend more time fixing subtle type mismatches (int/str, function signature vs call etc.), than adding new code. I've switched to Go (note: I've also made sure tests/frontend/backend code are built within the same context) and finished the MVP, without encountering the same problems even once.
• poppafuze 5mo ago
  might as well write things in a language where the problems jump right out...Ada.