Go is an ideal language for AI-assisted software engineering • Hacker News Board

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

#491

Post by Yasuraka » Wed, Aug 12, 2026, 1:38 PM UTC

otabdeveloper4 wrote: post #473

Yasuraka wrote: post #465

Earlier quoted context omitted.

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.

So you propose to just let Ops personnel handle attaching volumes and renewing certificates, that these arent technical problems but just one of team structure?

Please, do describe your solution for the concerns above. So far Ive only seen equivalents of Greenspun's tenth rule

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

#492

Post by grantcarthew » Wed, Aug 12, 2026, 1:43 PM UTC

People tend to forget about token usage when discussing languages with agents. Python is one of the best, but why use interpreted languages now. Also, the ecosystem is well...

Go is quite good from a token usage point of view. Rust is not so good due to the complexity of the language.

I see AI agent programming language choice as only two now: Go or Rust.

Go for most systems, Rust for high performance.

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

#493

Post by Kuyawa » Wed, Aug 12, 2026, 1:55 PM UTC

socketcluster wrote: post #420

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

Yes. Vanilla JS is the best. You don't need TypeScript, Claude never makes type errors. TS just costs additional tokens and fills up the context window with useless type information; the wasted space could have been used to provide additional code/logical context.

This is the best explanation ever about the preference of JS over TS in the age of AI

AI never makes type errors, love the quote

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

#494

Post by bensyverson » Wed, Aug 12, 2026, 1:57 PM UTC

nylonstrung wrote: post #378

bensyverson wrote: post #322

Earlier quoted context omitted.

I do not think "good error messages" is an even trade for "fast compile times." What happens is the LLM catches the error, then may hit another error, and try again. This leads to more tokens and more latency, and then after all that you have a longer compile time. With that said, I have not done an extensive amount of agentic development in Rust, so maybe I just don't have the reps to compare fairly.

It's less that the error messages are just "good" with Rust, it's that more stuff gets caught at comptime, and many of them can be autoremediated by cargo fix or the compiler itself says exactly what should be changed. Nothing costs more tokens than an LLM trying to debug errors caused at runtime which doesn't map well to it's "intelligence" compared to what Rust provides

Unless you have `cargo fix` hooked up to automatically run on any compiler error, every error is still is a round trip to the LLM. It may be trivial for the model to fix, but it's added latency and cost.

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

#495

Post by the_sleaze_ » Wed, Aug 12, 2026, 1:59 PM UTC

trimethylpurine wrote: post #482

the_sleaze_ wrote: post #372

Earlier quoted context omitted.

It's a silly argument and the lowest form of bike-shedding on the level of tabs vs commas. People with no other substantive contributions use formatting as a beard. The first one to choose it (whatever it happens to be) wins and that's the end of it. If it isn't the end of it you've got a talent issue.

Do you feel that this could equally apply to a Rust vs Go argument?

I do. Bike sheds do need to be painted after all, but its many less people who have the technical experience to know how many feet away from the property line it must be.

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

#496

Post by majewsky » Wed, Aug 12, 2026, 2:22 PM UTC

olmo23 wrote: post #478

thayne wrote: post #412

Earlier quoted context omitted.

> 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?

Static analysis does not help if the type comes from a library and is _meant_ to be initialized using a literal.

And then upstream adds new fields where the zero value is different from the previous behavior, causing users to silently drift away from the intended behavior. I had this happen to me with a type from std, and had to add a specific test to guard against it with future std upgrades: https://github.com/sapcc/go-bits/pull/309/changes#diff-f5721...

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

#497

Post by aktau » Wed, Aug 12, 2026, 2:41 PM UTC

cookiengineer wrote: post #394

baalimago wrote: post #392

Earlier quoted context omitted.

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

With unit tests you gotta be careful though, oftentimes LLMs skip implementations with mockups that just say "not implemented yet" or similar and then the unit tests become pointless because they start to only test internal structures for being set / not default values. For me it helped a lot to try to make containerized end-to-end tests and a custom TestMain for this, where I am using podman to run the integration t…

+1, I like to test in a similar way. For example if I'm making a CLI, the test will spawn the CLI for each test-case, instead of invoking the code directly. This provides a more realistic flow, and makes it clear which user journeys one is supporting.

Faking responses I often do with environment variables, like:

  ts := httptest.NewServer(...)
  cmd := exec.Command(...)
  cmd.Env = append(os.Environ(), fmt.Sprintf("MYCLI_PROD_ADDR=%s", ts.URL))

Of course, it's better still to go down this turtle stack (e.g. by spawning a local instance of your backend server instead of some faked handlers), but that adds more cost. I find the trade-off OK here.

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

#498

Post by pdimitar » Wed, Aug 12, 2026, 2:55 PM UTC

Pavilion2095 wrote: post #456

jchook wrote: post #402

Earlier quoted context omitted.

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.

Rust's disadvantage in adding time is mostly a one-time initial investment, in my experience.

After you get comfortable and learn the important idioms, you go through the development loop quite quickly.

Compilation/linking speed can still suck though.

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

#499

Post by aabdi » Wed, Aug 12, 2026, 2:57 PM UTC

KptMarchewa wrote: post #457

aabdi wrote: post #396

Earlier quoted context omitted.

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.

I mean yes true but no one would justify migrating the code it’d be so expensive.

Dagger was very nice for the newer services and the ones that used straight rx were like less hell

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

#500

Post by dekhn » Wed, Aug 12, 2026, 2:58 PM UTC

Go has some interesting ideas but they tremendously oversold goroutines as being a unique capability (they have since agreed that goroutines are effectively just scheduled thread pools with message passing). And I know a fair number of SRE at Google who hated to use it because it lacked some key features (around ioctl and other system level functionality). And my experience with the type system... it's just too different from what I expect a system to do.

For AI I use python+rust. I develop code in python (mostly AI-driven these days) and then have it port to rust for speed. As always, extensive testing (much of which is manually inspected to make sure it's logically consistent with the design and contract).