Live data from Hacker News

Go is an ideal language for AI-assisted software engineering

developers.googleblog.com

451–460 of 586 posts

Re: Go is an ideal language for AI-assisted software engineering

#451
post #438

I will leave this prediction here and maybe come back in few years: 1. JS is mem-safe, single-threaded, and there are lots of training data. Easily my first choice. I'd put Python here as well, although I don't like it personally. Both should be used with "avoid external deps" in your AGENTS.md 2. Go might be a good second choice. Simple language, IMO good primitives for concurrency, well-designed std, therefore smal…

I mostly use Elixir and JS, and I'm constantly surprised by how much easier and better the code quality is in Elixir, especially given the much smaller training data. I've started to use it for all my personal projects. I think Elixir's terseness, introspection capabilities, and strong ecosystem-wide quality guards really help. At work, we use C#. I'm shocked at how much worse it is. I've also used a bunch of Python,…

What issues are you seeing using LLMs with C#?

Re: Go is an ideal language for AI-assisted software engineering

#452
post #449

Earlier quoted context omitted.

Go's big advantage was M:N threads. Java's biggest flaw has been the lack of cooperative multitasking, which people worked around by mangling their code with promises. Now Java has M:N threads too thanks to Project Loom, but there's so much code written before that will never really go away.

Java already had M:N threads in the early days, aka green threads, because the JVM and Java specifications did not assert what kind of threading was to be provided. Thus most JVM implementations had a mix of red (1:1:) and green (M:N) threads, eventually only red threads were kept in the surviving implementations. With Project Loom now both models are officially supported and part of the specification.

Yeah I've heard of the Java 1-2 greenthreads, but supposedly those were M:1, ie you could only run them on one core. At least this SCO release note linked from Wikipedia says that: https://www.sco.com/developers/java/j2sdk122-001/ReleaseNote... And the pros are more about compatibility than performance

Re: Go is an ideal language for AI-assisted software engineering

#453

It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making. What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go. Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squint…

Very good point, thanks for confirming that! What is the reasoning behind the Go design choices you described?

Re: Go is an ideal language for AI-assisted software engineering

#454
post #396

Earlier quoted context omitted.

Java and C# (JVM and .NET in general) are favorable here.

Uh at the very least Java is bad. the java programs we run take 4 gigs and burn my entire compute. Every1 used spring or guice and the di runtime, so tests are expensive for e2e with mocks. There’s no scrutable way I can run more than 2 or 3 on a standard laptop without burning out the thing. Go can.

That could be a Spring issue then, not Java. Do you run with -Xmx specified?

Re: Go is an ideal language for AI-assisted software engineering

#455
post #318

Earlier quoted context omitted.

Surely the King is doing it, so that must be the correct way. Look, the King even wears clothes and is totally not naked at all. That the world runs on Kubernetes is no qualitative statement about the correctness of its Raft implementation. You can say that it's clearly good enough to not matter most of the time, but that is a different statement. No matter who you look at, they're just cooking with gas like you do,…

It's not even a qualitative statement about Kubernetes.

Kubernetes doesn't solve any technical problem, so the language it's written in is irrelevant.

Re: Go is an ideal language for AI-assisted software engineering

#456
post #402

It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making. What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go. Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squint…

Good point. It's sometimes challenging to get a Rust program to compile... but if you do, it's probably going to work.

And by that point a program written in go has been deployed and making money for months. These are two wildly different languages, people should stop comparing them as if they're targetting the same niche. Checks and protections that rust has aren't necessary in most cases, but increase development and maintenance time.

Re: Go is an ideal language for AI-assisted software engineering

#457
post #396

Earlier quoted context omitted.

Java and C# (JVM and .NET in general) are favorable here.

Uh at the very least Java is bad. the java programs we run take 4 gigs and burn my entire compute. Every1 used spring or guice and the di runtime, so tests are expensive for e2e with mocks. There’s no scrutable way I can run more than 2 or 3 on a standard laptop without burning out the thing. Go can.

You don't have to use Spring or the typical enterprise IOC that plagued 00s and 10s Java.

Re: Go is an ideal language for AI-assisted software engineering

#458
post #402

It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making. What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go. Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squint…

Good point. It's sometimes challenging to get a Rust program to compile... but if you do, it's probably going to work.

Not panicking doesn’t mean working as intended, the biggest issue with LLM generated code is that it will do something that’s subtly wrong not that it will crash. It anything LLMs are too careful with Golang code and litter useless nil checks everywhere e.g. for function calls with pointer receivers. That whole fear of panics is totally overblown.

Re: Go is an ideal language for AI-assisted software engineering

#459

It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making. What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go. Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squint…

Fair criticism, it's my main gripe with Go as well - it's not strict enough when it comes to e.g. nil, enums, and type safety. Annotations are supported but they're just strings. Projects require additional tooling / linters to check for things like unchecked errors and many more "gotchas" that I think could (should?) be part of the compiler or standard tools. Trivial example, Go's compiler will error when you have an unused variable, but won't if you reuse and overwrite an error variable a dozen times and only handle it once.

But on the other hand, I suppose it makes it a bit more pragmatic - less checks makes for a faster compiler, and fast compilation was/is very high up in the language's requirements and motivation. If you want / need more strictness in your language, there's Rust, Java, C#, etc.

Re: Go is an ideal language for AI-assisted software engineering

#460

It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making. What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go. Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squint…

With test, which LLM are good at writing, you can reduce this tremendously. Even Rust won't protect you in this case, remember the cloudflare outage. At the end it is not the language, it is you intrinsic ability to architecture well your software from there any LLM can do the work.
Post reply on HN