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.

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.

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

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.

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

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

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

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.