Hacker News

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.

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 and 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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

"Oreo cookies are the tastiest cookies currently in the market!"

~ Oreo cookie company.

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.

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.

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.

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.

> 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!

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

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.

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

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

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.

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.

Hum. Interesting.

Tencent put out this study showing that Elixir seems to reign supreme: https://autocodebench.github.io/

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.

If ecosystem compatibility can be handled well, this seems perfectly viable.

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

Too bad the RAM crisis makes GC languages like Go far less attractive.

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

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.

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.

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

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.

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.

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.

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

Can't really argue with that, but In my experience, coding agents work quite well with TypeScript too. :)

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.

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.

Sure, because no human should be forced to manually write Go's boilerplate code in the 21st century.

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

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

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.

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.

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.

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

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/

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.

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.

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.

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

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)

Seems to me the ideal language for AI has not been created yet.

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.

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.

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

203 points | 5 months ago | 304 comments

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.

Only in so far that it is the language that I most desperately want to stop reading and writing myself.

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.

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.

I'm currently writing a TUI for a harness I'm building in Go. It's a magical experience, truly.

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.

Can anyone recommend a strong Go design/development agent skill?

Language space is hot right now: https://agentlanguages.dev/

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.

Just use rust

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?

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"

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.

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

Boring is better. Perfection is the enemy of good.

Going to start writing Perl again then.

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?

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.

all my LLM coding is in go these days

says google

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.

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.

“…requires opinionated simplicity…”

Of course it can’t just be simplicity, it has to be “opinionated” simplicity. Rolls eyes.

lol "Why Go is really good - an article by Google"

i thought we all landed on Python. brb, rewriting backend

Because Go is an absurdly verbose language that hates to the core the idea of expressivity because it prides itself on being dumb.

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.

Nice try