4 ms·

Pretty balanced article, but I think it skips over the (for me) main points of using Go: * Go was developed within Google, mainly as a response to C++ projects

Pretty balanced article, but I think it skips over the (for me) main points of using Go: * Go was developed within Google, mainly as a response to C++ projects that had grown unwieldy, in terms of dependencies and compilation speed. As a result, the language is designed from scratch with compilation speed in mind, and unused dependencies are disallowed. * There are few changes to the language. When a new Go compiler is released, I go "nice, wonder which tooling and performance improvements are present" and not "oh no, how many repositories will need patches". Go code can be expected to compile 10+ years ahead. The same is not always the case for C, C++, Zig and possibly even Rust. * Deployment and crosscompilation is straightforward.

usrnm 3y ago
> The same is not always the case for C, C++ That's just completely not true, especially for C. There is a lot of C code older than most commenters on this site that's still used in production and compiled with modern compilers
- deleted 3y ago
  [deleted]
bestouff 3y ago
> and possibly even Rust. This is patently false. Rust has a severe backwards compatibility policy.
deaddodo 3y ago
> Go code can be expected to compile 10+ years ahead. The same is not always the case for C, C++, Zig and possibly even Rust. I'm sorry, but this comment just seems so blind to reality that it's hard not to comment on. C has a few particularly strong selling points: * Orthogonality to machine architectures * Freestanding (STD-free, in modern language parlance) compilation * An extremely conservative ruling body The latter is usually listed as a double-edged sword, since there are many new features people would like in C: true generics, polymorphic (overloaded) functions (without using the pre-processor), a true module system, etc; but it also means extremely old code compiles just fine on modern C compilers. Now, it might not work because it might be built for some bespoke hardware/environment, but the code will compile fine and be correct. For instance, here's a perfectly valid ANSI C application that will compile on any C compiler in the last 35 years (three times as long as Go has existed): https://godbolt.org/z/ja6WM5feT https://godbolt.org/z/ja6WM5feT Most of the features added in C11, C17 and C23 are additional features, usually with no backwards breaking changes. However, in some cases they do clarify undefined behavior; which can break old code. This is why most of the major modern compilers add flags to compile in specific dialects. Additionally, there are plenty of Go 1.0 (the first [and only] "10+" [11] year old version) codebases that won't compile without major changes.
- xyproto 3y ago
  Old C projects are very often troublesome to compile on a modern system with modern libraries. Source: Arch Linux package maintainer for 10+ years
  - memefrog 3y ago
    That's a problem with those libraries and not with C. People can make backwards-incompatible API changes to libraries in any language.
    - xyproto 3y ago
      Sure, but Go has a good system to avoid this, with go.mod and go.sum.
      - memefrog 3y ago
        Go didn't invent package management. You have been able to do this for 20 years in general. go.mod and go.sum help you with go dependencies on go packages. What about Python dependencies on C? Or C dependencies on Go? You can do this in full generality and yet people keep reimplementing it language-specifically because they refuse to just use APT or something.
- memefrog 3y ago
  C no longer has a conservative standards committee. This was true until C23. In practice it doesn't really matter, because compilers will never actually break old code. But the committee is now actively trying to break your code, by doing completely pointless things like replacing _Bool with bool to save you one #include.
orwin 3y ago
Just compiled my 10 year old C project to test this claim. No issues (and it was written in C89, not C99 nor C11). And couldn't compile my 9 year old Go project (a small supervisord clone) a few month ago (it was either in go 1. 2 or 1.3). Granted, it was a library issue (terminfo/ncurse, I can't remember which), but still. I'm not a huge C proponent anymore (except as a learning language), but C is absolutely more stable than most languages, especially if you account for external libs.
- sethammons 3y ago
  Heh, I too was surprised to find a similar aged project of mine that failed to compile for very similar reasons. It was a multiplayer terminal game. Nothing fancy, just ascii characters that could navigate an ascii maze and "eat" other characters. Didn't spend any time to dig in. Def let down by the backwards compatibility promise.

usrnm 3y ago

> The same is not always the case for C, C++ That's just completely not true, especially for C. There is a lot of C code older than most commenters on this site that's still used in production and compiled with modern compilers

deleted 3y ago
[deleted]

bestouff 3y ago

> and possibly even Rust. This is patently false. Rust has a severe backwards compatibility policy.

deaddodo 3y ago

> Go code can be expected to compile 10+ years ahead. The same is not always the case for C, C++, Zig and possibly even Rust. I'm sorry, but this comment just seems so blind to reality that it's hard not to comment on. C has a few particularly strong selling points: * Orthogonality to machine architectures * Freestanding (STD-free, in modern language parlance) compilation * An extremely conservative ruling body The latter is usually listed as a double-edged sword, since there are many new features people would like in C: true generics, polymorphic (overloaded) functions (without using the pre-processor), a true module system, etc; but it also means extremely old code compiles just fine on modern C compilers. Now, it might not work because it might be built for some bespoke hardware/environment, but the code will compile fine and be correct. For instance, here's a perfectly valid ANSI C application that will compile on any C compiler in the last 35 years (three times as long as Go has existed): https://godbolt.org/z/ja6WM5feT https://godbolt.org/z/ja6WM5feT Most of the features added in C11, C17 and C23 are additional features, usually with no backwards breaking changes. However, in some cases they do clarify undefined behavior; which can break old code. This is why most of the major modern compilers add flags to compile in specific dialects. Additionally, there are plenty of Go 1.0 (the first [and only] "10+" [11] year old version) codebases that won't compile without major changes.

xyproto 3y ago
Old C projects are very often troublesome to compile on a modern system with modern libraries. Source: Arch Linux package maintainer for 10+ years
- memefrog 3y ago
  That's a problem with those libraries and not with C. People can make backwards-incompatible API changes to libraries in any language.
  - xyproto 3y ago
    Sure, but Go has a good system to avoid this, with go.mod and go.sum.
    - memefrog 3y ago
      Go didn't invent package management. You have been able to do this for 20 years in general. go.mod and go.sum help you with go dependencies on go packages. What about Python dependencies on C? Or C dependencies on Go? You can do this in full generality and yet people keep reimplementing it language-specifically because they refuse to just use APT or something.
memefrog 3y ago
C no longer has a conservative standards committee. This was true until C23. In practice it doesn't really matter, because compilers will never actually break old code. But the committee is now actively trying to break your code, by doing completely pointless things like replacing _Bool with bool to save you one #include.

orwin 3y ago

Just compiled my 10 year old C project to test this claim. No issues (and it was written in C89, not C99 nor C11). And couldn't compile my 9 year old Go project (a small supervisord clone) a few month ago (it was either in go 1. 2 or 1.3). Granted, it was a library issue (terminfo/ncurse, I can't remember which), but still. I'm not a huge C proponent anymore (except as a learning language), but C is absolutely more stable than most languages, especially if you account for external libs.

sethammons 3y ago
Heh, I too was surprised to find a similar aged project of mine that failed to compile for very similar reasons. It was a multiplayer terminal game. Nothing fancy, just ascii characters that could navigate an ascii maze and "eat" other characters. Didn't spend any time to dig in. Def let down by the backwards compatibility promise.