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

Go is an ideal language for AI-assisted software engineering

developers.googleblog.com

Post reply on HN
Print view View original

471–480 of 586 posts

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

#471

Post by dnautics »

baalimago wrote: post #392
beaker52 wrote: post #386

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…

I've found that keeping very healthy test coverage solves issues like this. LLMs are very good at validating their own implementations with TDD.

i think they validate less with TDD; if you tell them a bare bones spec to validate they tend to write just that. if you write the test after, then their testing is causally conditioned on what was written. if you are going to write tests, it seems like teat first is way better than test last.

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

#472

Post by dnautics »

gyesxnuibh wrote: post #301
Thaxll wrote: post #218

Earlier quoted context omitted.

I'd like to know what you base your statement on that the Raft implementations in etcd or CockroachDB are incorrect. Your original paper does not mention those implementations, so where does that claim come from?

Having run a fleet of 100s of etcd clusters for 10000s of rps, and the fact that upstream runs tests similar to antithesis and recently partnered with antithesis [0], and jepsen has tested it long ago as well [1]. Etcd's raft algorithm is fine. Someone even did a TLA+ proof on it in the last couple years[2]. Yes there was a correctness issue a few years ago but otherwise the person you're replying to doesn't know wha…

doesnt raft have a problem that it assumes no hysteresis? and that in general you can construct a latency graph that deterministically causes a permanent lock in the leadership election phase?

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

#473

Post by otabdeveloper4 »

Yasuraka wrote: post #465
otabdeveloper4 wrote: post #455

Earlier quoted context omitted.

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

I have a bunch of volumes that I'd like to get automatically attached and mounted to nodes on which their respective workload runs (which are automatically scheduled) who automatically fetch and mount their config files and secrets from a HA DB on demand. I also need some internal loadbalancing and integrations with something like certbot for all of my web workloads. Id also like to make sure that I get metrics and l…

If k8s works for you, then go for it.

But k8s was invented so that "dev" and "ops" teams could play nicely when they are different org structures, with their own budgets, deadlines, etc.

If it solves some technical issue then that's incidental.

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

#474

Post by wannabe44 »

jeanbza wrote: post #27

Definitely agree with this article. At Netflix, I lead the Go language guild. We've been seen increasing reports of users finding their AI agents writing better Go code than other languages, and increasing reports of projects favouring Go over other languages. Two additional notes I'll add: - Go has _great_ resources on writing good Go code, including treasure troves at https://go.dev/doc/effective_go and https://goo…

I want to ignore Naysayers in the thread but even SOTA LLMs write boilerplate like it is Go 1.14. I have to constantly nudge it to use newer language features properly, even if it's also in my rules/ CLAUDE md files.

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

#475

Post by wannabe44 »

throwaway2037 wrote: post #369
osigurdson wrote: post #336

Earlier quoted context omitted.

If you know any other language, you basically already know Go (with the exception of the channels stuff). The biggest pain is the if err != nil stuff, which I know some people like but it is suboptimal in my view. While far better than C# and Java's exceptions, far worse than Zig's model.

> far better than C# and Java's exceptions What is wrong with them? When writing enterprise CRUD apps, they are very useful.

People don't understand exceptional control flow. They think they have to catch them at every point, instead of using them as intended (having a central boundary of error handling where you have enough context whether to retry or abort the operation). So they think Go errors are better.

With exceptions you can

1. Set exception breakpoints.

2. Have real stack traces.

3. No need to write 3 lines of boiler plate every 1 line of code which interacts with outside world.

Ironically this is the case in Go's niche - devopshit, cloud webshit - where the boilerplate error handling makes even less sense since because

1. You are making a network call or OS interactions every 2 lines which can err

2. The consequences of an unhandled exception are actually quite less severe. At worst your request will 500 or the application will restart - which is a consideration you can't escape in these environments.

3. I have seen indiscriminate error handling written by substandard developers which simply concatenates the full wrapped error string to API, leaking full details. At least with exceptions, you can designate different types of exception for 404s vs ayth errors vs bad requests vs Internal errors, and have a central handler which filters out. In go theoretically you can do this, but I have never seen someone utilize errors.As over stringy error handling.

I like Go - it has nice stdlib, nice compiler and runtime, and actually dared to innovate away from the fat-ass LLVM monoculture and made green threads popular. But error handling and uninitialised values sticks out like a sore thumb. It's impossible to read code which does many API/network/OS interactions.

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

#476

Post by pjmlp »

foldr wrote: post #466
pjmlp wrote: post #463

Earlier quoted context omitted.

How have you found a SCO note, which never did nothing relevant for Java? Here from Oracle, as historically taken from Sun documentation for JDK 1.1. => Many-to-Many Model (Java on Solaris--Native Threads) https://docs.oracle.com/cd/E19455-01/806-3461/6jck06gqk/inde...

I think there's a naming confusion here. You said "M:N threads, aka green threads". However, your linked document clarifies that "green threads" are the M:1 threads that "[do] not exploit multiprocessors" (see the "Green Threads" parenthetical in the first subheading). It is interesting that JDK 1.1 also had an M:N threading model, but that's not what people usually mean by green threads.

I always understood it like that, however maybe it is on me, when reading this with more detail.

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

#477

Post by byward »

larodi wrote: post #464
Cthulhu_ wrote: post #459

Earlier quoted context omitted.

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

How about Swift and Erlang? Why are these always left out of comparisons?

Haven’t you heard? Swift is the first-ever corporate programming language, and we on HN can’t take its community efforts seriously to the extent of considering its potential value in general-purpose software.

/s

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

#478

Post by olmo23 »

thayne wrote: post #412
cookiengineer wrote: post #393

Earlier quoted context omitted.

So your problem is the default/zero values of properties? In Go the convention is kind of to have a constructor pattern with a NewStruct(...) *Struct method that initializes all properties. Also can't you build your own validator for that with the reflect package in the Add() method of your UI graph to prevent this sorta thing?

> the convention is kind of to have a constructor pattern with a NewStruct(...) *Struct method that initializes all properties But that doesn't stop you from declaring a var s Struct, and never initializing it, or making a NewStruct {}. > can't you build your own validator for that with the reflect package in the Add() method of your UI graph Besides the fact that that would almost certainly significantly hurt perfor…

> But that doesn't stop you from declaring a var s Struct, and never initializing it, or making a NewStruct {}.

Static analysis tools can catch this, no?

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

#479

Post by Manfrednotfunny »

literalAardvark wrote: post #416
Thaxll wrote: post #139

Earlier quoted context omitted.

The "world" runs on Kubernetes which is using Raft: https://pkg.go.dev/go.etcd.io/etcd/raft/v3 Are you saying that this implementation is wrong? "This Raft library is stable and feature complete. As of 2016, it is the most widely used Raft library in production, serving tens of thousands clusters each day. It powers distributed systems such as etcd, Kubernetes, Docker Swarm, Cloud Foundry Diego, CockroachDB, TiDB, Pr…

etcd is notoriously unreliable and one of the biggest problems in k8s. I didn't know Go just isn't a good language for it, but now that I know I'm no longer surprised at etcd being problematic.

I'm running big k8s cluster and my small ones at home for 8 years, never had an etcd issue.

Could you elaborate?

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

#480

Post by tsss »

preisschild wrote: post #445
iscoelho wrote: post #358

Earlier quoted context omitted.

Not speaking to their code, but to start GoBGP has the worst performance of any BGP daemon by a large margin [1]. [1] https://elegantnetwork.github.io/posts/comparing-open-source...

Garbage collected languages like Go will always have worse performance than lower level languages like C (frr and bird are implemented in C). Gobgp is great if you want to embed it directly into a Go app though. Talos Linux has done that recently.

No they won't. They are generally faster in throughput than any non-gc application that isn't heavily hand optimized. Their problems are higher memory usage and unpredictable latency, not speed.
Post reply on HN