¿Scala está lista para el horario estelar? [cerrado]

Ahora que he hecho algunas cosas triviales con Scala (¡que me encanta para "hola mundo" y las aplicaciones artificiales!) Me quedo preguntándome ... parte sobre la madurez de las herramientas para apoyar el desarrollo, y parte sobre la aplicabilidad general. ¿Están listos los conjuntos de herramientas? ¿Es apropiado Scala para su uso en aplicaciones empresariales / empresariales? ¿Lo "usarías" en un proyecto no trivial?

Algunas de mis preocupaciones (posiblemente infundadas) serían:

• ¿son el IDE y los conjuntos de herramientas tan ricos como lo que tenemos para desarrollar aplicaciones .net y java (eclipse para Scala parece limitado en comparación con eclipse para java)?
• ¿son los conjuntos de herramientas de construcción / CI / prueba capaces de manejar efectivamente Scala?
• ¿ Qué tan fácil de mantener es el código conciso que se puede (animar) escribir en el idioma?
• ¿Es posible encontrar desarrolladores con experiencia en Scala?
• ¿Hay suficiente masa crítica para obtener ayuda a través de referencias en línea y libros que son más que una "introducción" al idioma?

Entonces, ¿es el ecosistema lo suficientemente maduro como para usarlo ahora, o mejor esperar a ver cómo evoluciona?

EDITAR: digamos que "no trivial" es un proyecto de desarrolladores de 10-20 de varios años y varios lanzamientos.

Si bien es cierto que Scala se ha utilizado en la naturaleza en The Guardian y en Twitter, existe una preocupación fundamental.

Gran parte de la popularidad de Java proviene del hecho de que es relativamente fácil de leer y mantener. Scala tiene un problema aquí, ya que se puede escribir en muchos estilos diferentes. El estilo OO frente al estilo funcional es la división obvia aquí, pero se vuelve más complicado cuando se habla de los 3 niveles de Scala .

Debe asegurarse de que su equipo y las posibles nuevas contrataciones puedan seguir el mismo estilo, y que el estilo sea lo suficientemente simple como para que pueda contratar desarrolladores que puedan ser efectivos (no todos pueden contratar el 2% superior) .

El soporte de herramientas tampoco está del todo disponible, aunque espero que esta brecha se cierre con bastante rapidez. También puede obtener soporte para la pila Scala completa de la multitud de TypeSafe . Creo que Scala forjará su nicho, pero hasta que los niveles estén realmente integrados en el lenguaje / compilador / lo que sea, veo un dolor de cabeza de mantenimiento en los equipos después de los primeros 1-2 años de productividad excitada.

Vea esta respuesta relacionada para más detalles.

Scala es utilizado actualmente por Twitter y por The Gaurdian, por lo que ciertamente está listo para aplicaciones no triviales.

Los programadores de Scala estarán muy motivados y probablemente muy buenos. Elegir un nuevo idioma es una excelente manera de atraer talento.

Por supuesto, los programadores de Scala a menudo no tendrán experiencia profesional en Scala, y puede haber alguna variedad en los modismos que usan. Algunos pueden luchar por la pureza tipo Haskell, mientras que otros pueden verlo como Java con cierres. Por lo tanto, probablemente llevará algún tiempo desarrollar estándares y convenciones de codificación consistentes.

Muchas herramientas Java funcionarán bien, aunque IntelliJ Idea probablemente valdrá la pena la inversión sobre Eclipse.

En general, podría ser una buena opción si tiene control sobre el proyecto. Si esto es parte de una gran compañía de seguros, puede tener problemas si existen pautas arquitectónicas como: 'Todos los proyectos deben ser construidos por Maven y desplegados en WebSphere'. (No tengo ninguna razón para pensar que esta regla en particular sea un problema, pero una proliferación de tales reglas podría hacer que te tropieces en algún momento).

Mi impresión es que gran parte del ecosistema que viene con lenguajes "convencionales" (como Java) está destinado a compensar su torpeza.

La pregunta no es cuántas herramientas hay para un idioma determinado (Scala), sino si las herramientas existentes para ese idioma son mejores que las herramientas existentes para el lenguaje de referencia (Java). Debido a que 100 herramientas mediocres no te darán, una buena herramienta puede darte. Y una cosa que no debe olvidar es que el lenguaje en sí es parte de esas herramientas.

La declaratividad de un idioma.

• es inversamente proporcional a la cantidad y gravedad de los errores que produce con él, por lo que Java es tan bueno para producir errores y necesita muchas herramientas para evitarlos y rastrearlos
• es proporcional a su productividad, por lo que Java es tan extremadamente detallado y necesita muchos generadores de código y herramientas similares

Por ejemplo, una vez leí una horrible publicación de blog de un tipo de Ruby, quien argumentó que la escritura estática no tiene sentido, porque sus pruebas cubrirán la seguridad de los tipos. Esto claramente vino de alguien que aún no había trabajado con un sistema de tipo estático expresivo. Suponiendo que puedo representar todas las relaciones de tipo en una semántica del lenguaje y que no es mucho trabajo (y no lo es, ya que la mayoría de los idiomas modernos admiten inferencia de tipos), obtengo todo esto de forma gratuita.

Para impulsar un pensamiento un poco más: las pruebas unitarias aseguran que una unidad actúa como se especifica o, para reformularla, las pruebas unitarias son especificaciones ejecutables. Sin embargo, a través de la programación declarativa, las unidades mismas son especificaciones ejecutables. De nuevo, obtienes algo gratis.

Lo que intento decir es que no debes subestimar lo que las características del lenguaje pueden hacer por ti. Y a menos que realmente los pruebes en el campo, nunca lo entenderás.

Entonces, volviendo a la pregunta original: ¿son las herramientas existentes para Scala mejores que para Java? Difícil de decir. Depende de lo que quieras hacer. Creo que todos estaríamos de acuerdo en que el idioma es significativamente mejor, ahora la pregunta es qué tan bueno será el ecosistema que encontrará en su área de negocios.
Para la web, Lift realmente es una opción sólida para ir. No sé sobre computadoras de escritorio o dispositivos móviles.

Digamos que "no trivial" es un proyecto de desarrolladores de 10-20 años, de lanzamiento múltiple y de varios años.

Esos son muchos riesgos. Las recompensas tendrían que valer la pena. En el mundo de las aplicaciones empresariales empresariales y los proyectos de tamaño medio a grande, la toma de riesgos suele ser limitada. O, más bien, ya hay suficiente riesgo para tratar ... La previsibilidad es más importante.

Dudo que la adopción funcione de esa manera.

Es más probable que comience como un puñado de personas que trabajan en una parte donde el riesgo está contenido, como POC, componentes no críticos, pruebas o partes en las que Scala parece abordar el problema mucho mejor que las alternativas (tal vez si algo involucra actor, por ejemplo) ... Luego, a medida que las herramientas maduran, la comunidad crece, el conocimiento crece en la empresa, entonces podría expandirse.

Al aprovechar el tiempo de ejecución de Java, Scala ciertamente está listo para el horario estelar. Si puede implementar una aplicación Scala, una vez que se genera el código de bytes, siempre debería funcionar con esa versión particular del tiempo de ejecución de Java. La biblioteca basada en Scala funcionará como cualquier otra biblioteca de terceros de Java con la que esté familiarizado.

En términos de IDE, herramientas de construcción y todo lo demás, Scala no tiene el mismo nivel de proliferación que Java. Por lo tanto, no tiene muchos marcos basados ​​en Scala o herramientas basadas en Scala. Eso tiene más que ver con la popularidad de Java que con la creciente popularidad de Scala. Scala tiene herramientas funcionales que incluyen Scala IDE y sbt, herramienta de compilación. Pero no son tan sofisticados como algunas de las otras herramientas de ayuda Java puras que existen.

Puntos de recogida de cerezas de @huynhjl y @FarmBoy:

• Encontrar un número suficientemente grande de programadores Scala con experiencia podría ser difícil.

• El dogma de la "mejor práctica" para Scala todavía está evolucionando (*).

• Las guías de estilo, convenciones, etc. todavía están evolucionando (*).

• El soporte de herramientas todavía está evolucionando (*).

Reuniendo estos, tal vez una mejor pregunta para usted (usted mismo) es si su organización está lista para usar Scala en un proyecto "no trivial". ¿Tiene la gente que puede hacer un gran proyecto con tantas cosas "en evolución"? Por el contrario, ¿sería mejor hacer un proyecto más pequeño primero?

(* De hecho, la mayoría de los idiomas todavía están evolucionando en uno o más de estos aspectos. El problema aquí es la tasa de cambio / flujo ... y si su equipo puede manejarlo).

David Pollak en Good Stuff tiene una excelente publicación en el blog titulada Los lenguajes funcionales regirán (pero no este año) que entra en el meollo de los lenguajes funcionales en general, y Scala en detalle que recomiendo leer para comprender mejor si Scala está lista para el horario estelar.

Nunca entendí la distinción entre enterprisey non enterpriseprogramas.

Yo uso los mismos programas en el trabajo que en casa. No usaría un programa mediocre en mi tiempo libre, ¿por qué debería hacerlo?

¿Qué es un programa no profesional? He visto que se han utilizado aplicaciones deficientes, porque el usuario no sabía mejor, debido a problemas de compatibilidad, o el usuario se negó a aprender algo nuevo.

Pero es un problema de software desactualizado y de objetivos que el desarrollador tenía en mente, no del lenguaje en el que estaba escrito el programa. Si comienza a pensar, en qué idioma está escrito un programa, ya terminó: fallar.

Enterprise-aplicación es un término marekting, que no es útil para una discusión seria.

¿Y qué cliente sabe en qué idioma has hecho tu trabajo? A veces les importa, a veces no.

Es posible que tenga preguntas relacionadas con la madurez de un idioma, pero no puede responder la pregunta para todo tipo de empresas y todas las aplicaciones.