How Three Guys Rebuilt the Foundation of Facebook
wired.com
wired.com
I don't know a lot about re-writing a code base in a different language, but I doubt the time/effort required for the re-write is the only consideration. You're not just replacing the source, you're replacing the entire development process. Tools, processes, talent, stack.
Is a pretty good explanation of why we don't rewrite the whole site. A rewrite would involve every product dev stopping what they are doing and probably spending at least 18 months reimplementing their product in a different language. During that time all forward progress on products would be halted. I am absolutely certain it would be an unmitigated disaster for the company to try to rewrite the site in another language.
Instead we have a small team of people making PHP really nice work work in. HipHop gives us full control over the language and lets us add in any constructs we like. We make sure stock PHP runs, but also the additions we need to the language can be added as well.
I don't really understand devs who think reimplementing in another language is easy or the right thing to do. It's almost always the wrong thing from my experience and always lot harder and takes a lot longer than expected.
They probably should've moved to a different language a while back, but those kinds of changes require a lot of effort that don't seem economically expedient at the time.
However, i am really surprised that there doesn't seem to be a plan to gradually migrate off PHP and on to something decent.
This would involve creating a viable new platform of some sort (Sinatra on JRuby, Scalatra, Node.js, whatever's cool now), working out how to do the interoperation with PHP that was necessary (decoding PHP cookies or whatever), building or porting some minimal feature onto it, getting it into production, and getting it stable. Further features could then be developed on it or ported onto it one by one. Establishing this platform should be much less effort than writing a high-performance PHP VM.
There would remain effort in actually porting bits of the site, but that can be applied incrementally. New features could be developed on the new platform at no extra cost.
The new platform would probably be based on the JVM (unless it's Node), and i would expect it to be faster than HHVM. I would confidently expect it to require less maintenance. Given that the old platform is PHP, i would also expect it to be more secure, and to afford better quality code.
My company (a tiny operation in financial services that you've never heard of) is currently going through something a bit like this. We have a monolithic legacy app written in Java on a homebrew platform made of servlets, XSLT, and cheap gin. All our substantial new features are being developed in Scala on the Play framework. Whilst i'm not certain Scala/Play was the right choice, the plan is working: we are shipping, we are moving faster when developing the new features, and we are crying less.
I'm in a similar legacy Java boat at my own work and doing quite a bit of the "okay, what small piece can we handle" at a time style replacement.
HHVM is a much, much smaller undertaking than rebuilding Facebook from scratch. Wired did another article from the same source interviews about just how big Facebook is these days: http://www.wired.com/wiredenterprise/2013/04/facebook-window...
Building HHVM was a fraction of the effort, and did not require that we sit on our hands while the competition beat us up during a rewrite.