I'm going to be pedantic here, but this merely means that Go can't fill Zig's niche.

Zig can (in a lot of situations) presumably easily fill Go's role. Both languages have a focus on simplicity and explicit syntax.

In other words, Zig is in fact a decent alternative to Go. Go just isn't a good alternative to Zig.

Zig isn't memory-safe, and you're not going to pay for the development overhead of manual memory management if you're doing regular back-end stuff.

People did for decades and a lot of that "regular back-end stuff" is in C++ at the moment. If you wanted to move it to a different language, you might currently choose to move it bit-by-bit to Go. But you could also move it bit-by-bit to Zig, and it wouldn't be an unreasonable choice. Zig is in that sense an alternative to Go, IMO.

> People did for decades

Yes, but it was before the invention of mobile phone… Since Java came out, the majority of back-end has been written in memory-safe language, for good reasons.

> you might currently choose to move it bit-by-bit to Go

Not even Google, the home of Go, has been doing a C++ to Go conversion. Backend services that are still in C++ in 2023 are probably so for good reasons, most likely because they either have:

1. really high performance requirements, hence no Go.

2. low budget, and are mostly maintained as it is, hence no rewrite.

In any case, those are only a fraction of the total backend code, which is mostly PHP, Java, and Nodejs.

AFAICT you could technically use a GC'd language for either, perhaps just not best suited for it.

On the other hand, Zig can fill the niche Go does, but again, probably not best suited for it.

I guess I'm just being pedantic here :).

If you really want to be pedantic, Zig could maybe be considered a GC’d lang, if you count selecting a GC for as it’s allocator (presumably with some ugly(?) comptime assurances) ;-)

There are production examples of both, written in Go.

Besides, is writing compilers and linkers, systems programming?