The most productive C codebases are the ones that have existed for years, where every possible utility and type has been built from scratch out of need; Go programmers are able to be productive from the get-go.
It's obviously not a true successor as it has a GC for one, but one way I like to think about it is that if Java is in some ways a more convenient C++ for application development, if you will, then Go would be that but a more convenient C, not C++
The 'C successor' comes more from the philosophical approach of Go's core team to the language design being similar to that of C, not it being a practical successor to C as such.
If it's just this "get out of my way"-ness, then my impression is that it's not as much a successor to C as it is just a good, modern, high-productivity language. You don't really see Go programmers reimplementing basic data structures (or stamping them out, over and over again) the way you do in C land.
"Go is sometimes described as a ‘‘C-like language,’’ or as ‘‘C for the 21st century.’’ From C, Go inherited its expression syntax, control-flow statements, basic data types, call-by-value param- eter passing, pointers, and above all, C’s emphasis on programs that compile to efficient machine code and cooperate naturally with the abstractions of current operating systems."
"All programming languages reflect the programming philosophy of their creators, which often includes a significant component of reaction to the perceived shortcomings of earlier lan- guages. The Go project was borne of frustration with several software systems at Google that were suffering from an explosion of complexity. (This problem is by no means unique to Google.)
As Rob Pike put it, ‘‘complexity is multiplicative’’: fixing a problem by making one part of the system more complex slowly but surely adds complexity to other parts. With constant pres- sure to add features and options and configurations, and to ship code quickly, it’s easy to neglect simplicity, even though in the long run simplicity is the key to good software."
Simplicity requires more work at the beginning of a project to reduce an idea to its essence and more discipline over the lifetime of a project to distinguish good changes from bad or perni- cious ones. With sufficient effort, a good change can be accommodated without compromis- ing what Fred Brooks called the ‘‘conceptual integrity’’ of the design but a bad change cannot, and a pernicious change trades simplicity for its shallow cousin, convenience. Only through simplicity of design can a system remain stable, secure, and coherent as it grows.
The Go project includes the language itself, its tools and standard libraries, and last but not least, a cultural agenda of radical simplicity. As a recent high-level language, Go has the bene- fit of hindsight, and the basics are done well: it has garbage collection, a package system, first- class functions, lexical scope, a system call interface, and immutable strings in which text is generally encoded in UTF-8. But it has comparatively few features and is unlikely to add more. For instance, it has no implicit numeric conversions, no constructors or destructors, no operator overloading, no default parameter values, no inheritance, no generics, no exceptions, no macros, no function annotations, and no thread-local storage. The language is mature and stable, and guarantees backwards compatibility: older Go programs can be compiled and run with newer versions of compilers and standard libraries."
The authors Frequently Asked Questions sections regularly refer to C.
As stated above: this is arguably a property of Go, but very definitely not a property of C.
The rest of this is "Go borrows good ideas from C," which nobody doubts. It doesn't establish the kind of successor relationship you've claimed. Most of the ideas mentioned also apply to Rust.
In many ways, the "less is more" property exists on separate axes for C and Go: C's syntax is relatively complex while Go's is relatively simple. C's standard library and runtime are minuscule; Go's are large.
In comparison, Go has both; a relatively simple syntax and semantics, (except for a few exceptions).
I guess people focus on the syntax part of Go to say it's like C and the semantics being easier is what makes it better/a successor? It's all rather vague and I'm not a proponent of this mantra myself, but that's how I understand it anyway.
With regards to the stdlib, that doesn't violate 'less is more' if you argue from a 'things to learn' point of view. A large stdlib doesn't really add to the complexity of the language feature set itself. It just provides utilities you don't have to write/hunt for.
In comparison Rust just added support for generic associated types. That's a language level feature, in that sense Rust is more akin to C++ than C. Go added generics, but apart from that it doesn't tend to add 'big' language features.
And if you adopt this mindset and close one eye it can just about make sense to liken C and Go.
I agree that C's syntax is visually simple, but it's actually pretty complex from a parsing perspective: it's both context sensitive and binding sensitive, meaning that a correct C parser needs to be aware of the current parsing context's "live" bindings (including other functions) in order to resolve ambiguities like this:
int foo(int(bar));
I can understand that ultimate mindset! Rust is certainly a much more complex language from a syntax and semantics perspective, and (I think) the community wouldn't want to claim the "C successor" label anyways.
Yes the std library is larger but I’d say that is a good thing and is not the language but the ecosystem.
In other words, you'd spend most of your time familiarizing yourself with the code itself, not Go.