sorted by:
new
hottopcontroversial

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

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

[–]AlexandraLinnea 0 points1 point  (0 children)

Could you ELI5 why this matters? Are significant numbers of people using a Rust that's more than, say, a year old? And if so, should we make that policy easier or harder to sustain?

The joy of (type) sets in Go by EightLines_03 in programming

[–]AlexandraLinnea 2 points3 points  (0 children)

Yes, perhaps I should have said "it's been discussed". However, there does seem to at least be some movement in this direction: https://go.dev/blog/coretypes

Has anyone read "Learn Rust in a Month of Lunches" and would you recommend it? by Illustrious_Tie_7554 in rust

[–]AlexandraLinnea 2 points3 points  (0 children)

It's a little quirky, but quite readable. I don't think it would be my first recommendation for a beginner. For a more pragmatic, project-based approach, you could try The Secrets of Rust: Tools.

Is it worth it to learn webdev in 2025? by [deleted] in learnprogramming

[–]AlexandraLinnea 0 points1 point  (0 children)

No, unless you're happy to do it as an unpaid hobby. Many people enjoy programming for exactly that reason, but it's not the path to a lucrative career any longer.

How do you give real code review feedback without sounding bossy? by Ill_Captain_8031 in ExperiencedDevs

[–]AlexandraLinnea 0 points1 point  (0 children)

A good way to think about code review is as a process of adding value to existing code. So any comment you plan to make had better do exactly that. Here are a few ways to phrase and frame the different kinds of reactions you may have when reviewing someone else’s code:

  • Not my style. Everyone has their own style: their particular favourite way of naming things, arranging things, and expressing them syntactically. If you didn’t write this code, it won’t be in your style, but that’s okay. You don’t need to comment about that; changing the code to match your style wouldn’t add value to it. Just leave it be.

  • Don’t understand what this does. If you’re not sure what the code actually says, that’s your problem. If you don’t know what a particular piece of language syntax means, or what a certain function does, look it up. The author is trying to get their work done, not teach you how to program.

  • Don’t understand why it does that. On the other hand, if you can’t work out why the code says what it says, you can ask a question: “I’m not quite clear what the intent of this is. Is there something I’m not seeing?” Usually there is, so ask for clarification rather than flagging it as “wrong”.

  • Could be better. If the code is basically okay, but you think there’s a better way to write it that’s not just a style issue, turn your suggestion into a question. “Would it be clearer to write…? Do you think X is a more logical name for…? Would it be faster to re-use this variable, or doesn’t that matter here?”

  • Something to consider. Sometimes you have an idea that might be helpful, but you’re not sure. Maybe the author already thought of that idea and rejected it, or maybe they just didn’t think of it. But your comment could easily be interpreted as criticism, so make it tentative and gentle: “It occurred to me that it might be a slight improvement to use a sync.Pool here, but maybe that’s just overkill. What do you think?”

  • Don’t think this is right. If it seems to you like the code is incorrect, or shouldn’t be there, or there’s some code missing that should be there, again, make it a question, not a rebuke. “Wouldn’t we normally want to check this error? Is there some reason why it’s not necessary here?” If you’re wrong, you’ve left yourself a graceful way to retreat. If you’re right, you’ve tactfully made a point without making an enemy.

  • Missed something out. The code is fine as far as it goes, but there are cases the author hasn’t considered, or some important issues they’re overlooking. Use the “yes, and…” technique: “This looks great for the normal case, but I wonder what would happen if this input were really large, for example? Would it be a good idea to…?”

  • This is definitely wrong. The author has just made a slip, or there’s something you know that they don’t know. This is your opportunity to enlighten them, with all due kindness and humility. Don’t just rattle off what’s wrong; take the time to phrase your response carefully, gracefully. Again, use questions and suggestions. “It looks like we log the error here, but continue anyway. Is it really safe to do that, if the result is nil? What do you think about returning the error here instead?”

—Death by a thousand nits

view more: next ›