How is Go not high level? What makes it "systems" language? That's just marketing.

It is a language with a fat runtime, running a garbage collector. You just burn it into the binary and call it a day.

(just like modern Java can burn its runtime / GC into the binary)

No, not just like. You're downplaying significant differences between the two that do in fact matter. So much so in fact, that you're just wrong. Stop spreading misinformation.

GraalVM indeed does a lot more than Go, it's a full optimizing compiler while Go does very little optimiations.

But burning a JVM next to a jar file is not hard at all, one could make something like cosmopolitan.

Go use cases overlap the most with Java. I think the reputation you mentioned comes from Google using a lot of C++ for high-level things others would likely do in Java, so they see Go as a replacement for C++ in some areas. (assuming you meant C++ not C)

> I think the reputation you mentioned. . .

Actually no. Go was designed from the beginning as a systems language as a C replacement.

In what way does that "design" show up in Go, besides marketing?

It's replete with oddities and limitations that signal "ah, this is because systems language."

Go’s type system, for example, is very much a systems-language artifact. The designers chose structural typing because it was lighter weight, but provided enough type safety to get by. It sucks though for enterprise app development where your team (and your tooling) are desperate for nominal typing clarity and determinism.

The error handling is like a systems language for sure, I'll agree on that.

But where do Go's docs or founders call it a C replacement? gf000 asked where this is mentioned besides marketing, but I don't see it in the marketing either.

Now that Go is styled as a Java competitor its framing is different. But here's an old golang.org archive for fun:

https://web.archive.org/web/20091113154831/http://golang.org...

The main page title *Go: a systems programming language*

It still sports all the low-level stuff too, pointer arithmetic and all.

Thanks. I'm not surprised they called it a C++ competitor back then. All those systems-style features do make it awkward now that it's targeting the Java-like use cases. No pointer arithmetic, but pointers yeah, and it's not very clear what you're supposed to pass by value vs by ref. You can do things like a DBMS in Go that count as systems programming, but for sure it's not a competitor with C.

Go happened to be attractive for web backends too because it had good greenthreading before Java etc did, and better performance than JS, so it makes sense that they changed the marketing.

And a fat runtime with a garbage collector. Like people can write all sorts of programs with a GC, that was never the issue.

But then just stay truthful, otherwise C# is also a system PL.

"Fat" runtime? Go? Nah.

Go's runtime is thin: goroutines, a GC specialized for concurrency, networking, and little else. Java, by contrast, assumes a JVM plus massive stdlibs to handle everything from enterprise apps to big-data, making its platform genuinely "fat" and layered. Other Java-tier languages, C# included, follow the same model.

I agree Go's runtime is as thin as runtimes get. But having a runtime at all disqualifies it from being a C replacement. Rust is trying to replace C, Go is trying to replace Java and some of C++.

Even Rust has a runtime. Compared to that Go's is absolutely fat though.

java has had profiles for an eternity and multiple jvm implementation. it can get really really thin.

also has modules now.