5 ms·

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

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 2mo ago
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.
- speed_spread 2mo ago
  > 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 2mo ago
    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 2mo ago
      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 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 https://arxiv.org/abs/2602.14469
    - stouset 2mo ago
      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.
  - dimgl 2mo ago
    It was and is a logical argument. Both C and Rust are much harder to learn.
    - speed_spread 2mo ago
      Considering the article was about usage for development by LLM, the learning difficulty should be a minor factor.
- super_flanker 2mo ago
  > long before LLMs I thought this thread was about an ideal language for LLMs, no?
  - unscaled 2mo ago
    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.
ratscylla 2mo ago
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 2mo ago
  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.
ignoramous 2mo ago
> 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 2mo ago
  Or Rust, Swift, etc.
groestl 2mo ago
Simple toolchain which supports trivial lightweight deployment is my go to attribute to select Go in projects.
henrymerrilees 2mo ago
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 2mo ago
  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.
  - amazingamazing 2mo ago
    Since when did does typescript compile faster than go? I do agree typescript is a good alternative but it is very different.
  - eudamoniac 2mo ago
    Typescript is single threaded and 2-10x slower and does not compile into a binary.
    - anon7000 2mo ago
      Funny enough, the Typescript 7 compiler is no longer single threaded because it’s (ironically) now written in Go, not Typescript.
  - anon7000 2mo ago
    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…)
everforward 2mo ago
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 2mo ago
  Java has GraalVM which compiles to native code if you care about startup time.
- stouset 2mo ago
  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?
aabdi 2mo ago
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.
- super_flanker 2mo ago
  What is "linting efficiency", never heard of this term before?
aabdi 2mo ago
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 2mo ago
  Java and C# (JVM and .NET in general) are favorable here.
  - aabdi 2mo ago
    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.
    - za3faran 2mo ago
      That could be a Spring issue then, not Java. Do you run with -Xmx specified?
      - aabdi 2mo ago
        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.
    - KptMarchewa 2mo ago
      You don't have to use Spring or the typical enterprise IOC that plagued 00s and 10s Java.
      - aabdi 2mo ago
        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
frollogaston 2mo ago
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.

runjake 2mo ago

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.

speed_spread 2mo ago
> 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 2mo ago
  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 2mo ago
    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 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 https://arxiv.org/abs/2602.14469
  - stouset 2mo ago
    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.
- dimgl 2mo ago
  It was and is a logical argument. Both C and Rust are much harder to learn.
  - speed_spread 2mo ago
    Considering the article was about usage for development by LLM, the learning difficulty should be a minor factor.
super_flanker 2mo ago
> long before LLMs I thought this thread was about an ideal language for LLMs, no?
- unscaled 2mo ago
  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.

ratscylla 2mo ago

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 2mo ago
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.

ignoramous 2mo ago

> 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 2mo ago
Or Rust, Swift, etc.

groestl 2mo ago

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

henrymerrilees 2mo ago

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 2mo ago
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.
- amazingamazing 2mo ago
  Since when did does typescript compile faster than go? I do agree typescript is a good alternative but it is very different.
- eudamoniac 2mo ago
  Typescript is single threaded and 2-10x slower and does not compile into a binary.
  - anon7000 2mo ago
    Funny enough, the Typescript 7 compiler is no longer single threaded because it’s (ironically) now written in Go, not Typescript.
- anon7000 2mo ago
  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…)

everforward 2mo ago

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 2mo ago
Java has GraalVM which compiles to native code if you care about startup time.
stouset 2mo ago
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?

aabdi 2mo ago

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.

super_flanker 2mo ago
What is "linting efficiency", never heard of this term before?

aabdi 2mo ago

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 2mo ago
Java and C# (JVM and .NET in general) are favorable here.
- aabdi 2mo ago
  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.
  - za3faran 2mo ago
    That could be a Spring issue then, not Java. Do you run with -Xmx specified?
    - aabdi 2mo ago
      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.
  - KptMarchewa 2mo ago
    You don't have to use Spring or the typical enterprise IOC that plagued 00s and 10s Java.
    - aabdi 2mo ago
      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

frollogaston 2mo ago

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.