"We migrated our entire API stack from Python (First Django then Falcon) to Go, reducing the mean response time of an API call from 100ms to 10ms
We reduced the number of EC2 instances required by 85%"
Go is going to be a lot faster than Python even without multiprocessor. The performance difference becomes even larger on multi-colored cpu's. Say, for example, if Go is 3 times faster than Python on one core then you throw in 4 or 8 cores, the win is even bigger.
That's true but how many tasks legit need multithreading? Not many in my experience. Over the course of my career I've come to the conclusion that multithreading is best left for systems programming and very few specific applications (such as a game engine and not much else).
For pretty much everything else that people use multithreaded applications for in the past (encoding, image editing)- multinode processing is vastly superior to multithreaded. Erlang calling out to C (if even necessary) is going to win there over most. Or you could use Python or whatever you wanted.
The Java/Go way of local multithreaded applications seems archaic to me.
"We migrated our entire API stack from Python (First Django then Falcon) to Go, reducing the mean response time of an API call from 100ms to 10ms We reduced the number of EC2 instances required by 85%"