What Go Programmers Think of AI

"Most Go developers are now using AI-powered development tools when seeking information (e.g., learning how to use a module) or toiling (e.g., writing repetitive blocks of similar code)." That's one of the conclusions Google's Go team drew from September's big survey of 5,379 Go developers.

But the survey also found that among Go developers using AI-powered tools, "their satisfaction with these tools is middling due, in part, to quality concerns." Our survey suggests bifurcated adoption — while a majority of respondents (53%) said they use such tools daily, there is also a large group (29%) who do not use these at all, or only used them a few times during the past month. We expected this to negatively correlate with age or development experience, but were unable to find strong evidence supporting this theory except for very new developers: respondents with less than one year of professional development experience (not specific to Go) did report more AI use than every other cohort, but this group only represented 2% of survey respondents. At this time, agentic use of AI-powered tools appears nascent among Go developers, with only 17% of respondents saying this is their primary way of using such tools, though a larger group (40%) are occasionally trying agentic modes of operation...

We also asked about overall satisfaction with AI-powered development tools. A majority (55%) reported being satisfied, but this was heavily weighted towards the "Somewhat satisfied" category (42%) vs. the "Very satisfied" group (13%)... [D]eveloper sentiment towards them remains much softer than towards more established tooling (among Go developers, at least). What is driving this lower rate of satisfaction? In a word: quality. We asked respondents to tell us something good they've accomplished with these tools, as well as something that didn't work out well. A majority said that creating non-functional code was their primary problem with AI developer tools (53%), with 30% lamenting that even working code was of poor quality.

The most frequently cited benefits, conversely, were generating unit tests, writing boilerplate code, enhanced autocompletion, refactoring, and documentation generation. These appear to be cases where code quality is perceived as less critical, tipping the balance in favor of letting AI take the first pass at a task. That said, respondents also told us the AI-generated code in these successful cases still required careful review (and often, corrections), as it can be buggy, insecure, or lack context... [One developer said reviewing AI-generated code was so mentally taxing that it "kills the productivity potential".]

Of all the tasks we asked about, "Writing code" was the most bifurcated, with 66% of respondents already or hoping to soon use AI for this, while 1/4 of respondents didn't want AI involved at all. Open-ended responses suggest developers primarily use this for toilsome, repetitive code, and continue to have concerns about the quality of AI-generated code.
Most respondents also said they "are not currently building AI-powered features into the Go software they work on (78%)," the surveyors report, "with 2/3 reporting that their software does not use AI functionality at all (66%)." This appears to be a decrease in production-related AI usage year-over-year; in 2024, 59% of respondents were not involved in AI feature work, while 39% indicated some level of involvement. That marks a shift of 14 points away from building AI-powered systems among survey respondents, and may reflect some natural pullback from the early hype around AI-powered applications: it's plausible that lots of folks tried to see what they could do with this technology during its initial rollout, with some proportion deciding against further exploration (at least at this time).

Among respondents who are building AI- or LLM-powered functionality, the most common use case was to create summaries of existing content (45%). Overall, however, there was little difference between most uses, with between 28% — 33% of respondents adding AI functionality to support classification, generation, solution identification, chatbots, and software development.

Re:All your base will belong to AI

[Anonymous Coward]

I notice that you said the output of Claude is cheaper, not better. Thank you mister clueless pointy-haired boss who doesn't care if your company produces shit code and shit products, as long as it is "cheaper".

Re:All your base will belong to AI

[backslashdot]

It's the customer that drives that. Back in the 90s, a friend of mine worked at a textile factory in North Carolina. They were producing high quality fabric at $20 a pound. The Asians were offering slightly lower quality "good enough" fabric at $4 a pound. What did the consumer choose? Take a guess. Don't bitch at the manufacturer, bitch at the consumer preference. You see two products on the shelf one is cheaper and you know it sacrifices quality. You don't care.

Buy Once, Cry Once.

[geekmux]

You see two products on the shelf one is cheaper and you know it sacrifices quality. You don't care.

Most don't care.

Those that do care often enjoy the kind of quality and benefit that infers buy once, cry once. Constantly replacing even "cheap" items makes them not cheap. Inflation is a bitch when you consider *anything* you bought last century and are now buying again is twice as expensive. Multiply that across a lifetime and you can really start to find respect a product built and guaranteed for life. Including the price.

I wonder who might still be using high quality North Carolina fabric, and who might have replaced *good enough* fabrics three times already.

Re:

[allo]

Blaming the customer never worked. It looks like there is a market for a slightly lower quality $4 product. There may be a market for the higher quality product at $8 even when there is a $4 product. But no market for $20 when the alternative is a not too bad $4 product. If you feel better, tell your customers they are stupid, but don't expect that it makes them come back.

Re:

[test321]

I think the argument is that the AI assistant is so cheap it is worth using even if it is not better than the human. So cheap it even compares favourably to a totally free intern, in that an AI assistant is available 24/7, does not complain, quit, is not temperamental nor hard to manage. Both make stupid mistakes, but the AI is more consistent along time, such that after an habituation period you can depend on it within usefulness boundaries you come to establish.

Re:

[rot16]

Current AI prices are all deceiving, since AI hasn't entered the shareholder value maximising phase, quite the opposite. It won't be exactly cheap when the enshittification starts. It will still be cheaper than real developers.

Re:

[jythie]

The big problem will not be how many mistakes it makes, but if you can explain some feature to it.

Something I have been noticing in a lot of AI generated media, it can be visually impressive, but once someone actually tries to use it to tell a story, even a simple one, they find they can't control it well enough to actually produce what they want.

Ai generated stuff is great when you don't care what it produces because you just need _something_ that is close.. but as Ai researchers have known long before t

Re:

[geekmux]

I notice that you said the output of Claude is cheaper, not better. Thank you mister clueless pointy-haired boss who doesn't care if your company produces shit code and shit products, as long as it is "cheaper".

Thank Microsoft, for writing The Billionaire's Guide to Suck-cess?

Thank the consumer, who kept buying it? Like, every time?

How many more thanks across the face would you like? Feels like you're standing next to two sheiks arguing over a Cannonball Run.

Re: All your base will belong to AI

[SigIO]

Claude can refactor your code a lot faster than you can correct your attitude, Mister Anonymous.

Deal with it.

Re:

[Samuel Silverstein]

This is important:

(e.g., learning how to use a module) or toiling (e.g., writing repetitive blocks of similar code)

They use the LLM for learning and for rote work. This is perfect for Go. Go means favoring simplicity over higher level concepts. Like English at elementary school level instead of college level. Most languages have macros, generic types and union types. Go philosophy is "these concepts take too long to learn". Favor long code over concise code. Repeat yourself, often. Fix the same bug, often.

The complexity is even less of a factor. This isn't hype or fear; it's the new reality.

Welcome to Go. Welcome to 2009.

Re:

[phantomfive]

If you write redundant code, that's on you. Even in Go, you don't need to do that. Even in assembly you don't need to do that.

Learn the Go tricks for conciseness.

Re:

[Entrope]

OK, please tell me how to avoid writing code like this:

a, err := foo()
if err != nil {
return fmt.Errorf("foo failed: %w", err)
}

b, err := bar(a)
if err != nil {
return fmt.Errorf("bar failed: %w", err)
}

(Ignore for the moment whether you're using a version of Go that rejects the second "err :=", which requires kludgier code, and that both "foo" and "bar" will be much longer in real life.)

Re:

[phantomfive]

This has some ideas [stackoverflow.com], although you are quite competent (based on your previous posts, etc) and I am quite certain you can figure out a more elegant way to do it.

Re:

[Entrope]

My question wasn't really meant to be about method chaining, but about the tedious boilerplate around testing error result values. There are answers to that also (https://stackoverflow.com/questions/18771569/avoid-checking-if-error-is-nil-repetition#18772200) but the general answer is still that you have to just suck it up and have N or N-1 "if err != nil { return ... }" blocks.

Re:

[Samuel Silverstein]

I prefer the ML way, which your stackoverflow doesn't consider. Rust, which borrows heavily from ocaml, does not have or use exceptions. You can do method chaining, and you can simply handle errors inline. How you do that is flexible, depending on your need. The error can be handled by the calling function using a simple question mark, like

let bar = foo()?.bar()?

Or you can transform the error or the resulting value using e.g.

let bar = foo().map(|v| v.bar())?

If your type implements Default (basically all pri

Re:

[gweihir]

You said that correctly, "cheaper" as in "cheaply (and hence badly) made".

Yes, LLMs allow you to make code even cheaper. But you still only get what you pay for. They are not magic. I do get that many people really do not get the idea of "quality" and how not having it ruins you in the longer term.

Also note that LLM-type AI is bound to be come A LOT more expensive in the near future, after the inevitable crash from the utterly catastrophic business stats.

Re: All your base will belong to AI

[SigIO]

Correction: Management and orchestration are all that will be left. ./npx get-shit-done-cc

For a glimpse of what's to come.

But does it compile? + AI is a religion

[Somervillain]

You could be right. That's how things are supposed to work. One problem: The shit Claude generates compiles just over half the time these days. While it's definitely a threat to stackoverflow, something is just off. Things should be exactly how you said they are. It makes perfects sense in theory. But.....if it were true, why don't we see more results? If LLMs could make "good enough" software for nearly free....why aren't we seeing a renaissance of nimble startups eating the lunch of every establis

Re:

[phantomfive]

You could be right.

He's not right, he's a liar.

Even the most ardent AI evangelist doesn't say "the platform is irrelevant and the complexity is even less of a factor." Beyond being nonsensical, it doesn't match the reality of AI (it's widely acknowledge to be better at some things than others).

Re:

[phantomfive]

I've been in this business for over 30 years.

Been in the business for 30 years, can't say anything about the business other than vague generalities. Can't clarify what his business is (but it doesn't matter, according to him).

How to spot a liar.

Re: All your base will belong to AI

[SigIO]

Listen son: My original post, which was free of negativity, yet has done nothing but stir up fear and loathing. Disbelief is one of the first stages of the denial process. See you at acceptance.

Re:

[phantomfive]

Liars blame other people, like you did.

It's easy to prove you're not lying, by saying something sensible. But you were quoting something you read somewhere, you aren't speaking from experience so you can't.

Re: All your base will belong to AI

[SigIO]

You want specifics? Fine.

CC has built no fewer than 4 modestly complicated NetSuite projects in the past 2 weeks. Custom Suitelet UI javascript. Custom Record and List definitions. REST API integrations. Implementation and Unit Test documentation. Just about everything I would bill (or pay) around $200 bucks an hour. And it works. Tens of thousands of dollars saved, for what, a $100 dollar Claude Pro subscription.

Remain in disbelief if you want, but your cheese is on the move.

Re:

[phantomfive]

Yeah, even when you get specific it's still vague. You can't even tell whether you are billing or paying. Which is it bro?

Re:

[HiThere]

The analogy I use is "John Henry drove 16 feet and the steam drill only drove 9". I don't think one should try to be John Henry, but you can if you want to.

OTOH, the real question is "Is the code good enough?", and that depends on context. Lots of people have been saying they need to spend too much time correcting it. The thing is steam drills kept getting better, and John Henry killed himself trying to outdo them.

My own opinion, take with salt and more salt

[silvergig]

I have spent the last 2 weeks really getting into CoPilot for helping write code, (python specifically). I am very fluent in Python, and have been for awhile. I give a shit about architecture, clean/simple code, data types, and can pass my stuff through mypy and it passes.

I started two greenfield projects - one for embedded development and one for math modeling using numpy and python, (C was a long time ago for me, and I am not deeply familiar with numpy, but I have knowledge of calculus and advanced

Re:

[gweihir]

I hope you do not plan to give that code any publicly available interfaces. Because LLMs are absolute crap at writing secure code. Probably because most people that proudly put their code on the net as "examples" are too.

Re:

[silvergig]

I hope you do not plan to give that code any publicly available interfaces. Because LLMs are absolute crap at writing secure code. Probably because most people that proudly put their code on the net as "examples" are too.

If I was going to give a public interface to anything, it's going to go through the same process that I have been using for a number of years now - a templated design that has been tested/pentested/tested again for holes. And these days, it will likely be behind an AWS api gateway as well if we're talking about internet-facing apis. It won't be some EC2 instance with a public ip and a sec group of 80 -> 0.0.0.0/0.

I should have added in my original post that I feel AI tools can be very useful in th

Re:

[gweihir]

I see you are being careful. Good. Careful and competent people can be trusted with any tool.

I had a student look at how well LLMs do with security (including several paid ones up to around the $100 tier) and the results for anything that matters (security-patch level or CVE level) are pretty bad. If code is well isolated, that matters not that much, unless it is something high profile with a lot of visibility.

That unmaintainable app will provide an interesting lesson. Fixing complex code is typically more

Re:

[HiThere]

Most published examples don't handle exception processing, either. But that's something that's easy to add. (OTOH, it can be really tedious. It's really something that AI *should* handle.)
(FWIW, I haven't used any code generator, so I don't know what Claude turns out, maybe it does handle exception. But the published examples sure don't.)

Re:

[gweihir]

Hmm. IMO exception design is one place where architecture matters and what you want to do overall matters. LLMs cannot do either.

Re:

[rot16]

This reflects my experience as well. It really lowers the bar of entry for much of technical work. It suits well when the cost of trying it out is nothing.
It can help learning a lot if it does not replace thinking. It can be an extremely kind and patient tutor, useful even if it is sometimes wrong.

Re:

[phantomfive]

But I also started with a basic architecture diagram of what I wanted, and that is also a big factor.

Do you recommend using UML to diagram your architecture, or is it basic enough that SGML worked fine?

Re:

[coofercat]

I've been using Gemini alongside a Vue web app. By preference I'm a backend sort of guy, but I've quite enjoyed working with Vue. I really dislike some aspects of Javascript, HTML and CSS, but there Gemini (usually) saves me quite well. It comes up with some useful chunks of code, which I accept maybe half the time. Sometimes that saves me one line of code, sometimes it saves maybe 10.

I would stress that in my view, however the code was generated, it's still my responsibility. As such, I do spend a lot of t

If you write a program even a fool can use

[symbolset]

Only a fool would want to.

Re:

[gweihir]

To be fair, there are tons of fools around. The very AI hype currently going shows that nicely. Or the 8 or so previous, equally mindless AI hypes. Although they were smaller and did not have a global economic crash at their end.

So search and copy & paste?

[gweihir]

What a great win for AI! Go info would be just as fast to look up directly (but no hallucination), and cut & paste needs care anyways. Better write a function.

Sounds like an entirely redundant use that will fall into "slightly faster .... slightly slower" and in no way even remotely justifies the effort that goes into LLMs. Or the risks, because that AI generated code may well not have copyright, may leak and may have hallucinations in it. Or, worse, attack code from model poisoning. And the module info might have hallucinations too, see "slop-squatting attacks".

Re:

[Mr. Dollar Ton]

Yeah, it is the stack exchange, but without the third comment by the person who actually got the question correctly and wrote the proper answer.

Re:

[gweihir]

That is an excellent comparison.

Yes, we understand the need

[Mr. Dollar Ton]

toiling (e.g., writing repetitive blocks of similar code)

If you're continuously "toiling", e.g. writing repetitive blocks of similar code, you're very likely doing it wrong.

But then you're the type of coder that will need to use "AI".

Re:

[serviscope_minor]

If you're continuously "toiling", e.g. writing repetitive blocks of similar code, you're very likely doing it wrong.

This is pretty much the origin story of go, replacing expressiveness with limited builtin types, no generics and endless toil.

Re:

[Mr. Dollar Ton]

Never had the need or the curiosity to look at it, but if this is the case, then I can pity those who must use it.

Re:

[HiThere]

That's not a fair description. There are areas where go is a superior choice. Channels are very useful, and could save an immense amount of effort. OTOH, the documentation really NEEDS an AI front end. And there's no decent way to generate local documentation (i.e. documentation for your code that doesn't require setting up a local server).

So I've always avoided it for anything that needed much documentation (i.e. most things). (FWIW, I don 't like Doxygen, but it's the best documentation system I've

Re:

[serviscope_minor]

That's not a fair description. There are areas where go is a superior choice.

Well, yeah I was being a bit of a dick. It's got a builtin set of types that are a good match to a certain type of web service. If you're working within that domain (which is not small), yeah it's a good fit.

Bit it's really manual for anything else.

No, I don't want all my code base belonging to AI

[butt0nm4n]

I don't trust the parties providing 3rd party AI services with my IP, data or commercial secrets. It's in the AI companies interest to rob my data to improve their product.

And I certainly don't trust them to manage integration with stuff behind my firewall or my money.

So no AI will not own my code base because I don't want it to. It's a security risk.

If you are interested in this technology, I suggest find a way for companies to easily grow and integrate LLM behind their firewall, independently, without hav

Avoidance of AI

[bakayoko]

correlates positively with intelligence, for reasons entirely internal to the issue at hand, which is simulating intelligence.

Very useful

[Dan East]

I've been coding since the 1980s, full-time since the mid 90s. Anyone NOT using some degree of AI at this point is really a luddite in that regard.

Not using at least some AI is along the lines of saying that IDEs make bad programmers, or inline auto-complete makes for bad programmers, etc. There has to be some kind of underlying dogma to not be using it at all at this point.

And this comes from someone whose code was originally stored on cassette tapes, and was thrilled to death having two floppy drives on m

Why Ask a Google-Centric View of AI

[BrendaEM]

Go was designed by Google, which has also AI holdings. So why ever ask them?
https://en.wikipedia.org/wiki/... [wikipedia.org] "Go was designed at Google in 2007 to improve programming productivity in an era of multicore, networked machines and large codebases.[23] The designers wanted to address criticisms of other languages in use at Google, but keep their useful characteristics:[24]"