ventajas - ¿Alguien probó el lenguaje de programación Crystal(código de máquina compilado por Ruby)?
ventajas y desventajas de ruby (2)
Como muchos otros, siempre mantengo que "un compilador puro nunca existirá para Ruby porque el lenguaje es demasiado dinámico para que funcione un compilador estático".
Pero recientemente me topé con estos:
El lenguaje de programación Crystal en GitHub
Ambos proyectos parecen ser muy interesantes. Podrían darnos la velocidad de un lenguaje compilado de forma nativa (y el código ofuscado, a menudo requerido comercialmente, de un lenguaje compilado) manteniendo al mismo tiempo toda (o la mayoría) de 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? (No lo hice todavía, debido a problemas de compilación con ruby-llvm)
¿Cuál fue su sentimiento al respecto?
¿Crees que, dadas esas opciones 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 ?
Soy el desarrollador de Foundry; El segundo artículo es mío.
Un artículo más reciente sobre el mismo tema sería "Un lenguaje para desarrolladores integrados" ; o también puede seguir el progreso del desarrollo suscribiéndose a foundry-lang.org .
Tenga en cuenta, sin embargo, que mi proyecto es comercial, (al menos inicialmente) no de código abierto, y se centra principalmente en el desarrollo integrado. Todavía puede usarlo en escritorios o servidores, por supuesto.
También soy uno de los mantenedores de ruby-llvm; informe los problemas que ha encontrado como errores en la página del proyecto .
Soy el desarrollador de cristal. Actualmente no todo se implementa desde la lista de puntos con viñetas. De hecho, las clases se empezaron a implementar.
Aunque realmente me gusta la idea de ello. Pero necesito pensar más en cómo implementarlo. Y también necesito más tiempo, jeje.
El segundo artículo tiene un enfoque completamente diferente porque no introducirá un nuevo lenguaje: solo tratará de compilar un subconjunto de Ruby, o tal vez se compilará en código nativo pero aún permitirá cierto dinamismo con costos de rendimiento (hablé con El autor de ese artículo hace unos meses).
Mi sentimiento hacia ambos enfoques: realmente podría suceder. Necesitamos un lenguaje rápido con una sintaxis y biblioteca elegante, legible y divertida de usar (como lo que ofrece Ruby).