4 ms·
Hi, Jelte from Stream here. The post was definitely not meant to indicate that people should stop using Python. We still use it happily for the website and I'm
by JelteF 9y ago
Hi, Jelte from Stream here. The post was definitely not meant to indicate that people should stop using Python. We still use it happily for the website and I'm still a big fan of it myself.
However, for the API we've outgrown it in performance requirements. That's what the article is about, together with the things we found during the switch that we liked and disliked about Go.
- 3pt14159 9y agoHey Jelte, quick question: Did you guys try Numba or Cython? Or did you guys figure that the language simplification that Go provides would be worth it even if the performance considerations were similar?
- JelteF 9y agoNo, we didn't try those. Mainly because it wasn't only raw performance that we were after. We also wanted more simplicity and better concurrency than what python was providing for us. Also, the reason we even considered a language switch is that we had performance problems related to our core design. Because of this we decided that we needed to rewrite most of our API code based on a new design. This required rewrite made us consider switching languages. Eventually we chose to rewrite our whole API codebase in Go for all the reasons in the article. (we did a small trial project in go first to evaluate it)
- the_mitsuhiko 9y agoI would love to hear your experience in two years though. I find the go runtime incredibly lacking in terms of introspectability. That's okay if you run google scale operations where you just throw away the environment on deploys and you do not care about the individual processes, but if you are running a reasonably lean operation the ability to see what a process is doing is incredibly helpful. That even affects simple things such as error reporting which is almost useless in Go to debug issues at runtime.
- weberc2 9y agoThese are good points. Stack traces in Go are a matter of discipline while they're free in Python. That said, I think Go brings a lot to the table even for a lean operation which more than compensate for these weaknesses. Probably the biggest advantages are that Go deploys as a single binary, and one Go process is sufficient to make efficient use of the machine's resources--no need for something like it's uwsgi. At our small Python shop, we probably have two full time positions dedicated to managing our Python installation process. This could conservatively be halved with Go. Beyond that, we have a couple more full time positions for managing the fleet of servers required to run or applications--Go could easily reduce our machine demand to 2 or 3 (including redundancy) which would probably require just one engineer to maintain not to mention the savings on our AWS bill. These are just a couple of obvious benefits to Go, but for us this isn't enough to justify a rewrite.
- fijal 9y agoDid you guys try PyPy before deciding to switch? If yes, what was the outcome? If not, why not?