¿Qué tan estable es el lenguaje Groovy?

Question

Estamos escribiendo un gran sistema de producción en Java, y estoy considerando si podemos o no escribir algunos de los componentes en uno de los lenguajes dinámicos basados ​​en JVM. Groovy parece ser la mejor opción desde el punto de vista de interoperabilidad de Java. Pero, ¿es la implementación de Groovy lo suficientemente confiable como para usarla en producción (supongo que sí), y la especificación del lenguaje Groovy en sí misma es lo suficientemente estable para que no tengamos que revisar nuestro código de producción sustancialmente en uno o dos años? ¿Cuáles son tus experiencias?

Resumen (30/05/09): Buenos comentarios, la sensación que tengo es que debes tener cuidado al adoptar Groovy para el uso de producción crítica, está bien para usos auxiliares como armar casos de prueba, y hay una un terreno intermedio donde probablemente esté bien pero haga su tarea primero. El rendimiento es un problema que debe equilibrarse con el aumento de la productividad del desarrollador. Bill e Ichorus tienen respuestas igualmente útiles basadas en el uso de Groovy, por lo que fue un lanzamiento de moneda.

Actualización (12/3/09): Más recientemente he echado un vistazo serio al Scala, otro lenguaje JVM. Fue diseñado e implementado por Martin Odersky, el autor original del compilador javac actual y el co-diseñador de Java Generics. Scala es fuertemente tipado, pero utiliza la inferencia de tipo para eliminar un montón de repetición. Es una buena combinación de programación orientada a objetos y funcional. James Gosling likes it. James Strachan, el autor de Groovy, likes it too. Y la experiencia de Odersky escribiendo javac significa performance is not far from Java en bruto de Scala, lo cual es impresionante.

Actualización (26/4/11): Eche un vistazo a Groovy++, una extensión estáticamente tipada de Groovy, que tiene performance equivalente a Java. Se ve muy interesante.

Answer 1

Editar: Aquí casi cuatro años después y Groovy se ha vuelto mucho más sólido.

Lo recomiendo de todo corazón para proyectos de grado de producción.

---

He estado usando maravilloso para soportar aplicaciones de producción por un tiempo y para este propósito, es lo suficientemente estable. En cuanto a tener Groovy en código de buena fe de producción; No creo que haría eso. Groovy hace demasiadas cosas sorprendentes. Ha mejorado mucho en este aspecto durante el año pasado, pero de vez en cuando me toparé con un error que es un poco difícil de rastrear debido al código generado (mis problemas parecen haber girado en torno al alcance).

Me he alejado de Groovy (aunque las cosas que utilizamos son simples y sólidas todavía) y he usado Python (implementación de jython), que en mi opinión ha sido mucho más predecible. Además, Python supera a Groovy en legibilidad.

Puede escribir un código muy interesante en Groovy con cierres y sobrecarga del operador y otras cosas.

Estos idiomas se utilizan por comodidad y velocidad en el código auxiliar ... cosas que se pueden cambiar sobre la marcha si es necesario. Nada de eso está en producción. No creo que pondría en producción a menos que fuera una medida provisional para sacar algo crítico de la puerta con mucha prisa o como una prueba de concepto o prototipo.

Y en el caso de ponerlo en producción real, tendría que ser en las más terribles circunstancias y asignaría a alguien para reescribirlo en Java puro para la próxima versión. Estoy 98% seguro de que cualquiera estaría bien en la producción pero que el 2% es un riesgo demasiado innecesario.

Answer 2

Los lenguajes de script evolucionan "demasiado rápido" en el aspecto de las características sintácticas.

Si desea un idioma para la JVM que se quedará compatible para muchos años,
Java es su única opción;)

Por cierto, no creo que la legibilidad del código de es asegurado por un lenguaje de scripting de forma automática.

Answer 3

Tenemos varias aplicaciones de producción ejecutándose en Grails (usando Groovy como idioma). Hasta el momento, no han surgido problemas. En cuanto a la compatibilidad de JVM, observe qué tan poco ha cambiado el código de bytes de JVM en los últimos 5 años ... como se ha agregado 1 instrucción, y ninguna se ha hecho obselete.

¿Aparecerán las nuevas versiones de Groovy el próximo año? Sí. ¿Se te pedirá que cambies a ellos? No. Aunque es posible que desee, 1.6 es una gran mejora de velocidad.

Lo que nos lleva a la gran desventaja de Groovy, el problema de la velocidad. Obviamente, Groovy es más lento que Java directo. El número actual es hasta 10 TIMES más lento, para ciertas acciones. Dicho esto, ¿su CPU es el cuello de botella en su aplicación? Para nosotros, es principalmente acceso a DB y latencia. Si es lo mismo para usted, ¿qué importa si la CPU gasta 200 ms procesando la solicitud de página en lugar de 35 ms?

¿Es ese el único problema con Groovy? Nop. Los lenguajes dinámicos tienen dificultades de refactorización, ya que no existe necesariamente una especificación de clase completa en ningún lugar del código. Sin embargo, esto está parcialmente equilibrado por el tamaño de código más pequeño, lo que hace que sea más fácil encontrar los lugares para modificar el código.

De todos modos, Groovy es un lenguaje perfectamente adecuado para usos de producción. Mézclalo con Java para tu código "crítico", si temes la fiabilidad. Esa es la MEJOR parte de Groovy ... qué fácil se mezcla con las clases de Java.

Answer 4

Actualmente estoy explorando el uso de Groovy para solo pruebas de unidades de escritura. Esto tiene los efectos de

1. Permitir que la parte potencialmente tediosa de las pruebas de escritura se realice en una sintaxis que es un poco más simple que Java.
2. Mantiene el código Groovy fuera de producción.
3. Permite que una gran parte de la base de códigos se escriba en un idioma que no sea Java.

Por supuesto, aún no hemos comenzado, pero esta es al menos mi forma de intentar introducir lenguajes JVM alternativos a nuestros nuevos proyectos (y posiblemente a los ya existentes). Tengo las mismas preocupaciones que tú, y más aún con el rendimiento que con la estabilidad.

Answer 5

Usamos Grails/Groovy como nuestro backend principal en mi empresa anterior, y de esa experiencia, diría que elegiría Groovy sobre Java en la mayoría de las circunstancias que encuentro, ya que interopera con Java sin problemas y de lo contrario, más divertido y expresivo. Además, supongo que la base de datos casi siempre será el cuello de botella de mi aplicación en lugar del rendimiento del lenguaje, y no encontramos problemas de estabilidad/errores con groovy por lo que recuerdo.

Pero personalmente no suele tratarse de Groovy vs Java en la mayoría de los casos: se trata de las bibliotecas disponibles de Groovy/Java + en comparación con otros lenguajes como Python/Jython/JavaScript/Ruby + bibliotecas disponibles.Y hay muchas otras consideraciones allí como la fuerza de la comunidad, la madurez de las tecnologías relevantes para su aplicación particular, etc. En particular, para el desarrollo web, Grails era decente, pero la comunidad parecía carecer. Mi opinión general es que usaría Python o Node.js en el futuro. Si necesitaba la JVM, usaría un entorno de desarrollo web python compatible con jython.

Answer 6

He estado jugando con Groovy durante un mes más o menos. La simplicidad es increíble, y las características dinámicas del lenguaje también son geniales. Sin embargo, la velocidad es definitivamente un problema. Además, la consola groovy realmente apesta. No puede hacer cosas que puede hacer, p. en python. De vez en cuando tengo que reiniciar la consola, volver a importar, cosas, etc. También me olvido de los valores que pongo en las variables mientras estoy en modo consola; de alguna manera místicamente salen del alcance. (¿Es por JVM? No lo sé.) No puedo pensar en un ejemplo, pero el comportamiento que obtengo en la consola de Groovy es diferente del comportamiento que obtengo en la consola de Grails. y es diferente de lo que obtengo simplemente escribiendo código en un script.

Algunas advertencias más. Tenga en cuenta que Groovy es casi, pero no 100% compatible con Java. Por ejemplo, esto no se compilará:

public class HelloWorld { 

    public static void main(String args[]) { 
     System.out.println("Hello, world!\n"); 
    } 
} 

también echar un vistazo a How to get classpath in Groovy?