Single deployment binary, static typing, gofmt, and takes "there should be one and only one obvious way to do it" even farther than Python. It's very easy for new team members to ramp up on a Go codebase - formatting is standardized, libraries are standardized, and the language encourages very simple readable constructs (at the expense of brevity and abstraction, sometimes). That makes it attractive for companies in their growth stage, where you're working in teams but still have constraints on fast execution (CPU) and fast execution (developer velocity).

IMHO Go is still inferior to Python for solo-developer projects.

100% this.

My personal view is that dynamically typed languages are largely falling out of favour with Javascript being the one glaring exception (and even there if I were starting a project today I'd use Typescript).

On the single deployment binary issue, let me just underline that point with one word: virtualenv.

> On the single deployment binary issue, let me just underline that point with one word: virtualenv.

can you expand ?

I'm a python user and parallelism and performance are not the reason I tried Golang because I had no poblem with these for my use cases. However, it solves the only problem I have with Python which is deployement/distribution: basically your server can be a single binary. Best of all, you can target whatever platform with ease. You don't have to worry about your client having the right python or the needed dependencies and this comes with no effort on your part.

Given that the language is relatively easy to grasp and that the standard library covers all the basic needs of a server application, that alone is a huge win.

Python still has more and better libraries for certain tasks though.

I haven't switched from Python to Go, but I program heavily in both languages and can offer an additional point here:

Go makes it easy to produce binaries for any target platform that execute without requiring a working Go installation.

This ease of packaging makes Go my default language when I'm writing developer tooling - for example, if I know that team-mates are going to have to run tools that I write but I don't want to make assumptions about their development environments.

There is one caveat: This only works well if you avoid platform-specific functionality (e.g. syscall package) and CGO.

I think a major one is simply the easy of deployment - one self serving binary is quite refreshing after dealing with wsgi etc.

I suppose the static analysis is quite cool too...

static types, native builds, cross-platform builds