5 ms·

Yes, if Go is a 'successor' then obviously it has to offer something over C, like a standard library. However it is still very much a low abstraction, get out o

by Matl 4y ago

Yes, if Go is a 'successor' then obviously it has to offer something over C, like a standard library. However it is still very much a low abstraction, get out of my way language 'in the spirit of C'. 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.

woodruffw 4y ago
Okay, but we haven't really gotten to what about the "philosophical approach" of Go's design makes it a spiritual successor. It can't be the GC, as you've pointed out. It can't be the standard toolchain reuse (cf. Unix composability), or a universal ABI for other languages/ecosystems to integrate with either. 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.
- andrewmcwatters 4y ago
  "Go bears a surface similarity to C and, like C, is a tool for professional programmers, achiev- ing maximum effect with minimum means. But it is much more than an updated version of C. It borrows and adapts good ideas from many other languages, while avoiding features that have led to complexity and unreliable code." "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. C doesn't have a standard ABI, so I don't understand why you keep making statements as if it does.
  - woodruffw 4y ago
    > achieving maximum effect with minimum means. 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.
    - grey-area 4y ago
      There is a vast philosophical gulf between languages like C and Go (less is more) and languages like Rust and C++.
      - woodruffw 4y ago
        Apart from a paucity of syntax, in what sense does Go obey "less is more"? It's well known for having a large and high-quality standard library (it has an X.509 parser! Even Python doesn't have that!). 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.
        grey-area 4y ago
        The syntax is simple, but more importantly they have left out a lot of things other languages take for granted: inheritance, exceptions (panic is not oft used) and of course till recently generics. Yes the std library is larger but I’d say that is a good thing and is not the language but the ecosystem.
        Matl 4y ago
        It's all very academic and I don't have a strong opinion on it either way but I would say C has a relatively simple syntax (no classes, no inheritance, few keywords, few symbols in its syntax etc.) but its semantics (i.e. how to use the simple syntax to produce correct software) are fairly complex. 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.

by Matl 4y ago

woodruffw 4y ago

Okay, but we haven't really gotten to what about the "philosophical approach" of Go's design makes it a spiritual successor. It can't be the GC, as you've pointed out. It can't be the standard toolchain reuse (cf. Unix composability), or a universal ABI for other languages/ecosystems to integrate with either. 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.

andrewmcwatters 4y ago
"Go bears a surface similarity to C and, like C, is a tool for professional programmers, achiev- ing maximum effect with minimum means. But it is much more than an updated version of C. It borrows and adapts good ideas from many other languages, while avoiding features that have led to complexity and unreliable code." "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. C doesn't have a standard ABI, so I don't understand why you keep making statements as if it does.
- woodruffw 4y ago
  > achieving maximum effect with minimum means. 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.
  - grey-area 4y ago
    There is a vast philosophical gulf between languages like C and Go (less is more) and languages like Rust and C++.
    - woodruffw 4y ago
      Apart from a paucity of syntax, in what sense does Go obey "less is more"? It's well known for having a large and high-quality standard library (it has an X.509 parser! Even Python doesn't have that!). 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.
      - grey-area 4y ago
        The syntax is simple, but more importantly they have left out a lot of things other languages take for granted: inheritance, exceptions (panic is not oft used) and of course till recently generics. Yes the std library is larger but I’d say that is a good thing and is not the language but the ecosystem.
      - Matl 4y ago
        It's all very academic and I don't have a strong opinion on it either way but I would say C has a relatively simple syntax (no classes, no inheritance, few keywords, few symbols in its syntax etc.) but its semantics (i.e. how to use the simple syntax to produce correct software) are fairly complex. 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.