Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.by p4bl0
- > A shipped app, in a language nobody on the team knew
Great! Let's look back on this not too far in the future.
by vhantz - Yeah that's probably the only thing in the world that could be scarier than the electron app they were replacingby tnelsond4
- Why? Just job hop in 12-18 months, and that will be someone else's problem.by hirvi74
- 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.by djeastm
- 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...
by fxj - If I were a billionaire I would bought enough tokens to rewrite all public source code in F# or OCaml. :)by DeathArrow
- 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.
by jryio - 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.
by slashdev - > I called this out back in 2023
People have been "calling this out" for decades. Yet the most productive languages are still dynamic/strongly typed.
by Quitschquat - LLMs are amazing at golang. They seem to have great training in the k8s world, so writing custom controllers and operators takes minutes instead of days now.by linuxftw
- Agree 100%.
In the early days (before Claude Code mastered Rust,) I would get into this annoying pattern where Claude used different names for variables between tests and implementation, get confused, and then more times than not, would change the implementation to match the test (which was not written first--was not doing TDD and thus not the behavior I wanted.)
Static languages prevent that. I've had great success with Claude writing Rust, and I think it's an excellent language for LLMs not just for low level work, but for production-grade code of all types (I see rust as better aligned to compete with C++, Java, and C#.)
I've also had great success with Claude writing C#. Using Claude, I've built C#/.Net in Linux, deployed in Windows (via Visual Studio) with Claude Code running in WSL, and it's been a great experience all around.
by theYipster - Hard disagree, LLM's benefit from jacking in to the powerful nREPL dynamic languages in the Lisp family like Clojure, letting the agent manipulate the code in unprecedented ways.by arikrahman
- I find it does not do very well with go at all. I speculate that it's partly because go is going to be a language you find a lot of concurrent programming happening in. And sure enough, I find even the best claude is nearly useless at anything beyond copy-pasting examples out of the docs for goroutines.
My own experience with agents, I'd summarize as "the more the world model (which the LLM does not have) is not concretely represented by the text, the worse LLMs are at it."
So it's _great_ at HTML, CSS, markdown, and most cursory-inspected English. Good at javascript. OK at most languages. Then very bad at concurrent programming and closely-inspected English.
I also don't think your top-line conclusion is right at all. I'm quite the opposite opinion. The types "working out" does not actually give me hardly any conviction that the code actually works. And notably, LLMs seem good at making types work out (they're in the text!) but then still have code that's not actually at all right (for the world model).
I also find that types are not worth the often COPIOUS amounts of boilerplate that comes with them. Some of the worst code I've seen is using reflection to make something happen that would otherwise barely be metaprogramming in Python or Ruby.
But that's not to say types are useless. I just think rigorous static typing is not worth it. My current favorite way to program is Python, with an enthusiastic use of type hints, enforced by a good type checker (pyright). It gets you 99% of the benefits of traditional static typing, but you can also just tell the type checker to just look the other way for a moment if you're going to commit a dynamic typing.
- > The static vs dynamic language debate is decisively over and static has won
I wouldn't be so fast. It wasn't that long ago that the dynamic zealots were declaring victory. And before that the static zealots. And before that the dynamic zealots. Going back decades.
by jghn - 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.
by prepend - Strong typing has clearly won.
However, verbose typing is likely a negative for LLMs.
Algorithms written in "pseudo-code", aka a higher level language without type information, are far more readable to a human, and thus likely an LLM too.
In regards to control flow and general concept of what code is doing, types provide very little info over well named variables. In fact they often impair understanding by breaking up logic with implementation details.
I'd be curious to see some experiments around this, but I'd guess strongly typed languages where the type information is mostly hidden/inferred would have better generation accuracy from a semantics perspective (and likely worse from a type safety perspective, but can be corrected on compile/retry)
by adam_arthur - 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.
by luodaint - except this will go away. we will likely reach a point sooner rather than later (I think 2027) where it will be infeasible for humans to review the code. This will happen at startups first rather than big corps obviously and the engineers who design systems (dark factories) fully leaning into this will have a huge advantage. And yes there are exceptions to this and a play on the other side but the this is where the buck is going. at that point even Assembly becomes interesting.by bilater
- 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.
- Is it though? You assume the abstractions in Python are battle tested and you understand them. Usually people are relying on arbitrary libraries so unless you’re constraining libraries and those libraries have good review processes, it won’t be long until high level functions you’re reading are generated by LLMs to, so to review your LLMs use of other LLM generated functions you have to drop down a few levels and review at that level.
At some point that becomes less sustainable and looking at something with less abstraction assures you’re at least looking at a baseline source of truth, even if the volume is massive.
There’s going to be a whole world in the knowledge economy, not just software but everywhere, around validation and sign off of information that we’ve taken for granted as a cost prohibitive process where only the best options make it to high levels of function and maturity.
by Frost1x - > Python is, thus, clearly superior to other languages in terms of ease of review.
Do we get visual comparisons along with this bold claim?
by d0100 - AI-unrelated tangent, but I think it's pertinent to your comment.
I come from a heavily Python background, professionally. I spent the entire first decade-and-change of my career using almost exclusively Python; I know it about as well as a person reasonably can (outside of scientific and ML Python, which I just never got interested in, but that's beside the point).
A year and a half ago I got a job doing Rust. At a surface level, it's about as far as you can get from Python in terms of ease of readability, but after 18 months I'm really reconsidering some of my points of view on the matter.
"Explicit is better than implicit," for example, is something I still strongly agree with, but my definition of "explicit" has shifted a lot in the past year. Seeing which guarantees are provided through mandatory, explicit, strong typing saves a lot of time over tracking down guarantees in MRs while reviewing Python code. If I see a signature as an `Arc<dyn AudioInterface>`, for example, I immediately know that:
- It's thread-safe and memory-managed using reference counting (because `Arc` provides those guarantees);
- It's a type-erased object but is guaranteed to provide all the functionality from the `AudioInterface` trait (which, let's say, could be a supertrait of `AudioInput` and `AudioOutput` -- so it provides both of those);
- It uses runtime dispatching (since it's a `dyn` rather than a generic/`impl T` where `T: AudioInterface`)
I can choose to operate on it by reference with all the caveats that entails, or decide to either `Copy` or `Clone` it, depending on whether that's available for that type and if I can stomach the runtime cost.
All that to say -- Rust doesn't suck to review, relative to Python, in the long run. At first, yes, holy crap, it's such a huge cliff, and I can appreciate your point of view... but there's something to be said about having all this information surfaced as part of the language's syntax and semantics.
Python still has a special place in my heart, and I'd still use it over anything else if Rust isn't an option, but to echo a popular sentiment from other people who've made this migration, I don't know if I can go back to handwaving away whether or not something'll cause an allocation :)
by _verandaguy - > Python is, thus, clearly superior to other languages in terms of ease of review.
My experience has not been this. Dynamic languages make it harder to figure out things locally, unless someone has done the hard work of adding type hints.
by spprashant - It is harder to review Python:
1. Indentation is harder to see in diffs.
2. Explicit types give context, and if a project guidelines do not enforce type hints, as many don't, then it's hard to see what happens there.
3. Monkey patching and operator override -- I mostly stumbled upon that with "smart" types like ORM objects. Combined with 2. makes it very hard to review.
So I almost always had to download the change and review with IDE help. So it's not just code review anymore, it's manual testing.
by deepsun - > Code readability of Python isn't an advantage during write; it's an advantage while reviewing.
This is completely subjective though. I personally find that Python's lack of static types makes code very difficult to reason about. Yes, some devs will write decent comments and name things in a way that's easier to read, but most devs are lazy (myself included) and things get out of hand quickly.
But this is also a subjective opinion, and you could argue that I feel this way because I spend most of my time in TypeScript, Go, and Rust.
by throwforfeds - 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.
by rchowe - I think the only use cases are when it wraps low level C++ libs like ML libraries, and yes those are extremely difficult to reproduce
- i think the enforcing the type system is good with AI for a couple reasons: - (speculating) typed language have faster/better LSPs that can be used to more efficiently modify code with tool use. - when a human DOES need to step in and start investigating/modifying the code, the strong typing makes it much easier to get oriented within their spaghetticodeby parpfish
- 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.by dev360