¿Por qué Facebook no ha migrado fuera de PHP?

La razón por la que Facebook no se ha alejado de PHP es porque tiene una inercia predominante (es lo que está allí) y los ingenieros de Facebook han logrado solucionar muchos de sus defectos a través de una combinación de parches en todos los niveles de la pila y una excelente disciplina interna a través del código convención y estilo: se evitan los peores atributos del lenguaje y el estilo de codificación se aplica rígidamente a través de una cultura bastante estricta de revisión de código (al no adherirse al estilo y “volverse vaquero” al escribir código descuidado resulta en una burla despiadada por parte de los compañeros) . La gerencia de ingeniería nunca ha tenido que tomar una mano fuerte aquí; Esto surgió en gran medida debido a que los líderes técnicos internos clave simplemente acorralaron a todos los demás.

También hay muchos precedentes de la industria que indican que reescribir una base de código completa en otro idioma suele ser una de las peores cosas que puede hacer, por lo que en todos los niveles hay renuencia a hacerlo. La estrategia preferida es escribir nuevos componentes de forma desacoplada utilizando un mejor lenguaje de elección (C ++, python, Erlang, Java, etc.); esto se ve facilitado fácilmente por el desarrollo temprano de Facebook de la economía, un marco eficiente de RPC en varios idiomas. Esto también ayuda a evitar los peores efectos de PHP: se puede evitar por completo en subcomponentes donde el lenguaje es extremadamente inadecuado. El efecto general es que la base de código general evoluciona lentamente para no depender tanto de PHP, con los componentes que aún están en PHP siendo escritos de manera estrictamente controlada y disciplinada por miembros veteranos del personal.

Porque es un máximo local. Tenemos nuestra propia VM que controlamos. Entendemos sus características de producción a gran escala. Tenemos una gran comunidad de programadores calificados. Tenemos herramientas para el desarrollo y la depuración.

A escala de Facebook, reducir la variación es mucho más valioso que aumentar el rendimiento. PHP es bueno para el desarrollo de baja latencia (experimentación), es bastante bueno en el rendimiento (suponiendo que dispares a cualquiera que use los bits difíciles), y entendemos la variación.

¿Qué obtendría a cambio del costo de cambio que valdría la pena?

El sabor de PHP que usamos en Facebook, Hack, está muy alejado de lo que normalmente piensas cuando imaginas PHP. En casi todos los aspectos, ha estado por delante de JavaScript. Hemos tenido tipeo estático, generadores, asíncrono / espera, tuplas, funciones anónimas, clases y XHP (básicamente Reaccionar) durante mucho tiempo, a menudo años antes de que estuvieran disponibles en Node. Como resultado, nuestra base de código Hack tiene un espíritu muy cercano a una aplicación JS moderna.

Lo único que no tenemos es JavaScript isomorfo. Esto se convierte en un problema menor con el tiempo porque la funcionalidad del cliente (web, móvil nativo) mejora y nuestra base de código Hack se transforma en una capa API.

La razón por la cual Facebook invirtió tanto en Hack es que tenemos una base de código absolutamente masiva. Hemos favorecido una reproducción monolítica sobre los servicios acoplados libremente. El cambio de tecnologías habría sido un esfuerzo total o nulo, e incluso más costoso que adaptar el lenguaje y adoptar características de forma gradual con el tiempo.