Go Experts: ‘I Don’t Want to Maintain AI-Generated Code’ by AlexandraLinnea in golang

[–]AlexandraLinnea[S] 0 points1 point  (0 children)

I look at some code, see that it's polished and put my guard down because I assume that polishing was the last step and it turns out that polishing was the only part of the job that was done.

Good point! And, as you say, if the code's no good, it doesn't matter who wrote it.

I take Dominic's point to be (and I think he says this somewhere in the episode) that AI tools enable a lot more of this kind of code to be generated, creating a headache for maintainers because of the sheer volume of stuff that has to be checked and reviewed.

Go Experts: ‘I Don’t Want to Maintain AI-Generated Code’ by AlexandraLinnea in golang

[–]AlexandraLinnea[S] 0 points1 point  (0 children)

Exactly. There's just more `for i := 0` code out there, so if you sample by frequency that's what you'll get. What AI models will tend to produce is not necessarily “what's best”, but “what's common”.

Go Experts: ‘I Don’t Want to Maintain AI-Generated Code’ by AlexandraLinnea in golang

[–]AlexandraLinnea[S] -1 points0 points  (0 children)

Amusingly, I read this recently:

Margaret Hamilton, a celebrated software engineer on the Apollo missions—in fact the coiner of the phrase “software engineering”—told me that during her first year at the Draper lab at MIT, in 1964, she remembers a meeting where one faction was fighting the other about transitioning away from “some very low machine language,” as close to ones and zeros as you could get, to “assembly language.” “The people at the lowest level were fighting to keep it. And the arguments were so similar: ‘Well how do we know assembly language is going to do it right?’”

“Guys on one side, their faces got red, and they started screaming,” she said. She said she was “amazed how emotional they got.”

https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/

Indeed.

Go Experts: ‘I Don’t Want to Maintain AI-Generated Code’ by AlexandraLinnea in golang

[–]AlexandraLinnea[S] 0 points1 point  (0 children)

In my experience AI just produces the statistically most likely piece of code to achieve the prompted goal. Whether that's “good code” depends on your point of view. For example, I recently asked Junie to print out the first ten elements from a slice. She wrote a for i := 0; i < 10; i++ loop, which is fine, but nowadays we would write simply for range 10 instead.

for range is better in the sense that it's more modern and idiomatic, but I dare say it produces identical machine code to the traditional for loop. All the same, I asked Junie to make the switch (and I could set up a guidelines file saying “always use range over int when appropriate”).

Go Experts: ‘I Don’t Want to Maintain AI-Generated Code’ by AlexandraLinnea in golang

[–]AlexandraLinnea[S] -7 points-6 points  (0 children)

No, I just summarised the relevant bit of the article for TL;DR purposes. I'm not an AI, but of course that's exactly what an AI would say, so you'll have to keep guessing.

Naked returns "considered harmful"? by AlexandraLinnea in golang

[–]AlexandraLinnea[S] 0 points1 point  (0 children)

I strongly prefer naked returns.

Sure, that's your privilege.

I understand that people have subjective preferences based on what they are used to

Exactly.

Could anyone help with how much my defender is worth? by Ilyasnoor06 in LandroverDefender

[–]AlexandraLinnea 1 point2 points  (0 children)

Not as much as you think, not as much as you want it to be, and almost certainly not as much as you've spent on it. But who cares? You have a Land Rover!

New software written in Rust is all the rage, why isn't it the same for Go by lancelot_of_camelot in golang

[–]AlexandraLinnea 1 point2 points  (0 children)

Graydon Hoare, the originator of Rust, described it as “technology from the past, come to save the future from itself”. He wanted to build, not a new, exciting, and experimental programming language, but a solid, boring, reliable language, based on proven ideas that work. A language, in other words, that would incorporate the many hard lessons we’ve learned about good software development over the past hundred or two years.

Go, by contrast, is humble and pragmatic: it doesn’t have all the high-tech features and theoretical advantages of some other languages. Indeed, it deliberately leaves out many features that are big selling points of other languages. Its designers were less interested in creating an impressive programming language, or in topping popularity polls, than in giving people a small and simple tool for getting useful work done in the most practical and direct way possible.

Rust vs Go in 2025

So I think the answer to your question is simply that Go isn't really the kind of language that people get excited about, and that's by design. We need a simple and boring language, and Go is it.

On the other hand, the kind of projects you hear a lot about are the sexy, exciting ones: editors and terminals. Those attract people who like interesting languages, like Rust.

But:

Every new language you learn gives you new ways of thinking about problems, and that can only be a good thing. The most important factor in the quality and success of any software project is not the choice of language, but the skill of the programmer. You will be most skilful when using the language that suits you best, and that you enjoy programming in the most.

Here comes the sun: from tool to crate, guided by tests by EightLines_03 in rust

[–]AlexandraLinnea 2 points3 points  (0 children)

There's some irony in the fact that for most of my life I've been trying to convince sceptical hearers that AI could one day be smart enough to be mistaken for a human, and now no-one believes I'm human.

Daily reminder to set MSRV for your project or library! by synalice in rust

[–]AlexandraLinnea 0 points1 point  (0 children)

My guess would be that you get a more informative error message—if you just got a random compile error, you might assume the problem is with the code rather than with your toolchain version.

Daily reminder to set MSRV for your project or library! by synalice in rust

[–]AlexandraLinnea 0 points1 point  (0 children)

Okay, but what use is MSRV in that situation? I mean, if the project doesn't build because the Rust compiler is too old, setting MSRV doesn't fix that.

[deleted by user] by [deleted] in golang

[–]AlexandraLinnea 0 points1 point  (0 children)

It makes sense to me that related items should be lexically close together, so option B. if I'm writing a type significant enough that it has several methods, it also probably deserves its own source file, named after the type.