I have a question: why do you think Go is better compared to other languages?

After all, learning a new language takes a lot of time. While basic syntax is common and quick to pick up, mastering a language's specific mental model requires a significant time investment, which is why I've used Go before but never seriously.

My interest was piqued recently when I heard about TypeScript tooling being ported to Go, and I know it is incredibly fast. However, where do the results claiming that AI agents generate superior Go code actually come from? Is it a fair, apples-to-apples comparison?

Since Go is a very small language with only 25 keywords, the way you write code is extremely standardized. Because of this, I would assume it naturally produces a lot of excellent best practices and conventions, but I'm not sure if there are actual, direct code examples proving this

▲

jeanbza 10 hours ago | parent | next [-]

> why do you think Go is better compared to other languages?

I didn't say that. :)

> where do the results claiming that AI agents generate superior Go code actually come from?

Like I said - reports from users.

> Is it a fair, apples-to-apples comparison?

No - these are reports from users, not a systematic analysis.

▲

PrimalPower 10 hours ago | parent | next [-]

>> why do you think Go is better compared to other languages?

> I didn't say that. :)

I call this the Go paradox.

I simultaneously believe we should reach for it 80% of the time to solve common collaborative problems. And being a poorer language is actually an asset in these cases.

However, in doing so, we get rusty lose our fluency in more expressive, perhaps even better languages.

▲

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

> Like I said - reports from users.

How does that work? Are they generating the same project in different languages and comparing the results? What does it mean for the code to be "better"?

▲

jdw64 10 hours ago | parent | prev [-]

Ah, I see. I misunderstood.Is the report from an internal source, so it can't be shared? If not, I'd appreciate it if you could send me a link so I can look into it too.

▲

jatins 10 hours ago | parent [-]

it’s probably just some informal Slack messages between colleagues that is being described as “reports from users”. There is no Report here

▲

jeanbza 9 hours ago | parent | next [-]

Yes, this. =) I talk to Go users around the company all the time. Their feedback has been in this direction for a bit now.

▲

switchbak 7 hours ago | parent [-]

But isn't this expected from users that like a certain language? Won't you also hear this response from Rust users that like Rust?

	▲	frollogaston 4 hours ago \| parent [-]
		Exactly. I only count opinions from people who have deeply used the two langs they're comparing and can express what exactly was wrong with one of them for their task.

▲

zero_shift 9 hours ago | parent | prev [-]

You are being downvoted but I think this is correct. I doubt Netflix is really doing a double blind RCT on which languages produce better AI pull requests. How would that even work, have two versions of each service in different languages?

It's anecdata and maybe, MAYBE, a spreadsheet. Or a Google Form somewhere.

▲

mbreese 7 hours ago | parent | prev [-]

Go is really amenable to being used to write code by LLMs. New code takes time to pick up, but the LLM is a quick study.

In my opinion, it has little to do with the speed of the language. The large quantity of source code to train on is quite helpful, but I think it's something else.

There are three things that I think make it well suited to LLM authorship -

1) static typing and a quick compiler - a variable can't change type after it's declared (unlike Python) makes Go more robust compared to dynamic languages. You (almost) always know what the type of a variable is. And the quick compiling with hard-stop errors means that the LLM gets a solid signal for each round.

2) It's quite opinionated, syntactically. There is generally one way that Go lang code is supposed to look. That means it's pretty easy to read as well as write. The lack of things like operator/method overloading make it an easy language to reason about.

3) the stdlib and limited dependencies. Dependency trees tend to be shallow, and because of the static linking (by default), you can generally be confident that what you wrote will run.