Una de las críticas más habituales que se hace a Ruby es el pobre rendimiento del intérprete Ruby frente a otros lenguajes rivales. Las cifras indican que por lo general para un mismo algoritmo el intérprete de Ruby ofrece un menor rendimiento que Python, PHP, Perl, ponga su lenguaje favorito.

La respuesta comunmente aceptada para esta penalización de rendimiento suele ser que Matz es un gran diseñador de lenguajes pero su labor como implementador no es tan brillante. El intérprete de Ruby escrito por Matz, conocido como MRI (de Matz Reference Implementation, o Implementación de Referencia de Matz) adolece de no pocos problemas (hay quien afirma que un lenguaje como C no es buena elección a la hora de implementar lenguajes dinámicos)

En todo caso, la comunidad de Rubistas (con Matz a la cabeza) hace tiempo que ha asumido el problema de rendimiento en la MRI y han surgido no pocos proyectos para corregir esta deficiencia. Uno de los problemas con los que se enfrentan los valientes que desean implementar un lenguaje es que, a diferencia de esfuerzos recientes como Perl 6, el lenguaje Ruby no dispone de una especificación funcional. Por tanto, la única fuente fiable de documentación sobre los entresijos del lenguaje Ruby es el estudio del código fuente en C del intérprete escrito por Matz (de ahí el nombre MRI)

YARV

El primero de estos esfuerzos es, por derecho propio, YARV de Sasada Koichi, la reimplementación de Ruby usando su propia máquina virtual y un compilador a código de bytes. El trabajo de Sasada Koichi, basado en un enfoque más moderno que la implementación de Matz, es tan brillante que la versión oficial 1.9.1 de Ruby estará basada en YARV. Aquí hay una serie de gráficos que muestran las mejoras de rendimiento de YARV frente a la MRI. Como puede verse, aún hay algún trabajo por hacer pero cabe destacar que, por lo general, una aplicación Rails verá mejoras de rendimiento del 15% sólo por usar YARV.

Como se ha visto, YARV divide el problema de la implementación del lenguaje en dos etapas: un compilador de código de bytes y una máquina virtual que ejecuta dicho bytecode. Surge de manera natural la pregunta de si no sería posible usar alguna máquina virtual ya existente y generar bytecode compatible con ella. Y, hablando de máquinas virtuales, la de Java está más que probada.

Ruby en Java

De aquí surge JRuby, que consiste en escribir un intérprete Ruby escrito en Java. Inicialmente un proyecto con pocos visos de ver la luz, al cabo de año y medio -y probablemente gracias al apoyo de Sun- en la actualidad es posible (como ya hemos visto) ejecutar aplicaciones Rails dentro de un contenedor de aplicaciones Java, lo que da una idea de la madurez del proyecto. La versión para Ruby de Netbeans soporta JRuby por defecto. Una de las ventajas de ejecutar Ruby en una máquina virtual de Java, por supuesto, es tener acceso a código ya existente escrito en Java lo cual hace a JRuby la implementación ideal para integrar Rails en entornos enterprise. Otra ventaja es que JRuby por definición se verá beneficiado de las mejoras posteriores que se realicen en el intérprete Java.

Y si JRuby es un intérprete de Ruby escrito en Java, XRuby es un traductor de Ruby a bytecode de Java (o lo que es lo mismo, de un fichero .rb generará un .class) Este traductor está basado en ANTLR. Aun en sus etapas iniciales, XRuby ya es capaz de generar bytecode Java para toda la librería estándar de Ruby y para Ruby on Rails 1.2.x

Rubinius

El siguiente en la lista esRubinius. El enfoque de esta iniciativa consiste en escribir la mayor parte del lenguaje en Ruby y dejar que la máquina virtual -escrita en C- ejecute el menor subconjunto posible de funcionalidad. En concreto, Rubinius pone el énfasis en el recolector de memoria y la implementación de forks y threads. A destacar que Rubinius parece surgir del mundo Rails (Evan Phoenix trabaja en Engine Yard, proveedores de alojamiento avanzado Rails) por tanto buena parte de las mejoras que promete en el intérprete atacan a los problemas de rendimiento que más pueden aquejar a nuestras aplicaciones Rails.

Ruby sobre .NET

Por supuesto que si hablamos de implementar Ruby sobre máquinas virtuales ya existentes sería pecado olvidarse de Microsoft. Microsoft, ya sea de manera oficiosa u oficial, ha estado detrás de dos proyectos.

El primero es Ruby.NET. Se trata de un proyecto de código abierto impulsado por Wayne Kelly y John Cough de la Queensland University of Technology (en Australia) y parcialmente financiado por Microsoft. Sin embargo, según los propios autores, la tarea de soportar RoR aún no está lista para su lanzamiento público.

IronRuby es la segunda implementación de Ruby sobre .NET más interesante quizá porque surge de un desarrollador de Microsoft, John Lam. Lam se ha basado en el Dynamic Language Runtime , originalmente pensado para Python y LISP. Parece ser que el desarrollo de IronRuby ha sido lo suficientemente complejo como para justificar cambios en el propio DLR oficial de Microsoft para acomodar a Ruby.

Si bien los esfuerzos en .NET como vemos parecen estar más verdes que sus equivalentes en Java, conviene tener en cuenta -sobre todo si desarrollamos sobre Windows- a estos dos proyectos.

Conclusión

Es evidente que vivimos tiempos interesantes. Si a un lenguaje que, no olvidemos, ya es suficientemente rápido como para ser competitivo por derecho propio le añadimos las mejoras y optimizaciones que están ahora mismo en los laboratorios de los desarrolladores arriba mencionados sólo pueden venir buenas noticias.

¿Ruby sobre C? ¿Sobre Java? ¿ Sobre .NET? ¿Ruby sobre Ruby? ¡Elige tus armas!