El artículo reflexiona sobre por qué Ruby on Rails encaja tan bien como entrada para un compilador: sus convenciones, pensadas para humanos, aportan a los modelos de IA y a los analizadores estáticos la misma información estructurada que un compilador necesita de forma gratuita. Esa misma propiedad es la que sostiene la promesa de un compilador "a tiempo de compilación" para Ruby como Spinel, creado por Matz.
El autor describe su proyecto, más estrecho que "hacer Rails rápido": el objetivo es que una aplicación Rails existente —sin reescrituras, anotaciones ni restructuraciones— pueda ser la entrada del compilador. Si el compilador necesita algo que la app no da, es problema del compilador. Esa restricción, afirma, es la única versión del objetivo que merece la pena perseguir.
Cuenta cómo, tras tres meses, un blog de demostración Rails ya transpila, compila a binario nativo y se ejecuta —mostrado en el escenario principal de RubyConf— y por qué ese capítulo está cerrado: un blog generado es un andamio con la forma que Rails pretende, no la forma que las aplicaciones reales adquieren. El siguiente objetivo es Lobsters, una aplicación Rails real, comunitaria, ya convertida en benchmark para YJIT por el equipo de infraestructura de Shopify.
Se utilizan dos carriles: un benchmark fijado a un commit concreto para medir velocidad, y un carril de conformidad que sigue el HEAD de Lobsters y ejecuta su propia suite RSpec contra el transpilado. En la última medición, el carril de Ruby emit sirve 26 de 26 rutas con un 200, a 133,3 ms frente a los 491,3 ms de Rails con YJIT (3,69 veces más rápido). El carril de Spinel sirve 10 de 26 rutas; 16 devuelven 500. En conformidad, 39 de 354 ejemplos pasan y 315 fallan; dos causas —el método Keystore.upsert no implementado y un parslet DSL que se pierde— explican 211 de los fallos. Cada fallo nombra una construcción específica sin modelar todavía, lo que convierte la suite en una lista de trabajo.