> 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

> 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.