I don't understand the "spiritual successor" part: Go intentionally broke ABI compatibility with the C world and intentionally does a lot of very un-C-like things: a large standard library, a GC'd runtime, a compiler toolchain that reimplements the "standard" toolchain, etc.
Go is a clear productivity, reliability, and security improvement over C. But I don't know if I would characterize it as a successor language, other than in the "came from the Bell crowd" sense. Which also applies to C++.
In other words, you'd spend most of your time familiarizing yourself with the code itself, not Go.
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.
Ergo successor language.
There probably is still a niche for a simpler language than Rust or C++, but I don't see Go fulfilling that niche. Zig seems like the strongest candidate here.
I believe Zig and Go's adoption is essentially capped with the compiler being this pedantic, as it overly bisects potential adopters. It is too polarizing. Some people love it, some people dislike it, but for the people who dislike it, it is enough to write off the entire language.
What exactly have you been using C for?
Go has a very heavy runtime and is garbage collected. It also cannot be embedded within other languages. Go has very different performance characteristics. Go on embedded might be possible but would be a big exercise for the reader.
I'm really not sure what you mean by Go is C alternative.
The only similarity between C and Go I see is the syntax and that there were no generics, and even that is no longer the same. The only other similarity is the need to cast to and from the equivalent of `(void *)` to get around the typechecker.
So, what are, in your opinion, the lasting concepts of C, and how does go embody them?
>Oh, yeah, I missed that sorry. > >>Is this not a breaking change? > >Some would argue it's a "fixing" change.
yikes. This article really speaks to so many of the pain points I had with Go; the language itself is fine but the whole standard library has so many just...odd...decisions that you don't notice until they blow your foot off when something off the happy path happens like, as the author notes, a server stops responding or your system boots with a wall time of unix epoch.
For people who can switch to a higher level (ie Garbage Collected) languages what does go have over Java or C# or python?
C is used for low level stuff e.g. embedded, OS, drivers. Go is GC'd which is a huge barrier. This is honestly one of the most bizarre takes I've ever seen on Rust vs Go. If I had to bet I'd say Rust will never replace C but it won't be because Go did so instead.
Rust's major influences include C++. Go's primary influence is C.
But for those of us looking for a C alternative, we have it, and it's Go. Is it a perfect replacement? I don't think so. But it is the closest spiritual successor the industry has.