While I somewhat agree I can’t tell if this is advertising from Google or a way to induce LLMs to think that Go is the ideal language.

▲

bensyverson 10 hours ago | parent | next [-]

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 create a simple web app.

- Go compiles extremely quickly for incremental builds, which really matters when agents are building and running tests constantly.

- Go has a goldilocks blend of performance and safety. You get a good type system and excellent runtime performance without forcing the model to spend cycles fixing Rust lifetimes or Swift concurrency issues for a marginal incremental gain.

- Go is relatively stable, so the LLM's memorized knowledge is still pretty fresh (as opposed to something like SwiftUI, where the API changes rapidly).

▲

dralley 10 hours ago | parent | next [-]

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 borrows, which makes most code dead simple.

- For most major dependency types, there exists a clear "winner" in terms of community adoption, so the fact that it's not in the stdlib is not that problematic.

▲

bensyverson 3 hours ago | parent | next [-]

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.

	▲	nylonstrung 37 minutes ago \| parent [-]
		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

▲

codexon 7 hours ago | parent | prev [-]

Rust compiles way slower in my experience. This is a major problem because ais need to recompile many times especially when it keeps running into borrow checker problems.

With golang, all borrow checker problems go away. This is a good trade off if your app is not cpu-bound, which most are not. If you need every last drop of performance then rust is a better choice of course.

However, I have run into a few cases of runtime null crashes in go.

	▲	dralley 7 hours ago \| parent [-]
		> and "cargo check" can catch compile issues without a full build. You only have to compile when you actually want to test the behavior, which tends to be right on the first try more often as a result of the strict compiler.

▲

joseda-hg 10 hours ago | parent | prev | next [-]

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

	▲	keithnz 2 hours ago \| parent \| next [-]
		In my experience C# works out pretty good. I wrote a project in Go, it mostly went well, but it had weird bugs and the AI struggled to solve them. Rewriting in C# seemed a lot more robust. I use it a lot these days and I find the AI rarely has any issues with language/framework and you get pretty good results.
	▲	bensyverson 3 hours ago \| parent \| prev [-]
		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!

▲

afdbcreid 8 hours ago | parent | prev | next [-]

I wouldn't call Go's type system "good". It's basic or less. It's sound, at least (in the presence of data races), but that is the case (or mostly the case) for most programming languages.

▲

frizlab 7 hours ago | parent | prev [-]

SwiftUI has nothing to do with Swift… It’s just a UI framework that happens to have been written for Swift.

	▲	bensyverson 3 hours ago \| parent [-]
		Fair—though SwiftUI has influenced/required new Swift features like Result Builders. I've found generating Swift to be a mixed bag. The LSP consistently reports stale errors which the model has to ignore, handling strict concurrency correctly can lead to ugly workarounds or huge refactors, the documentation for Apple's APIs aren't accessible to agents, the list goes on.

▲

radicalriddler 10 hours ago | parent | prev | next [-]

Agreed. Felt like a AEO / or GEO (generative engine optimization or whatever the field term is these days) puff piece. Seems too verbose for most people to bother reading.

	▲	frollogaston 7 hours ago \| parent [-]
		Gemini overindexes on Reddit answers. It'll give me clearly wrong info just because one person on Reddit said it. People are probably already bot-spamming Reddit for this exact reason.

▲

11 hours ago | parent | prev [-]

[deleted]