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.