Sure, but in those cases Java/Swift/C#/etc are also reasonable replacements. If you're not taking advantage of data locality then it's possible to approach C's performance in any of those languages.

If your primary concern is performance(which is the only reason I'd reach for C today, esp w/ security concerns) then Go is not going to replace C in that domain.

> Sure, but in those cases Java/Swift/C#/etc are also reasonable replacements.

Well, Swift certainly wasn't when Go was introduced, but, yes, Java and C# were competitors in that role when Go was introduced (Java, even moreso at the time, tended to fall short on expressiveness -- which some argue Go does too, though in different ways -- and C# was deeply tied to .NET, which only had a first-class implementation on Windows; both of those have improved somewhat since Go was introduced.)

Swift probably, but Java and C# still suffer in a lot of situations from the lack of good AOT compilation options. There are implementations for both, but they're incredibly primitive compared to the JIT reference implementations.

Not .NET Native, which uses the same backend as Visual C++.

Unfortunately .NET Native is still for UWP only, so for most places you'd use Go it's pretty useless. Microsoft appears to have no plans to even bring it to ASP.NET: https://github.com/aspnet/Home/issues/285

Probably not, but they have CoreRT instead.

https://github.com/dotnet/corert

Many of us are actually mostly working on Windows, so NGEN, RyuJIT and .NET Native are all very good nice toolchain features.

And if I compare Go with the whole .NET stack and tooling, there are lots of things I see missing, in spite of better AOT support across the board.

... which is still in a fairly early state, like I said. And NGEN doesn't help the issue of runtime dependence at all.

I'm not really a fan of Go, but being able to write small tools in it without pulling in a huge runtime is a big drawback.

But that isn't a language feature, rather a toolchain one.

Once upon a time, on the PC we only had static compilation, regardless of the language.

.NET Core would help with the runtime dependencies (XCopy Deploy), but currently it is also WIP for those of us that care about desktop applications.

Is the .NET stack and tooling any more a language feature? You were happy to argue that tooling was important a moment ago.

In any case, when choosing a language for a project which doesn't fit your requirements because maybe the tooling will get there someday, I think you're going to pretty consistently end up in a sticky situation. I like C# a lot more than Go for most things, and some of the reasons are things you listed, but the goalpost shifting is getting ridiculous.

I am just digressing, sorry if you see it as goalpost shifting.

>it is a replacement for C in the zone where C's performance and static typing are attractive

Was C's "static" typing ever attractive as a static type system?