Hacker News Reader

Comment by melling | Hacker News Reader

I think performance ended up being the big win:

"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%"

View on HN

I'm usually left wondering if anyone else know about the multiprocessing module. Specifically the Pool class.

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.

It eats a lot of RAM. If your app uses X RAM, with 2 processes it will use 2X RAM. It quickly gets expensive if you're using AWS or similar.

Reply on news.ycombinator.com