Thanks for asking, happy to share. I was referring to dev time, but Go is also much faster than Python at runtime. To give a little context, I've been writing Python since 2007, and professionally for ~5 years. I've been using Go in my hobby time for about ~5 years as well.

I think Go allows me to develop more quickly for a variety of reasons.

First of all, it is statically typed by default. This means that APIs tend to make more sense out of the box. You don't get APIs like Pandas' or matplotlib's or etc where you can pass three strs and an int or two floats and a datetime unless it's a Tuesday. I don't need to spend time pouring over documentation because it's all right there in the type signature, and there are high-quality plugins available for every major text-editor that allow the text editor to show you the function signature (and docs) at the push of a button (this is possible largely because of static typing).

Also, because of static typing, I get faster feedback when I've broken something. Unit tests do a pretty good job of catching things in Python, but I still find a couple of bugs a week in our Python codebase (usually in error paths) that a static analysis tool would have caught.

Now of course Python has a static type checker (mypy), and mypy can catch many of these errors. However, static typing support in Python isn't great. mypy is buggy, many popular libraries like SQLAlchemy simply can't be annotated, simple types like JSON can't be represented (no recursive types), dealing with type variables is miserable, and the documentation is poor. Things are progressing, but progress is slow. I will say that I like that Python at least has typing.Generic and typing.Union; Go has no generics and the idioms for sum types are all painful in one way or another.

Also, because of static typing, the documentation generation support in Go is way ahead of Python. Python basically has sphynx and readthedocs, which takes a pretty miserable syntax and turns it into a giant wall of HTML. Many popular projects are incompletely documented. Just today, I was searching on aiohttp's docs page for the errors documentation. It just doesn't exist, but they definitely have an exception for every HTTP status code. Many times, devs just punt and give you a handful of parameters and maybe their types (even in the stdlib, like `subprocess.run()` which tells you that the params are sorta like `subprocess.popen()`). It's basically impossible to ctrl-f in the docs either because you never know which class's `__str__()` method you're looking at. Also, in our own project, we kept seeing the sphinx docs getting out of date since there was no type checker running on the sphinx annotations (wrong annotations are worse than no annotations). Many times I just have to fire up the REPL and test the method until I figure out what the hell it actually expects for its args and what its concrete return type is, and this is an even bigger pain when the library depends on a connection to some remote database or service.

By contrast, Go has http://godoc.org which generates docs for any public package based on comments (no special syntax!) and types. You can tell at a glance that you're looking at `Foo.String()` instead of `Bar.String()` when you search for `String()` on the page. Even if the developer doesn't document anything, plenty of information is available, and if you ever need more information, each identifier has a link to its definition on Github (or bitbucket, gitlab, etc), so you're never more than a mouseclick from the complete information.

So static typing is a pretty big deal here, but there's also things like async. I'm really happy that async is taking off in Python, but it's still pretty confusing and tedious. I still don't have the whole model in my head (we've only been using it for ~8 months), but it's really annoying that every library that does any I/O at all now needs an async version. Recently I was trying to concurrently build Docker images from a Python script, but the Python Docker API isn't async, so I guess I'll need to fork a process or something. Most popular projects like Docker and AWS have some Joe Developer maintaining an equivalent async library, but that comes with a bunch of additional concerns.

In Go, everything is async by default with a synchronous interface, which is almost exactly the interface I want for async things (although I do prefer Python's `await` to Go's channels and goroutines).

Also, making things fast in Go is a lot easier and more straightforward than in Python. First of all, Go is 10-100X faster than Python, so you don't need to optimize in Go as often as you do in Python. But when you do, the optimizations are usually spelled out to you by the profiler and you can actually fix them (since Go gives you control over things like allocations which allows you to intervene to reduce memory pressure and improve cache performance). Also parallelism; for all intents and purposes, your only parallelism option in Python is multiprocessing, and this is shitty. For most peformance issues, the Python answer is "just use C for your hotpath", but this can actually make things slower for a lot of situations since calling into C typically means converting between Python data structures and C data structures. I had a coworker throw Pandas at a performance problem, but the solution involved running Python on every cell in the dataframe, so we actually lost (10-30X) performance over the naive list-o-dicts solution because of all of the calling across the language barrier. And if you're not using something like Pandas or Numpy, writing C is actually pretty hard for the average Python dev, and writing memory-safe, secure, portable, cross-platform C is hard for lots of above-average C developers. There are definitely cases where "just write it in C" is a reasonable thing to do, but even being able to identify those cases takes a certain amount of expertise that your average Python developer doesn't have.

Lastly, Go compiles everything to a static binary. Python finally got pipenv, which solves some of the same problems, but it's still a pain and every issue seems to take a full afternoon to debug. Go binaries just run out of the box on pretty much any Linux.

I don't want to give the impression that I write Go 10X better than Python; it's probably closer to 1.2-1.5X, and there are some times where Go is the clear loser. Some libraries just don't exist or aren't yet mature in Go, and any sort of magic is far easier in Python (although this is also a misfeature since you get more people adding unnecessary and/or bug-ridden magic into their APIs). Hopefully this wall-o-text answers your question. As always, YMMV.