What's peculiar is the way certain words are used by the authors, like "systems" programming, or "programming at scale", etc. I don't see how Go is more "syste

What's peculiar is the way certain words are used by the authors, like "systems" programming, or "programming at scale", etc. I don't see how Go is more "systems-ey" than say, Java; other than allowing you to pack struct members together by separating pointer and value types in a certain way. C# already allows you to do something similar. Furthermore, the main arguments I've seen for "programming at scale", are that unused vars get treated as errors, interfaces, and the way dependencies are managed (mainly to speed up compile times). The latter has been solved by probably any modern language post-C++. Warnings as errors is a preference. Interface types aren't that special when looking at languages like Scala and Rust, which provide very nice and powerful type and trait systems that go really well together; while maintaining the ability to extend types by other traits, not that much unlike Go to begin with. I am not a language designer, but I can't help but feel that the language was somehow designed into a corner, with the way interfaces and composition work together. All this is making adding generics much harder.