4 ms·
Yep. Facebook got pretty far down the road with PHP, MySQL, memcached, etc.
by tyingq 3y ago
Yep. Facebook got pretty far down the road with PHP, MySQL, memcached, etc.
- fauigerzigerk 3y agoAll they had to do was write a PHP compiler and a new storage engine for MySQL.
- tyingq 3y agoHipHop (later HHVM) was around 2010, so they scaled from 2004-2010 before that became needed. MyRocks was 2015. Wikipedia says FB was around 300 million users in 2009, then 400 million users in 2010.
- fauigerzigerk 3y agoYes, good point. But you have to wonder what kind of engineering effort went into scaling PHP and MySQL up to the point where they decided to build a compiler and a storage engine.
- rafark 3y agoWhen you have half a billion users that both read and write all day, you have to optimize, no matter the tech.
- fauigerzigerk 3y agoThat is undeniably true, but I do think the starting point still matters.
- disgruntledphd2 3y agoIt was much, much, much cheaper than a rewrite would have been, that's why they did it. Edit: also, in 2004 when they got started, what else could they have used?
- ericbarrett 3y agoThe trick was there was enough growth that the savings from the compiler were massive. (I worked there at the time.) The inefficiency of the PHP interpreter was a great problem to have, because it came from the success it enabled.
- fauigerzigerk 3y agoSo I think the interesting question is whether the rest of us can learn anything from what happened there. I believe Mark Zuckerberg simply used the technology he knew and took it from there. That's fine. I probably would have done the same thing. But many people are making an ideology out of this, arguing that not giving a shit about performance is always the right choice initially because that's how you grow fast enough to be able to retool later. I think this is based assumptions that are no longer true. In the early 2000s, mainstream programming languages and runtimes were either fast and low productivity or slow and high productivity (Exceptions such as Pascal/Delphi did exist but they were not mainstream). And the cost of scaling up was prohibitive compared to scaling out. Today, you can choose any fast high productivity language/runtime and go very far mostly scaling up.
- rafark 3y agoLearn what? That you should use the language that you’re more comfortable with and then scale? Or that languages have become more efficient? Php 8, for example, is many times faster than the php 4 and 5 that Facebook was using.
- fauigerzigerk 3y agoI think using what you already know remains a choice that is very hard to criticise. But we didn't have to learn that, did we? Beyond that I think there is more to unlearn than to learn from the history of the Y2K batch of startups. The economics of essentially everything related to writing, running and distributing software have changed completely.
- noir_lord 3y ago
- cagenut 3y agoyour comment implies your understanding of the timeline is backwards. they had to do those things after they had gotten hundreds of millions of users.
- fauigerzigerk 3y agoDepends on what you consider "far down the road" and what they had to do before writing a compiler and a storage engine. How long did it take until Facebook engineers realised that their technology stack was not the best tool for the job? It definitely wasn't the day when they decided to build a compiler and a storage engine.
- tyingq 3y agoI'm not sure there was really a best tool for the job in 2003-2004 that would have been high-level enough to be productive, and scalable enough to stay mostly as-is. Java, maybe.
- fauigerzigerk 3y agoI agree, and I'm not criticising the choices that Mark Zuckerberg made at the time. But we are no longer facing the same situation he did. We do now have high productivity, high performance language runtimes. And scaling up has become much cheaper (relative to the number of users you can serve). That's why I think it can't hurt to remind people of the great lengths to which Facebook had to go in order to deal with the limitations of their chosen platform.
- balder1991 3y agoYeah, I kinda don’t agree with the dichotomy of “you either optimize or you build features”. They’re not exclusive. If you understand the tools and their trade offs you should be able to use the right tools for the job which won’t hinder you in the future. Of course if all you know is JavaScript, then that requires going a bit outside your comfort zone.