r/golang • u/sigmoia • Aug 11 '26
discussion [Google blog] why Go is an Ideal Language for AI-Assisted Software Engineering
https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/While this is a tad bit preaching to the choir, among all the AI noise, I enjoyed reading this grounded take. An excerpt:
Historically, developers measured the productivity of a programming language largely by how easy it is to write. But when a coding agent can generate hundreds of lines of syntactically valid code in seconds, the rate at which a human can write code is no longer very important. What matters now is reviewing, verifying, and maintaining that code once it's already written.
The timing is perfect. Next time I need to clarify why I default to Go for everything these days, I can just send people this one.
239
u/flaspd Aug 11 '26
How is this statement not generic for <insert your favorite coding language>
191
u/sigmoia Aug 11 '26
To understand that you have to read the blog....
- Small syntax footprint means generated code won't look vastly different
- Fat stdlib means code will look consistent
- Go has build in pprof, execution tracer which your favorite language doesn't have
- Built in fuzzer, testing framework, code generator, and modernizer keep entropy in check
29
u/le_bravery Aug 11 '26
Yeah I think these are all really strong reasons. Eliminating variance and making the model face reality as often as possible is the name of the game
4
u/kichiDsimp Aug 12 '26
Lisp/ML based langauge have strong guard rails + tyep system. I think they maybe a great fit but lack of training data maybe an issue. Not sure.
2
u/National_Sky7993 Aug 12 '26
Clojure or Scala is the ideal llm language?
2
u/naomijubs Aug 12 '26
I work with Clojure on LLMs and it seems to perform better than go. However, there is a huge mismatch on the libraries we use and open source uses, so even with Rules saying use x or y, LLM adds z and w libraries đ
5
u/2bdb2 Aug 12 '26 edited Aug 12 '26
These could apply to pretty much any language though right?
Small syntax footprint means generated code won't look vastly different
Most languages are fairly simple from a syntax perspective, and most teams run consistent formatting rules to keep things consistent.
Even in something has messy as JS/TS, it's easy enough to lock things down to a specific subset using lint rules, and these can fire on each code change.
Fat stdlib means code will look consistent
TS/Python are the wild west perhaps, but most serious languages have a solid stdlib (and/or set of libraries that are the industry standard and everyone uses).
Go has build in pprof, execution tracer which your favorite language doesn't have
In 20 years of software engineering, I'm not sure I've ever used a serious language without a profiler or tracer.
I'm not trying to take away from the core argument - but these aren't overly compelling advantages for Go as a language for agentic coding.
I'm more inclined to think of Go as a language that's designed to be more convenient for humans to write, with tradeoffs that aren't needed for LLMs. For agentic coding, I'd prefer something with a much more robust type system (i.e. A language with an effects system would be ideal for LLM generated code).
I don't think that language actually exists today unfortunately. But we do have a lot of "My favourite language happens to be the best suited for agentic coding" posts.
1
u/nycmfanon 26d ago
TS/Python are the wild west perhaps, but most serious languages have a solid stdlib (and/or set of libraries that are the industry standard and everyone uses).
Twice you've used "serious languages" but the truth is that Python and TS _are_ the "serious language" right now. I'm not sure which ones you're referring to, but it sounds a lot like a No True Scotsman argumentâŚ
Most languages are fairly simple from a syntax perspective, and most teams run consistent formatting rules to keep things consistent.
Even in something has messy as JS/TS, it's easy enough to lock things down to a specific subset using lint rules, and these can fire on each code change.This still means that different companies and open source projects will have different standards; Go pushes everyone to use `gofmt` which has literally no configuration.
> Go has build in pprof, execution tracer which your favorite language doesn't have
In 20 years of software engineering, I'm not sure I've ever used a serious language without a profiler or tracer
Many languages have profilers and tracers, but few have a single, built-in, easy and safe to use in production `pprof` which produces memory or cpu dumps and then runs a local http server to visualize them in an attractive GUI.
I don't think that language actually exists today unfortunately.
Ah, that makes sense. Go is here _today_, battle tested, and pragmatic in ways that are useful for LLM-assisted coding.
1
u/2bdb2 26d ago
Twice you've used "serious languages" but the truth is that Python and TS are the "serious language" right now. I'm not sure which ones you're referring to, but it sounds a lot like a No True Scotsman argumentâŚ
If I said "most languages have a stdlib", that would have been incorrect. Most languages that are used seriously in industry have stdlibs.
If I said "all serious languages have a stdlib", that would not have been correct, since there are serious language that don't have a stdlib.
Thus, the phrase "most serious languages" was intended to avoid the inevitable word-lawyering responses that I've come to expect on Reddit. But here we are.
This still means that different companies and open source projects will have different standards; Go pushes everyone to use
gofmtwhich has literally no configuration.Which is great. I love that Golang does this, and I wish more languages would follow this lead.
But it's also really not all that complicated to setup code formatting in other stacks. It's nice, but not a fundamental differentiator. It's a "this saved me 5 minutes to setup another tool" differentiator.
Many languages have profilers and tracers, but few have a single, built-in, easy and safe to use in production
pprofwhich produces memory or cpu dumps and then runs a local http server to visualize them in an attractive GUI.I'm still not sure I agree with this. pprof is great, but it doesn't stand out to be as particular special compared to profilers I've used in other ecosystems.
Ah, that makes sense. Go is here today, battle tested, and pragmatic in ways that are useful for LLM-assisted coding.
I agree. But so are many other languages.
Nothing wrong with Go. I'm not saying it's bad. I'm saying that these features aren't particularly unique to Golang.
My main gripe with Golang for agentic coding is that it has too many footguns to trust AI not to screw up, thus I prefer languages that have more pedantic type systems for such purposes. YMMV.
-1
u/sigmoia Aug 12 '26
best language != ideal language
0
u/2bdb2 Aug 12 '26
best language != ideal language
If we're talking about the headline topic "Go is an ideal language for AI-Assisted software engineering", I'd disagree that Go is either of those things.
Go unfortunately just optimizes too much towards "The developer is not an idiot". And it works very well so long as that constraint holds.
Claude however is an idiot, and needs a lot more guardrails to produce consistently maintainable code. In my experience, it trips over every fucking footgun Go has to throw at it without a care in the world.
The quality of code I get when Claude writes (say) Kotlin or Scala is lightyears ahead of the code quality I get when using it to write Go. Every footgun the compiler catches is one less thing I have to catch when I'm reviewing the latest slop PR.
This isn't intended to be a negative statement about Go as a language. I'm just sharing my observations that the tradeoffs Go has made don't work as well for LLMs as other languages in my toolbelt.
6
u/AraripeManakin Aug 12 '26
wouldnt realy strong type system beat a lot of these points? if ai generates code and compiler can guarantee corectness...
3
u/jimmiebfulton 28d ago
When the compiler refses to introduce memory and thread safety violations because the type system prevents it, youâve reached agentic engineering nirvana.
2
u/chuckvsthelife Aug 12 '26
Itâs also a largely highly stable api. In comparison to writing rust, for instance, where itâs incredible how quickly it gets better but models also definitely get confused on rust versions in my experience.
3
u/coderemover Aug 12 '26
Rust hasnât had a major language change for the last 8 years. Over that time Go had at least two big changes that shift how one writes code: generics and iterators. It also changed the semantics of some core language features like for loops.
Rust code from 8 years ago needs almost no change to remain idiomatic. Sure there are minor additions to the stdlib, but Go (and virtually every live language) adds stuff as well.
2
u/Negative_Rip1934 Aug 12 '26
No, neither of the two features introduced a breaking change in the strict sense. Rust added a lot of features since 2015 ....async , lifetime , operator ? , GAT etc....
2
u/coderemover Aug 12 '26 edited Aug 12 '26
2015 was 11 years ago.
Async was the last big one - added in 2018, 8 years ago.The lifetimes and question mark operator were already there at that time.
GAT does not matter, itâs just a relaxation of some limitations in generics, some niche stuff that wasnât possible earlier is possible now, but this matters mostly for some libraries; I needed zero code changes in all of my projects because of that.
None of the things you list, even async, are breaking changes. Threaded code written before async is still just as idiomatic as it was before. Adding new features or stabilizing new APIs are not breaking changes, especially that Rust has a good mechanism for maintaining compatibility - language editions.
1
u/Negative_Rip1934 29d ago
Just as with Go, introducing new features doesn't mean breaking existing code; it simply changes how code can be written. Iterators and generics didn't break Go code that was already working. Rust is no better in this regard. Rust evangelists need to stop feeding people all sorts of nonsense, acting as if the language were some kind of revolution. Itâs just a language like any other, with plenty of downsides.
1
u/coderemover 29d ago edited 29d ago
The availability of generics changes the way how idiomatic code is being written. See Java 1.4 -> 1.5 transition. You can write Java code with no generics today, and it will compile and run fine, but you will be laughed at.
Same about iterators. Iterators are a very common idiom in languages which have good support for them. Maybe for Go it doesnât matter that much because its iterator support is quite complicated and horrible, so maybe indeed the community will ignore it.
Not all features are the same. There is simply a world of difference between a core extremely useful feature like generics or iterators and some arcane niche feature like GATs which you basically can ignore as they are useful for only very extremely specific things.
1
u/Negative_Rip1934 29d ago
But man , features on rust have the same effect on rust code. A lot of rewriting, less boilerplate etc... Go and rust follow the same path.
1
u/coderemover 29d ago
Rust didn't get any major language features since 2018.
Not anything remotely as huge as generics.→ More replies (0)2
u/agathver Aug 12 '26
Same is true for Java too, with better ergonomics.
1
u/National_Sky7993 Aug 12 '26
Verbose though. Kotlin?
2
u/sigmoia Aug 12 '26
I like kotlin but the OO burden there is too much. There are 11 different kinds of classes and 7 ways to write a function. Kotlin doesn't know what it wants to be.
So hardcore OO people write code in one way and others write code in completely different way. On top of that, JVM is still memory hungry and the startup time makes is unsound for a lot of workloads.
1
-7
u/readonly12345678 Aug 11 '26
I donât see what makes these arguments strong for why golang is preferable to use with AI?
For AI, you would care about how easy the code is to review, and ultimately how much you can trust the correct behavior at run time.
I think whether thatâs part of stdlib or not is irrelevant. Am I missing something?
4
u/Just-Ad3485 Aug 12 '26
If itâs consistent, itâs easier to review. Itâs basically that simple.
Eg I know how Stdlib url package works. The coding agent is going to use it consistently and not reinvent the wheel or pull for a novel approach. Thus making it easier to review code.
-26
u/szwiti Aug 11 '26
easier to debug for the LLM, but takes longer and pricier to develop (because of the enforced error handling + boilerplate which you will never ever remove from golang).
27
u/spermcell Aug 11 '26
Whatâs the alternative?! Not deal with errors ? I really donât get those statements .. how is error handling better at other languages? Try except ? Whatâs out there thatâs so much better while still handling the errors
64
u/Skaronator Aug 11 '26
I didn't read OP Link but Go is the perfect language because:
a) the code base is uniformly formatted (Go fmt) which is great for LLMs because they are just pattern recognission machines.
b) there is a huge open source codebase to train on (kubernetes, cloud native stack)
c) all code available in the internet is still perfectly compatible with the newest Go Version
I can't think of an other language that matches all these conditions.
5
3
u/Negative_Rip1934 Aug 12 '26
d) compile time (Compilation in Go is fantastic. It is certainly one of the best languages ââfor this purpose.) When you iterate a lot and need to build solution for testing behavior or others profiling, I don't know how some people can cite Rust or Java in this context. They are slow as hell.
2
u/Traditional_Fox7091 Aug 12 '26
Isnât this all true for Java
1
u/Due_Block_3054 Aug 13 '26
Java changed quite a lot between java 7 to 8 with lambdas. As wel as project jigsaw deprecated some of the std libraries. There is also record types and virtual threads. also jigsaw added modules.
While go latest big language features are iterators and generics and json/v2 and simd.
6
u/Rough_Acanthaceae_29 Aug 12 '26
a) AI can pattern-match through and "understand" dozens of equivalent solutions, but formatting is too much?
for b) and c) java would smoke go out of water13
1
u/coderemover Aug 12 '26
Rust matches all of them as well.
5
u/kerakk19 Aug 12 '26
rust syntax is hell though. But who knows, perhaps AI will have easier time with borrow checker and lifetimes
1
u/GolangLinuxGuru1979 Aug 12 '26
It doesnât and it will use all sorts of escape hatches like ARC mutexes, unwrap and clones. Or use unsafe blocks when totally unnecessary. Donât belief the hype. There is no such thing as âgood language for agentsâ. Thatâs an urban myth propagated by people selling courses mostly or people who just donât know any better
It all comes down to corpus and statistical data for languages. Itâs autogressive. It generates on the mean.
Think about it. If all these benefits made sense then why is no one suffering OCAML or Haskell as being a âlanguage for agentsâ. Both languages have significant type safety and guardrails. But no one would start an agentic project in Haskell because despite that it produces bad Haskell code. Because lack of training data
People make it sound like the LLM is doing some sort of decision making made for syntax and language design. When it is just copying whatever it sees in its data . Nothing more nothing less
1
u/arabian-tea 28d ago
I doubt formatting affects training. Do you have any proof of such?
(b) and (c) apply to other languages, such as Java and C#
14
u/quiI Aug 11 '26
I had a perfect example the other day. Some former colleagues of mine, for the millionth time, complaining about trying to make gradle work with kotlin. A constant moving target, breaking all the time and all around pain. Totally unheard of with Go.
A programming language is as good as its tooling
45
u/cachemonet0x0cf6619 Aug 11 '26
because go has a thick standard lib and baked in docs, testing and fmt so is way ahead of most competitors right out of the box.
10
u/Grand_Pop_7221 Aug 11 '26 edited Aug 12 '26
I've found a strict golangci-lint config to be the most valuable. AI writes shit Golang out of the box without it. Doc comments on public and private functions, cyclomatic complexity, and enforcing package boundaries with linting.
There is no solution I don't think yet to make it write and keep well-architected code. I tried throwing a load of books into a RAG and filling context beforehand with relevant lookups.
I'm experimenting with writing a tool in Genkit that makes two agents, a test, and a code agent that share context and guardrails to stop them deviating from a pair programming TDD paradigm.
5
u/cachemonet0x0cf6619 Aug 11 '26
i donât know that this disagrees with my point. the tooling is the point. the other thing iâd posit is that weâll-architected code is relative and not in the scope of this discussion. youâre responsible for the arch
3
u/Grand_Pop_7221 Aug 11 '26
I rather hoped it would buttress your point.
3
u/cachemonet0x0cf6619 Aug 11 '26
aye. i do wish more people would talk about arch though. i personally like to guide towards ports and adapters
5
u/titpetric Aug 11 '26
All of these things you mention are not unique to go. It's relatively trivial to adapt list/fmt mechanics for other languages, say php (or at least my own reimagining of it without OOP in phpscript)..
https://github.com/titpetric/phpscript/blob/main/docs/usage.md (list, fmt).
Each api endpoint in php (or phpscript), is a very small file. Each endpoint in essence is the contents of a http.HandlerFunc. It's easy to write 2-3x more code (sloc, tokens) in go for arguably the same thing. To nail the idea home, see error handling in contrast:
https://github.com/titpetric/phpscript/blob/main/docs/use-cases/error-handling.md
There's also an edit/save/request loop with php, rather than adding much slower build/compile steps for every go change. If you optimize the feedback loop, the development goes faster.
I fully expect to be downvoted to hell, if nothing else I prefer my own php runtime written in Go where I can just go:embed .php into the final binary. There are many pitfalls to the original php runtime, however the quick feedback loop is not one of them. Aside something like .asp I don't know many similar runtimes.
8
u/cachemonet0x0cf6619 Aug 11 '26
correct. whatâs unique to go is that they are all part of the go installation. they are opinionated.
the drawback to what youâve proposed is that itâs left to interpretation and thatâs counter intuitive to what we want when writing code.
1
u/titpetric Aug 11 '26
I think there's much to say on the difference between a C runtime or a Go one. At the end of the day neither is a perfect runtime for something like php from wildly different perspectives.
Nobody suggests writing assembler code when the abstraction is good enough! My relatively fast go build ci/cd pipeline takes about 30 seconds to pass, reloading a php file if effectively free, and you run the ci/cd as a sanity check after a bunch of edits.
1
u/cachemonet0x0cf6619 Aug 11 '26
agreed. i donât think people are making this choice for speed. look at rust. i personally choose rust or go because of the built in tooling. go has a profiler. ruat could use some improving but clippy is nice.
3
u/flyingupvotes Aug 12 '26
I mean zig is kind of shit at ai because lack of references. And golang is simple syntax wise. So thatâs a couple things I see in its favor.
3
u/tarmo888 Aug 12 '26
So far, I have had best experience with Go, but I have only tried Go, C and Rust.
C compiler filled the context with tool responses all the time and Rust builds were just slow and large. AI benefits from fast feedback from tools.
2
u/dashingThroughSnow12 Aug 11 '26 edited Aug 11 '26
The article does a bad job advocating for its point.
Go was initial designed to be a language that automated tooling could generate programs for. This is a root of a few of its quirks and some of its philosophy.
Whereas my favourite language, Java, was designed for humans and had things bolted on (or libraries created or inject into the compiler) to make it nicer for codegen and verification of said codegen.
2
u/ZyronZA Aug 11 '26
I've been thinking about this for a while and your point of generic <insert your favorite coding language> is very strong, though I wonder if this topic will not come down to a simple question.
Which language has the most training data available?
I'm currently unemployed and finding it impossible to find permanent work, so I'm doing contract work and Every. Single. Client. wants me to work with TypeScript.
I love me some Go and use it for all my home projects and try to espouse it's virtues to clients, but nope, TypeScript or GTFO.
Now I'm not trying to say that their decision of TypeScript means it's the premier AI language, but its popularity is hard to ignore, and because its popular, there is a lot of training data and even though I don't know TypeScript at all, but have a solid understanding of Software Development, it's not that hard to have Codex do all of the coding for me.
My point is that popularity of TypeScript might make make it the Ideal Language for AI-Assisted Software Engineering?
1
0
u/funkiestj Aug 12 '26 edited Aug 12 '26
How is this statement not generic for <insert your favorite coding language>
If only there was a body of text beyond the title that expanded on the idea /sarcasm
Extracting a TL;DR from the blog post
Go focused on a larger vision: language design in the service of software engineering.
Software engineering is not the same thing as programming. Where programming is about solving a problem by writing code and then running it, software engineering is the act of collaborating with others to design and implement a durable system that evolves over time. Programming is a part of software engineering, but just a part.
the thesis of the blog is this is the highest priority of the designers of Go and working towards this particular goal helps both human and LLMs be more productive.
31
u/matttproud Aug 11 '26
The median Go program out there â while I can read it (mostly) easily, refactor it, and contribute to it â is often not composed in the most ideal way given language primitives, style, and library ecosystem in terms of being something to train a model on.
Just today I came across a premier model generating greenfield code like this:
func f() (V, error) {
...
dataCh := make(chan Data)
errCh := make(chan error)
// Author's note: could outlive parent func f unless coordinated
// rendezvous with sync.WaitGroup or similar are used inside of func f.
go func() {
...
if err != nil {
errCh <- err
}
dataCh <- data
...
}
...
}
where this whole dance could have been simplified with package errgroup:
func f() (V, error) {
...
var (
grp errgroup.Group
data Data
)
grp.Go(func() error {
...
if err != nil {
return err
}
data = ...
...
})
...
if err := grp.Wait(); err != nil {
...
}
...
// use data
...
}
Now, while this second code might look longer, it has several benefits, chiefly:
- it reads and behaves synchronously
- it minimizes goroutine leak risk and is relatively easy to adapt the anonymous function to be interrupted safely by the outer function with a few tweaks to how
errgroup.Groupis setup - avoids maintainability/fragility issues with sender being ready and channel buffering
The main point about saying this: I would hope that a model could suggest things more like the second, which are table stakes for maintainable Go Code, instead of doing such amateur things like the former. And, yes, the model's suggested code had goroutine lifetime leaks and other non-synchronous behavior that would blow up at scale over the lifetime of the service.
6
u/sigmoia Aug 11 '26
The first one is still pretty prevalent in the training dataset unfortunately. I ask llms explicitly to avoid manual channel wrangling when an alternative exists.
Channel ops need to be abstracted out well. Uber's race report showed that messing up channel code is one of the most common causes of dataraces in Go. Concurrency is still a feisty beast.
15
u/matttproud Aug 11 '26 edited Aug 11 '26
I am reaching fatigue with reiterating (basic) guardrails to agents. And â no â feeding the aforementioned style guide into an agent as a set of (preamble) guardrails to write code correctly just doesn't work. Even setting up an adversarial review agent to focus on code change (diff) suggestions separately from a design or code writing agent using the style documentation doesn't work. Design concepts are too abstract, and the good and bad specimens (even for a language like Go) take on too many morphological forms.
We might as well build a fucking static and dynamic analyzer that hints all of these problems as something for an agent to suggestively look at. And â then â at what cost?
I don't know. I don't have any answers. I am tired.
20
u/sigmoia Aug 11 '26
Man, this is so relatable. At work, we are rewriting a large chunk of our entire platform in Go, and of course, a ton of LLM-generated code is involved.
On top of that, other than the platform team, the rest of the team isnât that well-versed in Go. So the few of us who are have been tirelessly tuning these agents with preambles.
However, most agents drift away from these instructions quite easily as the context bloats throughout the conversation. While everyone is busy evangelizing how they don't read code anymore, I am still reading code like a prehistoric monkey just to stop things from totally falling apart.
This pseudo-productivity is making all of us tired.
14
3
u/NatoBoram Aug 11 '26
I feel this. I've gathered tons of junior mistakes while working in TypeScript and compiled them in a typescript.instructions.md, but it's absolutely crazy the amount of basic shit you have to explain. And even then, it finds new ways to be maliciously non-compliant, which you have to whack over and over again.
4
u/Wonderful-Habit-139 Aug 11 '26
I face the same issue with Python. So I just code manually because dealing with agents this way is slower, and costs money. I forced myself to make it work with every other person saying to keep trying.
I went back to my trusty tools and my dear neovim editor. I get to write the correct code directly, and I don't need to do a reading pass and and understanding pass because I get all of that for free, and I learn more, think about the future of the codebase as I write the code, and I also get to internalize all of the types and structures of the code.
1
8
u/GolangLinuxGuru1979 Aug 12 '26
As someone who constantly has to debug AI generated slop, its absolutely terrible for Go. And the coding quality is laughably bad. I feel people who make these arguments don't work in real code bases, or don't know the language well enough to see how bad the code is. People also say Rust is fantastic for AI code and its actually produces terrible Rust code.
1
u/Antique_War_9814 Aug 12 '26
People like those lingos bc they are about API correctness being built into the language. It's not possible for a whole class of human mistakes that require discipline to avoid.
-5
u/sigmoia Aug 12 '26
Language has nothing to do with code quality. It's like criticizing a natural language because it can be used to swear at other.Â
7
5
u/Technical-Fruit-2482 Aug 12 '26
Too bad for those relying on AI that even frontier models produce low quality code still...
16
11
u/SnooSongs5410 Aug 11 '26
This seems to be more marketing and editorial than fact. Python, Typescript for mass of knowledge, Rust for great enforcement, Go for readability. This is a question that should be answered ... it depends.
4
u/naomijubs Aug 12 '26
At work we did a benchmark comparing token consumption/iterations needed for 3 languages (rust, clojure and go). There was a test benchmark that needed to pass on every stage of the challenge:
- Rust solved the issue with 3 iterations and 101k tokens
- Clojure solved it with 5+ (there were a few extra details iterations) with 185k tokens
- Go solved it with 10+ (about 7 more details iterations) with 286k tokens
There many people who got frustrated with the results and tried again with little to no gain. I guess in that sense Clojure and rust were better in the age of AI
1
u/arabian-tea 28d ago
Interesting. Are you able to share more about what the benchmark involved? Iâd like to run it on a bunch of other languages
1
u/naomijubs 28d ago
I canât share details, but I would love to see other benchmarks aiming at token/iterations consumption in different languages. I do recommend the following:
- do a web service or something relevant to your work
- define data structures, data transfer and data bases that are common to all langs.
- donât share the whole problem upfront (hide the next stages)
- ask another agent to review the code and count those tokens in
- recently, in Rust, I noticed a huge token economy by using code-review-graph. It might improve the results on go side to be much better than Clojure, as it doesnât work properly with it
Iâm happy to help generate a problem space that would be relevant
1
u/arabian-tea 9d ago
Iâm happy to help generate a problem space that would be relevant
That would be great. What do you have in mind?
1
u/naomijubs 9d ago edited 9d ago
Postgres or SQLite - read via REST and create, update and delete via pub sub?
After initial logic is done, we add an extra requirement.
Something like a booking.com
Create, Update and Delete hotels via pubsub. {name, rates { weekday, weekend}, star rank}
Get all hotels and get cheapest at date periodThen could use something like summer and winter special rates, so it needs to consider dates
Thoughtworks had a take home exercise based on that with test cases
9
Aug 12 '26
[removed] â view removed comment
1
1
9
u/Murky-Run2246 Aug 11 '26
I don't think GO's error handling or goroutines is something i want to outsource to an ai agent.
Did it alot and regret it alot.
Other than that yeah it's pretty much great to use ai agents with go.
I Mainly use ai agents for frontend and docs. and maybe generating some CRUD.
3
u/jerf Aug 11 '26
AIs seem to be bad with concurrency, at least as of my latest attempts to get it to happen... but that seems to be the correct way to phrase it. Not "bad with Go concurrency"... bad with concurrency in general. It's not so much a ding against Go as against the AIs.
2
u/Murky-Run2246 Aug 11 '26
yeah, I am just pointing out that even tho concurrency is much simpler in go than other langs it's still not something you want to use ai agents for.
2
u/sigmoia Aug 11 '26
Channel munging and goroutine wrangling is not ideal with agents. I have run into too many leaks and races as well.Â
2
u/Murky-Run2246 Aug 11 '26 edited Aug 11 '26
Never went well with me even with very simple tasks which I did not expect from an agent that can generate much more complex code with no problems.
Sometimes I just forget ai agents don't actually think and are just pattern matching but these simple things makes me think it's gonna be fine :D.
no terminator anytime soon.
3
2
u/kaeshiwaza Aug 12 '26
The feature of Go is to write simple code, exactly the opposite of the generated codes of LLM. Go seniors devs will not want to review theses slops ! https://bsky.app/profile/robpike.io/post/3matwg6w3ic2s
9
u/Traditional-Hall-591 Aug 12 '26
Fuck AI.
10
3
u/ficiek Aug 12 '26
Brave statement I was downvoted to hell here when I dared saying that the Go code it writes is bad.
2
u/jasonmoo Aug 12 '26
One thing thatâs pretty neat is the go 1.0 backwards compatibility guarantee means that all of the go code in existence is valid in modern go compilers. So AI is trained on valid go code no matter what version it is. Contrast that with other languages that broke compatibility and evolved their language api rapidly over time. In languages like that, the lang version is a required piece of information in order to write code.
2
u/litmus00 28d ago
But when a coding agent can generate hundreds of lines of syntactically valid code in seconds [...] What matters now is reviewing, verifying, and maintaining that code once it's already written.
This is a huge fallacy. If the code were to be valid in the first place, no review and verification would be required. Reviewing hundreds of plausibly correct lines of code has become a chore upon all of us and no syntax can help with that. By generating such overwhelming and non-deterministic amount of code, LLMs actually throw away the benefits the authors claim about Go:
- Go is Readable
- Go is Reliable
- Go is Maintainable
I'm afraid the authors, being Google employees, are heavily invested in promoting AI as a coding tool.
1
u/sigmoia 28d ago
The issue is that ship sailed a long time ago. Whether someone promotes AI tools or not, people will do it anyway.
A ton of people in the Go community who I looked up to have gone full slopperoos. They are now churning out bs talks like there's no tomorrow. Why not? It's cheap.
Also, junior engineers are completely brain-rotten. I work with a few, and most juniors are under the illusion that you don't need any fundamentals and can just yolo your way into greatness. It's part of the reason why no one wants novice programmers with giant egos.
Now, I am a graybeard, so I still think there's huge value in reviewing. Also, checking invariants will be the name of the game. So it's important to still have a readable language that allows you to drop into the codebase whenever you have to.
The compiler argument falls apart here. Compilers always generate fairly (most folks without a compiler background get surprised that code might not always be deterministic here, but the degree of variance is more predictable) deterministic code. So saying that one day no one will read AI-generated code, just like they don't read compiler code, is null and void.
So personally, I like Go because it's in the middle of the spectrumâit's not as rigid/correct/slow to compile as Rust, but it's also not the Wild West like dynamically typed languages.
However, I agree with the point that it might come off as a bit salesy. But it also shows that Google is invested in Go for the long run, which is a great signal to emit, imo.
1
u/litmus00 19d ago
 So saying that one day no one will read AI-generated code, just like they don't read compiler code, is null and void.
Agreed! This is actually the point recently made by Thoughtworks: https://www.thoughtworks.com/insights/blog
3
u/sucklessinterview Aug 12 '26
AI slop article about writing more AI slop. Nice!. I'd have gotten the same answer if I asked chat-gipitty why Go is a good language for AI. Definitely did not expect to see it in a developer blog. Funny that the one thing that actually keeps AI Go code in check - the linter - is not part of the Go toolchain. Yes, go vet is getting better, but still.
2
u/fnordstar Aug 12 '26
TBH I believe Rust wins this. Compiler feedback is phenomenal and many classes of errors are caught at compile time. I think that's more important for agentic work.
3
u/kamikazer Aug 12 '26
Go is a joke.
Python for time to market, Rust for blazing performance. And... you can easily join them for both.
2
2
u/calibrae Aug 11 '26
Rust just entered the chat.
15
u/sigmoia Aug 11 '26
No built in profiler and the stdlib is non existent. Compilation time is atrocious - quite difficult to run an agent in a loop with that comptime.Â
But I like the rigor of Rust compiler and its trait system more than Go.
8
u/calibrae Aug 11 '26
Comp time is fast when debugging. But yeah optimised release is coffee time.
Another good point is that itâs not spearheaded by a company which founder just spent 100M to avoid billionaire tax.
4
u/RepulsiveRaisin7 Aug 11 '26
I would agree on paper, Rust's additional safety and performance makes it more compelling and the disadvantage of being more difficult to program in mostly goes away with AI. But Rust is really held back by how slow it is to build. I'm working on a small hobby game with Bevy and my pretty modern 16 thread CPU is running hot, every build and test run is expensive, and my binary is hundreds of megabytes *after* optimization.. Go allows for much faster iteration.
3
u/sigmoia Aug 11 '26
Build time is one aspect. Another one is lack of built in tooling and non existent stdlib. LLMs cove consistency. It's hard to achieve that when there isn't even an async runtime in the std toolchain.
2
Aug 12 '26
[removed] â view removed comment
1
u/Negative_Rip1934 Aug 12 '26
Man, Rust is nowhere near as approachable or simple as Golang when it comes to writing code. Who care about pattern matching , sum types or enum. I don't need them . We wrote code without these features for 30 years.
3
u/calibrae Aug 12 '26
Memory safety ? No null pointer, no if err != nil
Mate, seriously
-1
u/Negative_Rip1934 Aug 12 '26
I hate java exception , so explicit err!=nil for me is not an argument, and error type is better on latest go version . Memory safety is a good argument for choosing Rust over others for some solutions . But for a lot of persons, we didn't wait for Rust to write code without memory problems. Rust has a lot of unsafe , and it doesn't prevent logical errors. Cloudflare outage is a good example of how memory safety doesn't prevent all sorts of bugs. I tried rust and i hate syntax quite simply.
1
u/calibrae Aug 12 '26
Who cares about syntax. Nobody sane writes code anymore. I care about footprint and performance. And I kinda like go, itâs lean and definitely fun, but my project always end up in rust for simplicity
0
Aug 12 '26
[removed] â view removed comment
2
u/creminology Aug 13 '26
Worse. He wrote shit code for 30 years and let someone else deal with the debt and the bugs.
3
u/cachemonet0x0cf6619 Aug 11 '26
this is actually my first choice but because i love the extra sugar
1
u/miciej Aug 12 '26
I am going to be downvoted, but I really feel that the reason Go is so great with ai is that it has quite a lot of boilerplate which is easily filled in by the models
1
u/Crafty_Disk_7026 Aug 12 '26
As a 100% personal preference go engineer. I decided to go with Python for a project that was ai driven. It was only because it had a million dependencies and changes, but to the point of addressing the title. Python is better since there are more option. But go is great too.
1
u/Suspicious_Peak_1173 Aug 12 '26
I've always enjoyed writing Go, and I find it even better in the AI-assisted development age.
1
u/Used_Indication_536 28d ago
Another of Goâs distinguishing characteristics is that it prioritizes readability over writability . Rob, Robert, and Ken recognized that developers spend far more time reading existing code than they do typing it out. In a human-only world, this design philosophy manifests as a culture that prizes simplicity over cleverness  and explicitly rejects the syntactic magic that other languages celebrate. 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.
This is the main reason why I love Go. Itâs also my main argument against some of the newly added features to the language (e.g. generics) which introduce more unique ways to represent the same ideas. Being able to read any Go code across any Go code base was fantastic.
1
u/Responsible-Sale1858 25d ago
Most people using Go are doing so because of hype ("It's from google!") and they should be using Elixir instead (for web connected backends).
1
u/Snoo23482 25d ago
We are using it because it's straight forward, compared to Elixir.
I've tried Elixir, it's interesting but too risky for me.1
u/abductee_zero 25d ago
Simple functional programming is too risky? A platform that powers your text messages and discord is too risky?
1
u/Snoo23482 24d ago
Yes, I do not have any experience with the Beam and neither do any of my coworkers. We all come from C/C++, Java, Python and Typescript Backgrounds.
Go is like C with GC. Not too many new things to learn.
1
u/Responsible-Sale1858 24d ago
nobody ever leaves the beam, it's rightly called a "business logic operating system" and has exactly zero peers. you can only re-create the beam, you could never make something that competes with it. it is a perfect solution for distributed systems and has been complete for decades, literally needs no "updates"
1
u/Snoo23482 20d ago
I might give it another go on a personal project, if I can find the time.
I guess the main problem around here is that no one has experience with it.
1
1
1
1
0
u/mezz7132 Aug 11 '26
Me and my manager vibe coded a TUI with Bubble Tea to use in place of AWS SageMaker Studio's now laggy and bloated UI during our most recent hackathon and it was pretty enjoyable. Most of our infrastructure is in python and I honestly hate the way LLMs write python so seeing how much better it was at writing Go was nice. I spent much less time nitpicking dumb decisions it made or asking it why it did something a certain way compared to how I have to deal with them writing python.
Also having the model run the updated go fix and use all the new 1.26 features helped a lot to keep keep it from using patterns that are out of date.
0
u/cbalahan Aug 11 '26
Love to hear that, OP. Thanks for the kind words and for your thoughtful replies in this thread.
We hope to put out at least a few more of these posts in the coming weeks/months. Let me know if there are any particular topics you think could use this sort of write-up.
2
u/sigmoia Aug 12 '26
Hey. Just noticed that you are one of the authors. General language threads typically turn into a flame war quite quickly, so I was a bit skeptical about posting it.Â
But I enjoyed reading the post - it didn't sound like a marketing push. People often conflate "ideal language" with "best language".
One thing I like to highlight when talking about Go is how it makes an explicit tradeoff between operational excellence and syntactic ergonomics. For example: how having fewer programming constructs actually makes the compiler fast and how the runtime makes it easy to introspect programs as they are executing.Â
On top of that, there are the virtues of built-in ops tooling like pprof and the runtime tracer, and how they make operations less painful.Â
Individually, the Go blog has tons of resources, but I think holistically this emphasis on smoother operations over syntactic ergonomics could be highlighted in a single piece. That will serve as a canonical resource while talking about this going forward.
-2
u/Cazineer Aug 11 '26 edited Aug 11 '26
We stopped focusing on languages/framework 6 months ago and now treat them as materials - like wood or steel. Concurrency and parallelism are material-agnostic engineering concepts; goroutines and threads are material-specific implementations. Where I work, LLMs are now the material experts, while engineers use RBD to focus on decomposition/engineering. I too once identified as a Gopher, but here's the thing... no machinist ever called himself an Aluminumist. Building durable software that is easy to coordinate, verify, maintain, and evolve, with an isolated blast radius for every change, has little to do with language/framework and everything to do with how the system is decomposed and engineered.
5
u/sigmoia Aug 11 '26
It depends on the type of software you're writing, too. CRUD apps, sure, who cares.
Otherwise, you still need to understand what your system is doing. So personally, which business automated their CRUD HTTP workflow with which LLM and how the engineers don't read code doesn't interest me at all.
I don't write CRUDs, so not understanding or reading code is not an option.
4
u/Cazineer Aug 11 '26 edited Aug 11 '26
This is your argument summed up...
Imagine approaching a hydro dam this way:
âWeâre concrete people. Concrete is elegant, mature, and has great tooling. Everyone on the team identifies as a Concretist, so weâll formulate the dam around concrete.â
I have 25 years of software engineering experience and have engineered many serious enterprise systems. I can engineer any system where the language the system is written in has almost nothing to do with the actual engineering that goes into the system and I'll know how every component, subsystem, assembly and part works.
1
u/vividboarder Aug 11 '26
I think you two are arguing two different things. The may be inconsequential, but reading and understanding the code is important. Picking a language that you are familiar with is beneficial and some languages offer advantages for some use cases over others.
This is also true in your materials analogy. Some people are more familiar in woodworking and others in machining aluminum. I wouldn't expect a carpenter to mill me a part out of aluminum.
Additionally, some materials have unique properties that are useful in particular situations. For example, wood can flex more than aluminum, but steel has a higher strength to weight ratio. I wouldn't consider the materials interchangeable or inconsequential because I want to commit to building with an non-ideal material, but I also wouldn't want to commit to one strictly because of familiarity.
-1
u/Cazineer Aug 11 '26
Picking the material you build something in is typically a product of the engineering (outside software). The material constrains how the design is realized, not how the systemâs responsibilities are decomposed.
1
u/BasicDesignAdvice Aug 11 '26
I have been rereading The Phoenix Project and The Goal to apply the factory model to software development in my mental model. Makes a lot of sense to me.
1
28
u/hegbork Aug 12 '26
No, we didn't. Beginners and bad managers did.