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 easiest to learn either, but I've never tried all that hard.

It only really makes sense to me at org-scale, though. I think you raise a very good point for individual projects, I too normally don't choose Go for that (unless I need compilation to make distribution to myself easier on corporate laptops).

Java has GraalVM which compiles to native code if you care about startup time.

Choosing a language because it's easy to learn might be common and popular, but that is just about the least meaningful criteria for a programming language given the length of time you expect to use it.

Can you imagine if structural engineers rushed to post comments about how they decided to use wood for all their projects because it was simple to get up and running with, and they didn't want to have to deal with the all complexities of having to learn about metals like steel?

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.

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

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.

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

The original point was that go is not a Pareto-optimal choice along any set of language criteria.

"I didn't feel like choosing $LANG's competitors, so I went with $LANG" might be how languages are chosen for projects in the real world, but it's not exactly a convincing rebuttal to the argument being made.

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

Considering the article was about usage for development by LLM, the learning difficulty should be a minor factor.

> long before LLMs

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

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.

Something doesn’t need to be the best at anything to be on a Pareto frontier. And (usually) no one chooses on a single dimension; they choose a point in many that maximizes distance from zero, scaled by their preferences, if you are thinking of it like a frontier.

Yes, you're technically correct (the best kind of correct).

I guess if you consider enough attributes or "dimensions" then any programming languages will be the furthest in some direction, including Go.

Is there a language that you would argue is at least as good as Go at everything and better than Go in at least one thing? That would be the most straightforward way to argue against its Pareto optimality.

Listing particular sets of preferences for which Go is not optimal is not sufficient unless you can show the list to be exhaustive.

I'm not GP, but for me that would be TypeScript. TypeScript's tooling is as good as Go's across the board, it's very readable, it's a simple language, it has very few footguns, and it compiles fast. But it has better type safety than Go.

This isn't an exhaustive proof as no language will every be fully Pareto optimal in practice (it's just not possible, there are too many dimensions), but I'd argue it's at least somewhat close.

Since when did does typescript compile faster than go? I do agree typescript is a good alternative but it is very different.

Typescript is single threaded and 2-10x slower and does not compile into a binary.

Funny enough, the Typescript 7 compiler is no longer single threaded because it’s (ironically) now written in Go, not Typescript.

As someone who’s written huge amounts of Typescript, and no Go… the JS/TS ecosystem is absolutely atrocious. I’ve worked on developer productivity teams for almost a decade and JS tooling issues are a never ending battle. Every upgrade to major dependencies almost anywhere in your stack will 1. Include breaking changes and required migrations, and 2. Will also force you to update other dependencies for compatibility, which may have their own breaking changes and so on and so forth.

The tooling will let you do whatever you want, but the lack of standardization is very poor. Even now, many are switching from Eslint to Oxlint. Or Jest to Vitest. Or tsc to faster build tools. There is massive fragmentation.

I frankly yearn for a language that is always backwards compatible (JS itself might be, but ESM/CJS/etc. won’t be because the language relied on 3rd party/runtime-provided methods of importing modules for so long…), and actually has standard basic tooling from the start. Along with halfway decent security posture towards dependencies. And no need to manage a runtime. And produces smaller images.

Like if it’s just about the language, sure TS is extremely usable, async is extremely easy because it’s not a real thread, etc etc. But has plenty of quirks due to being tacked on top of JavaScript. (For example, being forced to import typescript from “.js” extension and not “.ts” with certain normal compiler settings…)

Go was originally designed as a systems language to replace C++. It's much faster than JS but also less suited for applications code in some ways. JS (or TS) is definitely not strictly better than Go or vice versa.

One less obvious advantage: Go has greenthreading which is better than JS's async-await. Rust chose async-await to avoid the runtime overhead of greenthreading, but JS has no such reason, it's just a downside.

Java, but only the very latest one with records and virtual threads.

Simple toolchain which supports trivial lightweight deployment is my go to attribute to select Go in projects.

> if you highly value language popularity; Go is not most popular

Go is similar to popular languages like C, JS/TS, & Python. And so, easy to get started.

> highly value a type system that catches errors

Probably these folks already use even less popular ML-style languages like OCaml & Haskell; or (comparatively) obscure ones like Agda, Idris, & rocq/Coq.

Or Rust, Swift, etc.

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.

What is "linting efficiency", never heard of this term before?

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.

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.

You don't have to use Spring or the typical enterprise IOC that plagued 00s and 10s Java.

I mean yes true but no one would justify migrating the code it’d be so expensive.

Dagger was very nice for the newer services and the ones that used straight rx were like less hell

You might want to check out Quarkus, Mirconaut, or Helidon MP. They do build time DI, and are more focused on performance and reduced resource usage. They are similar enough to Spring, and I believe Quarkus and Micronaut have an optional Spring compatibility layer that one can use. LLMs could help with migration if the codebase is well written.

You might also want to checkout Project Leyden[1]

https://openjdk.org/projects/leyden/

Pareto frontier means they can't improve one aspect without hurting another one, not what you're describing. But I would say Go isn't on a Pareto frontier because the error handling is plain bad and could be fixed without any loss.