Rust, Elixir, and Go are the way to go for LLMs in my testing and experience, for this and other reasons
Here’s some of the reasons it’s so good with Elixir:
Use boring languages with LLMs
41–50 of 180 posts
Re: Use boring languages with LLMs
#42This is an interesting idea, but I'd want to see something solid before acting on it. From what I can tell, LLMs know/use patterns above the syntax and idioms of specific languages and the syntax and idioms of specific languages and how to apply the former to the latter. The bottleneck isn't what languages the LLM can handle, but what I can handle coming out of the LLM. The general advice, then, is to use the languag…
Yeah, probably that last point would depend on how you actually use LLMs, if you don't review the code at all, not even glancing on it (aka "vibe coding") then it probably doesn't matter so much, yolo and deploy.
But for the rest of us who aren't vibe coding, but pairing with LLMs and actively steer them, correct things and iterate while reviewing the code, design and architecture deeply then yes, I agree a lot, matters more that you're familiar with the language than the LLM, they can pick up new programming languages in a message so doesn't really matter, knowledge seems to come from programming, not locked into a specific language's syntax.
Re: Use boring languages with LLMs
#43I program in two languages: Swift (my main language), for client work, and PHP, for backend work. It’s overwhelmingly Swift. In the last year or so, I have been using LLMs, to assist my work, with generally, excellent results. I have noticed that the LLM delivers much better PHP, than Swift. I seldom need to rewrite or correct, the PHP code I get from it, and am constantly correcting the Swift. Part of the reason, ma…
I think it's pretty simple - there's just so much more open source PHP code out there in the LLM's training dataset. Swift has been around for much less, and most Swift is closed-source - not that many years have passed since Swift has been able to run on non-Apple platforms, too.
PHP changed a lot since its early days. To the point where anything old would be considered bad practice by contemporary ecosystem point of view. So duration is not all. Comparatively, C seems to have stick to the same idiom all the way. That's not to praise C style form here to be clear, which is ridiculously obfuscating and feeling like pointless collection of linguistic awkward atrocities. But at least it's consistent in doing it.
Re: Use boring languages with LLMs
#44Earlier quoted context omitted.
I think it's pretty simple - there's just so much more open source PHP code out there in the LLM's training dataset. Swift has been around for much less, and most Swift is closed-source - not that many years have passed since Swift has been able to run on non-Apple platforms, too.
I would also bet that 90% of Swift training data is UI code. And UI code quality tends to be technically pretty crummy/low-discipline. Your UI code doesn't need much consideration around data races, for example.
You wouldn't know that, if you looked at the UI code the LLM gives me. It loves threads; often mixing GCD and async/await, in one function.
A lot of the code I need to tear out, looks like that.
Most of the code I write is UI. It's actually fairly intense work, but relies on the underlying SDK, rather than language tricks.
I find the UIKit code I get, is a lot more robust and performant, than the SwiftUI code.
Re: Use boring languages with LLMs
#45Try to apply first principles to LLM coding:
* Chances are that fewer people (maybe even none) will look at the code when it's LLM-generated
* Amount of code being written isn't all that critical anymore
* Keeping patches small isn't that big of a deal anymore (because it's now the LLM's job to maintain it, not the human's)
All of this implies: boilerplate isn't a good reason to avoid a language anymore. (I hate this conclusion, because I hate boilerplate).
Then the question is: what kind of language can you use that buys safety with boilerplate? Probably a statically typed one, possibly with lots of asserts... Eiffel? I don't know if there's enough Eiffel code around the Internet to train LLMs, so maybe a more popular one would be better.
Maybe Java or C#? Haskell? OCaml?
The article suggests golang, and I think there are use cases where golang would be a good candidate.
It would be quite interesting to run an experiment: give separate instances of the same LLM coding agent the task to implement a specific application, and use different languages. Then compare quality, code size, runtime performance and token cost. Ideal would be a multi-stage development that better simulates a real development workflow (bug reports and new feature requests come in over time).
Re: Use boring languages with LLMs
#46Also use boring languages without LLMs
Re: Use boring languages with LLMs
#47I program in two languages: Swift (my main language), for client work, and PHP, for backend work. It’s overwhelmingly Swift. In the last year or so, I have been using LLMs, to assist my work, with generally, excellent results. I have noticed that the LLM delivers much better PHP, than Swift. I seldom need to rewrite or correct, the PHP code I get from it, and am constantly correcting the Swift. Part of the reason, ma…
> Part of the reason, may be that I am a much better Swift programmer, than PHP programmer Hard not to think that's a major part of it. IME you make loads more corrections in languages you're more opinionated about (and opinionated usually follows more experience & confidence). I correct AI Python all the time. When it cranks out TypeScript I just check it works.
Yes and no. I have been working with PHP for over 25 years, but I've never loved the language. It's always been a "necessary evil." I know it fairly well. I've only been writing Swift for half that time, but I like the language, and play with it more.
I feel that the reason posited by another poster is more likely. There's a ton of mature, well-written, shipping, PHP out there, due to the open nature of most PHP, as opposed to Swift; where the more robust and mature implementation is likely behind proprietary walls. Most of the public Swift that I see, tends to be folks showing off its fancier features, in relatively small code samples.
Re: Use boring languages with LLMs
#48> Python is the same story but sung in a different key. Asking a simple question like “which package manager are you using?” This is annoying but only needs to be solved once at the start, either by the LLM or the human guiding it. A single prompt of "Set up a uv project in this directory with Python 3.13" is enough that it's never an issue again for that repo. > Goroutines are a far more tractable primitive for codi…
RE the article you've linked: > everyone knows goto was bad. Absolutely hard disagree. You can write extremely clean and resilient C with C89, goto, and a handful of rules. Telling people `goto` is bad is how we get shitty C programs and paradigms where goto would have been better. Goto isn't bad, its misuse is bad. Beginners will write shit code regardless of whether you tell them they can or can't use goto. That's…
Bad code is result of not following enough good practices rather than following one too many. Goto creates too much cognitive load. It had to be phased out to make room for better ideas on describing the intention with code more clearly.
Re: Use boring languages with LLMs
#49> Python is the same story but sung in a different key. Asking a simple question like “which package manager are you using?” This is annoying but only needs to be solved once at the start, either by the LLM or the human guiding it. A single prompt of "Set up a uv project in this directory with Python 3.13" is enough that it's never an issue again for that repo. > Goroutines are a far more tractable primitive for codi…
> This really does read as "Go is my favourite language".
Because it always is that.
People advocating for boring languages always advocate for their boring language. For instance, if you tell a gopher that you agree with the point, and therefore the project is going to use java, they won’t be happy about it.
Re: Use boring languages with LLMs
#50> Python is the same story but sung in a different key. Asking a simple question like “which package manager are you using?” This is annoying but only needs to be solved once at the start, either by the LLM or the human guiding it. A single prompt of "Set up a uv project in this directory with Python 3.13" is enough that it's never an issue again for that repo. > Goroutines are a far more tractable primitive for codi…
> Goroutines are a far more tractable primitive for coding agents than threads Goroutines are literally threads. Yeah, this really is a "go is my fav" article.
As someone below said, they might be from programming perspective, but technically they are not. See GOMAXPROCS for more info.
That being said the whole `tractable primitive` thing used in the article sounds somewhat sloppy to me. I don't quite get it. Yeah, they could be easier for an agent to write than async/await, but threads are also trivial in that matter, and you'd still need a mutex with go routines.