[dead]
Go is an ideal language for AI-assisted software engineering
321–330 of 586 posts
Re: Go is an ideal language for AI-assisted software engineering
#322Earlier quoted context omitted.
Probably both, but I have to add: I agree with the post. I've done a ton of agentic development using Go over the past 6 months, and it hasn't let me down. You may ask "why not Rust, or Zig, or ____?" The reasons boil down to this: - There's a lot of Go code out there which the models have seen, so they know how to write it. - Go has an exceptional standard library, so you don't need to drag in 100 dependencies to cr…
I don't think Rust is particularly worse than Go in any of these respects. - LLMs have clearly been trained on a lot of Rust as well - Compile times are counterbalanced by strong compiler with excellent error messages, and "cargo check" can catch many issues without a full build. - If you're willing to accept Go levels of performance from Rust, there's nothing preventing you from using copies and clones rather than b…
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.
Re: Go is an ideal language for AI-assisted software engineering
#323I'd argue Go is not on a "Pareto frontier" and that no matter how you value the various attributes of programming languages, a fair assessment will never select Go. A simple example is: if you highly value language popularity; Go is not most popular. If you highly value a type system that catches errors; Go's type system catches fewer errors than others. Etc. There is no weighted sum of attributes that will select Go…
Go is relatively easy to learn, and the semantics of the language make it more difficult to write "clever" code that's difficult to understand. That's the main selling point, with a secondary point that it statically compiles so you don't have to do a whole Python/JS distribution thing for CLIs. Java feels like the closest contender here, although it really sucks for CLIs due to start up times. I don't think it's the…
Java has GraalVM which compiles to native code if you care about startup time.
Re: Go is an ideal language for AI-assisted software engineering
#324I'd argue Go is not on a "Pareto frontier" and that no matter how you value the various attributes of programming languages, a fair assessment will never select Go. A simple example is: if you highly value language popularity; Go is not most popular. If you highly value a type system that catches errors; Go's type system catches fewer errors than others. Etc. There is no weighted sum of attributes that will select Go…
Uh compile time and linting efficiency, lightweight runtime, gc. There’s no equivalent competitor, it’s the best if u want to just write lots of undifferentiated code. To caveat this if u want to run about 50 agents or so in parallel, all the typescript projects burn ur disk via node modules. The rust ones take forever to compile and burn too much compute
Java and C# (JVM and .NET in general) are favorable here.
Re: Go is an ideal language for AI-assisted software engineering
#325This would have been more credible coming from someone other than the creator of the Go language. I'm personally leaning into rust for LLM. The whole fussy compiler & errors surface at compile time seems IDEAL for LLMs for me. Hammering compile with tokens is a way better strategy than trying to deduce where stuff may fail at run time and try to catch it via tests. Tokens are cheap, surprises at runtime are not. So a…
fwiw I have a bunch of LLMs writing first Lean code and now Agda code. My observation. LLMs find reasoning about Agda as difficult as I find reasoning about C code. I've thrown a lot of gnarly C and Ruby code at all sorts of LLMs and they have only gotten more and more impressive as frontier models have gotten stronger. With Agda, they're like "hmm, tricky" whereas for me it's an impenetrable fortress. I've asked the…
A huge amount of it is also the amount of training data. Agda will have little training data so the result will not be nearly as good.
I did a shoot out of making AI make the same simple desktop app from a SwiftUI reference for 30 different language & desktop framework combinations, and by far the best implementation came from the electron web typescript one. The least amount of LoC, the best and most complete implementation and the fastest to implement.
Re: Go is an ideal language for AI-assisted software engineering
#326Earlier quoted context omitted.
Probably both, but I have to add: I agree with the post. I've done a ton of agentic development using Go over the past 6 months, and it hasn't let me down. You may ask "why not Rust, or Zig, or ____?" The reasons boil down to this: - There's a lot of Go code out there which the models have seen, so they know how to write it. - Go has an exceptional standard library, so you don't need to drag in 100 dependencies to cr…
How would you compare it to C#? Stable-ish There's a lot of documentation and plenty of stablished patterns, so LLM can produce it no sweat Everything and the Kitchen Sink Performant, and safeish, even if not null safe
Yeah, C# is probably the closest direct comparison. I like that Go emits a simple binary, whereas it seems like that needs to be configured with a .NET project. Probably just a matter of taste/preference!
Re: Go is an ideal language for AI-assisted software engineering
#327> By enforcing a single, standardized format via the built-in gofmt tool
I'd read about this many times before I started with Go so I was particularly disappointed to learn that it was a lie.
Re: Go is an ideal language for AI-assisted software engineering
#328Earlier quoted context omitted.
The intersection of the set of Raft libraries Antithesis tested and all Raft libraries in existence do not fully overlap. I personally have worked on multiple proprietary ones that Antithesis would not have access to.
I work at Antithesis, we're happy to test out any Raft implementation that has so far escaped our notice :)
I love what you all do! I don’t have any to submit. Enough time with consensus teaches you to avoid it unless it’s really, truly needed.
Re: Go is an ideal language for AI-assisted software engineering
#329> By enforcing a single, standardized format via the built-in gofmt tool
I'd read about this many times before I started with Go so I was particularly disappointed to learn that it was a lie. The most important task of a code formatter is to break long lines; it doesn't do it. It doesn't even have an option to do it!
Re: Go is an ideal language for AI-assisted software engineering
#330Earlier quoted context omitted.
To combine both TFA with this comment: I find that LLMs are ~fine at generating/editing gocode, or at least as ~fine as they generate most mainstream languages. But good god, the second it gets to anything concurrency-related, it just loses its mind. As much as it's gotten vaguely ok to try to let the agents loose on some bits of the codebase, they simply can't even do table stakes stuff with the kinds of concurrency…
I wouldn't be surprised if Java has a much better experience here. After all, java.util.concurrent has many great implementations, and Java's `record`s are immutable, as are it's upcoming value types.
I was thinking same but C#.