Como muchos otros, siempre mantengo la verdad de que "nunca existirá un compilador puro para Ruby porque el lenguaje es demasiado dinámico para que funcione un compilador estático".¿Alguien probó el Lenguaje de programación de Crystal (código de máquina compilado por Ruby)?
Pero recientemente me topé con estas:
The Crystal programming language at GitHub
Ambos proyectos parecen ser muy interesante. Podrían darnos la velocidad de un lenguaje nativo compilado (y el código ofuscado, a menudo requerido comercialmente, de un lenguaje compilado) al tiempo que conservan (o la mayoría) la elegancia y flexibilidad de Ruby. Agregue una buena biblioteca de soporte (o, más probablemente, la posibilidad de acceder a las bibliotecas C++ existentes) y podrá comprender fácilmente por qué esto podría ser interesante.
¿Alguien ha probado el lenguaje Crystal? (aún no lo hice, debido a problemas de compilación con ruby-llvm)
¿Cuál era su sensación al respecto?
¿Cree que, dadas esas elecciones de diseño, sería realmente posible desarrollar un compilador de código nativo (código de máquina) para Ruby (con un esfuerzo razonable y en un tiempo razonable)? ¿Sería significativo?
¿Cómo puede un compilador no ser significativo si es correcto? – Marcin
Sería significativo (es decir: _useful_) _desarrollar_ tal compilador, por supuesto. ¿Cómo podría ser tan idiota para pensar que el propio compilador? No podría ser significativo (es decir: correcto). – AlexBottoni
Según se informa, JRuby funciona tan rápido como cualquier otra aplicación de Java (peso por peso). Solía usar Smalltalk, y pensé que era "lento" ...Sin embargo, de hecho fue el IDE que tuvimos el retraso. Los módulos reales de Smalltalk se usaron a partir de los tiempos de ejecución C y C++. Lo que estoy diciendo es que los lenguajes esotéricos pueden ser rápidos; es la transpiración del 99% que Edison mencionó. – will