¿PHP ha muerto o sigue siendo el rey del backend?

Photographer

Se que esto puede sonar a herejía en pleno 2024, pero llevo 5 años trabajando con PHP (Laravel) y no entiendo el hate que recibe. Sí, tiene cosas raras, pero la cantidad de proyectos que he sacado con ese framework es brutal. Ahora bien, en mi empresa quieren migrar todo a Node.js porque 'es lo moderno', y yo me pregunto: ¿de verdad PHP está muerto o es solo un meme? ¿Alguien más ha tenido que defender su stack favorito en una reunión? ¿O debería subirme al carro de Go/Rust y olvidarme del asunto?

Data

PHP no está muerto, pero apesta. El problema no es el lenguaje, es que la mayoría de código PHP que encuentras es legacy horrible. Laravel es una joya, pero la comunidad PHP en general se queda atrás en temas de tipado y concurrencia. Node.js no es mejor per se, pero su modelo asíncrono encaja mejor con microservicios. Si te obligan a migrar, no lo veas como una derrota, es una oportunidad para aprender algo nuevo.

Jewelry

Llevo 10 años con PHP y sí, he defendido mi posición mil veces. Pero también he probado Go y Rust, y la sensación de seguridad y rendimiento es otra liga. Si tu empresa quiere migrar, que te paguen la formación y luego decides. Lo que no aguanto es que digan 'PHP es malo' sin argumentos. Eso sí, si tocan mi Laravel, me les planto.

Photographer

Gracias por las respuestas. Me alegra ver que no soy el único que ha pasado por esto. El punto de la seguridad y rendimiento me llega, pero en mi caso, con Laravel he dormido tranquilo. Aunque quizás debería probar Go para un side project y ver qué tal. ¿Alguien tiene un ejemplo de cómo se ve un endpoint simple en Go vs PHP? Me da curiosidad.

Surfing

Claro, un ejemplo rápido. En PHP (Laravel):

Route::get('/user/{id}', function ($id) {
    return User::find($id);
});

En Go (con Gin):

r.GET("/user/:id", func(c *gin.Context) {
    id := c.Param("id")
    var user User
    db.First(&user, id)
    c.JSON(200, user)
})

La sintaxis no es tan distinta, pero Go te obliga a manejar errores explícitamente y es más verboso. La curva de aprendizaje no es enorme, pero la recompensa en rendimiento es notable.

Cocktails

¿Y nadie menciona el elefante en la habitación? JavaScript en el backend es un caos. Node.js tiene 50 frameworks y todos cambian cada dos meses. Al menos PHP tiene una forma estándar de hacer las cosas. Y no me hagas hablar de TypeScript, que es JavaScript con maquillaje. Si quieres algo robusto, ve a Java o .NET, pero no me vengas con modas.

Knitting

¡Al fin alguien con sentido común! He trabajado con PHP, Node, Python y Java, y al final lo que importa es el equipo y el dominio del problema. El lenguaje es una herramienta, no una religión. Si tu empresa migra, que lo hagan con una buena razón técnica (no porque está de moda) y con un plan de pruebas. Y si te resistes, al menos propón un piloto con métricas.

Photographer

Me gusta eso de 'herramienta, no religión'. Al final, el debate es sano, pero lo que no soporto es el dogmatismo. Voy a proponer un piloto en el equipo: migrar un microservicio pequeño a Go y comparar. Si los números son mejores, acepto el cambio. Si no, tendré argumentos para quedarme. Gracias por el ejemplo de código, me da una idea clara. ¡Grande comunidad!

Gardening

Por cierto, si pruebas Go, no te olvides de los generics (ya están desde la 1.18). Y para el que dijo que JS es un caos, tienes razón, pero al menos Deno está intentando arreglarlo. Pero bueno, al final todos terminamos dependiendo de npm o composer, así que no hay salvación. 😂

FoodLover

El debate de fondo no es PHP vs Go, sino cómo medimos el rendimiento y la productividad. Si vas a hacer un piloto, que no sea solo con un microservicio trivial: prueba con un caso que use I/O intensivo, caché y concurrencia real. Y ojo con los generics de Go, que aunque ya están, no son la panacea: a veces complican la lectura. Si quieres datos duros, échale un ojo a los benchmarks de TechEmpower, pero ajusta los resultados a tu stack y a tu equipo. Y sí, todos dependemos de un gestor de paquetes, pero al menos Composer no te rompe el ecosistema cada dos versiones como npm. 😉