Here's how my assessment selected Go (long before LLMs):

- I had to write a moderately complex program. I didn't want to do it in C, and I didn't want to learn Rust.

- So I spent roughly about 2 hours becoming familiar with Go and playing around in Go playground. I decided that this would work.

- And then I got started on my program and I was immediately productive and that software is still running today, along with all the other stuff I've written since then.

Programmer productivity is excellent with Go. And it has a thriving ecosystem. Of course, some things could be better, but I don't really have much issue with it's error handling or types.

▲

super_flanker 7 hours ago | parent | next [-]

> long before LLMs

I thought this thread was about an ideal language for LLMs, no?

	▲	unscaled an hour ago \| parent [-]
		That's my take. The arguments for Go over Rust used to be: - Better concurrency story - Native cross-compilation of static binaries (great for CLIs) - Easier to learn, easier to teach - Opinionated: You don't have to enforce a single style everywhere Concurrency died out as an argument when Rust async/await got better. Sure, it has "function colors" and that matters for weird purists who care very much about typing a single "await" in their code, but don't care at all about typing "foo, err := bla(); if err != nil { return err }" all over the place. But it doesn't matter in practice, and tokio has far better concurrency tools: there ares separate channel for mpsc, oneshot, broadcast and watch scenarios, there Streams, JoinSets and a select! macro that can operate more than just channels. The static compilation argument also died pretty early on when the Rust musl target became more mature. It's still slightly easier to get cross-compilation started with Go, but now that you we have LLMs we wouldn't care. The learning curve argument is dead. It used to be harder to hire or train Rust programmers and that was a real pain. But LLMs don't care. The same goes for the "Go is built for software engineering" argument, which is a euphemism "Go is our way or the highway level of opinionated". LLMs do not need an opinionated language as much as humans do. If you want all code to follow an arbitrary standard, just ask your LLM to set up one. Engineering teams used to spend years bikeshedding things like brace styles and spaces vs. tabs and Go went ahead stole that opportunity from them. But this is no longer needed.

▲

speed_spread 9 hours ago | parent | prev [-]

> I didn't want to do it in C, and I didn't want to learn Rust.

Sounds like you made a decision right there. The rest is just retro-justification, not a logical argument or comparative between options. It works for you, good.

▲

geodel 8 hours ago | parent | next [-]

Retro-justification is not some flaw it is most common way people choose tech stacks.

The only logic that matters most of time is business logic of solution serving problem statement and not logic of choosing a technical stack.

	▲	genxy 4 hours ago \| parent [-]
		Post hoc rationalization The choice we made for other reasons is the best one for these constructed reasons that didn't exist until later. https://en.wikipedia.org/wiki/Choice-supportive_bias Measuring and Mitigating Post-hoc Rationalization in Reverse Chain-of-Thought Generation https://arxiv.org/abs/2602.14469

▲

dimgl 3 hours ago | parent | prev [-]

It was and is a logical argument. Both C and Rust are much harder to learn.