Go is an ideal language for AI-assisted software engineering

Post by thayne » Wed, Aug 12, 2026, 6:19 AM UTC

cookiengineer wrote: post #393

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…

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?

Post by fulafel » Wed, Aug 12, 2026, 6:21 AM UTC

xvedejas wrote: post #346

HAL3000 wrote: post #242

Earlier quoted context omitted.

> Go is bad so "I reach for Rust, Zig..." I hope my every competitor will take your advice to heart, as one of our competitors did when they read that "Go is not a memory safe language", so they wrote a blog about how they are porting to Rust. While our team was moving fast and using those "primitives that should almost never be used" around our long running production code base with success. Some time has passed and…

Where would one ever read that Go is not memory safe? That's just a false claim, and anyone believing it would have probably gone out of business regardless of choice of programming language.

Post by literalAardvark » Wed, Aug 12, 2026, 6:25 AM UTC

Thaxll wrote: post #139

rubiquity wrote: post #60

Earlier quoted context omitted.

Matches my experience as well. Go fans have conflated "can easily make something concurrent" with "does concurrency well." Go's primitives for concurrency should almost never be used directly and Engineers below a certain skill level shouldn't be allowed to use them directly ever for long running production code. As another example, Go still has not yielded a correct implementation of Raft or Paxos while there are do…

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…

Post by moomin » Wed, Aug 12, 2026, 6:46 AM UTC

jchook wrote: post #402

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…

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

Post by socketcluster » Wed, Aug 12, 2026, 6:56 AM UTC

Kuyawa wrote: post #179

99% of my projects are in NodeJS as web apps, so Javascript is king, my coding agents are in Node too, plain, boring, beautiful javascript, not typescript. Yesterday I needed a Rust project and my agents delivered so no need to change from JS