Noticias de Ruby Kaigi 2008: Estandarización

Estandarización

Yukihiro "Matz" Matsumoto expresó su intención de estandarizar a Ruby. El esfuerzo de estandarización será dirigido hacia la intención de mejorar la compatibilidad entre las diferentes implementaciones de Ruby, tales como JRuby y IronRuby, y facilitar el paso de Ruby hacia el gobierno japonés, que en el 2007 anunció guías sobre el uso de estándares abiertos (open standards) en lugar de productos específicos. Matz planea entregar el estándar a la organización ISO (International Organization for Standardization); sin embargo, no se ha definido una fecha concreta de cuándo esto sucederá, solo que "podría tomar, por lo menos, un par de años".

El Camino hacia Ruby 1.9x

El segundo día de la conferencia, Koichi Sasada—el creador de YARV—mostró un mapa para Ruby 1.9x y anunció sus planes para soltar la versión estable 1.9.1 en Diciembre de 2008. La versión corriente Ruby 1.9.0 fue siempre con la intención de ser usada para desarrollo [experimental], mientras que la versión 1.9.1 está planeada para ser la primera versión estable de la serie 1.9, y por lo tanto, se podrá usar en producción. En el mismo día, salieron las siguientes versiones actualizadas: 1.9.0-2, 1.8.7-p22, 1.8.6-p230, y 1.8.5-p231.

El plan para la versión 1.9 es como sigue:

* Julio 25: 1.9.0-3
* Agosto 25: 1.9.0-4
* Septiembre 25: 1.9.0-5 (feature freeze)
* Octubre 25: 1.9.0-6 (1.9.1 RC1)
* Noviembre 25: 1.9.0-7 (1.9.1 RC2)
* Diciembre 20: 1.9.1

El Siguiente Ruby

Koichi Sasada habló sobre las características posibles que se implementarían en versiones futuras de Ruby.

* Soporte para máquina virtual múltiple (MVM, Multiple virtual machine) de Ruby, por ejemplo, para poner a Ruby en los teléfonos celulares.
* Ruby Atómico: Poder compilar Ruby con los módulos necesarios solamente. Ruby Atómico se enfoca hacia los dispositivos embutidos (embedded).
* Byte Code Serialization: Como tecnología que permita Ruby Atómico, byte code serialization puede ser útil; puesto que no hay necesidad de analizar el código fuente, el parser no se requiere y se puede excluir de la compilación si se incluye el código serializado completo. Esto puede resultar ser útil para controladores de microprocesadores en dispositivos caseros o para distribuir el código hacia otros nodos de un cluster.
* Traductor de bytecode a C: usando la generación de código fuente a partir de bytecode se pueden aplicar optimizaciones que ya se conocen en compiladores C y facilitar plataformas que no tengan una implementación de Ruby.
* Optimización para números de punto flotante se puede tratar como un valor inmediato en máquinas de 64 bits: Comparado con el método de asegurar el número de punto flotante en la heap, esto permite reducir a la mitad la cuenta y hacerlo más rápido así como disminuir el número de actividades del colector de basura (garbage collector, GC). Estudios han demostrado que esto casi que duplica la eficiencia de la aritmética de punto flotante.
* Repasar la asignación de memoria (Memory Allocator) y el colector de basura (GC): Puesto que el costo del GC y la asignación de memoria ha aumentado con la introducción de YARV, parece válido considerar un GC en tiempo real o un GC compacto.
* De-optimización efectiva: En respuesta a la recarga de clases (class reloading) y la redefinición de métodos, el código compilado por JIT se puede restaurar para ser luego modificado.

Referencia:
http://www.infoq.com/news/2008/07/rubykaigi