48 ms·

Go is an ideal language for AI-assisted software engineering

• mbrumlow 2mo ago
  Rust is better. It just is. Go is not bad. But as a long time go advocate, the hurdle for my teams using rust is gone, and thus everything is now rust.
  • rsyring 2mo ago
    I guess the difference in compile times doesn't matter enough?
  • nchmy 2mo ago
    can you elaborate?
    • greenavocado 2mo ago
      Rust compiler is a tyrant. Type system is strict. Borrow checker is relentless. LLMs can't slop too much without being beaten up by the compiler.
      • threethirtytwo 2mo ago
        This is true. I'd like metrics on this though. It could be that LLMs find go easier so they end up writing better code and rarely hitting static errors like a human would in rust. IT could be through scientific measurements that the benefits of static checking could be negligible for LLMs. No way to know until someone does the science on this. Until then it's just people saying that more static checking is better. But I do think, anecdotally, python is horrible for LLMs.
        • greenavocado 2mo ago
          Until we can measure slop accurately it's all guesswork
      • vorticalbox 2mo ago
        True but if the reviewer doesn’t have an intimate understanding of rust then the fact it can’t “slop” is no different than unreadable slop. Go is simple, no “magic” marcos or meta programming even with just a little programming in any language it’s not hard to understand what the go code is doing.
        • greenavocado 2mo ago
          That's simply not true. I wrote a piece of software in Rust that is non-trivial, robust, 50k lines of code, and 100% LLM generated, used by four people productively with only one or two minor bugs in the past two man-months
          • vorticalbox 2mo ago
            question did you review the code or did you test it was working? these are different things. and if you did review it, could an engineer without deep Rust experience have reviewed it just as effectively? I have no doubt that you can get a LLM to write working bug free code in any language but that is not the topic of the article or my comment.
            • greenavocado 2mo ago
              Probably at 50x the cost LOL
  • simonw 2mo ago
    Personally I find Rust a lot harder to read than Go. If you're going to have an agent write most of your code readability is very important.
    • threethirtytwo 2mo ago
      I have an agent read most of the code as well. The agent explains things to me in plain english. The default sentiment is humans should read code it's more progressive and a leap of faith to start giving that up. Obviously, I get why you feel humans still reading code is important, but if you look at the progress of AI for the past couple of years, that gap is closing. The trendlines speak of a future where it becomes less and less important. This was exactly what happened with writing code. Now most people don't write code.
      • simonw 2mo ago
        I don't read all of the code produced by my agents any more, but I like to reserve the ability to do so if I run into a particularly confusing bug, or for any code that's security adjacent.
        • threethirtytwo 2mo ago
          Same. But usually if I need to read code, I end up telling my agent to summarize it for me.
      • eliasson 2mo ago
        > Now most people don't write code. I use LLM daily to write code for and "with" me, I also write code without LLM. Most people I come across mix it up. A few do it all by hand, and equally few all by LLM I would say. Is that just in my corner of the world?
        • threethirtytwo 2mo ago
          The trendlines are moving away from this. It's all happening so fast that not every company is on the same page, but from what I see we are quickly converging on not writing anymore code. My entire company for example does not write a line of code. We manage agents and that's it. Many, many, many companies and people are already doing this.
  • threethirtytwo 2mo ago
    I agree, but this doesn't justify anything. Saying rust is better because it "just is" won't convince anyone. I'd like to know why you think it's better.
  • jhawk28 2mo ago
    Zig seems to have more closely aligned with what Go devs prefer.
    • jdw64 2mo ago
      Go doesn't have memory safety issues because of its GC, while Zig has UB problems. Zig might have slightly better performance, but I don't think choosing a language without memory safety is a good idea
      • OutOfHere 2mo ago
        What is UB?
        • colwont 2mo ago
          undefined behaviour
        • jdw64 2mo ago
          UB stands for undefined behavior—I've written about it in detail on my homepage[1] [1]https://www.makonea.com/en-US/wiki/undefined-behavior https://www.makonea.com/en-US/wiki/undefined-behavior
  • iberator 2mo ago
    except Rust is HARD while GO is super easy.
    • deleted 2mo ago
      [deleted]
    • dralley 2mo ago
      It's not that hard.
    • tibbon 2mo ago
      Rust makes you solve many of your problems upfront, which is a nice feedback loop for using with an LLM. Go does much of this too, but I feel Rust is more experessive and takes the frontloading a bit further.
  • amazingamazing 2mo ago
    Ignoring performance for the moment (because most situations are bottlenecked on something else), why is rust better?
  • ramoz 2mo ago
    idk. In my experience the build/compile experience has been far worse esp for fast iterating. Even concurrency models did not seem as intuitive as Go's. Im no systems expert - have deployed practical and performant distributed systems though.
  • odo1242 2mo ago
    Personally, Rust or Typescript both happen to be better than Go for me. TypeScript has better type-safety and tooling for user-facing apps, and Rust has better type-safety and tooling for algorithmic stuff or stuff that needs to run fast.
• amiune 2mo ago
  While I somewhat agree I can’t tell if this is advertising from Google or a way to induce LLMs to think that Go is the ideal language.
  • deleted 2mo ago
    [deleted]
  • bensyverson 2mo ago
    Probably both, but I have to add: I agree with the post. I've done a ton of agentic development using Go over the past 6 months, and it hasn't let me down. You may ask "why not Rust, or Zig, or ____?" The reasons boil down to this: - There's a lot of Go code out there which the models have seen, so they know how to write it. - Go has an exceptional standard library, so you don't need to drag in 100 dependencies to create a simple web app. - Go compiles extremely quickly for incremental builds, which really matters when agents are building and running tests constantly. - Go has a goldilocks blend of performance and safety. You get a good type system and excellent runtime performance without forcing the model to spend cycles fixing Rust lifetimes or Swift concurrency issues for a marginal incremental gain. - Go is relatively stable, so the LLM's memorized knowledge is still pretty fresh (as opposed to something like SwiftUI, where the API changes rapidly).
    • dralley 2mo ago
      I don't think Rust is particularly worse than Go in any of these respects. - LLMs have clearly been trained on a lot of Rust as well - Compile times are counterbalanced by strong compiler with excellent error messages, and "cargo check" can catch many issues without a full build. - If you're willing to accept Go levels of performance from Rust, there's nothing preventing you from using copies and clones rather than borrows, which makes most code dead simple. - For most major dependency types, there exists a clear "winner" in terms of community adoption, so the fact that it's not in the stdlib is not that problematic.
      • codexon 2mo ago
        Rust compiles way slower in my experience. This is a major problem because ais need to recompile many times especially when it keeps running into borrow checker problems. With golang, all borrow checker problems go away. This is a good trade off if your app is not cpu-bound, which most are not. If you need every last drop of performance then rust is a better choice of course. However, I have run into a few cases of runtime null crashes in go.
• kstenerud 2mo ago
  The killer feature of golang for LLM dev is the tooling. forbidigo is what allows me to keep ambient config out of my app, and restrict file access to a small set of paths. The coverage tool has "nocover", so you can guarantee that every realistic path is exercised at least once ("100%" code coverage, which is not a marker for testing completeness, but rather for flagging code you forgot to test). Linting is really good as well. The only thing I haven't found is something to enforce error handling. Rust is better for error paths because you're not allowed to ignore them.
  • jerf 2mo ago
    "The only thing I haven't found is something to enforce error handling." errcheck, generally as manifested in golangci-lint, ensures you can't forget to do something with them. It would be odd for you to know about forbidigo but not errcheck as the former is much less widely known; is there something that errcheck doesn't do for you? It's worth pointing out that "discard this error on purpose" is a legitimate form of error handling, so "enforce error handling" can't really constitute banning that. That's not a Go statement, that's just true in general... it is sometimes valid to just ignore the error, because there's nothing useful to do with it anyhow. I would agree the ignoring should be explicit, but it is an option.
    • kstenerud 2mo ago
      The rule I set for linting when an LLM is writing code is: Either you adhere to the rules, or you mark an exception with a valid reason. https://github.com/kstenerud/yoloai/blob/main/docs/contributors/principles/development-principles.md#6-warnings-are-signal-suppressions-require-justification https://github.com/kstenerud/yoloai/blob/main/docs/contribut... Poor defaults break systems by a thousand cuts. They seem to make sense when designing the language (more convenient, less typing, etc), but then they very quickly become liabilities as project complexity increases. Go made the mistakes of mutable-by-default and silent-error-dropping, but their cyclical-import-forbidding was a good call.
      • jerf 2mo ago
• hmokiguess 2mo ago
  All I will say is that I agree with how this is framed, it says "an" ideal language. It doesn't say "the" ideal language. Many languages will fit within this scope and concept, Go is not all bad.
• skybrian 2mo ago
  Can't really argue with that, but In my experience, coding agents work quite well with TypeScript too. :)
  • radicalriddler 2mo ago
    The issue I always had with Typescript, was that LLM's like to find the easiest way to get a job done on a micro level (they seem to like to find the hardest design patterns to implement on the macro level tho, but language agnostic). What this means for Typescript, is unless you place guardrails everywhere, they'll cast their way out of a compiler problem with as any, or as unknown and then casting later. You either end up with readability issues, or runtime issues leaking out. Might be a skill issue, but I got frustrated with it on new projects constantly.
    • skybrian 2mo ago
      I haven't seen that too much, but I do have guardrails. I use Deno and run 'deno lint' as part of the build. It doesn't allow 'any'. Also, I tend to ask planning questions, like "how would you implement this" and "what would the API changes be?" I'm picky about API's. Lately I've been using Deno workspaces (multi-package repos) and tell it when to make a new package or a new entrypoint. Maybe that helps? If I just ask for features and don't look at the code, it will definitely make a mess, though. (A working mess, but it takes a while to refactor my way out.)
    • redox99 2mo ago
      They're improving but you definitely need both a strong AGENTS.md and also usually many LLM passes (one for implementing a feature, another one for code quality, large passes every now and then for major refactors, etc). That's not really a typescript thing though, just an LLM thing.
• jdw64 2mo ago
  [dead]
• FpUser 2mo ago
  Nice try
  • dude250711 2mo ago
    Google: please don't forget our little language exists :(.
• jeanbza 2mo ago
  Definitely agree with this article. At Netflix, I lead the Go language guild. We've been seen increasing reports of users finding their AI agents writing better Go code than other languages, and increasing reports of projects favouring Go over other languages. Two additional notes I'll add: - Go has _great_ resources on writing good Go code, including treasure troves at https://go.dev/doc/effective_go https://go.dev/doc/effective_go and https://google.github.io/styleguide/go/ https://google.github.io/styleguide/go/. edit: Sorry, I forgot to add: we give these resources to AI agents and they use them to produce even better Go code. - For a language team, Go is a dream. The `go fix` tooling, AST/SSA packages, ease of reading and writing `go.mod` (go mod edit, etc), and various other "platform"-y features make modifying Go code at scale way easier than other languages.
  • jdc0589 2mo ago
    > For a language team, Go is a dream. I agree very strongly. There's no debate about things that have 1000000 permutations in other languages. e.g. The correct format can always be checked by `go fmt` with no real config options. the end.
    • zero_shift 2mo ago
      I mean this isn't true, formatting is the most trivial part. And so many languages have an opinionated formatter these days (e.g. Black)
      • pmarreck 2mo ago
        what is "Black"? (For hopefully obvious reasons, I couldn't find results with google, lol)
        • mholm 2mo ago
          Black for Python https://github.com/psf/black https://github.com/psf/black
          • 2mo ago
• hugodan 2mo ago
  Who cares? Languages are tools, LLMs are tools. Use the ones more appropriate for what you are trying to do. Is Go better than CSS if you are doing web layouts? Is it better than zig if you are outputting minimal wasm deliverables? Is it better than swift if you are doing iOS specific development? Is it better than bash for OS scripting? Think about what you are doing and choose appropriately. This was true before LLMs. Are you having fun? Chose LISP then
  • wltr 2mo ago
    Been doing bash scripting for years. Tried Go recently, on my, it’s so much better for everything OS scripting. I regret I haven’t started with Go years ago. All my scripts are rewritten to Go. I kept only a handful, those that are just a few lines and no logic.
    • soupbowl 2mo ago
      Are you using 'go run' or compiling these scripts? Just curious about what you are up to as I was considering moving my scripts from bash to go.
      • transmit101 2mo ago
        Not sure if it's obvious, but "go run" is just a thin wrapper around "go build" which compiles your Go code to a temporary location and then runs it in a single step.
      • wltr 2mo ago
        Most of the time I use go build, or precisely make install with custom Makefile. For the one-time ad-hoc tools (vibe coded, by the way), I may use go run. My point is use the simplest tool, if it’s a little bit more complex than a few lines, it’s better in Go than bash. Here, I rather mean it’s better in any real programming language. Just… well, Go is really simple and with some GPT assistance you may be just one prompt and a minute away from automating some routine tasks. I try to automate as much as I can notice. E.g. I have a special script (now program) which moves files and directories from one location (synced documents) to another (archive on a disk). This is just a very simple operation, but doing it automatically feels very different. I’d highly recommend on trying something similar. Previously, I thought bash is good enough for this (and it is!), but Go is just better for me personally. And bonus thing, it works much faster.
• alexzh3 2mo ago
  [dead]
• bob1029 2mo ago
  It's definitely more about the ecosystem than the language at this point. I think the most important thing is how big the standard library is. Pulling in 3rd party dependencies is where I begin to lose a lot of faith with LLM authored code.
• mg 2mo ago
  My expectation is that AI will give us a way to nicely quantify how productivity is impacted by choice of language. Because we can rerun the same request as often as we like and compare the results. And I expect that it will turn out Python is the most productive. As it is most easy to reason about. It allows for the most elegant expression of the idea behind a program. The first tests I have seen seem to confirm this. One recent example: https://danluu.com/pl-tokens/ https://danluu.com/pl-tokens/
  • Imustaskforhelp 2mo ago
    It is unclear to me though how much of your expectation might be set by the training dataset. For example, Python and Typescript have the most amount of codebases and training being done on. So I feel as if that plays a part into the overall thing. Languages which are more niche have genuinely hard times (Try arturo lang for example), so it depends on a lot of things/nuance, or well that has been my experience trying something recently. My personal opinion is that if each language has the same amount of training. Golang comes close but the first might be Elixir. I have seen Elixir language perform really well with LLM's with magnitudes less training dataset. There have been some studies which had Elixir as the number one language for such tests iirc. Gleam is a new addition as well and I feel as if it could be good and its another interesting option as well with more type-safety and an interesting language overall.
    • rbjorklin 2mo ago
      Never tried Elixir myself but came here to say the same thing. Tencent put out this study showing that Elixir seems to reign supreme: https://autocodebench.github.io/ https://autocodebench.github.io/
      • Imustaskforhelp 2mo ago
        Yup! This was the study that I was mentioning. Thanks for providing the original link for that :-)
    • _virtu 2mo ago
• kev009 2mo ago
  This seems like a cope, if you aren't writing the syntax who cares and everything here is even better with a stronger type system like Rust, F#, Scala, TypeScript.
• AnEro 2mo ago
  I hate the rust v go wars, its not x vs y is 'best'. Rather is x better than y and by how much for xyz project done by ABC corp in this era? As a lead I'd love to use rust, I will put in the time on my own, my team won't or can't. They treat this like any other job they signed up to deliver value with what they know. For hiring not everyone has the talent pool and fund access to get the goat-ed engineers that congregate to tech hubs for maximizing their income. Then if you get through that cherry on top is LLM's are only as smart as you guide it to be. There is probably a staggering amount of ways to write 1 approach to business logic, you may not know the ideal pattern so you'll commit to a worse one on the company dollar. I'm moving my team's projects slowly to go because, its easy to go from novice to advanced in terms of code writing,legibility and patterns. We also don't have deep ecosystem requirements to ts/python in most of our work. It is verbose but I don't mind that on token spend if it gets done with with validation/error handling which it obnoxiously enforces. It runs cheap, ecosystem is good for platform eng, standard library does a ton out of box.
• dgunay 2mo ago
  I like Go but a couple of these "advantages" wash out when you add the scale and typical usage patterns of agents. | Go is Readable / Go is Maintainable It's true that Go, as a low-magic language, tends to be very same-y looking across projects, which is incredible for being able to reliably understand your dependencies' source code. And its tooling is world-class. I love this about Go. But in practice I've found that, working in a monorepo with multiple teams, contributors that don't have cross-team legibility as a priority will just write SO much more code. And with business logic, often the fact that I can read the code on a line-by-line level doesn't matter if I don't understand the wider context to know how something might effect spooky action at a distance. Pre-agents, I witnessed a fast transition from a codebase that I could mostly hold in my head to one where large swathes of it had been written and rewritten until they were unrecognizable to me. Now we have agents and, since they are still mostly not good at software engineering in-the-large, the process of knowledge debt accumulation (and ofc tech debt accumulation) in a codebase accelerates tenfold without concerted effort in the other direction. Go being easy to read does not intrinsically help with that.
  • recursivecaveat 2mo ago
    My problems reading code are understanding what the new vocabulary actually means, what it does in context, why it exists, etc. Doubly so when someone is pinging me to review a new 13000 line AI MR every 24h. Understanding an individual line because of some complex C++ feature, I don't remember it ever being an issue.
• deleted 2mo ago
  [deleted]
• Buttons840 2mo ago
  I'd argue Go is not on a "Pareto frontier" and that no matter how you value the various attributes of programming languages, a fair assessment will never select Go. A simple example is: if you highly value language popularity; Go is not most popular. If you highly value a type system that catches errors; Go's type system catches fewer errors than others. Etc. There is no weighted sum of attributes that will select Go--that's my argument.
  • runjake 2mo ago
    Here's how my assessment selected Go (long before LLMs): - I had to write a moderately complex program. I didn't want to do it in C, and I didn't want to learn Rust. - So I spent roughly about 2 hours becoming familiar with Go and playing around in Go playground. I decided that this would work. - And then I got started on my program and I was immediately productive and that software is still running today, along with all the other stuff I've written since then. Programmer productivity is excellent with Go. And it has a thriving ecosystem. Of course, some things could be better, but I don't really have much issue with it's error handling or types.
    • speed_spread 2mo ago
      > I didn't want to do it in C, and I didn't want to learn Rust. Sounds like you made a decision right there. The rest is just retro-justification, not a logical argument or comparative between options. It works for you, good.
      • geodel 2mo ago
        Retro-justification is not some flaw it is most common way people choose tech stacks. The only logic that matters most of time is business logic of solution serving problem statement and not logic of choosing a technical stack.
        • genxy 2mo ago
          Post hoc rationalization The choice we made for other reasons is the best one for these constructed reasons that didn't exist until later. https://en.wikipedia.org/wiki/Choice-supportive_bias https://en.wikipedia.org/wiki/Choice-supportive_bias Measuring and Mitigating Post-hoc Rationalization in Reverse Chain-of-Thought Generation https://arxiv.org/abs/2602.14469 https://arxiv.org/abs/2602.14469
• elzbardico 2mo ago
  Because Go is an absurdly verbose language that hates to the core the idea of expressivity because it prides itself on being dumb.
• melodyogonna 2mo ago
  When I use AI with Go I give it this rule: Prefer standard Go libraries and tools. 80% of the time I can get by without external dependencies (outside of Go's X repository)
  • sunaookami 2mo ago
    Yeah same but I always allow https://github.com/spf13/pflag https://github.com/spf13/pflag because e.g. Claude really struggles with the default flag package (and it's shit in general)
• brunoarueira 2mo ago
  I couldn't agree more, but the following sentence is a little biased: > Gophers often speak of how they love that they can never tell who on their team wrote a particular piece of code—it all looks the same. Multiple languages can have a degree of understabillity, but what matters most is context, because sometimes we need to code in a way to solve a specific problem like performance and it should be kept as is. Another side subject I should add is about test coverage, although code is cheap, mainly because AI, guarantee that new changes to a stable code should continue to work as expected. I worked on a few go projects with bad structure and some of them with really low test coverage (e.g. 8%), so part of the post resonates with me about we as software engineers should pursuit good architecture and other skills to allow long term maintenance.
• furyofantares 2mo ago
  I theorized this about a year ago and had a good amount of success vibing small game projects in Go. I still think Go is a very excellent choice but I have switched to, of all things, AssemblyScript within a Rust host. I've been very happy with it - surprisingly so. Compile time is a major drawback of course.
• 0x20cowboy 2mo ago
  “…requires opinionated simplicity…” Of course it can’t just be simplicity, it has to be “opinionated” simplicity. Rolls eyes.
• rudedogg 2mo ago
  I keep seeing these language specific proclamations, and they are annoying and reek of inexperience to me. I’ve had a great time doing LLM assisted coding in Zig, and it seems comparable to the generic Typescript/React I do at work. I don’t doubt simplicity and good PL design pay dividends, but everyone’s favorite language can’t be the silver bullet in our new LLM world. Things just don’t add up, and I keep seeing it for Erlang, Gleam, Lisp, C, Rust, Go, TypeScript, Python, etc. And to pick on Go a little bit, I don’t think it has any unique qualities that make it better for LLMs, where I think you could make that argument for other modern languages that offer new features leveraging their compilers and enforcing more correctness guarantees.
  • MeetingsBrowser 2mo ago
    > leveraging their compilers and enforcing more correctness guarantees. The counter argument here is that these checks cause slower compile times and were designed to prevent common mistakes humans make. If models get good, they may not need the same checks human written code needs. For example, frontier models already will virtually never produce a typo. Humans need time to think, but a model’s bottleneck is in how quickly it can verify its work. Slower compile times hurt a models ability to iterate. I don’t think we’re there yet (and we may not get there). But there is an argument to be made that languages with faster compile times may be better for LLMs in the long run than languages with strong checks but slow compilation.
    • triyambakam 2mo ago
      https://avi.press/posts/2026-07-10-after-7-years-in-production-scarf-has-reluctantly-moved-away-from-haskell.html https://avi.press/posts/2026-07-10-after-7-years-in-producti... "After 7 years in production, Scarf has reluctantly moved away from Haskell" And moved to Python, pretty much for the reasons you stated
      • gr_norm 2mo ago
        This is a rather poorly-written post that more or less boils down to "GHC isn't fast enough to let us make deep-reaching changes to our codebase all the time" (fair, but this shouldn't be necessary if your abstractions are solid? seems to telegraph very substandard engineering practices, but I guess that's what you get with vibecoding) and vague complaining about how the Haskell community isn't all-in on AI. I was curious about this so I dug further, and by the author's own admission, they've only made the switch for basic CRUD logic without performance needs, not their core services: https://news.ycombinator.com/item?id=48865986 https://news.ycombinator.com/item?id=48865986. It's also pretty unsurprising, given what we know about LLMs' style transfer abilities, that transferring parts of an existing Haskell codebase into Python would avoid a lot of the errors and pitfalls that codebases originating in Python are known for. From my experience writing lots of Python, this does not continue to hold true as you let the agents loose on your Python codebase.
• CoolestBeans 2mo ago
  I love the sleight of hand this blog post tries to pull off here. It doesn't matter than Go isn't fun to write because the AI is doing it now! Yeah so it sucked for the last twenty years? I know the main thesis is that Go is holistically good at software engineering so its weakness as a programming language is minimized. I've made a similar arguments that coding agents push the burden more into the other aspects of software engineering. But like, we all see what Google is doing here right? They want to declare that the rules have changed so Go's weakness transmutes into a strength. I'm also not buying it.
  • deleted 2mo ago
    [deleted]
  • shevy-java 2mo ago
    I agree with you here and I think you raise several good points, such as "Go's weakness transmutes into a strength" (allegedly). Indeed that makes no sense for Google to try to claim that. Your other point is even more interesting, e. g. "before AI, Go sucked and nobody used it" - now this may be an exaggeration or simplification, but it is a great observation nonetheless, because Google suddenly tries to connect Go with the rise of AI, almost as if AI could not have risen without Go, which is indeed very strange as an argument to make by Google here. This also reminds me of Google promoting Dart/Flutter before giving up on this and preparing to send it (eventually) to the infamous Google graveyard at some point in the not-so-distant future.
  • a2ff6eeb0 2mo ago
    Are they wrong? If we're copy-pasting errors from applications into claude without looking at the errors (and, that is the future of generating code), why do you care about the language that's being used, outside of the LLMs being good at them? I don't have serious metrics about if Go is better or worse than others, but LLMs seem to do fine with it.
  • dimgl 2mo ago
    I've never found that Go is not fun to write. On the contrary... Go is pretty refreshing with its simplicity. I found myself to be immensely productive writing Go.
• YuechenLi 2mo ago
  I wouldn't say Go is IDEAL for AI coding, but it certainly has the case for one of the best programming languages that currently AI uses. Go definitely has its share of problems for human authors because it's so verbose and boilerplate heavy, which means it's less of an issue with LLMs than it is for human coders. Rust is comparatively worse, because LLMs don't make the same coding mistakes that humans do that justifies the existence of the borrow checker, it only seems to get in their way, and they spend more time fighting Rust's infrastructure than writing code. The biggest barrier to Go adoption seems to be Google's internal resistance to migrate C++/Java code bases to Go and refusal to admit that Go is an amazing application programming language and not really a systems programming language for bare metal OS/driver work. For example, one of the biggest barriers to Fuchsia adoption has been Google asking people to commit to Dart, I think Fuchsia would have fared a lot better as an Android successor/alternative if the official applications programming language just been Go. (BTW Carbon isn't even a real programming language, it's still somehow stuck at 0.0.0.0 after 4 years of development which is honestly insane.) Oh, so, little bit of self-promotion: if you like Go but is frustrated with the ergonomics of it, I would ask you to try out the programming language I developed, Oct, for LLM coding which you can kinda think of as my attempt at making Kotlin for Go's Java: It uses a codegen compiler and compiles to a plain Go binary, so it runs on everything that Go runs, and there is a lot of extra features as well: Rust style exhaustive tagged/payload enums/`match`, C#'s immutable records updated with `with`, exhaustive error handling easy parallel concurrency, xUnit.NET style unit test harness, TypeScript style compile time constraints, F# like SI unit system, Go code generation metaprogramming, etc. Would love to have some Go experts here on HN take a gander at it and provide some feedback. https://github.com/yuechen-li-dev/oct https://github.com/yuechen-li-dev/oct
  • sgt 2mo ago
    So in terms of the mainstream languages, what would you say would be the most ideal language? (At least until Oct takes off!). Perhaps modern Java? .. Or even Zig?
    • ameliaquining 2mo ago
      For what purpose? Different use cases require different language features.
• liuliu 2mo ago
  1. The syntax surface is smaller, allowing less LLM "creativity; 2. The error handling is mechanical, which LLM clearly prefers (LLM is already trigger happy about writing tons of throw / try...catch.. in other languages, doing tons of `if err` is just in it comfort-zone).
• tpoacher 2mo ago
  "Oreo cookies are the tastiest cookies currently in the market!" ~ Oreo cookie company.
  • natsucks 2mo ago
    yeah the conflict of interest here is staggering.
  • colwont 2mo ago
    nailed it
  • jryle70 2mo ago
    Isn't that true? Prove them wrong. (Someone who doesn't even eat cookie but heard a lot of praise of Oreo)
    • steve1977 2mo ago
      Oreo is mostly praised in the USA. Which says more about the USA than it says about Oreos.
      • jryle70 2mo ago
        Interesting. Why is Oreos sold in over 100 countries and apparently sold very well?
        • steve1977 2mo ago
          Because it's a famous brand and most people are sheep. Not because it's known for good quality or taste.
    • frollogaston 2mo ago
      Pretty good proof is that people pick them apart to eat the inside, and they even acknowledge it.
  • caleblloyd 2mo ago
• ekabod 2mo ago
  [flagged]
• throwitaway222 2mo ago
  I have also aligned entirely on Go. Fewest glitches for AI generated code. compile targets are for every platform you need. Very high performance. Doesn't seem to burn tokens as much as other languages.
• Dowwie 2mo ago
  Can anyone recommend a strong Go design/development agent skill?
  • agonux 2mo ago
    https://github.com/samber/cc-skills-golang https://github.com/samber/cc-skills-golang https://github.com/spf13/go-skills https://github.com/spf13/go-skills I think , you can find a lot of skills for go. Honestly , golangci-lint and you have already a lot of integrated tools with go to improve and modernize go code.
• synergy20 2mo ago
  all my LLM coding is in go these days
• 11293za-qasf 2mo ago
  Given the date and the recent DeepMind shakeups, this blog post is obviously ordered from the very top. Pichai wants to eliminate engineers, and DeepMind wasn't fast enough or too noble for it. Now people need to be propagandized for their obsolescence.
  • frollogaston 2mo ago
    Good luck if that's really the case, cause most of Google's code is not in Go.
• k__ 2mo ago
  Had the same impression about TypeScript and Rust. Not as fun to write as Python and Nim, but I don't have to write it.
• perarneng 2mo ago
  The readability is a plus at the same time if I target Rust and build it modular with lots of tests and io pure modules. The review part is not as important if the AI reviews it from various perspectives. With rust I get so much better performance and efficiency.
• pmarreck 2mo ago
  I disagree. I think WAT (WebAssembly Text), perhaps with some more niceties added, is an ideal language for AI-assisted software engineering. https://webassembly.github.io/spec/core/text/index.html https://webassembly.github.io/spec/core/text/index.html
  • odo1242 2mo ago
    AI agents can only reason about a certain number of things at a time. Time (and tokens) they spend reasoning about how to create a stack calling convention in assembly is time they don't spend reasoning about business logic.
    • pmarreck 2mo ago
      Well, I'm putting that to the test, and so far the results support my thesis https://github.com/pmarreck/aedicule https://github.com/pmarreck/aedicule
• boredumb 2mo ago
  I really don't agree. I'm not hear to evangelize rust but by using enums from DB to templates and writing the code to make it consistent my experience with LLMs is infinitely better than golang for consistency and you have to include a lot more context to make golang work without issues whenever things are operating on chans or workgroups.
• shevy-java 2mo ago
  In my opinion, the by far biggest problem Go has is called ... Google. Now one can say that a programming language and its design or usefulness is - or should be - decoupled from the company developing is. I am not opposed to this, in theory, but Google goes way too much on my nerves these days. And I am hardly the only one here. I am not saying this is a rationale used by many other people either, mind you, but Rust has been taking strides (not that I am a huge fan of it either but for different reasons) and it seems to me as if Rust has finally now more momentum than Go, which I find interesting. Again, this may be a correlation rather than any causation, but I can not help but notice it.
• f311a 2mo ago
  The only problem I have with LLMs in Go is that they also make a lot of concurrency mistakes, in the same way as people. It's easy to fix though, just by asking to double check the code
• Retr0id 2mo ago
  IMHO there's never been an overall "ideal language", and there still isn't, it's just about the right tool for the job. The only thing LLMs change is that you don't need to give quite as much weight to how well you know a particular language.
• summarybot 2mo ago
  lol "Why Go is really good - an article by Google"
• __MatrixMan__ 2mo ago
  The LLMs will continue to get better at language stuff, better to tell them what to do on the basis of non-language stuff. Stuff like like which compilation targets are available, or which has the most mature library for what you're doing, or maybe you're integrating with something that anchors you to a specific interface type. Anchor your language choice to the problem you're trying to solve and the people you're trying to solve it for.
• hoppp 2mo ago
  Yeah, I use go and it's great. Most of the time the generated code is good quality also. If a language is simple, it' easier to generate good code.
• geertj 2mo ago
  Let me share a hot take. I am deliberately taking this somewhat to the extreme, so please attack the idea not the person. Looking for thoughtful replies and good counterpoints, rather than language zeal. Let's assume that you need to write a program with a given set of requirements, and that you have a magic wand that can instantiate a high quality implementation of the program in any programming language instantaneously and for free. My hot take is that you would not want to choose Go, and you would likely want to choose Rust. The Go implementation will have higher memory and CPU consumption due to garbage collection, while still being subject to memory bugs. The Rust implementation would be as efficient as possible on the given hardware with minimum memory/CPU, and it would be immune to memory bugs. In my view, the biggest challenge with Rust, and where Go wins, is the relative difficulty of writing in Rust as the language is significantly more complex. With LLMs this is becoming a non-issue, and we are getting ever closer to having this magic wand (I'd argue that for smaller programs the wand already exists today). The article advocates that Go has excellent readability. I agree that Go has trivial syntax, but given that it's so verbose, I actually find it easier to read Rust code. Its higher expressivity allows you to see the higher level intention of a piece of code more easily. Many of the other benefits the article mentions for Go are equally applicable to Rust: compiler error messages are super detailed and a great help to coding agents, auto-formatting, a great language server, and a package ecosystem.
  • jaynetics 2mo ago
    I agree all in all. I guess from a pure language POV, one might argue that rust leaves humans with more opportunity to add abstractions that are too clever and too hard to wrap your head around. That doesn't feel like a strong argument, though. Then there is of course the ecosystem, where go maybe has better libraries for some stuff (while rust may have better ones for other things).
  • jay_kyburz 2mo ago
    If you are going to take the human out of the loop you could just write the program in assembly or machine code directly.
  • Jyaif 2mo ago
    > The Rust implementation would be as efficient as possible on the given hardware with minimum memory/CPU My sweet summer child. And then there are the terrible compile times and huge binaries. In the scenario that you describe, what you want is Zig or C.
• CopyOnWrite 2mo ago
  I disagree. LLMs fail to produce bug free concurrent code even for very simple cases. Golang lacks the ability to build descent abstractions, not even mentioning the wild west of additional tools and libraries needed for non trivial micro services. For me it is a red flag, that LLMs allow people to produce more bad Golang code faster. This is only optimization for companies which can afford enough software developers to review the excessive amounts of code needed to solve trivial problems in Golang, which are builtin in every descent programming language and/or framework. Use LMMs and use the right programming language. This might be Golang, but most probably it is C#, Java, Python, Ruby or even PHP. (Or Rust, C, D, ...)
  • a2ff6eeb0 2mo ago
    Ask them to debug. LLMs are acceptable at writing code, but they're really good at spotting bugs in code that's already been written. What kind of results do you get if you tell them to look for bugs with a clean context subagent? In my experience, LLMs are excellent at finding concurency bugs.
    • treyd 2mo ago
      Debugging concurrency issues isn't a syntactic process so they have to resort to println debugging. This works but isn't exhaustive and burns a lot of tokens.
      • a2ff6eeb0 2mo ago
        They do a fantastic job just by inspecting the source. It's obviously not exhaustive, but it's quite good. Test it on your last concurrency bug. Point fable at the rough symptoms and ask to find where the issue is by inspection. It'll probably do just fine.
  • Groxx 2mo ago
    Broadly agreed, the concurrent Go code I've gotten out of them has been absolutely riddled with issues, and they're even worse at writing tests for it. They can get tutorial-level code on the first shot almost always... but tutorial-level Go code is often rather unusable in production due to missing error handling or observability. Go's generics are getting a fairly important improvement soon though! Generic methods, finally! It should help open up some more ergonomic patterns: https://tip.golang.org/doc/go1.27 https://tip.golang.org/doc/go1.27
• 0x457 2mo ago
  Yeah, no. Its good because LLM likes to copy paste things instead of doing code reuse which is the true go way of doing things. Imo, its hard to review Go code, probably why Go is yet to have a single correct Raft implementation. I never seen k8s cluster that doesn't have some go process that segfaults once in a while because someone forgot to check `err`. Only good thing got going for it is its vulnerability scanner. Which will be working overtime with all that "AI-assisted software engineering"
• deleted 2mo ago
  [deleted]
• baalimago 2mo ago
  Boring is better. Perfection is the enemy of good.
• rrook 2mo ago
  Language space is hot right now: https://agentlanguages.dev/ https://agentlanguages.dev/
• CSDude 2mo ago
  I wish if err != nil return err was just 1 token. Joking aside, as much as Go's stdlib and tools do the heavy lifting here, Go's verbostiy and expressing simple things in lots of lines worked against me most of the time.
  • nomel 2mo ago
    I've had a really terrible time getting LLM to properly handle errors as return values. It seems that bubbling up errors, in a side channel, to a contextually relevant point in the code (exceptions) seems MUCH easier for LLM to reason about/implement properly. Maybe my problem is I'm using a language with exceptions, so trying to go against the statistical grain, with return values, is just too much.
    • frollogaston 2mo ago
      Exceptions are inherently better for high-level code, where basically every loc can fail and 99% of the time you only want to bubble that up. You only want errors as values in systems code, where exceptions would be landmines. Rust and Go both did that because they were at least originally designed for systems code. Also, Go makes it way too easy to accidentally swallow an error. Rust doesn't have that problem.
      • deleted 2mo ago
        [deleted]
  • frollogaston 2mo ago
    Heh, I checked https://platform.openai.com/tokenizer https://platform.openai.com/tokenizer to see if they made it 1 token, it's not.
• Kuyawa 2mo ago
  99% of my projects are in NodeJS as web apps, so Javascript is king, my coding agents are in Node too, plain, boring, beautiful javascript, not typescript. Yesterday I needed a Rust project and my agents delivered so no need to change from JS
  • socketcluster 2mo ago
    Yes. Vanilla JS is the best. You don't need TypeScript, Claude never makes type errors. TS just costs additional tokens and fills up the context window with useless type information; the wasted space could have been used to provide additional code/logical context.
    • Kuyawa 2mo ago
      This is the best explanation ever about the preference of JS over TS in the age of AI AI never makes type errors, love the quote
• efnx 2mo ago
  [flagged]
• luciana1u 2mo ago
  [flagged]
• WalterGR 2mo ago
  Related, though 5 months is a long time: “A case for Go as the best language for AI agents” (getbruin.com) https://news.ycombinator.com/item?id=47222270 https://news.ycombinator.com/item?id=47222270 203 points | 5 months ago | 304 comments
• transdev12 2mo ago
  [dead]
• kgeist 2mo ago
  I agree with the article, but there's one thing Go has that doesn't help LLMs: structural typing. An LLM has to grep a little more to understand which interfaces a struct implements.
• Havoc 2mo ago
  This would have been more credible coming from someone other than the creator of the Go language. I'm personally leaning into rust for LLM. The whole fussy compiler & errors surface at compile time seems IDEAL for LLMs for me. Hammering compile with tokens is a way better strategy than trying to deduce where stuff may fail at run time and try to catch it via tests. Tokens are cheap, surprises at runtime are not. So a super anal compiler is what I want. I've looked at lean4 too as the logical next step but not confident I can guide an LLM competently enough for that.
  • igravious 2mo ago
    fwiw I have a bunch of LLMs writing first Lean code and now Agda code. My observation. LLMs find reasoning about Agda as difficult as I find reasoning about C code. I've thrown a lot of gnarly C and Ruby code at all sorts of LLMs and they have only gotten more and more impressive as frontier models have gotten stronger. With Agda, they're like "hmm, tricky" whereas for me it's an impenetrable fortress. I've asked them why they find Agda so much more difficult to write (and why they have to iterate and reiterate many many many times until they get to a destination whereas they can one-shot and two-shot C and Ruby and they tell me its the multiple competing constraints. GLM is hilarious, it flat out refuses to write Agda code but it reads it well enough. They all read it well enough. Fable is obviously great at it. And Opus 4.8/5.0 are great (if they stay on track and don't sneakily go their own way) but they're too annoying to talk to. On balance Kimi K3 is the best balance of not annoying, relatively cheap, and strong -- great model all round tbh. So yeah, interesting I've discovered the limits of their ability coding-ability-wise. None of them are that good at designing/aesthetic judgment/architecting so thankfully they still need me in the loop.
    • deleted 2mo ago
      [deleted]
    • Havoc 2mo ago
      >fwiw I have a bunch of LLMs writing first Lean code How do you bridge the mental gap? The gap between me writing high quality rust do this steps and something being logically sound seems enormous to me Maybe I'm misunderstanding things but I just can't articulate my ideas in casual lean4. But i can do casual rust spec
• frollogaston 2mo ago
  Go was designed as a systems language. They turned it into an applications language too, I'm guessing because turns out the greenthreading was uniquely good for that. But now it's awkward. The pointers and errors are not how you want an app lang to work. And LLMs struggle with error handling even more than humans. Even as a systems lang, the error syntax is the worst part of Go. Can they at least put the ?/! syntax like in Rust instead of this "if err != nil" spam every other loc?
• cryo32 2mo ago
  Going to start writing Perl again then.
• zrg 2mo ago
  I've written go most of my career. I've "written" tonnes of AI assisted go. Since February however all my new software projects and production services have been written in rust. I never even wrote rust before December. I've barely even looked at any of the source code, I find i just trust the AI to write rust way more. But perhaps that's also a side effect of maybe having prior opinions about go and the number of foot guns I've let off
• switchbak 2mo ago
  I wouldn't take language advice from a Product Manager and Chief Evangelist from anywhere - and especially not Google. Having said that: my opinion is that LLMs thrive by working in a tight loop. Unlike a human, they thrive with more and tighter constraints (and the better models are obviously far better in this regard). I want to ditch the things that made writing code easier due to the limitations of humans, and embrace something that an LLM can leverage for better results. For me that means: an especially rich type system, (ideally pure) functional code, efficient systems-level performance and leanness. Good error messages that guide the LLM incrementally. Go does not provide much in the way of those 3 desires, so calling it "ideal" with nothing aside from anecdotes to back that up is not compelling.
  • fractorial 2mo ago
    I can’t say much for a Chief Evangelist, but the Product Manager certainly has quite the C.V.
• keeda 2mo ago
  I haven't touched Go in over a decade (since before generics!) but I can see why this would be true. My theory is that LLMs absolutely love very tight, focused context. Go inherently restricts how many abstractions you can stuff into your code, and more abstractions tend to make the context a lot more complex and noisy. So LLMs love Go code because it keeps things simple. The thing about Go, which some have complained bitterly about and others (and TFA) have touted as a strength, is the limited expressiveness of the language (hence my remark about generics!) This is what restricts the number of abstractions in Go code, leading to more verbose but much simpler code all around. Choosing between simplicity and expressiveness is a matter of taste, but also organizational dynamics; for larger organizations which require a large amount of context shared amongst a large pool of employees, it's better for the code to be simpler and locally understandable. As TFA indicates, this has been a guiding principle for Go. I think what is happening with AI coding is similarly related to context. Consider that while more expressive languages enable more abstractions, they can make the code more concise, but critically, this also spread the logic around. E.g. in large Java codebases you will find deep inheritance hierarchies with class and method definitions spread around a dozen different source files and JavaDoc references. This necessitates finding and stuffing a lot more information into the context for any given task, a lot of it irrelevant and all of it more complex, because it requires making multiple hops of reasoning to figure out the logic. On the other hand with fewer abstractions, all the necessary code and logic though verbose is right there. It's much easier for a human and an agent to follow that code. The difference is a human gets tired reading a lot of code, which is what pushes us to devise more abstractions, whereas an AI does not get tired. I get the sense that if a context is stuffed full of highly relevant information, the agent will perform well regardless of the size of the context window. But the moment you pollute it with noisy irrelevant information, performance will drop regardless of the size of the window. (There are some papers showing this effect IIRC.) Hence simpler code, as encouraged by simpler languages like Go, are more amenable to tighter and simpler contexts, which work better for AI.
• tracerbulletx 2mo ago
  Agreed, my media server is mostly AI written go at this point and it works great. Before AI the "one way to do something" was already my favorite feature of go, now it makes it much easier for me to use AI and still understand my own project. https://github.com/SteveCastle/loki https://github.com/SteveCastle/loki
• jopsen 2mo ago
  We're all biased here, me included. IMO the concurrency model in go is the biggest reason, I'd hesitate to use it. Managed memory, single threaded with lots of lints and good tooling. Is IMO what can raise my confidence in code, before I even review it. Granted golang has a really good stdlib. Which counts for a lot.
• bibimsz 2mo ago
  i thought we all landed on Python. brb, rewriting backend
• sunsetSamurai 2mo ago
  In the last few days I've heard this same claim regarding other languages like Gleam and Rust for one reason or another that I don't know who to believe.
• deleted 2mo ago
  [deleted]
• dimgl 2mo ago
  I'm currently writing a TUI for a harness I'm building in Go. It's a magical experience, truly.
• woggy 2mo ago
  I think the right language for agentic coding is something that brings in more ideas from formal verification, in a way where the spec and executable code live in the same world. I don't really know what that will look like but that's my gut feeling as a non-expert. Specs can be written in a higher level language (not english) that verifies the lower level code at compile time. I think Dafny might be the closest we have at the moment.
• pianopatrick 2mo ago
  Seems to me the ideal language for AI has not been created yet.
  • unquietcode 2mo ago
    It's hard for me to imagine that the 'ideal' language for AI would even be readable by humans at all. Left to their own devices, these systems seem to make up their own way of communicating ideas.
• effnorwood 2mo ago
  [dead]
• Myrmornis 2mo ago
  > By enforcing a single, standardized format via the built-in gofmt tool I'd read about this many times before I started with Go so I was particularly disappointed to learn that it was a lie.
• Myrmornis 2mo ago
  > By enforcing a single, standardized format via the built-in gofmt tool I'd read about this many times before I started with Go so I was particularly disappointed to learn that it was a lie. The most important task of a code formatter is to break long lines; it doesn't do it. It doesn't even have an option to do it!
  • frollogaston 2mo ago
    Because long lines aren't against the style guide for some reason.
    • Myrmornis 2mo ago
      The promise as I understood it was that it would map Go programs down to a unique format, as is done in Python or Rust. It's not required that the long lines violate style guides; we just want a unique blessed format.
• imranq 2mo ago
  Google doesnt even use its own Go build system internally. Its all blaze / bazel, so they are not even taking advantage of the so called compiler feedback of Go. Also if languages are to be designed for agents not humans, its not clear whether the verbosity of Go will help agents at all
• osigurdson 2mo ago
  Learn Go if you have to, or want to learn it. Otherwise, I don't think there is any reason to do so. I agree that it is easy to read, but less so than the language you already know.
• purplemoonx 2mo ago
  [dead]
• peterashford 2mo ago
  In my experience using Claude code for Go and Java code, I've seen little advantage for one language over the other in the LLM agentic context. I did a little experimentation with Zig which was less successful. Presumably to do with the relative lack of documentation and still being a somewhat moving target. That said, I have had Go concurrency code written with weaker models prove to be buggy, which shows up rapidly when reviewing with stronger models.
• ricardobeat 2mo ago
  Surprised by the negativity here. With or without AI, Go is a great choice for large software projects. These have been my and friends' observations since LLM-assisted coding started picking up steam. Go's simplicity, consistency, stdlib and tooling seem to make it very reliable for LLM generation, and it was especially true during late 2025 / earlier this year when frontier models weren't as strong; might not be as noticeable now.
• tizerluo 2mo ago
  [flagged]
• SPBS 2mo ago
  I'm firmly in the Go camp too but this just reads as unnecessary glazing > Go solves this through unyielding consistency. What? Why is the word "unyielding" used here? What was the point of generating this AI article on the google blog post?
• mintflow 2mo ago
  Nice article and some tenets have been said, such as software engineering is not same thing as programming. As a long term C programmer and start using go from the early days, really love it's rich ecosystem and portability. Nowadays, for any backend code, i just let agent to write using go, and for resource constraint environment, i just use rust. And both have good C interop, and good ffi interface to hook into more higher level language such as Swift/Kotlin if one wnat to develop some mobile Apps
• zarzavat 2mo ago
  My calculus is very simple these days: If I care about performance, use Rust. If I care about iteration speed, use TypeScript. If I want a script or numerical code, use Python. LLMs are better with Rust because the more expressive type system provides stronger guardrails especially when writing multithreaded code. Go is almost the worst conceivable design of a programming language for LLMs: powerful but weak guardrails. Only C and C++ would be worse. LLMs don't struggle with the low-level lifetimes like humans do. They struggle with the high-level view because of limited context windows. That's why you want a powerful type system to enforce those global constraints. Go ain't it.
  • grantcarthew 2mo ago
    You're not considering one of the important factors, token usage. Rust is a complex language and burns through tokens compared to Go. Python is good with tokens, but why would you use an interpreted language when you don't write the code. Same with TypeScript. Compile it. I see language choice as only two now: Go or Rust. Go for most systems, Rust for high performance.
  • qlte 2mo ago
    > If I want a script or numerical code, use Python. I had the same convention until about a year ago when I started specifying Go for any kind of scripts on a whim. Now I get blazing fast, dependency-free static binaries with nearly equivalent OS/shell ergonomics as with bash or data processing with Python. It’s a huge speed boost and being able to drop a binary on a new VM without messing with uv/pip is a breath of fresh air. LLMs hit zero road blocks doing 1:1 ports of existing Python/bash scripts.
• beaker52 2mo ago
  It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making. What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go. Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squinted eyes. But the teams I work with are working on sprawling, evolving software where the compiler saying “hey, that’s not a valid Widget” would be extremely useful and save much heartache. An LLM does a good job of “checking” for other uses and “checking” if everything is going to work correctly, but - supposedly we’ve committed the concept to code so that the compiler can actually verify it - and Go intentionally permits invalid states of structs. This makes Go a fundamentally problematic language choice for the kind of software I work with teams on, LLM or not.
  • temphaaa 2mo ago
    i am using nilaway from fb it's great for those
    • tgv 2mo ago
      It's from uber, I believe.
  • baalimago 2mo ago
    I've found that keeping very healthy test coverage solves issues like this. LLMs are very good at validating their own implementations with TDD.
    • cookiengineer 2mo ago
      With unit tests you gotta be careful though, oftentimes LLMs skip implementations with mockups that just say "not implemented yet" or similar and then the unit tests become pointless because they start to only test internal structures for being set / not default values. For me it helped a lot to try to make containerized end-to-end tests and a custom TestMain for this, where I am using podman to run the integration tests. This way the end-to-end tests are forced to be on network level, and you can test protocol and API quirks much easier with LLMs. Also, never forget to write a bootstrapping docs/ folder so that you don't have to re-explain these things all the time.
• fragmede 2mo ago
  No it isn't. The best LLM software engineering language hasn't been invented yet. As a human, spaghetti code sucks and goto's are considered harmful. I can't reason above what my puny human brain can keep in context. Phone numbers are hard to remember, and that's only 7-10 digits. LLMs have no such problems, and as such, should be able to write more performant code given fewer constraints. Given a problem statement, an LLM could "hand" optimize assembly for the specific CPU the code is to run on, eg that exact Intel CPU's speculative decoder pipeline length.
• socketcluster 2mo ago
  Plain JavaScript is the ideal language for AI coding. It's very good with complex architectures. I think partly it's because the training set contains a lot of JS, but also because complex software written in JavaScript must have impeccable architecture in order to exist at all. It's rare to encounter a complex, functioning JavaScript application with bad architecture. I've never met any engineer smart enough to maintain a large spaghetti-code JavaScript project. On the other hand, I've seen horrible TypeScript projects. If it wasn't for the helpful type annotations, no human being would have been able to maintain it.
  • frollogaston 2mo ago
    I have always preferred plain JS without AI coding too, partially cause of what you said. Typescript encourages bad code. It also gets in the way of good code, doesn't really prevent bugs in prod, and complicates the toolchain.
• laszlojamf 2mo ago
  I use go for work and basically 100% agent-driven. I'd say using go with agents is a lot better than without. We use to have a consistent source of production errors where we forgot the pointer case in type switches (we'd pass a pointer to a struct where a concrete struct was expected and vice versa). AI hasn't made that mistake once in my experience. That being said, the whole thing about go being "readable" is a little bit of a two-edged sword. Sure, it's straight-forward to read, but it's pretty verbose. And agents are good at producing a lot of text. The problem with reviewing go code for me is to see the forest for the trees. Subtle misunderstandings often hide in the vast amount of code that you have to read through while keeping the whole context in your head.
• pjmlp 2mo ago
  Sure, because no human should be forced to manually write Go's boilerplate code in the 21st century.
• neprotivo 2mo ago
  I am using Go right now for personal projects. One such project is to collect per-test-case coverage data and use it to study the structure of the underlying codebase. I'm hoping to develop a new knowledge base for agents to do feature location. Here's a demo https://atlas.vihren.dev https://atlas.vihren.dev Anyway, it turned out that Go ironically makes it difficult to collect per-test-case coverage data. In spite of the standardized tooling it looks impossible to write a standardized collector that would run on most codebases. In hindsight using another language would have been a better choice
• fpauser 2mo ago
  says google
• fmind-dev 2mo ago
  I'm using Go more and more for my projects (AI, Web, CLI, ...). This is my go to for all my new projects. My background is in data science and MLOps, where Python rules. But the focus is now less on building new AI models, and more on building the infrastructure and API calls with AI Agents. Go has a great async model, stellar performance, amazing tooling ecosystem, and far less ways of doing things than Python. I except grow to become more and more popular, as our LLMs are now writing most of our code. Between a 50 MB portable binary in Go with 10x performance, and a 5 GB venv in Python with lack of proper parallelism, the choice is easy.
• patwoz 2mo ago
  Just use rust
• TimByte 2mo ago
  [dead]
• cztomsik 2mo ago
  I will leave this prediction here and maybe come back in few years: 1. JS is mem-safe, single-threaded, and there are lots of training data. Easily my first choice. I'd put Python here as well, although I don't like it personally. Both should be used with "avoid external deps" in your AGENTS.md 2. Go might be a good second choice. Simple language, IMO good primitives for concurrency, well-designed std, therefore smaller potential for supply chain attacks. 3. Elixir/Erlang, little training data but rising. Safe language, safe concurrency, immutable, scalable, there are some many advantages... It has been avoided because it's different but that could change drastically in the age of LLMs. 4. Rust is probably next choice, along with C++, because while Rust is safer, the language is quite complex. C might be here too, there is a lot of training data, but every project is different and the language is very unsafe. 5. Zig, I really like the language, but it is terrible for LLMs, mainly because it's constantly changing, and the std is also under-featured and IMO weirdly designed. It's a fun language for hobby hacking, which I believe is not going anywhere, it's just not going to be something you will be payed for.
  • rio517 2mo ago
    I mostly use Elixir and JS, and I'm constantly surprised by how much easier and better the code quality is in Elixir, especially given the much smaller training data. I've started to use it for all my personal projects. I think Elixir's terseness, introspection capabilities, and strong ecosystem-wide quality guards really help. At work, we use C#. I'm shocked at how much worse it is. I've also used a bunch of Python, but I still feel the quality isn't as good as the codebase grows, but I didnt put as much effort trying to improve it.
    • za3faran 2mo ago
      What issues are you seeing using LLMs with C#?
  • cztomsik 2mo ago
    Can't edit now but somehow I forgot to mention LISP/Clojure - I think it might be very interesting choice for LLMs because of the macro system and overall expresiveness. Also, Clojure specifically is mem-safe because of the host VM and concurrency saf(ish) thanks to persistent data structures and core.async. It might be somewhere between 3 and 4, maybe together with Elixir. Unfortunately I never had enough time to play with it but I definitely will.
• rio517 2mo ago
  Hum. Interesting. Tencent put out this study showing that Elixir seems to reign supreme: https://autocodebench.github.io/ https://autocodebench.github.io/
• blindseer 2mo ago
  I can't help but think this is Google attempting to poison the training data for future LLMs to incentivize them to pick Go. Rust or Nim are really the ideal targets for LLMs and will continue to grow. As LLMs write more code and as humans review less, it will be more important to have confidence that your code doesn't run into a weird one off runtime heisenbug issue.
• jpgvm 2mo ago
  It really isn't. Poor correctness guarantees, especially w.r.t concurrency. Nil pointer. Why. LLMs are like a magnifying function. Whatever you put in you get back 10x over. In the case of Go, in goes verbosity, Nil pointers, poor concurrency and synchronisation primitives (or poor performance of the safe ones, leading to sync.Mutex everywhere anyway). Also Go prioritises local readability over global understandability which is a poor tradeoff for LLMs with limited context windows. So the LLM generates absolutely monstrously huge amounts of very hard to review very likely incorrect code. No thanks. Rust > Go. In goes powerful, terse type system. Strong correctness guarantees not just around memory and pointers but also data races. A tendency towards using the type system to model invariants instead of relying on procedural guards and runtime assertions etc. Producing denser code is an LLM feature, it increases context window efficiency. Similarily the typesystem takes something that the LLM can spend a bunch of thinking tokens on to create a powerful global constraint. This fixes the global reasoning/context problem by pushing it back onto the typesystem. Depending on the quality of your robot you will get different quality of code out but the ceiling is much higher. With Go better robots don't help much, even the highest quality robots output insanely verbose Go. Sort of just like with people... sort of like the language was designed as a lowest common denominator tool... For a seasoned Rust programmer the output probably won't be hard to review, it will be easy to look at the types and either say "yeah that should probably be correct" or "no robot, do better". You simply can't actually review the output of the slop cannons with Go, there is too much, looking at a struct tells you almost nothing about how correct the thing likely is, etc. The tests don't help either because there is going to be 10x the usual amount of those too so trying to review those for correctness is the same Sisyphean endeavour.
• leZon 2mo ago
  [flagged]
• roca 2mo ago
  Too bad the RAM crisis makes GC languages like Go far less attractive.
• tsss 2mo ago
  Only in so far that it is the language that I most desperately want to stop reading and writing myself.
• NegativeAbsence 2mo ago
  If ecosystem compatibility can be handled well, this seems perfectly viable.
• Decabytes 2mo ago
  As expected Google completely forgets about it’s other language, Dart
• c7b 2mo ago
  My gut feeling would be that most of not all of the points apply to Rust as well, and even more so. Rust's compiler is famously strict, the whole language and tooling is designed to catch footguns early, and it's less verbose than Go, meaning you can fit larger codebases into a given context window.
• grantcarthew 2mo ago
  People tend to forget about token usage when discussing languages with agents. Python is one of the best, but why use interpreted languages now. Also, the ecosystem is well... Go is quite good from a token usage point of view. Rust is not so good due to the complexity of the language. I see AI agent programming language choice as only two now: Go or Rust. Go for most systems, Rust for high performance.
• dekhn 2mo ago
  Go has some interesting ideas but they tremendously oversold goroutines as being a unique capability (they have since agreed that goroutines are effectively just scheduled thread pools with message passing). And I know a fair number of SRE at Google who hated to use it because it lacked some key features (around ioctl and other system level functionality). And my experience with the type system... it's just too different from what I expect a system to do. For AI I use python+rust. I develop code in python (mostly AI-driven these days) and then have it port to rust for speed. As always, extensive testing (much of which is manually inspected to make sure it's logically consistent with the design and contract).
• TheMagicHorsey 2mo ago
  Rust's more powerful type system seems like a better match for LLMs ... better guardrails. But Rust is so painful to read that LLM code becomes inscrutable. If I'm never going to read the source, probably Rust would be better. If I'm reading the source then Go or Zig.
• MetroWind 2mo ago
  It's 2026 and programmers are still fighting over language choices. Lmao
• guestbest 2mo ago
  I’ve been using Perl 5 with minimal 3rd party libraries. I just feel like it will be supported for a long time, and the language parser and runtime are especially small
• init1 2mo ago
  Ada Spark is better. Embedding proofs into the code that prove absence of runtime errors lets the bot know what your actual intent is and gives it an iterable target that is actually correct.
• deterministic 2mo ago
  My experience: C++ is an ideal language for AI-assisted software engineering. It just works beautifully with Claude Code.
• yohamta 2mo ago
  Yes, as long as a senior SWE guides AI agents properly.
• coreyi 2mo ago
  [dead]
• caseymarquis 2mo ago
  Go ignores the needs of the developers in favor of the needs of the architect and technical managers. I’ve always disliked it for that reason. In roughly November of 2025, “software developer” stopped being a position that humans fill directly. We all became architects and technical managers. Even the most complex code is now pair programmed with an AI. I’ve chosen go for all new backend work since January 2026. Development is now about good architecture that optimizes for locality of reasoning, rock solid testing, and categorizing risk on modules to decide what needs human pair programming and detailed review, and what can be safely vibecoded and left to AI to manage. Frontend dev is now vibecoded directly by PMs at my organization within very specific and heavily enforced architectural constraints. The quality of work went up substantially because the experienced devs now just focus on the rules and review for the fronted codebases, while the PMs focus entirely on UX. It is a strange new world.
• lenny321 2mo ago
  Honestly this article is already 8 months behind. In 6 months they will recommend Rust. Still wrong. Answer already been found. Formal verification or nothing. Lean v4.33.0. Since v4.30.0 LLVMBindings are included making direct projection to llvm IR instead of emitting C or emitting IR Only formal verification kernels will solve the issues discussed. It cannot make your c design correct, it can only verify the code itself whatever is written. Point is, this is solved known, and everyone get enough ahead made the jump long time ago. Also, sorry, standard libs are almost always forbidden now. They can’t be trusted. Anything important is written from scratch. Why? Go and others standard libs are “broken”, meaning they are half assed lightly defined not purpose built for a developers job. They are general. That was good once upon a time. Not anymore. Use Go and attempt JSON Canonicalization. You can’t. It’s valid. Proven so. Why? Stdlib json parsing is normalizing and lossy. Fail closed. Float to string violates ecma 262 for floats. Every single action taken is in violation. This is the stage of today’s programmmkng. Developers who don’t even understand what “correct” is. https://lattice-substrate.github.io/blog/2026/02/27/shortest-roundtrip-ieee754-burger-dybvig/ https://lattice-substrate.github.io/blog/2026/02/27/shortest... The issue is NOT AI LLM, it’s poor development by HUMANS. The same problem we always had.
• deleted 2mo ago
  [deleted]
• deleted 2mo ago
  [deleted]
• deleted 2mo ago
  [deleted]
• deleted 2mo ago
  [deleted]
• thstart 2mo ago
  [flagged]
• yburkov 2mo ago
  I’m not sure that’s true, but GO definitely good in PR and marketing :)