4 ms·
They cite their main reason for migrating as being self-hosting, which is hard in Python. I've had a huge amount of success using pyinstaller for this problem,
by cowsandmilk 11y ago
They cite their main reason for migrating as being self-hosting, which is hard in Python.
I've had a huge amount of success using pyinstaller for this problem, shipped many products into hugely diverse environments.
https://pyinstaller.org https://pyinstaller.org
- melling 11y agoI 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%"
- medecau 11y agoI'm usually left wondering if anyone else know about the multiprocessing module. Specifically the Pool class.
- melling 11y agoGo 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.
- BuckRogers 11y agoThat'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.
- faceplanter 11y agoIt 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.