When we talk about a language, we tend to mix together the language itself and it's ecosystem/runtime/tooling. For example C# can be compiled to produce single-megabyte executables, you could concievably use it without a GC, but that's very non-standard tooling with poor support. So practically speaking, C# can't do that for most people for most usecases, even if hypothetically the language could.

So currently the issue is you can't write baremetal stuff in Go, for example the linux kernel or Arduinos. You can't get rid of GC if you have realtime requirements.

GO is 'close enough' to C in many areas like writing server-side code and CLI tools - it's GC pauses are short, even though C could produce an executables in a few KB, rather than an MB, that has no practical relevance in those areas.

I think you are agreeing with me. Go fails to solve some problems that C does, but feels fairly comfortable to C programmers. Therefore it works well for C programmers when solving problems that can be solved by Go.

As a low-level programmer, I am not convinced. The Go runtime really confuses the use case.

If I needed a C alternative, rust gives me all (most of) the power of C, plus safety, without all the drawbacks of a heavy runtime.

If I am okay with paying the garbage collection tax, etc, then I would use scala or kotlin. If I'm using a higher level language, then I expect higher level features like exceptions, generics, reflection, etc.

I'm sure go is a great language with it's own usecases, but it's not a C replacement.

I didn't say it was a C replacement, I said it was approachable to C programmers.

Most of the C lovers that I have spoken with find that Rust is far too complicated with templates and lifetimes. Similar arguments can be provided for Scala and Kotlin with their more functional syntax.