I'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--that's my argument.

▲

runjake 10 hours ago | parent | next [-]

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.

▲

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

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.

	▲	Buttons840 10 hours ago \| parent [-]
		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.

▲

henrymerrilees 9 hours ago | parent | prev | next [-]

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.

▲

odo1242 9 hours ago | parent [-]

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.

	▲	eudamoniac an hour ago \| parent \| next [-]
		Typescript is single threaded and 2-10x slower and does not compile into a binary.
	▲	amazingamazing 4 hours ago \| parent \| prev [-]
		Since when did does typescript compile faster than go? I do agree typescript is a good alternative but it is very different.

▲

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

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

	▲	za3faran 3 hours ago \| parent [-]
		Java has GraalVM which compiles to native code if you care about startup time.

▲

aabdi 5 hours ago | parent | prev | next [-]

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

	▲	za3faran 3 hours ago \| parent [-]
		Java and C# (JVM and .NET in general) are favorable here.

▲

groestl 9 hours ago | parent | prev | next [-]

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

▲

aabdi 5 hours ago | parent | prev | next [-]

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.

▲

ignoramous 10 hours ago | parent | prev [-]

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

	▲	odo1242 9 hours ago \| parent [-]
		Or Rust, Swift, etc.