Live data from Hacker News

Go is an ideal language for AI-assisted software engineering

developers.googleblog.com

501–510 of 586 posts

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

#501
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.

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

Yes, but different services varied.

I think we experimented between 4096 and 8192 to measure p99 latency performance and that was the optimal as tradeoff.

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

#502

I disagree. I think WAT (WebAssembly Text), perhaps with some more niceties added, is an ideal language for AI-assisted software engineering. https://webassembly.github.io/spec/core/text/index.html

AI agents can only reason about a certain number of things at a time. Time (and tokens) they spend reasoning about how to create a stack calling convention in assembly is time they don't spend reasoning about business logic.

Well, I'm putting that to the test, and so far the results support my thesis

https://github.com/pmarreck/aedicule

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

#503

Earlier quoted context omitted.

what is "Black"? (For hopefully obvious reasons, I couldn't find results with google, lol)

What did you search? If I do the simplest possible thing that isn't a single word, by highlighting "opinionated formatter these days (e.g. Black)" and clicking search, I get the right result. I also get the right result for black formatter, and I get the right result if I yolo the entire comment as my search.

Ah, it's Python. Python is gross. That explains why I couldn't find it. /shrug

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

#504

Earlier quoted context omitted.

But you're probably better off with Ruff these days: https://docs.astral.sh/ruff/ Similar to black but faster, written in Rust, by the same team who created uv.

So... A: not trivial. And B: not part of the language. > mean this isn't true, formatting is the most trivial part. And so many languages have an opinionated formatter these days (e.g. Black) I don't think this is correct

    B: not part of the language.
1) Some would call this a perk.

2) When your tooling around a language works better when it's not actually written in the language... That should tell you something. And yet...

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

#505
post #497

Earlier quoted context omitted.

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

I actually had to use a similar hack there due to the limitation that go test compilates cannot spawn themselves where I needed to have an environment variable with the actual binary prebuilt before the tests run. Took me a while to understand that TestMain doesn't cover that use case...

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

#506
Rust's more powerful type system seems like a better match for LLMs ... better guardrails. But Rust is so painful to read that LLM code becomes inscrutable. If I'm never going to read the source, probably Rust would be better.

If I'm reading the source then Go or Zig.

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

#507

My calculus is very simple these days: If I care about performance, use Rust. If I care about iteration speed, use TypeScript. If I want a script or numerical code, use Python. LLMs are better with Rust because the more expressive type system provides stronger guardrails especially when writing multithreaded code. Go is almost the worst conceivable design of a programming language for LLMs: powerful but weak guardrai…

  > If I want a script or numerical code, use Python.
I had the same convention until about a year ago when I started specifying Go for any kind of scripts on a whim.

Now I get blazing fast, dependency-free static binaries with nearly equivalent OS/shell ergonomics as with bash or data processing with Python.

It’s a huge speed boost and being able to drop a binary on a new VM without messing with uv/pip is a breath of fresh air. LLMs hit zero road blocks doing 1:1 ports of existing Python/bash scripts.

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

#508
post #379

Earlier quoted context omitted.

This seems to have little to do with Go's facilities. Any concurrent program has hazards like these.

Rust's concurrency libraries leverage the type system to make these issues much harder to encounter.

Rust's std::sync::mpsc contains most of the hazards of Go's channel, and arguably adds some because the Go runtime provides deadlock detection that Rust lacks.

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

#509

Earlier quoted context omitted.

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.

Sure, rust has better memory safety than most languages, but it also has a strong enough type system that many other kinds of programming errors won't pass compilation.

So the language knows what you want to program and if it’s functionally correct? I don’t think so.

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

#510

Earlier quoted context omitted.

It is unclear to me though how much of your expectation might be set by the training dataset. For example, Python and Typescript have the most amount of codebases and training being done on. So I feel as if that plays a part into the overall thing. Languages which are more niche have genuinely hard times (Try arturo lang for example), so it depends on a lot of things/nuance, or well that has been my experience trying…

Never tried Elixir myself but came here to say the same thing. Tencent put out this study showing that Elixir seems to reign supreme: https://autocodebench.github.io/

Yup! This was the study that I was mentioning. Thanks for providing the original link for that :-)
Post reply on HN