> Expecting to be able to look at a code sample in isolation and know what it does is unrealistic for any large-scale system. My number one favorite thing abou

> Expecting to be able to look at a code sample in isolation and know what it does is unrealistic for any large-scale system. My number one favorite thing about Go: you can look at a code sample in isolation in a large-scale system and know what it does. Why? Every identifier is either lexically scoped or lives in a module. There are about 6 control structures and they all do what they look like they do. Operators are all defined over a small set of well-defined primitives, they can't be overridden. Closures, callbacks, and non-linear control flow are rare and obvious. There is no way for code to be skipped by exceptional control flow apart from the single escape hatch called panic(). It's really like no other language I've ever coded in. You can work in large codebases that are as clear as your average Go code, if you have strong guidance about what kinds of code complexity are acceptable and you are ever-vigilant about avoiding language pitfalls, but nothing is quite as freeing as knowing for a fact you will be able to parse someone else's code because there wasn't any way for them to write something you can't understand.