I wouldn't say that Go is an alternative approach. I mean, what's the difference between Go and Java AOT with Graal? But Rust is truly an alternative to C/C++.

In many ways Go is the safer more productive language for C lovers. There are only a couple major differences between the two languages so I think that it is one of the easier places to convince C lovers to move to. I have met a number of strong C proponents and they all seem to be relatively OK with Go, especially compared to C++, Rust and Python.

The major differences in my head are:

- Garbage Collection

- Interfaces

There are some other more minor things like defer and the built-in generic types but many C programmers already had macros to implement similar things.

So sure, Go doesn't solve all of the problem spaces that C does. But if you are in a problem space where you don't need see (or another low-level systems language) Go may be a middle ground to move C programmers to.

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.

> what's the difference between Go and Java AOT with Graal?

The thing that C/Go authors brought in straight from the seventies: utter garbage naming of identifiers.

But then again, the name of the language itself should be warning enough.

This is git, not github.