hckrnws

I really liked this part:

In December 2024, during the frenzied adoption of LLM coding assistants, we became aware that such tools tended—unsurprisingly—to produce Go code in a style similar to the mass of Go code used during training, even when there were newer, better ways to express the same idea. Less obviously, the same tools often refused to use the newer ways even when directed to do so in general terms such as “always use the latest idioms of Go 1.25.” In some cases, even when explicitly told to use a feature, the model would deny that it existed. [...] To ensure that future models are trained on the latest idioms, we need to ensure that these idioms are reflected in the training data, which is to say the global corpus of open-source Go code.

PHP went through a similar effort a while back to just clear out places like Stackoverflow of terrible out of date advice (e.g. posts advocating magic_quotes). LLMs make this a slightly different problem because, for the most part, once the bad advice is in the model it's never going away. In theory there's an easier to test surface around how good the advice it's giving is but trying to figure out how it got to that conclusion and correct it for any future models is arcane. It's unlikely that model trainers will submit their RC models to various communities to make sure it isn't lying about those specific topics so everything needs to happen in preparation of the next generation and relying on the hope that you've identified the bad source it originally trained on and that the model will actually prioritize training on that same, now corrected, source.

This is one area where reinforcement learning can help.

The way you should think of RL (both RLVR and RLHF) is the "elicitation hypothesis[1]." In pretraining, models learn their capabilities by consuming large amounts of web text. Those capabilities include producing both low and high quality outputs (as both low and high quality outputs are present in their pretraining corpora). In post training, RL doesn't teach them new skills (see E.G. the "Limits of RLVR"[2] paper). Instead, it "teaches" the models to produce the more desirable, higher-quality outputs, while suppressing the undesirable, low-quality ones.

I'm pretty sure you could design an RL task that specifically teaches models to use modern idioms, either as an explicit dataset of chosen/rejected completions (where the chosen is the new way and the rejected is the old), or as a verifiable task where the reward goes down as the number of linter errors goes up.

I wouldn't be surprised if frontier labs have datasets for this for some of the major languages and packages.

[1] https://www.interconnects.ai/p/elicitation-theory-of-post-tr...

[2] https://limit-of-rlvr.github.io

I believe you absolutely could... as the model owner. The question is whether Go project owners can convince all the model trainers to invest in RL to fix their models and the follow up question is whether the single maintainer of some critical but obscure open source project could also convince the model trainers to commit to RL when they realize the model is horribly mistrained.

In Stackoverflow data is trivial to edit and the org (previously, at least) was open to requests from maintainers to update accepted answers to provide more correct information. Editing is trivial and cheap to carry out for a database - for a model editing is possible (less easy but do-able), expensive and a potential risk to the model owner.

I know Claude will read through code from Go libraries it has imported to ensure it is doing things correctly, but I do have to wonder for other languages and those small libraries, if we'll start seeing things like AGENT_README.md a file that describes the project, then describes what functionality is where in the code, and if necessary drills on a source file by source file basis (unless it's too massive - context limits are still limits). In any regard, I could see that becoming more common. Especially if you link to said file from the README.md for the model to go to. ;)

I think this can be fixed more generally by biasing towards newer data in model outputs and putting more weight on authoritative sources rather than treating all data the same. So no one needs to go in and specifically single out Go code but will instead look at new examples which use features like generics from sources like Google who would follow best/better practices than the rest of the codebase.

[flagged]

They're particularly bad about concurrent go code, in my experience - it's almost always tutorial-like stuff, over-simplified and missing error and edge case handling to the point that it's downright dangerous to use... but it routinely slips past review because it seems simple and simple is correct, right? Go concurrency is so easy!

And then you point out issues in a review, so the author feeds it back into an LLM, and code that looks like it handles that case gets added... while also introducing a subtle data race and a rare deadlock.

Very nearly every single time. On all models.

Good use case for Elixir. Apparently it performs best across all programming languages with LLM completions and its concurrency model is ideal too.

https://autocodebench.github.io/

This is the exact opposite of my experience.

Claude 4.6 has been excellent with Go, and truly incompetent with Elixir, to the point where I would have serious concerns about choosing Elixir for a new project.

Shouldn't you have concerns picking Claude 4.6 for your next project if it produces subpar elixer code? Cheapy shot perhaps, but I have a feeling exotic languages will remain more exotic longer now that LLM aided development is becoming the norm.

We've finally figured out how to spread ossification from network protocols to programming languages! \o/

We live in different realities.

Opus and Sonnett practically writes the same idiomatic elixir (phoenix, mind you) code that I would have written myself, with few edits.

It's scary good.

> a subtle data race and a rare deadlock

That's a langage problem that humans face as well, which golang could stop having (see C++'s Thread Safety annotations).

For Go, there is https://pkg.go.dev/gvisor.dev/gvisor/tools/checklocks. There are some missing things from C++ Thread Safety annotations, but those could be added.

Go has a pretty good race detector already, and all it (usually) takes to enable it is passing the -race flag to go build/test/run/etc.

No language protects from dead lock.

I probably agree that they don't protect you from all deadlocks, but some languages protect you from some dead locks.

You should be using rust... mm kay :\

Doing concurrency in Rust was more complex (though not overly so) than doing it in Golang was, but the fact that the compiler will outright not let me pass mutable refs to each thread does make me feel more comfortable about doing so at all.

Meanwhile I copy-pasted a Python async TaskGroup example from the docs and still found that, despite using a TaskGroup which is specifically designed to await every task and only return once all are done, it returned the instant theloop was completed and tasks were created and then the program exited without having done any of the work.

Concurrency woo~

The person I was replying to sounded exactly like the Rust zealots roving the internet trying to convince people to change.

So you are trying to explain concurrency to the folks who implemented CSP in both Plan9 and Go. Interesting. I should return "cspbook.pdf" back.

One day, maybe today, you will learn to read

(eval) rather than (read), then.

On concurrency, Go has the bolts screwed in; it basically was 'lets reuse everything we can from Plan9 into a multiplatform language'.

I have run into that a lot which is annoying. Even though all the code compiles because go is backwards compatible it all looks so much different. Same issue for python but in that case the API changes lead to actual breakage. For this reason I find go to be fairly great for codegen as the stability of the language is hard to compete with and the standard lib a powerful enough tool to support many many use cases.

The use of LLMs will lead to homogeneous, middling code.

Middling code should not exist. Boilerplate code should not exist. For some reason we're suddenly accepting code-gen as SOP instead of building a layer of abstraction on top of the too-onerous layer we're currently building at. Prior generations of software development would see a too-onerous layer and build tools to abstract to a higher level, this generation seems stuck in an idea that we just need tooling to generate all that junk but can continue to work at this level.

But Go culture promulgates this practice of repeating boilerplate. In fact this is one of the biggest confusion points of new gophers. "I want to do a thing that seems common enough, what library are you all using to do X?". Everyone scoffs, pushes up their glasses and says, "well actually, you should just use the standard library, it's always worked just fine for me". And the new gopher is confused because they really believe that reinventing the wheel is an acceptable practice. This is what leads to using LLMs to write all that code (admittedly, it's a fine use of an LLM).

The "LLMs shouldn't be writing code" take is starting to feel like the new "we should all just use No-Code."

We’ve been trying to "build a better layer" for thirty years. From Dreamweaver to Scratch to Bubble, the goal was always the same: hide the syntax so the "logic" can shine. But it turns out, the syntax wasn't the enemy—the abstraction ceiling was.

LLMs have always been great at generating code that doesn't really mean anything - no architectural decisions, the same for "any" program. But only rarely does one see questions why we're needing to generating "meaningless" code in the first place.

This gets to one of my core fears around the last few years of software development. A lot of companies right now are saddling their codebases with pages and pages of code that does what they need it to do but of which they have no comprehension.

For a long time my motto around software development has been "optimize for maintainability" and I'm quite concerned that in a few years this habit is going to hit us like a truck in the same way the off-shoring craze did - a bunch of companies will start slowly dying off as their feature velocity slows to a crawl and a lot of products that were useful will be lost. It's not my problem, I know, but it's quite concerning.

Where are the amazing no-hassle, no-boilerplate tools from last generation? Or the generation before that? Give me a break: it's easy to post this but it's proven very hard to simply "pick the right abstraction for everyone".

[dead]

It does. I’ve been writing Go for long enough, and the code that LLMs output is pretty average. It’s what I would expect a mid level engineer to produce. I still write code manually for stuff I care about or where code structure matters.

Maybe the best way is to do the scaffolding yourself and use LLMs to fill the blanks. That may lead to better structured code, but it doesn’t resolve the problem described above where it generates suboptimal or outdated code. Code is a form of communication and I think good code requires an understanding of how to communicate ideas clearly. LLMs have no concept of that, it’s just gluing tokens together. They litter code with useless comments while leaving the parts that need them most without.

I am also of the opinion that LLMs are still pretty bad at what's called "Low level design" - that is structuring functions and classes in a project. I wonder if a rule like torvalds' "No more than 4 levels of indentation" might make them work better.

Do LLMs generate code similar to middling code of a given domain? Why not generate in a perfect language used only by cool and very handsome people, like Fortran, and then translate it to once the important stuff is done?

This might work if Fortran were portable, or if only one compiler were targeted.

middling code, delivered within a tolerable time frame, budget, without taking excessive risk, is good enough for many real-world commercial software projects. homogeneous middling code, written by humans or extruded by machines, is arguably even a positive for the organisation: lots of organisations are more interested in delivery of software projects being predictable, or having a high bus-factor due to the fungibility of the folks (or machines) building and maintaining the code, rather than depending upon excellence.

You might even say that LLMs are not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

This is a rob pike reference for the uninitiated: https://news.ycombinator.com/item?id=30688969

For a few years, yeah. Eventually it will probably lead to the average quality of code being considerably higher than it was pre-LLMs.

I'm not sure if that's a criticism or praise - I mean, most people strive for readable code.

LLM generated code reminds me of perl's "write-only" reputation.

Does it really? Because I see some quite fine code. The problem is assumptions, or missing side effects when the code is used, or getting stuck in a bad approach "loop" - but not code quality per se.

In all honesty I've only used LLMs in anger with Go, and come away (generally speaking) happy with what it produced.

[dead]

I'd prefer we start nuking the idea of using LLMs to write code, not help it get better. Why don't you people listen to Rob Pike, this technology is not good for us. Its a stain on software and the world in general, but I get it most of ya'll yearn for slop. The masses yearn for slop.

I totally agree. I read threads like this and I just can’t believe people are wasting their time with LLM’s.

The masses yearn to not have to fiddle with bs for rent and food

I definitely see that with C++ code Not so easy to "fix", though. Or so I think. But I do hope still, as more and more "modern" C++ code gets published

battle of my life. several times i’ve had to update my agent instructions to prefer modern and usually better syntax to the old way of doing things. largely it’s worked well for me. i find that making the agents read release notes, and some official blog posts, helps them maintain a healthy and reasonably up-to-date instructions on writing go.

I think tooling that can modify your source code to make it more modern is really cool stuff. OpenRewrite comes to mind for Java, but nothing comes to the top of my mind for other languages. And heck, I into recently learned about OpenRewrite and I've been writing Java for a long time.

Even though I don't like Go, I acknowledge that tooling like this built right into the language is a huge deal for language popularity and maturity. Other languages just aren't this opinionated about build tools, testing frameworks, etc.

I suspect that as newer languages emerge over the years, they'll take notes from Go and how well it integrates stuff like this.

In PHP you can use Rector[1]

It's used a lot to migrate old codebases. The tool is using itself to downgrade[2] it so that it can run on older PHP versions to help upgrades.

[1] https://getrector.com

[2] https://github.com/rectorphp/rector-downgrade-php

Coccinelle for C, used by Linux kernel devs for decades, here's an article from 2009:

https://lwn.net/Articles/315686

Also IDE tooling for C#, Java, and many other languages; JetBrains' IDEs can do massive refactorings and code fixes across millions of lines of code (I use them all the time), including automatically upgrading your code to new language features. The sibling comment is slightly "wrong" — they've been available for decades, not mere years.

Here's a random example:

https://www.jetbrains.com/help/rider/ConvertToPrimaryConstru...

These can be applied across the whole project with one command, rewriting however many problems there are.

Also JetBrains has "structural search and replace" which takes language syntax into account, it works on a higher level than just text like what you'd see in text editors and pseudo-IDEs (like vscode):

https://www.jetbrains.com/help/idea/structural-search-and-re...

https://www.jetbrains.com/help/idea/tutorial-work-with-struc...

For modern .NET you have Roslyn analyzers built in to the C# compiler which often have associated code fixes, but they can only be driven from the IDE AFAIK. Here's a tutorial on writing one:

https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/t...

Rust has clippy nagging you with a bunch of modernity fixes, and sometimes it can autofix them. I learned about a lot of small new features that make the code cleaner through clippy.

Does anyone have experience transforming a typescript codebase this way? Typescript's LSP server is not powerful enough and doesn't support basic things like removing a positional argument from a function (and all call sites).

Would jscodeshift work for this? Maybe in conjunction with claude?

jscodeshift supports ts as a parser, so it should work.

If you want to also remove argument from call sites, you'll likely need to create your own tool that integrates TS Language Service data and jscodeshift.

LLMs definitely help with these codemods quite a bit -- you don't need to manually figure out the details in manipulating AST. But make sure to write tests -- a lot of them -- and come up with a way to quickly fix bugs, revert your change and then iterate. If you have set up the workflow, you may be able to just let LLM automate this for you in a loop until all issues are fixed.

Try ast-grep

Haskell has had hlint for a very long time. Things like rewriting chained calls of `concat` and `map` into `concatMap`, or just rewriting your boolean expressions like `if a then b else False`.

python has a number of these via pyupgrade, which are also included in ruff: https://docs.astral.sh/ruff/rules/#pyupgrade-up

> but nothing comes to the top of my mind for other languages

"cargo clippy --fix" for Rust, essentially integrated with its linter. It doesn't fix all lints, however.

Java and .NET IDEs have had this capabilities for years now, even when Eclipse was the most used one there were the tips from Checkstyle, and other similar plugins.

Yeah I've noticed the IDEs have this ability, but I think tooling outside of IDEs that can be applied in a repeatable way is much better than doing a bunch of mouse clicks in an IDE to change something.

I think the two things that make this a big deal are: callable from the command line (which means it can integrate with CI/CD or AI tools) and like I mentioned, the fact this is built into Go itself.

eslint had `--fix` since like 10 years, so this is not exactly new.

Lebab too: https://lebab.github.io/

I can’t find where in the article the author claims it is new (as in original).

In fact, the author shows that this is an evolution of go vet and others.

What’s new, however, is the framework that allows home-grown add ons, which doesn’t have to do everything from scratch.

Its tooling like this that really makes golang an excellent language to work with. I had missed that rangeint addition to the language but with go fix I'll just get that improvement for free!

Real kudos to the golang team.

There have been many situations where I'd rather use another language, but Go's tooling is so good that I still end up writing it in Go. So hard to beat the build in testing, linting, and incredible compilation.

Absolutely.

The Go team has built such trust with backwards compatibility that improvements like this are exciting, rather than anxiety-inducing.

Compare that with other ecosystems, where APIs are constantly shifting, and everything seems to be @Deprecated or @Experimental.

I just searched for `for` loops with `:=` within and hand-fixed them. I found a few forms of the for loops and where there was a high number, I used regexp.

This tool is way cooler, post-redesign.

Not even mentioned in the article, my favorite capability is the new `//go:fix inline` directive, which can be applied to a one-line function to make go fix inline it's contents into the caller.

That ends up being a really powerful primitive for library authors to get users off of deprecated functions, as long as the old semantics are concisely expressible with the new features. It can even be used (and I'm hoping someone makes tooling to encourage this) to auto-migrate users to new semver-incompatible versions of widely used libraries by releasing a 1.x version that's implemented entirely in terms of thin wrappers around 2.x functions and go fix will automatically upgrade users when they run it.

Incidentally I saw the Wes McKinney podcast who said that Go was the perfect language now because of the fast compile-run cycle with strong types and built in multi thread safety was perfect for Coding Agents. Gave me a whole new interest. https://www.youtube.com/watch?v=1VfzDXeQRhU

[dead]

Go and its long established conventions and tools continues to be a massive boon to my agentic coding.

We have `go run main.go` as the convention to boot every apps dev environment, with support for multiple work trees, central config management, a pre-migrated database and more. Makes it easy and fast to dev and test many versions of an app at once.

See https://github.com/housecat-inc/cheetah for the shared tool for this.

Then of course `go generate`, `go build`, `go test` and `go vet` are always part of the fast dev and test loop. Excited to add `go fix` into the mix.

And the screamingly fast compilation speed is a boon to fast LLM iterations as well.

the LLM training data angle is real - we noticed the same thing when reviewing AI-generated Go code. the style is fine to fix automatically, but the security patterns are harder. LLMs trained on pre-1.21 code will happily generate goroutines with shared mutable state and no context propagation, which go fix doesn't touch. honestly not sure if the solution is more tooling or just better review habits for AI-generated code specifically

Not related with go: I recently tried to learn Python beyond the classical example code from the web. After discovering that there are more or less 4 different ways to do a thing with no clear guide what best practice is. I come from C and there one is happy if there is ONE way to do a thing :). Is Go at this stage? Im Intrested in learning Go but not to a point where i need a LLM to determin if my code follows best practice.

go is fairly opinionated and there is very often only one way to do a thing.

For parts where it is not the case see this thread they really work on keeping a fairly simple language. I'd recommend it to anyone tired of python messes

Self-service analyzers! This will be huge for big libraries and I can imagine heavily used by infra folks (although they could use analyzers already).

I wonder if you could make a language that is NOT backward compatible if you develop a tool like this alongside it.

biome kind of does this stuff for me in the typescript world. for example, it recommends for...of instead of forEach. paired with ultracite, it really improves my workflow because it is super easy to add to any project, just one dependency. breath of fresh air compared with the eslint ecosystem.

i now have an agents.md file that says to run biome fix after every modification. i end with much nicer code that i don't have to go and fix myself (or resave the file to get biome to run). speeds things up considerably to not have that step in my own workflow.

[dead]

We have this with our frontend code through elm-review. There are a great many rules for it with fixes, and we write some specifically for our app too. They then run pre-push so you get feedback early that you need to fix things.

The real key: there's no ignore comment as with other linters. The most you can do is run a suppress command so that every file gets its current number of violations of each rule recorded in JSON, and then you can only ever decrease those numbers.

[dead]

I believe go tooling is one of the top loved features among gophers, in particular gofmt.

The best part is that all those command line utilities are also available for import. I've used them to create a license checker by walking the dep tree in code.

There are also a ton of gems in the `./internal` directories, Roger Peppe has extracted them for reuse here: https://github.com/rogpeppe/go-internal

[flagged]

[flagged]