8 ms·

Use boring languages with LLMs

230 points by evakhoury 5mo ago

snikeris 5mo ago
I was a little surprised to find when I gave an LLM REPL access to the running program, it readily started using it during development and debugging.
wryoak 5mo ago
Contradictory anecdote: there’s basically only one way to write Elm, as it is a very trend-resistant language with minimal updates over long timespans, but most agents in my experience will throw Haskell syntax and Prelude functions into their Elm output. Compiler or LSP will often set them right but they still try it initially
- epolanski 5mo ago
  Interesting, I have a different experience. I have worked extending the Elm compiler and both Opus 4.6, GPT 5.4 and GLM 5 had no issues both with the Elm compiler (written in Haskell) and my extended Elm. I didn't see them hallucinate much, not more than on mainstream languages.
- djohnmustard 5mo ago
  Interesting, what models are you using? My use with sonnet 4.6 has been a breeze for the most part
- BoumTAC 5mo ago
  I’ve just started a new app with an Elm frontend. I’m using Grok Build, and it integrates really well. The compiler is incredibly helpful because it catches errors and gives clear explanations and the LLM can iterate over it. I’ve also added the elm-review package with the default configuration, which is fantastic for ensuring code quality.
- gampleman 5mo ago
  I do agentic Elm development every day (it's my job). I feel like what you describe was a problem with models perhaps two years ago. Today's models don't seem to struggle with it at all and in fact do seem to benefit from what the author describes.
- amarant 5mo ago
  I think you touch on a language feature I think is very important: compile time errors over runtime ones. I'm biased, I preferred it this way before AI. But even so I think there is real merit. Firm guardrails and clear feedback seem to benefit AI. Anecdotally, the worst AI performance I've seen was with gdscript, which is basically python minus the huge corpus of training data. Best results I'm getting with rust, which is in the opposite end of the strictness spectrum.
- Weebs 5mo ago
  I keep asking LLMs if I can define an interface implementation as an expression or without creating a new type in C# Every single one I ask always happily says yes, and starts claiming C# has local classes (a feature of Java)
wewewedxfgdf 5mo ago
Has Go become a "boring language"?
- ncruces 5mo ago
  The most non boring thing you can say about it is that it's terrible for ignoring most of what we've learned in the past couple decades of programming language design. That generates plenty of excitement.
- pjmlp 5mo ago
  It has been boring from the start. It would be an interesting language, had it been released at the time of any of its influences, Oberon in 1987, Limbo in 1995. Back when the type system ideas from CLU, Standard ML, Cedar were still taking off among industrial programming languages.
- dist-epoch 5mo ago
  Become? Always has been. It was intentionally designed for programmers with limited skill. Go language creator Rob Pike: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
  - antonvs 5mo ago
    > They’re not capable of understanding a brilliant language What a coincidence, since Rob Pike wasn't capable of designing a brilliant language.
  - boxed 5mo ago
    Such a weird take from him since Go has a bunch of pit falls that are not needed at all.
  - p2detar 5mo ago
    > It was intentionally designed for programmers with limited skill. No. That is not true. It was designed as a language so programmers of all levels can be productive at the scale of what Google does and across possibly many different teams, no matter your prior background. Google does a lot at scale and a language that is easy to pick up and handles concurrency seamlessly is definitely a helpful tool.
Havoc 5mo ago
> From a model’s standpoint, there are simply too many ways to write any of this They seem quite good at figuring this out in my experience
zitterbewegung 5mo ago
I haven’t had an issue using Python with LLMs where I have to decide “Should one use pip, poetry, or uv?” Since there is enough training data using pip or just choose that since it is the most boring solution and many of the commands map to uv since uv has a superset of features. Not that go is a bad solution honestly I would just say use what you know best.
lmm 5mo ago
Rather than "boring", this seems to be reaching for something like the concept of a "pit of success", or https://haskellforall.com/2016/04/worst-practices-should-be-hard https://haskellforall.com/2016/04/worst-practices-should-be-... . I don't think the fact that the most common pitfalls in Go are well known should be taken as a sign that it doesn't have more esoteric pitfalls as well; it's just that the common cases (like nil) are the ones that everyone sees all the time.
sheepianka 5mo ago
I disagree. "Boring" languages leave a lot of assumptions in code, which will start to compound the more changes model (and programmers) make to the code. The more assumptions I can move to compile time the better models are at dealing with emerging complexity. I would go the other way with LLMs and I wish for liquid types and effects in Rust to make type specifications even more strict. P.S. effects and liquid types and type specifications in general add a lot of busywork, but models have higher level of tolerance to busywork compared to developers.
- bluegatty 5mo ago
  The problem is that most of Rust annotations are related to memory management in special conditions aka solving problems that don't even exist in JS or Java. That's not going help the AI solve problem space issues, it just helps the AI (and us) do things in the solution space aka solve lower level things we consider important.
  - zozbot234 5mo ago
    Memory management annotations are actually quite rare in Rust. It mostly uses plain RAII as seen in C++. You do need to annotate whenever an object may have multiple "owners" extending its lifecycle (which requires refcounting) but that's often directly visible in the problem domain.
    - bluegatty 5mo ago
      & and &mut is all over the code in Rust. &T by far the most common arg type. In the OP article, they mention 'don't need to worry about thread cause the concept does not exist' - well, & does not exist in Python. Those things are related to low-level computational issues (memory management) not problems space issues (moving money, transcoding the file, checking the spreadsheet), so a lot of &/&mut etc. and all that extra thinking slows down AI for the same reason it slows down you and I. In particular, building in rust requires us to think a bit different about how we create the program in the first place and I don't think AI is very good at architecture yet. Probably ... eventually none of this will really matter though, it will just be like 'compiler pedantry' for the small number of people who work on those things.
Yokohiii 5mo ago
> Languages and ecosystems with low variance in their training corpus are represented better and executed more reliably by coding agents. So I think the author is saying that go is a simple language that tends to have less solutions to the same problem. I personally agree to that to a degree. What I don't agree on is that we can choose what "low variance" is. There is a lot of go code out there, it's shape may have little "noise", but the variance is massive.
keepamovin 5mo ago
I agree with the idea that boringly predictable should be what is preferred but anecdotally my experience in using Go with LLMs is that they trip up a lot on the races and locking from go’s thread model. I haven’t seen the same problem in rust which is now why I’m doing all my LLM work for tooling in rust. The parallelism issue in particular was also not something I noticed agent struggling with in JavaScript, although JavaScript concurrency model is clearly fundamentally different. The concurrency issues that I saw LMM‘s face was one reason why I created freelang which uses a very boring and audible concurrency model of OS processes that use the file system to talk instead of IPC, shared state, or anything like that. Higher overhead, lower throughput, but more boring and hopefully less bugs: https://github.com/DO-SAY-GO/freelang https://github.com/DO-SAY-GO/freelang
- nathannaveen 5mo ago
  Personally I generally try to avoid concurrency when writing code with AI since I feel AI makes concurrency unnecessary complex in Golang.
  - keepamovin 5mo ago
    Right. But for things like GUI or orchestration tooling it’s unavoidable
  - quietbritishjim 5mo ago
    Probably reasonable, but that means you're disagreeing with the article's point about goroutines being good for LLMs (since goroutines are a form of concurrency). I've never seriously used Go so I don't know how easy it is to avoid using them.
  - dnautics 5mo ago
    I don't have this issue in elixir.
    - innocentoldguy 5mo ago
      Neither do I.
sd9 5mo ago
I wonder if the training data for some languages has higher quality code. I can imagine some niche languages having a higher standard than, for example Python, which surely has a bunch of random buggy scripts in the mix. On the other hand, even if that were true, I don’t know how important it would actually be since LLMs can generalise across languages well. It might be best to pick languages where it’s just harder to screw up, the canonical example being to prefer typescript over JavaScript.
ChrisMarshallNY 5mo ago
I 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, may be that I am a much better Swift programmer, than PHP programmer, and there’s just a lot more Swift code. I haven’t really taken the time to analyze it. I have my theories, as to why, but it’s not something I’m really into researching. I’ve just noted the trend.
- sleepy_keita 5mo ago
  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.
  - iamcalledrob 5mo ago
    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.
    - ChrisMarshallNY 5mo ago
      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.
  - psychoslave 5mo ago
    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.
quietbritishjim 5mo ago
> 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 coding agents than threads, callbacks, async/await, or any of the colored-function regimes that dominate elsewhere. I disagree with this. Goroutines, along with threads, callbacks, and traditional async, are all in the same category: spaghetti of unbounded background tasks. Structured concurrency [1] on the other hand is dramatically easier to reason about. Python has support for this (in Trio and asyncio.TaskGroup) as do other languages like Kotlin and Swift. Function colouring a red herring; if anything, it's useful because it highlights the scheduling/cancellation points in your code. [1] https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g... ----- This really does read as "Go is my favourite language". In fairness, that's a good reason to choose a language to use with an LLM (so long as it's powerful enough and not too obscure). But let's not pretend it's the best language for everyone.
- dminik 5mo ago
  > 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.
  - Retr0id 5mo ago
    Goroutines are not directly equivalent to threads.
    - IshKebab 5mo ago
      They used to not be, because they were cooperatively scheduled and threads can be preempted. But they added goroutine preemption in Go 1.14 so in practice there aren't really any significant differences to threads, at least in semantics. (At least as far as I remember; been a while since I wrote any Go.) You can be pedantic and say they aren't technically threads but that doesn't really matter from a programming perspective.
citbl 5mo ago
We are the point now where we let LLM dictate the language?
- badgersnake 5mo ago
  Yeah, but then generally you pick the language your dev team are most familiar with. Or you hire a team of specialists for the language you want. Perhaps niche languages should have fine-tuned LLMs in the same way.
zuogl 5mo ago
[flagged]
shantnutiwari 5mo ago
What?? Python __is__ a boring language (it is mature and well supported) with a somewhat convoluted package manager that has gotten a lot better since that xkcd came out. Yeah, I get it, Go is better for distributing your code-- just one binary you can copy. But what does that have to do with "boring"?
tern 5mo ago
Rust, Elixir, and Go are the way to go for LLMs in my testing and experience, for this and other reasons
- mohamedkoubaa 5mo ago
  I have no professional experience in Rust and over 10 years in c++ but to me the decision to use rust in a greenfield project written by agents was obvious.
- cpursley 5mo ago
  Here’s some of the reasons it’s so good with Elixir: https://dashbit.co/blog/why-elixir-best-language-for-ai https://dashbit.co/blog/why-elixir-best-language-for-ai
  - tern 5mo ago
    My intuitions for using Elixir: - Durable, 'enterprise grade' software patterns are baked into the runtime and into common, stable libraries that everyone uses - You can use Ash, which pretty much entirely solves architectural considerations for many types of backends - The tooling for inspecting and enforcing style (tidewave, credo, dialyzer, Dan's "vibe" ecosystem tools) is far beyond what I see in other ecosystems - Ecosystem coverage for pretty much everything you need, including numerical software - Excellent performance escape hatches (NIFs) And, as has been shown in various benchmarks, agents are quite good at it. My one problem in practice has been that getting tests right is hard. LLMs need a lot of cajoling to not build flaky tests with all the concurrency, and I find myself spending hours rewriting parts of the test suite once or twice a week.
    - cpursley 5mo ago
      Is ex_slop one of Dans? That one is great. Been looking for an equivalent in Swift.
jmull 5mo ago
This 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 language (and related setup/environment) you're familiar with.
- embedding-shape 5mo ago
  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.
perlgeek 5mo ago
Try 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).
- chuckadams 5mo ago
  Excessively verbose syntax to express concepts is something I can let an LLM paper over, but a language that does not even function properly without the ceremony is still a non-starter. I want to refactor chains of operations without having to check for errors myself after each step, and I want that with or without an LLM.
xnx 5mo ago
Also use boring languages without LLMs
tracker1 5mo ago
For myself, I've generally setup a few boundaries... for JS projects, I tend to use Deno for tooling, even targeting npm lately. Similarly, I've favored modern TypeScript over JS. Often Hono + OpenAPI + Zod as a set for services. I've also been doing quite a bit of Rust for web services and wasm targets, which has worked exceedingly well... similarly with Tokio + Axum, etc. I have seen very few issues with either of the above... that said, C# has been a bit more painful by comparison... I often rely on FastEndpoints for services and Grate for database migrations, and LLMs often get a bit tangled with those libraries in practice.
eithed 5mo ago
I think that this not only applies to languages, but general patterns that you use. Don't mix functional with OO. Don't mix repositories with DAOs. Don't mix MVC and MVVM. Code should be predictable in what it does and what you expect from other developers how to code. If you don't have that then you shouldn't blame LLM when it goes haywire and starts doing whatever
dnautics 5mo ago
I don't think the python package manager is the high level difficulty for LLMs doing python. I think the high level difficulty are nonlocal effects. At any given callsite, it might be difficult to know exactly what is going to happen to the data you pass into the call.
- AustinDev 5mo ago
  A sibling mentioned that LLMs benchmark better on elixir. Immutability and functional programming are likely the reason why it benches better.
znnajdla 5mo ago
Instead of empty theorizing, we should have benchmarks for this. There is at least one benchmark which suggests that LLMs are better at writing Elixir than most other languages: see the AutoCodeBenchmark.
- jryio 5mo ago
  Send me an email I'd love to make one
- justinhj 5mo ago
  Thanks for the tip. If they are representative the results are quite surprising. Anecdotally, I always thought Go would be on one of languages LLM's were best at. https://github.com/Tencent-Hunyuan/AutoCodeBenchmark/blob/main/figures/exp_acb.png https://github.com/Tencent-Hunyuan/AutoCodeBenchmark/blob/ma...
  - vunderba 5mo ago
    In my experience, LLMs are pretty good at writing Go code. In fact, that’s one of my principal use cases: I have a number of bespoke Node programs from many years ago that usually run in the background on my computer. Each process (with the Node runtime engine) consumes about 50–100 MB of RAM. One of the first things I tried was using large language models to help port them over to Go. Since the model has a point of reference (the original Node program plus its unit tests) it’s been easy to use a test-driven approach and ensure the Go version maintains parity with the originals. Memory usage usually drops from around ~50 MB to about ~5 MB per process, which really adds up when you’ve got a dozen of these programs running at once.
KaiShips 5mo ago
[flagged]
TheGRS 5mo ago
I can probably fix package manager issues by hand, and quickly with a little rubber ducking with the LLM itself. I'm not sure that's a huge problem in the grand scheme. There's a lot of stuff in Python's favor in regard to coding with LLMs: its wildly popular so there's a lot of references for the right and wrong ways to use it, it can be typed using included libraries - its as simple as telling the LLM "use typing for this", and there are several great lint and unit testing tools to cover the hallucinations and poor decisions. The flexibility seems like an advantage to me personally, but I've always been a Python stan.
- mountainriver 5mo ago
  Why choose a significantly worse language when you are writing it in the same English either way. It’s increasingly obvious that whole swaths of developers will just continue using the language they did before LLMs “just cause” It’s more identity based at this point. My LLMs write Rust for me and I couldn’t tell you the difference outside of it being way faster and more reliable
  - TheGRS 5mo ago
    For immediate term you should stick with what you know. I think that makes for much better prompting where you are coming in with experience with the language and the general style you'd like to see. Rust is a language I would like to adopt longterm, but its not one I can easily grok and so my output would be worse for it.
    - mountainriver 5mo ago
      I think that's fair, but I honestly can't tell you if I'm writing python or rust anymore. When I review I just ask Claude to add comments to all the code to make things clear as I review
bluegatty 5mo ago
"The concurrency model is the first of these. Goroutines are a far more tractable primitive for coding agents than threads, callbacks, async/await, or any of the colored-function regimes that dominate elsewhere. They are simple, type-safe, and ubiquitously used in the corpus the model was trained on. There is no question of what color your function is, because the question does not exist." I don't really buy the intuition (aka Goroutines are more 'clear' than 'coloured' functions or threads), and there's no evidence presented for this either. Although this could very well be true, I'm doubtful without seeing some real world data points. The 'general premise' aka 'cosine similarity' may have been true before bit it may not be that anymore. AI just pretty good at anything it's 'seen enough' and that's it, I think it's more likely a 'threshold' problem than an ability problem, at least for most things. 'Rust' may represent a different domain, given the very detailed nature of notation and the vast possibilities that arise from that.
dionian 5mo ago
Large codebases are much easier to manage with type safety. Not a fan of Go but definitely much better than python in this regard.
jryio 5mo ago
Author here, wasn't expecting this piece of writing to show up on HN. The specifics of Python were chosen only due to the language ecosystem being fragmented and inconsistent while Python remains an essential learning, research, and now ML programming language (it was my first language and I still love it). My thoughts on LLM generated code have changed immensely in the last 9 months as I've taken on teams and projects through my consulting work [1] as a fractional CTO. Python remains a difficult, flakey, and inconsistent programming language for complex production systems. Most other programming languages suffer from fragmented toolchains and ecosystems: JavaScript (famously), PHP, and even C/C++ to a degree. Languages with a single way to do things benefit the most: Ruby, Rust, Swift (even). Low entropy is the way to go and convention > configuration seems to pay off with LLMs. Mean cost of management is more important than specific edge examples "X company run on Y language". I think that 'boring' languages with rock-solid compilers, toolchains, testing frameworks, and package managers make for high return on engineering time and production maintenance. [1]: sancho.studio
- e12e 5mo ago
  > Languages with a single way to do things benefit the most: Ruby I love ruby - but surely it's closer to Perl and "There's more than one way to do it" - than python which generally strives for "There should be one-- and preferably only one --obvious way to do it."? https://legacy.python.org/dev/peps/pep-0020/ https://legacy.python.org/dev/peps/pep-0020/
  - dasil003 5mo ago
    In practice, Ruby is much more opinionated than Perl, mostly because of Rails being the catalyst to drive mass adoption of Ruby. So you basically have Rails, and then the RubyGems/Bundler package management was pretty linear. There's no equivalent of python2->python3 schism and the package management churn, and more stylistic continuity since ruby adoption is lower and more concentrated in the 2005-2015 time frame compared to python which had greater diversity of adoption and use cases both before and after the Web 2.0 era. I do feel pythons explicit imports and cultural aversion to meta programming win it some points. Overall though it kind of feels like a wash and I still choose the language based on the some criteria I would have used before agentic coding--claude does fine with either.
gregman1 5mo ago
Haskell is I think a great language for llms - just make everything as pure as possible and you are golden.
dogleash 5mo ago
>Languages and ecosystems with low variance in their training corpus are represented better and executed more reliably by coding agents. Just narrow your window of thought to easier problems for the LLM, and all of a sudden the LLMs do everything you want! Reminds me of playing around with image generation models. Someone who's been practicing can crank out prompts for really impressive images back to back. But you try to use an everyday object or concept the model isn't trained on? Everybody will race to show off how smart they are by saying "just don't hold it like that."
badlibrarian 5mo ago
My experience a year ago (back when half of HN was still in denial about what was already working, let alone what was to come) was that Python was the linqua franca of LLMs. You could achieve almost anything that fit in 700 lines or less if you told it to write it in Python. Times change, and I work more in R&D space than on legacy codebases, but I still ask it to write something in Python then convert it to the actual language on occasion. I don't know if I'm tricking the context window, forcing alternate pathways, or both, but it works.
- roughly 5mo ago
  > Times change, and I work more in R&D space than on legacy codebases, but I still ask it to write something in Python then convert it to the actual language on occasion. I don't know if I'm tricking the context window, forcing alternate pathways, or both, but it works. My experience with LLMs is that they perform best in one of two modes - either one carefully scoped context or translating between two different contexts without modification - so this modality lines up with that fairly nicely: think in the programming language the LLM thinks "best" in and then translate that to the one you want. That said, there's often enough structural and conceptual differences between languages that a direct "transliteration" between, say, Python and Go is going to result in some fairly crummy Go, so I'm curious what you see in terms of the fidelity of that translation - do you mostly get "Python written in Go," or does the LLM really do a proper conversion from one language to the other?
  - badlibrarian 5mo ago
    I have strict context in place on what I expect from the final language (C# or C++) and I'm frequently left with my jaw open. Used my preferred json library on C++, used LINQ appropriately in C#. Mapped AWS libraries appropriately and used existing credential stores. Certainly better than what I got when I asked for the native version first, which is why I do the hurdle. It feels hacky but it works. In a year it probably won't be necessary.
Animats 5mo ago
I wonder what we end up with as an LLM-friendly programming language. It's likely to be something rather formal, with entry and exit assertions. Humans hate writing those, but LLMs need them to keep them on track and give them goals.
sunshowers 5mo ago
In my experience, LLMs benefit greatly from the existence of sum types and exhaustive pattern matching.
jaen 5mo ago
LLMs have a limited context window - similar to the limited attention span and memory of humans. LLMs also have trouble attending to many constraints at once. Therefore the best language for agents is likely the one that, on one hand erases all irrelevant details (ie. raises the level of abstraction and does not force focusing on eg. memory management), and on the other hand encodes any domain-relevant details in the code (eg. using advanced type systems, annotations, contracts, spec-like tests eg. property-based). Human readability is a separate concern and still relevant, but the two mentioned properties actually generally improve on that as well (at least for engineers persistent enough to scale the tower of abstraction). Based on this, it seems Go is certainly not that "agent endgame" language. It has large amounts of boilerplate, a general lack of safety around concurrency features, a pretty middling static safety story overall with a generally underpowered type system. I don't think the perfect language exists, yet, but just wildly imagining, it would probably be something like a cross between Scala, Elixir and Lean (or equivalents). Unfortunately none of those languages also have the large training corpus required to make them perform well in all agenting engineering situations (yet). For any language comparison, one must separate the expressiveness of the language, which limits the long-term possibilities for agents, and the training corpus, which is what mostly gives it the current standing. I think we are still in the phase where the languages are separated by essentially random non-design factors such as the amount of training environments the frontier labs are willing to create for them. Given that, the syntax does not matter all that much, as long as the base language itself is flexible enough - as a another wild idea, it's also possible that eg. Python could mostly swallow all these features through external tools (eg. the pre-existing type checkers or linters), and if the frontier labs bother to RL on those tools, that would also work (see also: Mojo).
- devin 5mo ago
  I know Clojure misses the mark for you in some major areas, but having a real, proper REPL for an agent to interact with makes for an extremely strong feedback loop. IMO, a strong candidate for an "agent endgame" language has this.
  - jaen 5mo ago
    I love REPL-driven development, and exploratory "programming" via small snippets is likely part of the endgame (the more the agent strays outside its comfort zone, the more it's needed). It also looks like it paradoxically saves context, since piling up many small snippets is still better than trying to fix a one-shot gone horribly wrong. And yeah, if Clojure had a better static safety story, it would actually rank high, since it's high-abstraction with metaprogramming capabilities, excellent runtime specifications, and has a good "garden path" ie. natural code is good code. (As a devil's advocate though, REPLs can be replaced with gluing together scripts with ad-hoc state/caching via the file system, which LLMs seem to be pretty good at already...) So as an addendum, introspectability is also important ie. allowing to discover the state and composition of the system at any moment - though that's partially a language (eg. reflection) and partially a tooling (eg. debuggers) issue.
janpeuker 5mo ago
Great post showing the ironic revenge of opinionated architecture in times of cheap code. Exactly what LLMs can’t deliver, they always seem to be bias towards added complexity, not simplification.
tlonny 5mo ago
I think _some_ but not _too much_ typechecking is the sweet spot for LLMs. Without any typechecking, LLMs obviously find it harder to work agentically and validate their work. With too much typechecking (I'm looking at you, rust), I've found agents get themselves stuck in local "architectural minima" and end up doing insane shit to mitigate ownership/borrow-checker issues inherent in the design they ended up with. That said, if you're hands-on I think rust is a fantastic language for pairing with an LLM.
itpragmatik 5mo ago
Java 21, Spring Boot 4.x, Spring AI 2.x - probably most boring stack that is working fantastic for me to generate solid, reliable code for agents, mcp servers using Claude Code or Cursor.
haolez 5mo ago
This made me remember of a benchmark that I saw a few months ago about LLMs being unexpectedly _very good_ with Perl when compared to any other language. I couldn't find it right now. If someone knows what I'm talking about, please post it here :)
gertlabs 5mo ago
When you're working on something difficult that requires a model to reason intelligently, lower level and strongly typed languages often outperform on the same problems [0]. We have a few hypotheses about why, with a moderately high correlation between performance and token density of the output program -- i.e. more token dense languages are more difficult for programs to reason about. Most models come up with the least effective solutions when writing Python. [0] https://gertlabs.com/rankings https://gertlabs.com/rankings
- ajb 5mo ago
  That's a very interesting page, but the language ranking is wildly different for "average percentage" (python bottom) and "success rate" (python second). Sounds like there is some subtly about this.
  - gertlabs 5mo ago
    Success rate is essentially loading/compilation success + ability to adhere to the environments' rules. For one-shot responses, the majority of failures are environmental/syntax, which naturally favors interpreted languages. For longer agentic coding sessions, models solve the environment issues quickly and it becomes a fair comparison of who comes up with the smarter solution. You can filter for that here: https://gertlabs.com/rankings?mode=agentic_coding https://gertlabs.com/rankings?mode=agentic_coding
- christophilus 5mo ago
  I ran a little test with Go, TypeScript, Clojure, F#, Haskell, and Rust. Token count was roughly in the same ballpark, but it used the fewest for TypeScript, then Go. The rest required a bit more. Clojure always won in terms of lines of code though, generally coming in at 1/2 the size of the Go or Typescript solutions.
  - iLemming 5mo ago
    I bet you have not tested it with live Clojure REPL. When you give the LLM living, breathing REPL, it stops guessing and starts empirically analyzing current state of things and produces working solution faster, costing far less tokens. This article doesn't seem to mention it either https://martinalderson.com/posts/which-programming-languages-are-most-token-efficient https://martinalderson.com/posts/which-programming-languages... even though states Clojure to be the most token efficient. I personally, honestly don't care much. In my opinion (using LLMs with multiple different languages), specifics of PLs don't matter to the point of stating a "clear winner". It's not the language that matters but the "stories you tell" with the language. And greatest stories sometimes told in the languages people long forgotten.
sorenjan 5mo ago
Why are we having computer programs generate source code in the first place? Shouldn't they generate something lower level, like an AST or some computational graph or something? Source code is made to be written and read by humans, and is then translated into machine code via various transformations. In theory a program should look the same to a computer no matter which language it started out as. We have decades of compiler research, static code analysis etc, why do these extremely complicated black boxes of billions of parameters have to produce readable source code as their main output?
- JadeNB 5mo ago
  > Why are we having computer programs generate source code in the first place? Shouldn't they generate something lower level, like an AST or some computational graph or something? Source code is made to be written and read by humans, and is then translated into machine code via various transformations. In theory a program should look the same to a computer no matter which language it started out as. Presumably because LLMs are trained on corpora read, and for now still probably mostly written, by humans, rather than on corpora consisting mostly of ASTs or graphs?
- carlostkd 5mo ago
  In 5–10 years there will be no more code written by humans.
suis_siva 5mo ago
My experience is that higher-kinded languages (ie. Haskell) allow for "controlled chaos". I design a type-system, the higher kinded types, the interfaces (though it's getting rarer I need to do this) and I let Claude slop the implementation. Additionally, fault-tolerant languages such as Erlang/Elixir allow me to not worry about the billions of edge-cases, and let Claude aggressively implement a mostly good-enough application. With LLMs, accepting a limited amount of failure may be a necessity (depending on the business/domain), and that's exactly what the BEAM enables.
keithnz 5mo ago
I think use any language that can achieve / or is close to native speed and has a reasonable ecosystem of significant libraries around it. Trivial libs are pretty much dead as AI will implement what you need, so if you need something like MQTT, its much easier when you have mature lib that handles that. I've experimented a bunch of language with LLM, like Go, Rust, C, C++, C#, Kotlin. All work fine. My decision on what to use depends on what the larger ecosystem provides and what I'm programming for (embedded, backend, Web, GUI, App etc). I'd probably add in swift if I get around to doing iOS stuff. There's no real "best" here, multiple options are likely going to be fine choices. Crazy thing is, if you don't like your language choice you can use AI to change it (ideally early on). Just for fun I got AI to convert one of my TUI apps to various languages. Went reasonably well.
trees101 5mo ago
Anyone use this stuff with Delphi? I've been looking for tips for getting the best out agents for Delphi
- fmxexpress 5mo ago
  I use it with Delphi. Claude Code with Opus 4.7 works fine. It can use FPC in Delphi mode so that it can test itself. I'm doing greenfield and not an old project though.
  - thijsvandien 5mo ago
    Care to share your specific setup/workflow? I'd be interested.
iLemming 5mo ago
[dead]
zane_shu 5mo ago
[flagged]
cpard 5mo ago
* Large language models amplify inconsistent technology and quietly reinforce consistent ones. * This is another way of saying that the tools you equip the LLM affect their effectiveness, in other words, the harness you build around them matters and matters a lot. At the end of the day, the language you pick, enriches the harness with the toolchain, libraries etc. it offers. This is most evident with the toolchain as the author mentioned but if you think about it, picking a specific framework that constraints the choices the model can make (e.g. the Ruby on Rails example) is also affecting the behavior it has.
dr_kretyn 5mo ago
I'm developing a terminal agent (https://GitHub.com/laszukdawid/trrminal-agent https://GitHub.com/laszukdawid/trrminal-agent) in golang and can't say that it's easier or less error prone to write it in golang vs Python or JS. There's still plenty of bad ideas and bad code being suggested by Claude Code / Codex so it's still hands on work. However, testing is much easier and it makes me think more about the arch more than with Python.
synergy20 5mo ago
kind of agree here, golang is my main LLM language. for low-level, it's C or Lua, or modern c++ for simple cross-platform system daemons.
gemsquared 5mo ago
[flagged]
justomsharma 5mo ago
Though I dont know GO, but reading your post - really have me thinking that okayy this is a cool and easy language too But as someone who is working in python since ages - I guess it is pretty much easy too, and as not as hard as you described. LOL, but whatever, your this post was really amazing
Decabytes 5mo ago
Just want to throw the other Google language into the ring. While I would say Dart has a few more fancy language features than Go, it has an extremely strong and modern cli tool, which is a one stop shop for all your formatting, linking, and project building needs. It even grades how well your project is constructed before you publish it to pub.dev
- nylonstrung 5mo ago
  What does it bring to the table that isn't achievable with Cargo? I just feel like Dart doesn't offer enough for a fairly standard OOP lang which isn't particularly fast and doesn't have the library ecosystem or vast training data of Rust, Go etc
  - Decabytes 5mo ago
    > What does it bring to the table that isn't achievable with Cargo? Speaking purely about the cli dart devtool (flutter and debugging) dart compile (More options but the big one is JavaScript transpilation) dart info (outputs diagnostic information about installed dart toolchain) > which isn't particularly fast Against other programming languages that are also garbage collected Dart compares favorably, though it's implementations of things typically aims for user accessibility over maximum performance. For example a Dart Isolate is much more heavy weight than a goroutine due to it's higher startup cost and additional memory per worker. The advantage is that it has its own memory, own event loop, and communicates with other isolates only by message passing, so it's much harder to mess up. But where Dart shines for me is in two instances. The first is as a Python programmer that wants to work in a statically typed, ahead of time compiled language. Dart fits the bill here, and covers a weakness many programming languages have which is user facing GUIs. I would argue nothing comes close to Flutter when it comes to slapping together cross platform GUIS that just work. Dart is also very good on the front and backend (with more emphasis on the frontend) of web development, and can be integrated into an existing project very well through it's ability to compile into JavaScript. Typescript definitely eats Dart's lunch here, and Go more so for the backend, but very few languages can do Webdev in a way that feels natural and due to many design decisions of the past Dart is better than most. So Dart is good for packaged user facing apps. This also makes it a strong contender as the higher level language to pair with a lower level language. You mentioned Rust, and Dart has a Flutter Rust Bridge^1 which allows you to write normal Rust code that automatically has the glue code generated. The native code interaction story gets even better through Dart's Hooks^2, Which allow you to integrate and compile or download native assets into your Dart projects directly through Darts build interface. > doesn't have the library ecosystem or vast training data of Rust, Go etc LLMs are better at handling niche languages than they have ever been. And the fact that Dart is not applied broadly, in the same way Python is, means you don't need a million examples to cover the most common use cases. 1. https://pub.dev/packages/flutter_rust_bridge https://pub.dev/packages/flutter_rust_bridge 2. https://dart.dev/tools/hooks https://dart.dev/tools/hooks
impulser_ 5mo ago
I have tested almost every language and Go is pretty good but for some reason LLMs get paranoid over races and just start spamming locks next thing you know every fucking struct has mutexes and every function has locks lol. The best language I have seen an LLM use was Kotlin. It actually surprised me how well it wrote the language. I wrote a project in it and I think I didn't have to correct it once. Like I was seriously impressed. I just wish Kotlin had better tooling so I didn't have to use gradle or maven lol.
byrohitrajan 5mo ago
[flagged]
zuogl 5mo ago
[flagged]
ffzlff 5mo ago
In the future, we might need a new layer for LLM programming, the layer is more boring and more standardized
kstkrv 5mo ago
Gleam is a new kid, but it seems to fit this trend: - Less ways to write code; - Strongly typed; - Erlang parallelism; - Exhaustive pattern matching; - No nulls (and many other stuff); - Pipelines (not sure about LLMs, but it fits my eye);
ljosifov 5mo ago
+1 for boring. Boring code is Solid Code, in the sense of "Writing Solid Code" - the old book by Steve Maguire.

230 points by evakhoury 5mo ago

I was a little surprised to find when I gave an LLM REPL access to the running program, it readily started using it during development and debugging.

wryoak 5mo ago

Contradictory anecdote: there’s basically only one way to write Elm, as it is a very trend-resistant language with minimal updates over long timespans, but most agents in my experience will throw Haskell syntax and Prelude functions into their Elm output. Compiler or LSP will often set them right but they still try it initially

epolanski 5mo ago
Interesting, I have a different experience. I have worked extending the Elm compiler and both Opus 4.6, GPT 5.4 and GLM 5 had no issues both with the Elm compiler (written in Haskell) and my extended Elm. I didn't see them hallucinate much, not more than on mainstream languages.
djohnmustard 5mo ago
Interesting, what models are you using? My use with sonnet 4.6 has been a breeze for the most part
BoumTAC 5mo ago
I’ve just started a new app with an Elm frontend. I’m using Grok Build, and it integrates really well. The compiler is incredibly helpful because it catches errors and gives clear explanations and the LLM can iterate over it. I’ve also added the elm-review package with the default configuration, which is fantastic for ensuring code quality.
gampleman 5mo ago
I do agentic Elm development every day (it's my job). I feel like what you describe was a problem with models perhaps two years ago. Today's models don't seem to struggle with it at all and in fact do seem to benefit from what the author describes.
amarant 5mo ago
I think you touch on a language feature I think is very important: compile time errors over runtime ones. I'm biased, I preferred it this way before AI. But even so I think there is real merit. Firm guardrails and clear feedback seem to benefit AI. Anecdotally, the worst AI performance I've seen was with gdscript, which is basically python minus the huge corpus of training data. Best results I'm getting with rust, which is in the opposite end of the strictness spectrum.
Weebs 5mo ago
I keep asking LLMs if I can define an interface implementation as an expression or without creating a new type in C# Every single one I ask always happily says yes, and starts claiming C# has local classes (a feature of Java)

wewewedxfgdf 5mo ago

Has Go become a "boring language"?

ncruces 5mo ago
The most non boring thing you can say about it is that it's terrible for ignoring most of what we've learned in the past couple decades of programming language design. That generates plenty of excitement.
pjmlp 5mo ago
It has been boring from the start. It would be an interesting language, had it been released at the time of any of its influences, Oberon in 1987, Limbo in 1995. Back when the type system ideas from CLU, Standard ML, Cedar were still taking off among industrial programming languages.
dist-epoch 5mo ago
Become? Always has been. It was intentionally designed for programmers with limited skill. Go language creator Rob Pike: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
- antonvs 5mo ago
  > They’re not capable of understanding a brilliant language What a coincidence, since Rob Pike wasn't capable of designing a brilliant language.
- boxed 5mo ago
  Such a weird take from him since Go has a bunch of pit falls that are not needed at all.
- p2detar 5mo ago
  > It was intentionally designed for programmers with limited skill. No. That is not true. It was designed as a language so programmers of all levels can be productive at the scale of what Google does and across possibly many different teams, no matter your prior background. Google does a lot at scale and a language that is easy to pick up and handles concurrency seamlessly is definitely a helpful tool.

Havoc 5mo ago

> From a model’s standpoint, there are simply too many ways to write any of this They seem quite good at figuring this out in my experience

zitterbewegung 5mo ago

I haven’t had an issue using Python with LLMs where I have to decide “Should one use pip, poetry, or uv?” Since there is enough training data using pip or just choose that since it is the most boring solution and many of the commands map to uv since uv has a superset of features. Not that go is a bad solution honestly I would just say use what you know best.

lmm 5mo ago

Rather than "boring", this seems to be reaching for something like the concept of a "pit of success", or https://haskellforall.com/2016/04/worst-practices-should-be-hard https://haskellforall.com/2016/04/worst-practices-should-be-... . I don't think the fact that the most common pitfalls in Go are well known should be taken as a sign that it doesn't have more esoteric pitfalls as well; it's just that the common cases (like nil) are the ones that everyone sees all the time.

sheepianka 5mo ago

I disagree. "Boring" languages leave a lot of assumptions in code, which will start to compound the more changes model (and programmers) make to the code. The more assumptions I can move to compile time the better models are at dealing with emerging complexity. I would go the other way with LLMs and I wish for liquid types and effects in Rust to make type specifications even more strict. P.S. effects and liquid types and type specifications in general add a lot of busywork, but models have higher level of tolerance to busywork compared to developers.

bluegatty 5mo ago
The problem is that most of Rust annotations are related to memory management in special conditions aka solving problems that don't even exist in JS or Java. That's not going help the AI solve problem space issues, it just helps the AI (and us) do things in the solution space aka solve lower level things we consider important.
- zozbot234 5mo ago
  Memory management annotations are actually quite rare in Rust. It mostly uses plain RAII as seen in C++. You do need to annotate whenever an object may have multiple "owners" extending its lifecycle (which requires refcounting) but that's often directly visible in the problem domain.
  - bluegatty 5mo ago
    & and &mut is all over the code in Rust. &T by far the most common arg type. In the OP article, they mention 'don't need to worry about thread cause the concept does not exist' - well, & does not exist in Python. Those things are related to low-level computational issues (memory management) not problems space issues (moving money, transcoding the file, checking the spreadsheet), so a lot of &/&mut etc. and all that extra thinking slows down AI for the same reason it slows down you and I. In particular, building in rust requires us to think a bit different about how we create the program in the first place and I don't think AI is very good at architecture yet. Probably ... eventually none of this will really matter though, it will just be like 'compiler pedantry' for the small number of people who work on those things.

Yokohiii 5mo ago

> Languages and ecosystems with low variance in their training corpus are represented better and executed more reliably by coding agents. So I think the author is saying that go is a simple language that tends to have less solutions to the same problem. I personally agree to that to a degree. What I don't agree on is that we can choose what "low variance" is. There is a lot of go code out there, it's shape may have little "noise", but the variance is massive.

keepamovin 5mo ago

I agree with the idea that boringly predictable should be what is preferred but anecdotally my experience in using Go with LLMs is that they trip up a lot on the races and locking from go’s thread model. I haven’t seen the same problem in rust which is now why I’m doing all my LLM work for tooling in rust. The parallelism issue in particular was also not something I noticed agent struggling with in JavaScript, although JavaScript concurrency model is clearly fundamentally different. The concurrency issues that I saw LMM‘s face was one reason why I created freelang which uses a very boring and audible concurrency model of OS processes that use the file system to talk instead of IPC, shared state, or anything like that. Higher overhead, lower throughput, but more boring and hopefully less bugs: https://github.com/DO-SAY-GO/freelang https://github.com/DO-SAY-GO/freelang

nathannaveen 5mo ago
Personally I generally try to avoid concurrency when writing code with AI since I feel AI makes concurrency unnecessary complex in Golang.
- keepamovin 5mo ago
  Right. But for things like GUI or orchestration tooling it’s unavoidable
- quietbritishjim 5mo ago
  Probably reasonable, but that means you're disagreeing with the article's point about goroutines being good for LLMs (since goroutines are a form of concurrency). I've never seriously used Go so I don't know how easy it is to avoid using them.
- dnautics 5mo ago
  I don't have this issue in elixir.
  - innocentoldguy 5mo ago
    Neither do I.

sd9 5mo ago

I wonder if the training data for some languages has higher quality code. I can imagine some niche languages having a higher standard than, for example Python, which surely has a bunch of random buggy scripts in the mix. On the other hand, even if that were true, I don’t know how important it would actually be since LLMs can generalise across languages well. It might be best to pick languages where it’s just harder to screw up, the canonical example being to prefer typescript over JavaScript.

ChrisMarshallNY 5mo ago

I 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, may be that I am a much better Swift programmer, than PHP programmer, and there’s just a lot more Swift code. I haven’t really taken the time to analyze it. I have my theories, as to why, but it’s not something I’m really into researching. I’ve just noted the trend.

sleepy_keita 5mo ago
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.
- iamcalledrob 5mo ago
  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.
  - ChrisMarshallNY 5mo ago
    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.
- psychoslave 5mo ago
  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.

quietbritishjim 5mo ago

> 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 coding agents than threads, callbacks, async/await, or any of the colored-function regimes that dominate elsewhere. I disagree with this. Goroutines, along with threads, callbacks, and traditional async, are all in the same category: spaghetti of unbounded background tasks. Structured concurrency [1] on the other hand is dramatically easier to reason about. Python has support for this (in Trio and asyncio.TaskGroup) as do other languages like Kotlin and Swift. Function colouring a red herring; if anything, it's useful because it highlights the scheduling/cancellation points in your code. [1] https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g... ----- This really does read as "Go is my favourite language". In fairness, that's a good reason to choose a language to use with an LLM (so long as it's powerful enough and not too obscure). But let's not pretend it's the best language for everyone.

dminik 5mo ago
> 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.
- Retr0id 5mo ago
  Goroutines are not directly equivalent to threads.
  - IshKebab 5mo ago
    They used to not be, because they were cooperatively scheduled and threads can be preempted. But they added goroutine preemption in Go 1.14 so in practice there aren't really any significant differences to threads, at least in semantics. (At least as far as I remember; been a while since I wrote any Go.) You can be pedantic and say they aren't technically threads but that doesn't really matter from a programming perspective.

citbl 5mo ago

We are the point now where we let LLM dictate the language?

badgersnake 5mo ago
Yeah, but then generally you pick the language your dev team are most familiar with. Or you hire a team of specialists for the language you want. Perhaps niche languages should have fine-tuned LLMs in the same way.

zuogl 5mo ago

[flagged]

shantnutiwari 5mo ago

What?? Python __is__ a boring language (it is mature and well supported) with a somewhat convoluted package manager that has gotten a lot better since that xkcd came out. Yeah, I get it, Go is better for distributing your code-- just one binary you can copy. But what does that have to do with "boring"?

tern 5mo ago

Rust, Elixir, and Go are the way to go for LLMs in my testing and experience, for this and other reasons

mohamedkoubaa 5mo ago
I have no professional experience in Rust and over 10 years in c++ but to me the decision to use rust in a greenfield project written by agents was obvious.
cpursley 5mo ago
Here’s some of the reasons it’s so good with Elixir: https://dashbit.co/blog/why-elixir-best-language-for-ai https://dashbit.co/blog/why-elixir-best-language-for-ai
- tern 5mo ago
  My intuitions for using Elixir: - Durable, 'enterprise grade' software patterns are baked into the runtime and into common, stable libraries that everyone uses - You can use Ash, which pretty much entirely solves architectural considerations for many types of backends - The tooling for inspecting and enforcing style (tidewave, credo, dialyzer, Dan's "vibe" ecosystem tools) is far beyond what I see in other ecosystems - Ecosystem coverage for pretty much everything you need, including numerical software - Excellent performance escape hatches (NIFs) And, as has been shown in various benchmarks, agents are quite good at it. My one problem in practice has been that getting tests right is hard. LLMs need a lot of cajoling to not build flaky tests with all the concurrency, and I find myself spending hours rewriting parts of the test suite once or twice a week.
  - cpursley 5mo ago
    Is ex_slop one of Dans? That one is great. Been looking for an equivalent in Swift.

jmull 5mo ago

This 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 language (and related setup/environment) you're familiar with.

embedding-shape 5mo ago
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.

perlgeek 5mo ago

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

chuckadams 5mo ago
Excessively verbose syntax to express concepts is something I can let an LLM paper over, but a language that does not even function properly without the ceremony is still a non-starter. I want to refactor chains of operations without having to check for errors myself after each step, and I want that with or without an LLM.

xnx 5mo ago

Also use boring languages without LLMs

tracker1 5mo ago

For myself, I've generally setup a few boundaries... for JS projects, I tend to use Deno for tooling, even targeting npm lately. Similarly, I've favored modern TypeScript over JS. Often Hono + OpenAPI + Zod as a set for services. I've also been doing quite a bit of Rust for web services and wasm targets, which has worked exceedingly well... similarly with Tokio + Axum, etc. I have seen very few issues with either of the above... that said, C# has been a bit more painful by comparison... I often rely on FastEndpoints for services and Grate for database migrations, and LLMs often get a bit tangled with those libraries in practice.

eithed 5mo ago

I think that this not only applies to languages, but general patterns that you use. Don't mix functional with OO. Don't mix repositories with DAOs. Don't mix MVC and MVVM. Code should be predictable in what it does and what you expect from other developers how to code. If you don't have that then you shouldn't blame LLM when it goes haywire and starts doing whatever

dnautics 5mo ago

I don't think the python package manager is the high level difficulty for LLMs doing python. I think the high level difficulty are nonlocal effects. At any given callsite, it might be difficult to know exactly what is going to happen to the data you pass into the call.

AustinDev 5mo ago
A sibling mentioned that LLMs benchmark better on elixir. Immutability and functional programming are likely the reason why it benches better.

znnajdla 5mo ago

Instead of empty theorizing, we should have benchmarks for this. There is at least one benchmark which suggests that LLMs are better at writing Elixir than most other languages: see the AutoCodeBenchmark.

jryio 5mo ago
Send me an email I'd love to make one
justinhj 5mo ago
Thanks for the tip. If they are representative the results are quite surprising. Anecdotally, I always thought Go would be on one of languages LLM's were best at. https://github.com/Tencent-Hunyuan/AutoCodeBenchmark/blob/main/figures/exp_acb.png https://github.com/Tencent-Hunyuan/AutoCodeBenchmark/blob/ma...
- vunderba 5mo ago
  In my experience, LLMs are pretty good at writing Go code. In fact, that’s one of my principal use cases: I have a number of bespoke Node programs from many years ago that usually run in the background on my computer. Each process (with the Node runtime engine) consumes about 50–100 MB of RAM. One of the first things I tried was using large language models to help port them over to Go. Since the model has a point of reference (the original Node program plus its unit tests) it’s been easy to use a test-driven approach and ensure the Go version maintains parity with the originals. Memory usage usually drops from around ~50 MB to about ~5 MB per process, which really adds up when you’ve got a dozen of these programs running at once.

KaiShips 5mo ago

[flagged]

TheGRS 5mo ago

I can probably fix package manager issues by hand, and quickly with a little rubber ducking with the LLM itself. I'm not sure that's a huge problem in the grand scheme. There's a lot of stuff in Python's favor in regard to coding with LLMs: its wildly popular so there's a lot of references for the right and wrong ways to use it, it can be typed using included libraries - its as simple as telling the LLM "use typing for this", and there are several great lint and unit testing tools to cover the hallucinations and poor decisions. The flexibility seems like an advantage to me personally, but I've always been a Python stan.

mountainriver 5mo ago
Why choose a significantly worse language when you are writing it in the same English either way. It’s increasingly obvious that whole swaths of developers will just continue using the language they did before LLMs “just cause” It’s more identity based at this point. My LLMs write Rust for me and I couldn’t tell you the difference outside of it being way faster and more reliable
- TheGRS 5mo ago
  For immediate term you should stick with what you know. I think that makes for much better prompting where you are coming in with experience with the language and the general style you'd like to see. Rust is a language I would like to adopt longterm, but its not one I can easily grok and so my output would be worse for it.
  - mountainriver 5mo ago
    I think that's fair, but I honestly can't tell you if I'm writing python or rust anymore. When I review I just ask Claude to add comments to all the code to make things clear as I review

bluegatty 5mo ago

"The concurrency model is the first of these. Goroutines are a far more tractable primitive for coding agents than threads, callbacks, async/await, or any of the colored-function regimes that dominate elsewhere. They are simple, type-safe, and ubiquitously used in the corpus the model was trained on. There is no question of what color your function is, because the question does not exist." I don't really buy the intuition (aka Goroutines are more 'clear' than 'coloured' functions or threads), and there's no evidence presented for this either. Although this could very well be true, I'm doubtful without seeing some real world data points. The 'general premise' aka 'cosine similarity' may have been true before bit it may not be that anymore. AI just pretty good at anything it's 'seen enough' and that's it, I think it's more likely a 'threshold' problem than an ability problem, at least for most things. 'Rust' may represent a different domain, given the very detailed nature of notation and the vast possibilities that arise from that.

dionian 5mo ago

Large codebases are much easier to manage with type safety. Not a fan of Go but definitely much better than python in this regard.

jryio 5mo ago

Author here, wasn't expecting this piece of writing to show up on HN. The specifics of Python were chosen only due to the language ecosystem being fragmented and inconsistent while Python remains an essential learning, research, and now ML programming language (it was my first language and I still love it). My thoughts on LLM generated code have changed immensely in the last 9 months as I've taken on teams and projects through my consulting work [1] as a fractional CTO. Python remains a difficult, flakey, and inconsistent programming language for complex production systems. Most other programming languages suffer from fragmented toolchains and ecosystems: JavaScript (famously), PHP, and even C/C++ to a degree. Languages with a single way to do things benefit the most: Ruby, Rust, Swift (even). Low entropy is the way to go and convention > configuration seems to pay off with LLMs. Mean cost of management is more important than specific edge examples "X company run on Y language". I think that 'boring' languages with rock-solid compilers, toolchains, testing frameworks, and package managers make for high return on engineering time and production maintenance. [1]: sancho.studio

e12e 5mo ago
> Languages with a single way to do things benefit the most: Ruby I love ruby - but surely it's closer to Perl and "There's more than one way to do it" - than python which generally strives for "There should be one-- and preferably only one --obvious way to do it."? https://legacy.python.org/dev/peps/pep-0020/ https://legacy.python.org/dev/peps/pep-0020/
- dasil003 5mo ago
  In practice, Ruby is much more opinionated than Perl, mostly because of Rails being the catalyst to drive mass adoption of Ruby. So you basically have Rails, and then the RubyGems/Bundler package management was pretty linear. There's no equivalent of python2->python3 schism and the package management churn, and more stylistic continuity since ruby adoption is lower and more concentrated in the 2005-2015 time frame compared to python which had greater diversity of adoption and use cases both before and after the Web 2.0 era. I do feel pythons explicit imports and cultural aversion to meta programming win it some points. Overall though it kind of feels like a wash and I still choose the language based on the some criteria I would have used before agentic coding--claude does fine with either.

gregman1 5mo ago

Haskell is I think a great language for llms - just make everything as pure as possible and you are golden.

dogleash 5mo ago

>Languages and ecosystems with low variance in their training corpus are represented better and executed more reliably by coding agents. Just narrow your window of thought to easier problems for the LLM, and all of a sudden the LLMs do everything you want! Reminds me of playing around with image generation models. Someone who's been practicing can crank out prompts for really impressive images back to back. But you try to use an everyday object or concept the model isn't trained on? Everybody will race to show off how smart they are by saying "just don't hold it like that."

badlibrarian 5mo ago

My experience a year ago (back when half of HN was still in denial about what was already working, let alone what was to come) was that Python was the linqua franca of LLMs. You could achieve almost anything that fit in 700 lines or less if you told it to write it in Python. Times change, and I work more in R&D space than on legacy codebases, but I still ask it to write something in Python then convert it to the actual language on occasion. I don't know if I'm tricking the context window, forcing alternate pathways, or both, but it works.

roughly 5mo ago
> Times change, and I work more in R&D space than on legacy codebases, but I still ask it to write something in Python then convert it to the actual language on occasion. I don't know if I'm tricking the context window, forcing alternate pathways, or both, but it works. My experience with LLMs is that they perform best in one of two modes - either one carefully scoped context or translating between two different contexts without modification - so this modality lines up with that fairly nicely: think in the programming language the LLM thinks "best" in and then translate that to the one you want. That said, there's often enough structural and conceptual differences between languages that a direct "transliteration" between, say, Python and Go is going to result in some fairly crummy Go, so I'm curious what you see in terms of the fidelity of that translation - do you mostly get "Python written in Go," or does the LLM really do a proper conversion from one language to the other?
- badlibrarian 5mo ago
  I have strict context in place on what I expect from the final language (C# or C++) and I'm frequently left with my jaw open. Used my preferred json library on C++, used LINQ appropriately in C#. Mapped AWS libraries appropriately and used existing credential stores. Certainly better than what I got when I asked for the native version first, which is why I do the hurdle. It feels hacky but it works. In a year it probably won't be necessary.

Animats 5mo ago

I wonder what we end up with as an LLM-friendly programming language. It's likely to be something rather formal, with entry and exit assertions. Humans hate writing those, but LLMs need them to keep them on track and give them goals.

sunshowers 5mo ago

In my experience, LLMs benefit greatly from the existence of sum types and exhaustive pattern matching.

jaen 5mo ago

LLMs have a limited context window - similar to the limited attention span and memory of humans. LLMs also have trouble attending to many constraints at once. Therefore the best language for agents is likely the one that, on one hand erases all irrelevant details (ie. raises the level of abstraction and does not force focusing on eg. memory management), and on the other hand encodes any domain-relevant details in the code (eg. using advanced type systems, annotations, contracts, spec-like tests eg. property-based). Human readability is a separate concern and still relevant, but the two mentioned properties actually generally improve on that as well (at least for engineers persistent enough to scale the tower of abstraction). Based on this, it seems Go is certainly not that "agent endgame" language. It has large amounts of boilerplate, a general lack of safety around concurrency features, a pretty middling static safety story overall with a generally underpowered type system. I don't think the perfect language exists, yet, but just wildly imagining, it would probably be something like a cross between Scala, Elixir and Lean (or equivalents). Unfortunately none of those languages also have the large training corpus required to make them perform well in all agenting engineering situations (yet). For any language comparison, one must separate the expressiveness of the language, which limits the long-term possibilities for agents, and the training corpus, which is what mostly gives it the current standing. I think we are still in the phase where the languages are separated by essentially random non-design factors such as the amount of training environments the frontier labs are willing to create for them. Given that, the syntax does not matter all that much, as long as the base language itself is flexible enough - as a another wild idea, it's also possible that eg. Python could mostly swallow all these features through external tools (eg. the pre-existing type checkers or linters), and if the frontier labs bother to RL on those tools, that would also work (see also: Mojo).

devin 5mo ago
I know Clojure misses the mark for you in some major areas, but having a real, proper REPL for an agent to interact with makes for an extremely strong feedback loop. IMO, a strong candidate for an "agent endgame" language has this.
- jaen 5mo ago
  I love REPL-driven development, and exploratory "programming" via small snippets is likely part of the endgame (the more the agent strays outside its comfort zone, the more it's needed). It also looks like it paradoxically saves context, since piling up many small snippets is still better than trying to fix a one-shot gone horribly wrong. And yeah, if Clojure had a better static safety story, it would actually rank high, since it's high-abstraction with metaprogramming capabilities, excellent runtime specifications, and has a good "garden path" ie. natural code is good code. (As a devil's advocate though, REPLs can be replaced with gluing together scripts with ad-hoc state/caching via the file system, which LLMs seem to be pretty good at already...) So as an addendum, introspectability is also important ie. allowing to discover the state and composition of the system at any moment - though that's partially a language (eg. reflection) and partially a tooling (eg. debuggers) issue.

janpeuker 5mo ago

Great post showing the ironic revenge of opinionated architecture in times of cheap code. Exactly what LLMs can’t deliver, they always seem to be bias towards added complexity, not simplification.

tlonny 5mo ago

I think _some_ but not _too much_ typechecking is the sweet spot for LLMs. Without any typechecking, LLMs obviously find it harder to work agentically and validate their work. With too much typechecking (I'm looking at you, rust), I've found agents get themselves stuck in local "architectural minima" and end up doing insane shit to mitigate ownership/borrow-checker issues inherent in the design they ended up with. That said, if you're hands-on I think rust is a fantastic language for pairing with an LLM.

itpragmatik 5mo ago

Java 21, Spring Boot 4.x, Spring AI 2.x - probably most boring stack that is working fantastic for me to generate solid, reliable code for agents, mcp servers using Claude Code or Cursor.

haolez 5mo ago

This made me remember of a benchmark that I saw a few months ago about LLMs being unexpectedly _very good_ with Perl when compared to any other language. I couldn't find it right now. If someone knows what I'm talking about, please post it here :)

gertlabs 5mo ago

When you're working on something difficult that requires a model to reason intelligently, lower level and strongly typed languages often outperform on the same problems [0]. We have a few hypotheses about why, with a moderately high correlation between performance and token density of the output program -- i.e. more token dense languages are more difficult for programs to reason about. Most models come up with the least effective solutions when writing Python. [0] https://gertlabs.com/rankings https://gertlabs.com/rankings

ajb 5mo ago
That's a very interesting page, but the language ranking is wildly different for "average percentage" (python bottom) and "success rate" (python second). Sounds like there is some subtly about this.
- gertlabs 5mo ago
  Success rate is essentially loading/compilation success + ability to adhere to the environments' rules. For one-shot responses, the majority of failures are environmental/syntax, which naturally favors interpreted languages. For longer agentic coding sessions, models solve the environment issues quickly and it becomes a fair comparison of who comes up with the smarter solution. You can filter for that here: https://gertlabs.com/rankings?mode=agentic_coding https://gertlabs.com/rankings?mode=agentic_coding
christophilus 5mo ago
I ran a little test with Go, TypeScript, Clojure, F#, Haskell, and Rust. Token count was roughly in the same ballpark, but it used the fewest for TypeScript, then Go. The rest required a bit more. Clojure always won in terms of lines of code though, generally coming in at 1/2 the size of the Go or Typescript solutions.
- iLemming 5mo ago
  I bet you have not tested it with live Clojure REPL. When you give the LLM living, breathing REPL, it stops guessing and starts empirically analyzing current state of things and produces working solution faster, costing far less tokens. This article doesn't seem to mention it either https://martinalderson.com/posts/which-programming-languages-are-most-token-efficient https://martinalderson.com/posts/which-programming-languages... even though states Clojure to be the most token efficient. I personally, honestly don't care much. In my opinion (using LLMs with multiple different languages), specifics of PLs don't matter to the point of stating a "clear winner". It's not the language that matters but the "stories you tell" with the language. And greatest stories sometimes told in the languages people long forgotten.

sorenjan 5mo ago

Why are we having computer programs generate source code in the first place? Shouldn't they generate something lower level, like an AST or some computational graph or something? Source code is made to be written and read by humans, and is then translated into machine code via various transformations. In theory a program should look the same to a computer no matter which language it started out as. We have decades of compiler research, static code analysis etc, why do these extremely complicated black boxes of billions of parameters have to produce readable source code as their main output?

JadeNB 5mo ago
> Why are we having computer programs generate source code in the first place? Shouldn't they generate something lower level, like an AST or some computational graph or something? Source code is made to be written and read by humans, and is then translated into machine code via various transformations. In theory a program should look the same to a computer no matter which language it started out as. Presumably because LLMs are trained on corpora read, and for now still probably mostly written, by humans, rather than on corpora consisting mostly of ASTs or graphs?
carlostkd 5mo ago
In 5–10 years there will be no more code written by humans.

suis_siva 5mo ago

My experience is that higher-kinded languages (ie. Haskell) allow for "controlled chaos". I design a type-system, the higher kinded types, the interfaces (though it's getting rarer I need to do this) and I let Claude slop the implementation. Additionally, fault-tolerant languages such as Erlang/Elixir allow me to not worry about the billions of edge-cases, and let Claude aggressively implement a mostly good-enough application. With LLMs, accepting a limited amount of failure may be a necessity (depending on the business/domain), and that's exactly what the BEAM enables.

keithnz 5mo ago

I think use any language that can achieve / or is close to native speed and has a reasonable ecosystem of significant libraries around it. Trivial libs are pretty much dead as AI will implement what you need, so if you need something like MQTT, its much easier when you have mature lib that handles that. I've experimented a bunch of language with LLM, like Go, Rust, C, C++, C#, Kotlin. All work fine. My decision on what to use depends on what the larger ecosystem provides and what I'm programming for (embedded, backend, Web, GUI, App etc). I'd probably add in swift if I get around to doing iOS stuff. There's no real "best" here, multiple options are likely going to be fine choices. Crazy thing is, if you don't like your language choice you can use AI to change it (ideally early on). Just for fun I got AI to convert one of my TUI apps to various languages. Went reasonably well.

trees101 5mo ago

Anyone use this stuff with Delphi? I've been looking for tips for getting the best out agents for Delphi

fmxexpress 5mo ago
I use it with Delphi. Claude Code with Opus 4.7 works fine. It can use FPC in Delphi mode so that it can test itself. I'm doing greenfield and not an old project though.
- thijsvandien 5mo ago
  Care to share your specific setup/workflow? I'd be interested.

iLemming 5mo ago

[dead]

zane_shu 5mo ago

[flagged]

cpard 5mo ago

* Large language models amplify inconsistent technology and quietly reinforce consistent ones. * This is another way of saying that the tools you equip the LLM affect their effectiveness, in other words, the harness you build around them matters and matters a lot. At the end of the day, the language you pick, enriches the harness with the toolchain, libraries etc. it offers. This is most evident with the toolchain as the author mentioned but if you think about it, picking a specific framework that constraints the choices the model can make (e.g. the Ruby on Rails example) is also affecting the behavior it has.

dr_kretyn 5mo ago

I'm developing a terminal agent (https://GitHub.com/laszukdawid/trrminal-agent https://GitHub.com/laszukdawid/trrminal-agent) in golang and can't say that it's easier or less error prone to write it in golang vs Python or JS. There's still plenty of bad ideas and bad code being suggested by Claude Code / Codex so it's still hands on work. However, testing is much easier and it makes me think more about the arch more than with Python.

synergy20 5mo ago

kind of agree here, golang is my main LLM language. for low-level, it's C or Lua, or modern c++ for simple cross-platform system daemons.

gemsquared 5mo ago

[flagged]

justomsharma 5mo ago

Though I dont know GO, but reading your post - really have me thinking that okayy this is a cool and easy language too But as someone who is working in python since ages - I guess it is pretty much easy too, and as not as hard as you described. LOL, but whatever, your this post was really amazing

Decabytes 5mo ago

Just want to throw the other Google language into the ring. While I would say Dart has a few more fancy language features than Go, it has an extremely strong and modern cli tool, which is a one stop shop for all your formatting, linking, and project building needs. It even grades how well your project is constructed before you publish it to pub.dev

nylonstrung 5mo ago
What does it bring to the table that isn't achievable with Cargo? I just feel like Dart doesn't offer enough for a fairly standard OOP lang which isn't particularly fast and doesn't have the library ecosystem or vast training data of Rust, Go etc
- Decabytes 5mo ago
  > What does it bring to the table that isn't achievable with Cargo? Speaking purely about the cli dart devtool (flutter and debugging) dart compile (More options but the big one is JavaScript transpilation) dart info (outputs diagnostic information about installed dart toolchain) > which isn't particularly fast Against other programming languages that are also garbage collected Dart compares favorably, though it's implementations of things typically aims for user accessibility over maximum performance. For example a Dart Isolate is much more heavy weight than a goroutine due to it's higher startup cost and additional memory per worker. The advantage is that it has its own memory, own event loop, and communicates with other isolates only by message passing, so it's much harder to mess up. But where Dart shines for me is in two instances. The first is as a Python programmer that wants to work in a statically typed, ahead of time compiled language. Dart fits the bill here, and covers a weakness many programming languages have which is user facing GUIs. I would argue nothing comes close to Flutter when it comes to slapping together cross platform GUIS that just work. Dart is also very good on the front and backend (with more emphasis on the frontend) of web development, and can be integrated into an existing project very well through it's ability to compile into JavaScript. Typescript definitely eats Dart's lunch here, and Go more so for the backend, but very few languages can do Webdev in a way that feels natural and due to many design decisions of the past Dart is better than most. So Dart is good for packaged user facing apps. This also makes it a strong contender as the higher level language to pair with a lower level language. You mentioned Rust, and Dart has a Flutter Rust Bridge^1 which allows you to write normal Rust code that automatically has the glue code generated. The native code interaction story gets even better through Dart's Hooks^2, Which allow you to integrate and compile or download native assets into your Dart projects directly through Darts build interface. > doesn't have the library ecosystem or vast training data of Rust, Go etc LLMs are better at handling niche languages than they have ever been. And the fact that Dart is not applied broadly, in the same way Python is, means you don't need a million examples to cover the most common use cases. 1. https://pub.dev/packages/flutter_rust_bridge https://pub.dev/packages/flutter_rust_bridge 2. https://dart.dev/tools/hooks https://dart.dev/tools/hooks

impulser_ 5mo ago

I have tested almost every language and Go is pretty good but for some reason LLMs get paranoid over races and just start spamming locks next thing you know every fucking struct has mutexes and every function has locks lol. The best language I have seen an LLM use was Kotlin. It actually surprised me how well it wrote the language. I wrote a project in it and I think I didn't have to correct it once. Like I was seriously impressed. I just wish Kotlin had better tooling so I didn't have to use gradle or maven lol.

byrohitrajan 5mo ago

[flagged]

zuogl 5mo ago

[flagged]

ffzlff 5mo ago

In the future, we might need a new layer for LLM programming, the layer is more boring and more standardized

kstkrv 5mo ago

Gleam is a new kid, but it seems to fit this trend: - Less ways to write code; - Strongly typed; - Erlang parallelism; - Exhaustive pattern matching; - No nulls (and many other stuff); - Pipelines (not sure about LLMs, but it fits my eye);

ljosifov 5mo ago

+1 for boring. Boring code is Solid Code, in the sense of "Writing Solid Code" - the old book by Steve Maguire.