9 ms·
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 bette
by 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 agoI 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 agowhat is "Black"? (For hopefully obvious reasons, I couldn't find results with google, lol)
- mholm 2mo agoBlack for Python https://github.com/psf/black https://github.com/psf/black
- rsyring 2mo agoBut you're probably better off with Ruff these days: https://docs.astral.sh/ruff/ https://docs.astral.sh/ruff/ Similar to black but faster, written in Rust, by the same team who created uv.
- marcus_holmes 2mo agoSo... A: not trivial. And B: not part of the language. > mean this isn't true, formatting is the most trivial part. And so many languages have an opinionated formatter these days (e.g. Black) I don't think this is correct
- pmarreck 2mo agoB: not part of the language. 1) Some would call this a perk. 2) When your tooling around a language works better when it's not actually written in the language... That should tell you something. And yet...
- frollogaston 2mo agoThis back-and-forth is a good example of why Go benefits from having a centralized linter. And uv isn't the official Python package manager even though it should be.
- maleldil 2mo agoI don't get why this is a big issue. This isn't some recurrent decision to be made. It's something a lead decides once and the project follows. That's it. Many companies have style guides anyway (eg Google[1]); the choice of a formatter is much simpler. [1] https://google.github.io/styleguide/go/ https://google.github.io/styleguide/go/
- frollogaston 2mo agoBecause at some point you have to interact with some other team or project that made a different decision. And whatever you picked might fall out of favor and lose support. There's already a graveyard of Python type linters, including Google's pytype. Especially the uv thing. You clone some non-uv git repo that has no pyproject.toml and you don't know what to install. Maybe has requirements.txt but it's partially wrong.
- Dylan16807 2mo agoWhat did you search? If I do the simplest possible thing that isn't a single word, by highlighting "opinionated formatter these days (e.g. Black)" and clicking search, I get the right result. I also get the right result for black formatter, and I get the right result if I yolo the entire comment as my search.
- pmarreck 2mo agoAh, it's Python. Python is gross. That explains why I couldn't find it. /shrug
- overfeed 2mo ago>> ...there is no debate... > ...And so many languages have an opinionated formatter these days The crux of gp's post is for Go, there is no debate as 'go fmt' is the only one that matters. Black is great, but some people prefer Ruff, leading to ...debates about which formatter the team/org should use. Go's batteries-included philosophy makes those discussions moot on so many levels beyond formatting.
- ciupicri 2mo agoAs if projects haven't used to have a coding style. What's so hard in saying that code should be formatted with Black, yapf, ruff etc, beats me.
- badrequest 2mo agoLiterally within this thread someone has already suggested using ruff instead of Black and nobody here are colleagues.
- the_sleaze_ 2mo agoIt's a silly argument and the lowest form of bike-shedding on the level of tabs vs commas. People with no other substantive contributions use formatting as a beard. The first one to choose it (whatever it happens to be) wins and that's the end of it. If it isn't the end of it you've got a talent issue.
- overfeed 2mo ago> It's a silly argument and the lowest form of bike-shedding on the level of tabs vs commas Guess what other low-level bike-shedding argument 'go fmt' obviates? That's right - tabs vs spaces! > If it isn't the end of it you've got a talent issue. I know you meant this as a slur, but the implication is Go works better than other languages for those who have what you call "a talent issue"
- 2mo ago
- Cthulhu_ 2mo agoAnd I'm thankful that they do, but also, Go was one of the first languages that really pushed for a standard code format - I'm actually surprised this wasn't a thing before. Or I suppose there was, like Checkstyle for Java or ESLint for JS, but they were not strongly opinionated or pushed by the core team.
- TimByte 2mo ago[dead]
- jdw64 2mo agoI have a question: why do you think Go is better compared to other languages? After all, learning a new language takes a lot of time. While basic syntax is common and quick to pick up, mastering a language's specific mental model requires a significant time investment, which is why I've used Go before but never seriously. My interest was piqued recently when I heard about TypeScript tooling being ported to Go, and I know it is incredibly fast. However, where do the results claiming that AI agents generate superior Go code actually come from? Is it a fair, apples-to-apples comparison? Since Go is a very small language with only 25 keywords, the way you write code is extremely standardized. Because of this, I would assume it naturally produces a lot of excellent best practices and conventions, but I'm not sure if there are actual, direct code examples proving this
- jeanbza 2mo ago> why do you think Go is better compared to other languages? I didn't say that. :) > where do the results claiming that AI agents generate superior Go code actually come from? Like I said - reports from users. > Is it a fair, apples-to-apples comparison? No - these are reports from users, not a systematic analysis.
- jdw64 2mo agoAh, I see. I misunderstood.Is the report from an internal source, so it can't be shared? If not, I'd appreciate it if you could send me a link so I can look into it too.
- jatins 2mo agoit’s probably just some informal Slack messages between colleagues that is being described as “reports from users”. There is no Report here
- zero_shift 2mo agoYou are being downvoted but I think this is correct. I doubt Netflix is really doing a double blind RCT on which languages produce better AI pull requests. How would that even work, have two versions of each service in different languages? It's anecdata and maybe, MAYBE, a spreadsheet. Or a Google Form somewhere.
- yosefk 2mo agoUber reported that their Go code has quantitatively more concurrency bugs than code in other languages, and while to me it seems obvious from looking at Go's concurrency model, this is backed by actual data. Is there any quantitative data to back the claim that Go is better in an LLM based workflow than another popular language?
- vips7L 2mo agoYou know there’s no quantitative data. It’s vibes from the top down.
- rubiquity 2mo agoMatches my experience as well. Go fans have conflated "can easily make something concurrent" with "does concurrency well." Go's primitives for concurrency should almost never be used directly and Engineers below a certain skill level shouldn't be allowed to use them directly ever for long running production code. As another example, Go still has not yielded a correct implementation of Raft or Paxos while there are dozens in Java, C++, and Rust. Antithesis found some more bugs in HashiCorp's Raft implementation recently[0]. I'm sure etcd still has some kicking around. Maybe this is a "don't throw the baby out with the bath water' problem but the general evolution of Go has been lackluster. I reach for Rust, Zig, and modern Java instead depending on the specific needs and constraints. 0 - https://antithesis.com/blog/2026/finding-bugs-in-raft-implementations/ https://antithesis.com/blog/2026/finding-bugs-in-raft-implem...
- ramoz 2mo agoThat does not seem like a fair/accurate reference? The antithesis author states: "we’ve found bugs in every Raft implementation we’ve tested, including HashiCorp Raft, Aeron Cluster, OpenRaft, and MicroRaft"
- rubiquity 2mo agoYou're misreading what I said. I didn't say other languages don't have buggy Raft/Paxos implementations, just that Go is yet to yield a single correct one.
- melodyogonna 2mo agoIsn't Netflix a Java shop
- allset_ 2mo agoLarge companies use more than one language.
- deleted 2mo ago[deleted]
- deleted 2mo ago[deleted]
- giancarlostoro 2mo agoThey use more than just Java. The UI was originally C#... I'm still surprised the front-end was C# but they went with Java longer term for the backend.
- dotwaffle 2mo agoWhen I worked at OpenConnect (Netflix's CDN) there was a lot of Python too, and I started porting a lot of the tooling to Go. By the time I left (2019), Go was really starting to take off outside of OpenConnect too -- but yes, there's historically a huge amount of Java there.
- 0x457 2mo agoTheir UI originally was Silverlight which at that time had the best "adaptive streaming" story.
- seabrookmx 2mo agoLikely because Netflix relied on Silverlight for video playback early on. I'd be surprised if they still had C# in their front-end stack (and I say that as a general C# fan, though I use it on the back-end).
- 2mo ago
- red_hare 2mo agoWhen you give those resources to your coding agent, do you give them URLs? Or work with local versions? I've found a lot of success pointing claude at locally downloaded docs over llms.txt URLs but not sure how to scale the pattern for a bigger project.
- zero_shift 2mo agoI work at a large devsec company which uses primarily Go and TypeScript I've found that the LLM generated Go has few mistakes, and generally isn't too obscure. But the volume of code is so high, colleagues do a bad job of reviewing it. I've seen a lot of very silly decisions made, like returning the wrong HTTP code, or miscategorizing a metric used for an SLO, that I just don't think is helped by the sheer volume of code one has to wade through. Ironically, we are considering migrating some initiatives to Rust, exactly because experiments indicate it works well with LLM development.
- jeffbee 2mo agoIsn't any equivalent system going to have more statements in Rust than it would have in Go?
- super_flanker 2mo agoWhy would you think so? Rust provide better type system and abstraction mechanisms compared to Go, hence equivalent system should have less lines of code, at least in from my experience.
- icedchai 2mo agoConsidering every other line of Go is `if err != nil`, this makes sense. I do prefer Go's simplicity, personally.
- bb88 2mo agoYes, and that's the case I've seen as well. I would also say rust is also more heavy on symbols, which can make code look kinda hard to parse in places. But weirdly Opus (N=1) in Claude Code does okay on it. Enough I can reliably have it write software and feel confident it works.
- Cthulhu_ 2mo agoI'd argue that this is neither down to the programming language nor LLM used, but down to your own company's requirements, testing, and code review practices - but you did point the latter out so you're aware of it. I think the only thing you realistically can try to do is slow down. But it's also a trap I fall into myself - I don't usually thoroughly review my own merge requests because I wrote them, but now that LLMs generate them I don't review my code thoroughly either, and some issues have fallen through. Nothing critical, just stuff that, if someone asked me to review it, I'd flag up as something that could be polished a bit.
- dizhn 2mo agoA sort of an amateur I found Go to be really good when used with language models. Simplicity and tooling helps I suppose and I expected it to. However I was pleasantly surprised with how they are also pretty good with Flutter and Dart. Again good tooling, good documentation and perhaps not much historical baggage like a python or a PHP would have. And no stack overflow to speak of pretty much.
- giancarlostoro 2mo agoYour post reminds me of what I love about Python, we have PEP-8 which is a style guide, and it kind of shifts how you write code a bit (for the better) which is something I sorely miss in other languages, I don't get the feeling people care about style guides for other languages very much.
- dzonga 2mo agoGo wins for simplicity. however what I have seen is companies end up going with Java coz it's simple enough - not simple as Go, but simple enough + fast enough. though the letdown with Java is the wider ecosystem that makes unwarranted contraptions out of simple things.
- frollogaston 2mo agoGo's big advantage was M:N threads. Java's biggest flaw has been the lack of cooperative multitasking, which people worked around by mangling their code with promises. Now Java has M:N threads too thanks to Project Loom, but there's so much code written before that will never really go away.
- pjmlp 2mo agoJava already had M:N threads in the early days, aka green threads, because the JVM and Java specifications did not assert what kind of threading was to be provided. Thus most JVM implementations had a mix of red (1:1:) and green (M:N) threads, eventually only red threads were kept in the surviving implementations. With Project Loom now both models are officially supported and part of the specification.
- frollogaston 2mo agoYeah I've heard of the Java 1-2 greenthreads, but supposedly those were M:1, ie you could only run them on one core. At least this SCO release note linked from Wikipedia says that: https://www.sco.com/developers/java/j2sdk122-001/ReleaseNotes.html#THREADS https://www.sco.com/developers/java/j2sdk122-001/ReleaseNote... And the pros are more about compatibility than performance
- pjmlp 2mo agoHow have you found a SCO note, which never did nothing relevant for Java? Here from Oracle, as historically taken from Sun documentation for JDK 1.1. => Many-to-Many Model (Java on Solaris--Native Threads) https://docs.oracle.com/cd/E19455-01/806-3461/6jck06gqk/index.html#ch2mt-41 https://docs.oracle.com/cd/E19455-01/806-3461/6jck06gqk/inde...
- AndyNemmity 2mo agoWhich exact documents to you give them. The single style guide? The references as well? The additional detail listed in the guide as links? I'm curious to try your proposal, I just want more specifics.
- AndyNemmity 2mo agoI've made a pr to my agent trying to implement it. it did fine in blind a/b tests so just going to go forward https://github.com/notque/vexjoy-agent/pull/908 https://github.com/notque/vexjoy-agent/pull/908
- fishfasell 2mo agoI assume it's because Go is so opinionated? I experimented with it and found it almost boring to write, but I strangely loved it. Now in the AI era I crave the forced uniformity.
- Cthulhu_ 2mo agoBoring is a feature, although it's understandable why people don't like that. But, major software (maintenance) issues have been caused by people writing interesting code. It's gratifying and fun for the individual, but detrimental to the application / codebase / business.
- bushbaba 2mo agoGo is heavily opinionated on style, design, and semantics. Its design was around being as concise as possible…which means token efficient. Yeah Go is my preferred language to code with AI. Second up is type script. Followed by Java, then Python.
- joaohaas 2mo agoGo design is not around being concise as possible, in fact it's the complete opposite. One of the cores behind Go is to make language simple, even if at the expense of more verbose code. Two main examples of this is the infamous 'if err != nil' and how you handle filter/map/funcional operations.
- bushbaba 2mo agoYes but it’s err not error. The variable and method names are meant to be concise and highly readable without the CS fluff of Java naming hell.
- joaohaas 2mo agoI don't think naming convention is the kind of stuff that helps save tokens, specially considering how text is tokenized. On the other hand, being able to write 'list.filter(v => v.selected)' (or something similar) instead of: listFiltered := []Item{} for _, item := range list { if item.selected { listFiltered = append(listFiltered, item) } } would save much more tokens.
- osigurdson 2mo agoIf you know any other language, you basically already know Go (with the exception of the channels stuff). The biggest pain is the if err != nil stuff, which I know some people like but it is suboptimal in my view. While far better than C# and Java's exceptions, far worse than Zig's model.
- pjmlp 2mo agoYeah, panic/defer/recover are so much better. /s
- throwaway2037 2mo ago> far better than C# and Java's exceptions What is wrong with them? When writing enterprise CRUD apps, they are very useful.
- wannabe44 2mo agoPeople don't understand exceptional control flow. They think they have to catch them at every point, instead of using them as intended (having a central boundary of error handling where you have enough context whether to retry or abort the operation). So they think Go errors are better. With exceptions you can 1. Set exception breakpoints. 2. Have real stack traces. 3. No need to write 3 lines of boiler plate every 1 line of code which interacts with outside world. Ironically this is the case in Go's niche - devopshit, cloud webshit - where the boilerplate error handling makes even less sense since because 1. You are making a network call or OS interactions every 2 lines which can err 2. The consequences of an unhandled exception are actually quite less severe. At worst your request will 500 or the application will restart - which is a consideration you can't escape in these environments. 3. I have seen indiscriminate error handling written by substandard developers which simply concatenates the full wrapped error string to API, leaking full details. At least with exceptions, you can designate different types of exception for 404s vs ayth errors vs bad requests vs Internal errors, and have a central handler which filters out. In go theoretically you can do this, but I have never seen someone utilize errors.As over stringy error handling. I like Go - it has nice stdlib, nice compiler and runtime, and actually dared to innovate away from the fat-ass LLVM monoculture and made green threads popular. But error handling and uninitialised values sticks out like a sore thumb. It's impossible to read code which does many API/network/OS interactions.
- gertlabs 2mo agoWe've seen a pretty consistent pattern in our evaluations where Go is among the languages that models perform worst with (alongside Python), for reasons unclear. Our coding evaluations are typically measuring the foresight and planning expressed in code that is run in interactive environments/games. This trend has been there since we started evaluating models using different languages in February 2026 and if anything, the disparity has grown in frontier models. Even Google models prefer Kotlin/C#/Rust for coming up with creative ideas (compilation success is a different story). Data at https://gertlabs.com/rankings https://gertlabs.com/rankings That being said, models love to recommend Go, and Go does have a lot going for it, especially if you are serving a public-facing website. So most of our public facing API handlers are written in Go, and we offload some of our most important binaries to Rust. There are just too many reasons not to use the languages that models think a little more effectively in.
- kromem 2mo agoYep. Have a primarily Go backend and from even early on the agents were doing a good job. Now they are even better than me. I do think the way software is organized for primarily agent driven repos will need to change a bit from how I preferred setting things up. (Guessing we're going to be returning to a world of microservices in the near future.)
- wannabe44 2mo agoI want to ignore Naysayers in the thread but even SOTA LLMs write boilerplate like it is Go 1.14. I have to constantly nudge it to use newer language features properly, even if it's also in my rules/ CLAUDE md files.
- cute_boi 2mo agoLast week i implemented few program in Go and Rust, Fable wrote rust without any bugs, but go was full of concurrency bugs...
- agonux 2mo agoIt seems like developers who champion Rust have a knack for making up a load of nonsense about other languages. Claude Fable knows exactly how to handle things in Go; the most recommended concurrency patterns are mastered by the likes of Sonnet, Opus, or Fable, and most of the concurrency "errors" cited in the Uber article are the sort of mistakes a Go beginner would make, some bugs are fixed on major go version too (capture loop..).
- cute_boi 2mo agoYour experience may vary, but Rust code once compile generally always works. I don't have same confidence about go or typescript. And, I don't know much rust, but I do use lot of go in my work.
- Ecko123 2mo ago[dead]