5 ms·
Did it seem to anyone else that sticking to Python would have been way easier? It didn’t seem like any of the performance gains were through Golang.
by throwthisawayt 9y ago
Did it seem to anyone else that sticking to Python would have been way easier? It didn’t seem like any of the performance gains were through Golang.
- deepnotderp 9y agoYeah, either a good Python JIT or Cython would have been fine honestly. I never understood the obsession with "python is slow" when you can recover almost all of the performance with a good JIT or Cython (in many/most cases).
- victor106 9y agoWhat are some good Python JIT's that are worth trying out?
- dr_zoidberg 9y agoPyPy.
- victor106 9y agoThanks.
- Drdrdrq 9y agoYes. Or simply profiling the app and optimizing sore spots would have helped too. It seems to me there was no real reason to move from Python to Go, apart from preference.
- stmw 9y agoFrom reading this, seems HTTP handling speed was important to them? which Go is probably better for. Also, interfacing Python to C/C++ is pretty unpleasant.
- jononor 9y agoIn Python they already had an extremely fast library with bindings available.
- smaili 9y agoI believe this little piece answers your question: > We likely could have addressed this behavior in Image Proxy, but we had been experimenting with using more Go, and it seemed like a good place to try Go out. At the heart of if, they were looking for opportunities to use more Go in their stack and they deemed this situation as a fit.
- prophesi 9y agoAnd they ended up open-sourcing the library they built, so it's a win on all sides.
- fleitz 9y agoThe age old solution in search of a problem.
- Karrot_Kream 9y agoI think that's a bit reductionist, no? There are many reasons they may have been searching for moving to Go. Off the top of my head I can think of: 1. Static typing increasing confidence and velocity 2. Better developer-facing tooling increasing velocity 3. More employees knowledgeable about Go than Python 4. More enthusiasm (and therefore faster velocity) around Go development. The blog post was about the engineering challenges they faced and how they solved them and I think it was a great write-up in that regard. The post wasn't about why they switched this service from Python to Go.
- fleitz 9y agoIt might be, then again I see a lot of wheel reinvention in tech / NIH syndrome. I'm the kind of hacker who if a service runs out of memory every 2 hours, writes a crontab to restart it every hour after X random minutes so they don't all restart at the same time. It gets a lot of eye rolls from the other engineers searching for perfection, but it tends to produce services quickly that are highly reliable. And look now the engineers who like chaos monkey don't even have to set that up. It's built in. It looks like most of the savings were in switching from pillow to opencv, something that thumbor already does. https://github.com/thumbor/opencv-engine https://github.com/thumbor/opencv-engine
- deleted 9y ago[deleted]
- harikb 9y agoI understand this is a personal preference, but having spent a good amount time with both Python and Go, FWIW I would also choose Go if I were solving the same problem.
- detaro 9y agoI don't think the article gives us the data to know this. Where did the latency spikes in the original implementation come from? Would fixing them have required a complete rewrite of the Python parts anyways?