No debería llamarse Grails
viernes 13/04/2007
No soy muy amigo de batallas del estilo "yo la tengo más grande que tú", pero creo que voy a dedicar un rato a explicar por qué Grails no debería llamarse Grails, y cómo en mi opinión la vinculación (teórica, porque en realidad tienen poco que ver) con RoR nos va a terminar trayendo más mala fama que buena.
Es verdad: Grails es un framework muy joven. Todavía hay mucho movimiento en el código fuente, refactorizaciones, corrección de fallos, y en definitiva falta de madurez. Eso no es en absoluto malo ni una razón para no usarlo, pues la versión 0.4.2 es suficientemente estable y capaz para tener en producción sitios como este y muchos otros que en ImaginaWorks desarrollamos a diario. Simplemente Grails sigue cambiando porque aún no ha llegado a su madurez.Lo que pasa es que aún siendo muy joven, Grails es muy sólido y estable (por eso lo de poder usarlo en producción aún estando en la versión 0.4.2) gracias a que en realidad Grails aporta un porcentaje muy pequeño del código de Grails: la mayor parte es spring, hibernate, ant, etc. O sea, que desde que nació, Grails ya se apoyaba sobre miles de línas de código Java sobradamente probadas y estables.
Por otra parte, Rails tiene ya años de experiencia, de forma que uno espera que sea más estable que Grails, y que tener una aplicación real en producción con Rails sea una labor más amigable que con Grails. Y sin embargo no es así. Hoy he leído en el blog de Brandon Werner que Twitter (uno de los últimos booms de la web 2.0) vive al límite de morir de éxito porque, estando hecho en Ruby on Rails, resulta que no escala convenientemente para soportar una carga de trabajo tan grande.El desarrollador jefe comenta que "todos los métodos de conveniencias y virguerías sintácticas que hacen que programar con Ruby sea una delicia están pasando una factura enorme en cuanto a rendimiento".
¿Podría pasar si fuera Grails? Simplemente: NO. Una aplicación desarrollada con Grails y desplegada en Tomcat aguantará todo lo que Tomcat sea capaz de aguantar (que es mucho). La penalización de rendimiento introducida por Groovy pasa desapercibida una vez que el código ha sido compilado a bytecodes (ojo, existe penalización, pero es despreciable en orden de magnitud frente a, por ejemplo, el acceso a base de datos).Quizá en el comienzo lo de llamarlo "Groovy on Rails" fuese una buena idea, al traer un poco de "hype" que promocionase el framework, pero a día de hoy Grails es una plataforma mucho más estáble y sólida para desarrollar aplicaciones que RoR. Cometeríamos un gran error si ignorásemos que lo que hace grande a Grails no es heredar el nombre de Ruby on Rails, sino heredar la robustez y estabilidad de la plataforma Java y todas las librerías desarrolladas sobre ella.
Ibon Urrutia - miércoles 18/04/2007
Debido a un resfriado, hoy he tenido tiempo de seguir un poco la polémica sobre RoR y la escalabilidad. Me quedo con dos cosas:
- No es para tanto: hay gente que ha aportado ya muchas soluciones para dicha escalabilidad. El problema es que no son tan "ruby"ales (si se me permite el palabro), no resultan tan "elegantes" ni "sencillas", como el scaffolding al que muchos se han acostumbrado. Y eso ha asustado a algunos, pero es que se olvidan, como muy bien indicas, que Rails (e incluso Ruby a un nivel tal de popularidad) son unos "recién llegados". Vamos, que en los blogs de "ruby"eros (otro palabro), yo no hago más que ver: "consultando el svn me he encontrado con un nuevo plugin". Osea que está evolucionando. Pero han tenido muy buenas ideas, y ahí me quito el sombrero
- Los programadores no aprendemos del pasado, no vivimos en el presente y suponemos conocer el futuro :-) Me ha hecho una gracia tremenda ver las MISMAS ACUSACIONES hacia Ruby que las que había hacia Java: que si es lento, que si come recursos... Lo mejor de todo es que hace unos meses, en el primer boom de rails, en jH hubo una oleada de flames de supuestos programadores ruby (alguien realmente profesional no hace ciertas afirmaciones) que acusaban a java de lo mismo de lo que ahora son acusados ellos. Lo bueno es que los flames se han derivado ahora hacia la "guerra" PHP/Rails, algo más lógico (en JavaME todavía no he tenido un flame con nadie de Ruby :-))
Lo que me ha sorprendido, es que si creo que he entendido bien, usar un pool de conexiones en Ruby se puede hacer a través de un plugin semi-experimental (o eso es lo que he entendido leyendo la lista de rails). No sé si será cierto, pero si es así, parece que no hemos aprendido nada o no queremos aprender nada del pasado: no conzco ningún programador Java que no haya usado un pool, e incluso en Java EE usando un Datasource es el comportamiento por defecto. Parece que siempre queremos tirar todo lo "viejo", descojonarnos de los años de experiencia de ingenieros solucionando problemas, e idear lo nuevo ideal de la muerte. Y entono el mea culpa, por si alguna vez me he choteado del Cobol, C o C++ :-D
Y es aquí donde groovy me encanta: reutilizar el conocimiento adquirido durante años, usar librerías ampliamente testeadas, y además aportar innovación. Vamos, para mí la cuadratura del círculo. Unido a esto el poco hype que despierta, me hace pensar que tal vez le hace falta algo de marketing... aunque mejor pensado, casi que no, que potra vez empezarían los infinitos flames :-)
Salu2
PD: Pues amí grails me gusta por lo de Santo Grial. Y que digan que se aprovecha del éxito del "código Da Vinci" :-)