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

41–50 of 97 posts

Re: Using go fix to modernize Go code

#41

Post by shoo »

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.

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.

Re: Using go fix to modernize Go code

#42

Post by jpalepu »

munk-a wrote: post #7
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…

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…

[flagged]

Re: Using go fix to modernize Go code

#43

Post by homebrewer »

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…

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

Re: Using go fix to modernize Go code

#44

Post by hbogert »

monooso wrote: post #40
brightball wrote: post #26

Earlier quoted context omitted.

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.

Re: Using go fix to modernize Go code

#45

Post by nu11ptr »

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…

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

Re: Using go fix to modernize Go code

#46

Post by loevborg »

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…

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?

Re: Using go fix to modernize Go code

#47

Post by 1-more »

Arifcodes wrote: post #22

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

Re: Using go fix to modernize Go code

#48

Post by throw432196 »

dakolli wrote: post #39
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.

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

Re: Using go fix to modernize Go code

#49

Post by nitnelave »

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…

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.

Re: Using go fix to modernize Go code

#50

Post by whattheheckheck »

dakolli wrote: post #39
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.

The masses yearn to not have to fiddle with bs for rent and food
Post reply on HN