I have been playing with Go on and off for a couple of months now and am really enjoying it. I could probably do a post just on why and what I like, but in short, it adheres to and encourages simplicity, obviousness, and explicitness that Python does (moreso than Python in many cases) while adding some new tools, implementation options, and deployment options.

Background

Part of the explicitness and obviousness of Go is in function signatures. In Python you can have named parameters with defaults, so they are optional. You even have the *args and **kwargs parameters which take variable, unspecified positional and named parameters. This pretty strongly violates Python's "Explicit is better than implicit" rule since the named parameter with defaults is implicit and *args and **kwargs are not even clearly options without digging into the source code of the function or method. Go allows no such thing. There are no named parameters, there are no optional parameters, and there certainly are no unmentioned wildcard, anything goes parameter collections (there are some options for getting around this if you really, really insist on putting in more effort just to shoot yourself in the foot). All arguments to a function must be specified, are typed, are positional, and must have some value passed in even if it is nil in the case of a pointer. This is great. It's explicit and it's obvious what the function expects from the caller.

Go also encourages using dependency injection, so you will create things such as database connections, callback functions, etc. Anything which may be configurable due to differences in environment such as dev vs staging vs production or for distributable code used by others or passing in mock objects in test cases. This builds upon the explicitness, making it clear what is needed and what will be done, while maintaining flexibility and configurability as opposed to using global state for settings and databases for ease of access anywhere in the code at the cost of explicitness as you will commonly see in web frameworks.