Last time I checked they're working on improving Python performance instead (yes I know they forked it into Cinder, but they're trying to upstream their optimizations [0]). Which is very similar to what we're doing at Shopify.
Of course 100% of Instagram isn't in Python, I'm certain there's lots of supporting services in C++ etc, but AFAIK the Instagram "frontend" is still largely a Python/Django app.
The joke is that if Meta thought that replacing all the Python code they have with something else was worth it, they'd have done it already.
"Worth it" depends on both how much performance improvement you get, and how hard it is to replace. Did you consider maybe the rewriting effort is so humongous that it is not worth doing despite large performance improvements? Thus making the joke not funny at all...
But that's some silly engineer tunnel vision, squeezing the very last bit of performance out of a system isn't a goal in itself. You just need it to be efficient enough that it cost you significantly less to run that the amount of revenue it brings you.
I can bet you that moving off Python must have been pitched dozens and dozens of time by Meta engineers, but deemed not worth it, because execution speed isn't the only important characteristic.
So yes, I find it hilarious when HN commenters suggests companies should rewrite all their software into whatever is seen as the most performant one.
Instagram is presumably in the same position. Switching language is basically impossible once you have a certain amount of code. I'm sure they were aware of the performance issues with Python but they probably said "we'll worry about it later" when they were a small startup and now it's too late.
Hack is actually surprisingly pleasant, basically about the best language they could have made starting from PHP. (I know, that's damning with faint praise. But I actually mean this unironically. It has TypeScript vibes.)
IMHO Hack's best feature was native support for XHP... which (also unfortunately) isn't something PHP decided to take.
Is the Instagram stack Python? I doubt it, but stranger things have happened
I suspect it is actually some derivative of Apache, or Nginx. Something sensible
1. 10% performance improvement at Instagram could lead to many millions of revenue "instantly". It is not laughable at any company. 2. It won't be a 5000% performance improvement. Facebook uses its own fork of Python that is heavily optimized. Probably still far from C++, but you should be thinking about languages like Java when talking about performance.
"Better" is a very subjective term when discussing languages, and I hope such discussions can be more productive and meaningful.
https://github.com/facebookincubator/cinder/blob/cinder/3.8/...
Well, it really depends on whether that alternative is open to you, and at what cost.
So eg lots of machine learning code is held together by duct tape and Python. Most of the heavy lifting is done by Python modules implemented in (faster) non-Python languages.
The parts that remain in Python could potentially be sped up by migrating them, too. But that migration would likely not do too much for the overall performance, but still be pretty expensive to do (in terms of engineering effort).
For organisations in these kinds of situations, it makes a lot of sense to hope for / contribute to a faster Python. Especially if it's a drop-in replacement (like Python 3.12 is for 3.9).
What makes really me hopefully is actually JavaScript: on the face of it, JavaScript is actually about the worst language to have a fast implementation. But thanks to advances in clever compiler and interpreter techniques, JavaScript is one of the decently fast languages these days. Especially if you are willing to work in a restricted subset of the language for substantial parts of your code.
I'm hoping Python can benefit from similar efforts. Especially since they don't need to re-invent the wheel, but can learn from the earlier and ongoing JavaScript efforts.
(I myself made some tiny efforts for CPython performance and correctness. Some of them were even accepted into their repository.)
So likely the 5000% improvement is no longer possible because they already did multiple 10% improvements? I don't know how this counters the original point.
All clues point to FB going this route because they had too much code already in PHP, and not because the performance improvement would be small.
In any case, "facebook does it" is not a good argument that something is the right thing to do. Might be, might not be. FB isn't above wrong decisions. Else we should buy "real estate" in the metaverse.