Thanks a lot for the detailed answer. Some other comments inline below. >Also, because of static typing, I get faster feedback when I've broken something. Unit

Thanks a lot for the detailed answer. Some other comments inline below. >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. True, static typing can help a lot, and you get the feedback at compile time, not run time, as you said. >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). Interesting, will check that feature out. >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. Those are good points about issues with calling C from Python. >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. True, and that (binaries from compiled-code languages) was a more common deployment method before dynamic languages like Python, Ruby and Perl became popular. Done a lot of dev work in C earlier.