Rust is the new C. Go had a shot but went in an applications direction. I predict that very soon, perhaps even inside of three decades, Rust will become the dominant, first-choice systems programming language.
It's important to note that Microsoft's choice of Go for tsgo was because it would be easier to port the existing TypeScript codebase due to the structural similarity of TypeScript and Go. If writing from scratch, they likely would not have chosen Go.
Which is not to say that Go can't do well in tooling. Only that Go was not necessarily their first choice.
That is kinda my point though. None of those are kernels, device drivers, hypervisors, virtual machines, interrupt handlers, bootloaders, dynamic linkers; and writing such things in Go would be an uphill battle against the language's own design, much like the Go runtime itself. Being a GC'd language almost completely fences Go off from even being in the running for these, except for hobby projects trying to prove a point.
Universal applicability may not be necessary to write a Ruby installer, but it certainly is to have any hope of taking C's crown.
MS uses Go for tsc because they are basically doing a line by line rewrite of tsc from typescript to Go.
It's impossible to do this kind of rewrite from a GC language to a non GC one, especially Rust where the object soup of typescript will probably cause the borrow checker to explode.
I think that if MS or someone else decided to write a typescript type checker from scratch there is a high chance Rust will be chosen.
I think Go is going away. It occupies such a weird niche. People have said it's good for app backends, but you should really have exceptions (JS, Py, Java) for that sort of thing. For systems, just use Rust or worst case C++. For CLIs, it doesn't really matter. For things where portability matters like WASM, can't use Go. Bad syntax and type system on top of it.
What if Google spent all that time and money on something from the outside instead of inventing their own language? Like, Microsoft owns npm now.
I always thought of Go as a middle ground between C and Python. From C it gets simple syntax, from Python - "batteries included" part.
Deserializing JSON and XML is a breeze from my experience. And it's available out of the box. But I guess C++ will get there with reflection having been approved in C++26.
So I don't think it will go away (in the coming years at least), since a lot of tools is written in it.
It's not that bad to handle some JSON in C++ or Rust. It can get annoying if you're doing it everywhere, but that's usually that's the kind of use case where JS or Python works anyway. Yes I get that some people prefer Go, but it's not necessary enough to guarantee that it'll stick around.
Actually, I'd say this is where Go has a real advantage. Are any other mainstream languages both garbage-collected (for ease of development) and native-compiled (for ease of distribution)?
Yeah. Only ObjC and Swift, which nobody wants. But JS distribution is arguably easier than building for every platform. Google did that with Gemini CLI.
Also if you're ok being dirty, short-lived processes can just leak. Some of those Go CLIs are probably not even GCing before the program exits.
Maybe - but in this case, Ruby is written in C, it uses C extensions when performance matters, but tooling for the Ruby language itself is all in Ruby. Rust isn't replacing the use of C in the core of Ruby (yet) - it's stepping in to the area where Ruby would have been traditionally used.
Similar thing is in motion with the JS toolchains. Rewriting in Rust is easier than rewriting in C, but why didn't they previously rewrite in something like C++ or Go? I'm guessing because people were simply not interested.
Microsoft chose Go for tsc rewrite. https://devblogs.microsoft.com/typescript/typescript-native-...
And then there's esbuild, also in Go, which revolutionized web bundling speed https://esbuild.github.io