Instead, people shoehorn it into data processing and databases, the domain at which .NET is incomparably more adept due to performance primitives it offers, if we still talk high-level-ish languages with automatic memory management. Of course if there is no such requirement, there are many (like Zig, Rust and C++) systems programming languages that are better in every possible way at solving the task. And yet, we get Go and startups struggling to scale. But all the interesting problems in which Go is attempted to be applied to, where the solution, if successful, is despite Go not because of it, would have benefited from C#/F# which offer much better control and performance assurances, without having to fight the tool.
I have meticulously benchmarked Go in previous roles and also used Go as a load generator and with smart allocation strategies the language is quite fast. I think you're letting your emotions cloud your judgement but that's nothing new in PL discourse. There's no better way to bring out those that identify with/against programming languages than PL discourse.
See, I would not call Zig unexpressive. I've written a number of iteration structs in Zig, because it has true optionals this is easy, using them is just:
var iter = thing.iterateSomeWay();
while (iter.next()) |item| {
// do stuff
}
It's a low level language, yes, but an expressive one given that design constraint. Go just makes this stuff harder, because nil is just zero wearing a costume, an antipattern it inherited from C. In Zig every type can be nullable, and the compiler takes care of representing the null case distinctly from the load-bearing one.
Take these things a little less personally. Live and let live. People think differently from you, and that's okay.