Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using go fix to modernize Go code

go.dev

Post reply on HN
Print view View original

31–40 of 97 posts

Re: Using go fix to modernize Go code

#31

Post by meowface »

HumblyTossed wrote: post #5
homarp wrote: post #2

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 a…

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

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

Re: Using go fix to modernize Go code

#32

Post by zhfliz »

retrodaredevil wrote: post #8

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 popularit…

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

Re: Using go fix to modernize Go code

#33

Post by awesome_dude »

Jyaif wrote: post #23
Groxx wrote: post #18

Earlier quoted context omitted.

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,…

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

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

Re: Using go fix to modernize Go code

#34

Post by nzoschke »

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.

Re: Using go fix to modernize Go code

#35

Post by pklausler »

bee_rider wrote: post #19
HumblyTossed wrote: post #5

Earlier quoted context omitted.

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

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.

Re: Using go fix to modernize Go code

#36

Post by kbolino »

Jyaif wrote: post #23
Groxx wrote: post #18

Earlier quoted context omitted.

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,…

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

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.

Re: Using go fix to modernize Go code

#37

Post by [deleted] »

Groxx wrote: post #18
homarp wrote: post #2

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 a…

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,…

[deleted]

Re: Using go fix to modernize Go code

#38

Post by silverwind »

retrodaredevil wrote: post #8

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 popularit…

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

Re: Using go fix to modernize Go code

#39

Post by dakolli »

homarp wrote: post #2

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 a…

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.

Re: Using go fix to modernize Go code

#40

Post by monooso »

brightball wrote: post #26
Groxx wrote: post #18

Earlier quoted context omitted.

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,…

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.

Post reply on HN