RIA: tiempo de apostar

He mencionado las Rich Internet Application a la pasada en algunas entradas anteriores. Hasta hace poco estaba indeciso a cual solución apostar entre Adobe, Microsoft, Sun, Google, etc. Ya me decidí.

Un poco de historia

Cada salto tecnológico es acompañado de avances notorios pero también de retrocesos.

De la época mainframe con terminales tontos a la época cliente servidor, se gano la capacidad de generar aplicaciones más interactivas basadas en ventanas graficas. Pero, el costo de despliegue de las aplicaciones aumento significativamente, porque había que desplazarse para instalar cada nueva versión en cada PC y era frecuente que diferencias pequeñas de configuración de Windows introduzcan incompatibilidades. Ese ultimo fue llamado el DLL Hell.

La época web permitio solucionar los problemas de despliegue: hay mucho menos versiones de browsers que configuraciones de Windows posibles y las aplicaciones se instalan en un servidor donde técnicas como el classloading de Java reducen significativamente el problema del DLL Hell. Lo que se perdió es la capacidad de hacer aplicaciones interactivas complejas como por ejemplo, tener un control fino de los movimientos del ratón.

La meta de las RIA es recuperar la interactivad usando el browser como método de despliegue. Se obtiene entonces los beneficios de todas las plataformas anteriores:

• de la web con HTML puro y del mainframe monolítico: un ambiente centralizado y controlado donde se hace el despliegue de las aplicaciones,
• del cliente-servidor: la capacidad de hacer aplicaciones clientes sofisticadas.
  

El termino es reciente pero hubieron varios intentos con distintos grados de éxito:

• las applets Java: aparte de lanzar el lenguaje a la fama, se usaron en algunos sitios de juegos en-linea como el de Yahoo. Cuando Microsoft abandono Java por .Net, no se actualizo más la versión de la JVM en internet explorer y las applets se estancaron. Además, los grandes sponsores de Java, Sun, IBM, Oracle se preocuparon más del lado servidor donde podían generar ingresos. A pesar de eso, Java y las API's J2SE son una buena plataforma para aplicaciones desktop: Eclipse, Netbeans, Azureus, Limewire demuestran que se pueden hacer aplicaciones de buena calidad grafica.

• ActiveX de Microsoft: no tuvo el efecto esperado pero permitio distribuir algunos plug-ins importantes como...
  

• Flash: tiene un gran éxito para generar contenido más vistoso que lo posible con HTML puro.

Técnicas en competencia

• Javascript, AJAX: Google con su servicio Gmail permitio revivir tecnologías que ya existían dentro de los browsers, pero que no habían sido usadas con toda su potencial. Se abre en varias alternativas:
• javascript puro, usando framework o API's como Dojo, jQuery, Prototype
• componentes en el servidor que generan el código Javascript (potencialmente, usando uno de los framework anterior),
• GWT de Google que permite compilar un programa Java basado en las API's de Google a código Javascript que se ejecuta en el browser
• seguramente, otros que no conozco
  

• las applet Java: están de retorno con nuevas facilidades que las hacen un poco más entretenidas, como por ejemplo:
  
• hacer drag de la applet para dejarla en el escritorio de Windows donde se ejecutará posteriormente como cualquier aplicación.
• el lenguaje JavaFX que es más amigable para diseñadores y tiene acceso a las capacidades de Java2D,
• API's graficas que se han mejorado en todos estos años, incluyendo mejoras de rendimiento con acceso directo al hardware
  

• Adobe AIR: gracias al tremendo éxito de Flash, Adobe tiene una buena recepción con los diseñadores web. Tiene que convencer ahora a los programadores.
  

• Microsoft Silverlight: se puede esperar muchos esfuerzos de parte de Microsoft para recuperar su influencia sobre los programadores de la capa cliente. Alguna vez Visual Basic reinaba el mundo y MS perdió este liderazgo con la web, Java y PHP.

Por gustos personales, siempre voy a preferir una solución basada en estándares. Antes de probar Adobe AIR y MS Silverlight, tendría que descartar completamente a Javascript y las applet java. A primera vista, las dos soluciones estandares tienen defectos:

• Javascript es la más compleja de todas las soluciones, partiendo por todas las alternativas disponibles, las incompatibilidades entre browsers y la falta de IDE que facilitan el desarrollo.
  

• las Applets sufren de su pasado y Sun ha generado mucho anti-cuerpo por haber abandonado un grupo de programadores que se fueron mayoritariamente a Flash.
  

Entonces, mi apuesta es:

• no a Adobe AIR y Microsoft Silverlight. No soy el único en el mundo a quien le gusta los estándares y se inquieta cuando depende de un solo proveedor: por algo Java tuvo mucho éxito
  

• dudo del retorno de las applets. Creo que va a depender de como Sun se maneja en el mundo de los celulares donde tiene que hacer un upgrade de su exitoso J2ME a una plataforma más sofisticada y compatible con el desktop: JavaFX es supuestamente para eso. Pero Sun esta cada vez más solo. Google, por ejemplo, decidio crear una platafarmo propia con Android.

• Apuesto al éxito de Javascript porque es mucho más fácil de usar de lo que creía.
  

Javascript y programación genérica en Scala

Finalmente, sigo con Scala y Liftweb para la implementación de mi proyecto de innovación tecnológica. El proyecto me permitio además incursionar en el desarrollo de componentes para aplicación web. y eso me obligo a usar Javascript y programación genérica. En ambos casos, tuve agradables sorpresas.

Javascript

La web esta llena de cuentos de horrores sobre la incompatibilidad entre los browsers y lo difícil de implementar DHTML. Tantas habían hace 5 años, que yo prohibí el uso de Javascript avanzado para el desarrollo de aplicaciones web. Yo trabajaba en una empresa grande de Chile donde me tocaba dar directrices de desarrollo y apalear a los proveedores que no cumplian: ningún proveedor me cuestiono la directriz de minimizar el uso de Javascript, así que puedo deducir que era una practica acceptada por la industria.

Obviamente, Google cambio el paradigma y demostró que se puede hacer aplicaciones complejas con Javascript en el browser. Igual, las malas sensaciones perduran y me costo hacerme a la idea que, ahora si, Javascript y DOM sirven para algo más que un "alert", exceptuando quizás, en mano de los mejores programadores del mundo. Además el hecho que Javascript sea un lenguaje tipo "dynamic typing" no me atrae porque me gusta que el compilador trabaje por mi y no al revés.

Entonces, mi recomendación de arquitectura seguía casi intacta: no se programa Javascript en el browser, se usa componentes en Java/JSF o Java/Wicket que generan el código cliente automáticamente. Mantengo esta recomendación como primera opción porque tiene un efecto simplificador dentro del equipo de desarrollo: se usa menos tecnologías. Pero, como liftweb no tiene todavía la misma cantidad de widget que wicket, no me quedo otra que crearlos yo mismo (de eso se trata mi pequeño proyecto OSS).

Y tengo que admitir, que los frameworks Javascript ayudan bastante. Liftweb usa jQuery para su soporte AJAX y esta API tiene algunos plug-ins muy buenos como el Flot y otros bastante decentes como jqTreeTable: hacer un wrapper Scala/Liftweb para usar estos plug-ins no es tan complicado. Todavía hay diferencias entre los browsers, pero las versiones modernas de IE y Firefox reclaman cuando encuentran un problema y es relativamente fácil rastrear la fuente. Una sola vez, perdí 2 horas con un detalle de MS Internet Exploerer: no es tanto.

En resumen, si el equipo de desarrollo tiene un programador Javascript avanzado, es una buena opción usar este lenguaje para crear interfaces complejas usando los plug-ins de jQuery, Dojo o Prototype.


Programación genérica

Hemos sido literalmente bombardeado de criticas sobre la implementación de generic en Java. Tantas, que hay una corriente en Java que pide "no más innovación en el lenguaje" y usa generic como el argumento del costo de hacer las cosas mal. El miedo se instalo y no se quiere avanzar.

Por mi parte, yo encuentro que usar generic en Java simplifica mucho los programas y es un avance que valió la pena. Para evitar los supuestos problemas, lo uso en forma simple como por ejemplo, iterar sobre colecciones sin tener que hacer type cast.

Ahora, me tocaba hacer un componente MVC donde a la clase de mi modelo, un árbol con nodos y hojas, le vendría bien usar programación genérica. Pero había leído las criticas de uno de los programadores de Wicket que respeto mucho y era para pensarlo dos veces. Del thread de theserverside que acabo de linkear, me llamo la atención lo siguiente:

• el numero de post que demuestra que la programación genérica en Java es un tema que anima pasiones,
• históricamente se ha echado toda la culpa al "type erasure" y algunos cuestionan esta afirmación. Además, cuestionan si la opción "type erasure" era o no era necesaria para mantener compatibilidad con versiones anteriores de java. O sea son 2 mitos importantes que fueron cuestionados.
  

Si el problema de Java reside en el "type erasure", cualquier lenguaje que compila a bytecode como Scala va a sufrir las consecuencias. Si no, quizás una mejor sintaxis como la de Scala puede permitir que humanos programen en forma genérica. De nuevo, había que poner Scala a prueba.

Y creo que otra vez salio bien parado el lenguaje. No me crean, vean el código. En mi modelo, un nodo es objeto de tipo A y una lista de hojas con nodos de tipo B. Cada hoja es a su vez un nodo de tipo B y con sub-hojas de tipo C. Fijense en el uso del underscore "_" para referirse a un tipo C desconocido:

class TreeModel [A, B] (node : A, leafs : List [TreeModel [B, _]], isCollapsed : Boolean)


No puede ser más simple, Scala es absolutamente genial.


Conclusión

Los cazadores de mitos deberían trabajar en TI. javascript en el browser no es tan difícil y la programación genérica es totalmente utilisable (por lo menos en Scala).

Lightweight vs Heavyweight

Hace poco tiempo atrás, la búsqueda del Santo Grial para las aplicaciones Java en el servidor era usar soluciones "livianas" y se consideraba que los servidores de aplicación JEE eran los campeones de la "pesadez". Era una conversación bastante confusa porque era difícil encontrar una definición clara del tema. Este blog es una retrospectiva sobre el tema.

Ciclo de vida de la búsqueda

Creo que la búsqueda de la liviandad se hizo popular porque usa los mismos términos que en la parte cliente donde el "cliente liviano" (el browser) tiene ventajas sobre las soluciones tipo "cliente pesado" ("fat client" o aplicación ejecutable Windows o Linux). Quedo en el sub-conciente colectivo que liviano es mejor que pesado.

Ahora, "pesado" dejo de ser un concepto tan negativo en la parte cliente. Las RIA consisten en dejar más pesadas las aplicaciones en los browsers, claro que no se dice "pesado", se dice "rico": es la traducción literal de "rich" en inglés que suena mal en español chileno cuando se dice "aplicación rica". Pero, se refiere a lo mismo, son aplicaciones más complejas que usan API's javascript como Dojo's, jQuery o plug-ins como Flex, Silverlight e incluso applet java ("el retorno", "java begins", etc)..

En la parte servidor no se dice "rico" sino "modular". Es aceptable que un contenedor sea "pesado" si levanta solamente los servicios requeridos por las aplicaciones que corren sobre el y, por esta razón, OSGI es tan popular.


¿Cuales eran los criterios para definir un contenedor como pesado?

Eso, nunca me quedo exactamente claro, pero leyendo comentarios de otros y en base a mi propia experiencia puedo deducir que los factores importantes en el mundo JEE eran:

• factores que afectan el tiempo de aprendizaje y tiempo para montar la arquitectura base:
• cantidad de especificaciones distintas: es casi imposible conocer "al dedo" todas las especificaciones de JEE y sus relacionadas: XML, Web Service, HTML, CSS, etc.
  
• cantidad de páginas/complejidad de una especificación. Por ejemplo, cada vez que dejo de usar un tiempo EJB Session Bean voy a leer de nuevo el capitulo de manejo de transacción y de excepciones, porque me cuesta recordar este tema y es muy fácil mandarse un condoro.
• cantidad de framework que extienden y/o reemplazan algunas API's: solamente contando los ORM (como Hibernate) y los MVC Web (como Struts) deben haber más de 100. Eso obliga a probar muchas combinaciones, para detectar incompatibilidades, lo que provoca una situación equivalente al "DLL Hell" de Windows
• cantidad de patrones necesarios para sacar provecho a la arquitectura (por ejemplo, "sesión bean de fachada", "service locator", etc)

• factores que afectan la implementación y mantención:
• Turn-around o tiempo necesario entre hacer un cambio en el código y poder probarlo, lo cual incluye:
  
• tiempo necesario para compilar la aplicación,
  
• tiempo necesario para desplegar los artefactos EJB-JAR, WAR, EAR
• tiempo necesario para arrancar el servidor,
• cantidad de capas de código necesarias para mitigar problemas/lagunas en la especificación como por ejemplo: el uso de DTO entre la capa EJB y la capa de presentación porque no se especifico que pasaba con los EJB Entity Beans despues de terminar la transacción.
  
• dependencia del ciclo de desarrollo hacia un IDE como por ejemplo, cuando algunas opciones criticas se pueden setear solamente a través del IDE del fabricante del servidor de aplicación,
  
• dependencias hacia clases o interfaces de la API, por ejemplo, obligando a extender una clase padre. De allí, nació la mítica búsqueda del POJO
  
• cantidad de clases y archivos de configuración a generar. Por ejemplo, un EJB requiere editar 3 archivos java y una entrada en XML
  
• Muchas API's relativamente de "bajo nivel" como Servlet JDBC, JMS, JTA, que obligan a generar mucho código. Curiosamente son dentro de las más exitosas.
  

• factores que afectan el ambiente de ejecución
  
• cantidad de recursos, memoria, CPU, espacio en disco usado por el servidor de aplicación,
• rendimiento, escalabilidad de los servidores: las primeras versiones no eran para nada optimizadas.

¿JEE es el gran culpable?

Los especificadores de JEE hicieron muchos errores. El método que se uso fue: especificar primero y luego ver como el mercado reacciona. Como consecuencia, se incluyo ideas, conceptos y soluciones no probadas o probadas dentro de otro contexto (por ejemplo con los monitores transaccionales en lenguaje C que precedieron).

Pero el método tuvo varios logros excepcionales:

• se formo una comunidad gigantesca alrededor de Java y JEE,
• la portabilidad de las aplicaciones no tiene equivalente en la historia de la TI. Comparamos un poco:
• SQL básico (select, insert, update, delete, más definición de tipos de datos) se resume a 50 páginas de especificación. A pesar de eso, no hay portabilidad absoluta entre los motores. Y eso sin contar la incompatibilidad completa entre las implementaciones de los store-procedure,
• Javascript, DOM, HTML es relativamente sencillo: todavía hay diferencias notables entre los browsers.
• Ruby tiene varias maquinas virtuales e implementaciones de sus bibliotecas que tienen problemas serios de compatibilidad entre si.
• las especificaciones cubren todo lo requerido por aplicaciones empresariales (el mundo Java hizo en menos de 5 años lo que tardo 30 años para lenguajes C y COBOL)
  

Entonces, estoy de acuerdo que las especificaciones JEE tienen algo de culpa, pero lograron crear un mercado que vino al rescate: Hibernate/Spring no existieran si no fuese por estos estándares. Consientes de las deficiencias, los especificadores se dedican a simplificar (desde JEE 5) y ahora, a modularizar (JEE 6).


Pero las especificaciones no son las únicas responsables. Para mi, la sensación de "pesadez" esta más asociada a las implementaciones de éstas y voy a volver a mencionar Resin porque es el mejor ejemplo que se puede implementar JEE sin crear un monstruo. Resin implementa EJB versión 2.x y a pesar de eso:

• usa menos de 30 MB en mono-usuario,
• arranca en segundos (similar o inferior a Tomcat)
  
• recarga los cambios en los fuentes sin tener que rebootearse. Detecta cambios en los fuentes Java, los recompila y genera si necesario los artefactos intermedios (como stub, skeleton, tablas de la BD).
• No requiere de un IDE e incluso de una herramienta tipo make (como ant o maven). Con jEdit (o cualquier editor que pinta la sintaxis del código) sobra y basta.
• tiene archivos de configuración XML editables por humanos.
  

Estas capacidades permite editar un fuente Java en un editor de archivo, guardar el fuente y recargar la página web: exactamente igual a lo que se hace en PHP y Ruby. Para lograr todo eso, tuvo que extender las normas JEE para el tema de despliegue de aplicaciones (no obliga a usar EJB-JAR por ejemplo). Eso no es una violación a la norma, porque permite desplegar con todo lo de la ley si se desea mantener compatibilidad.

Al otro lado del espectro esta el campeón de la pesadez, el IBM WAS y WSAD (ahora Rational Application Developper). Seguro, WAS tiene muchas cualidades como robustez, seguridad, facilidad de monitoreo, rendimiento, escalabilidad y el soporte de la empresa más importante de la historia de la TI ("nadie pierde su trabajo por elegir IBM"), pero de liviano no tiene nada. Yo creo firmemente que cuando muchos programadores piensan en lo pesado que es JEE están pensando en WAS y WSAD.


Conclusión

La pesadez en las especificaciones JEE y los servidores de aplicación que las implementan existieron. Las nuevas versiones reducen el problema gracias a la modularización (JEE6 y Glassfish v3). Las implementaciones de JEE tuvieron un rol importante en crear esta sensación.

El termino es demasiado ambiguo y es bueno que se deje de usar. Para mucha gente, pesado implica lento y dificil de escalar: ningun servidor de aplicación moderno es lento o impide la escalabilidad.


Update 13 de Agosto de 2008

Netbeans 6.5 beta y Glassfish v3 acaban de lanzar la facilidad "Compile & Deploy on Save": luego de guardar un fuente en el IDE, el ambiente (servidor de aplicacion+IDE) recompila y deploya el proyecto automaticamente Resin tiene una competencia muy seria.

Evolucione en el mundo Open Source

Antes era un usuario agradecido que trataba de convencer a otros de los beneficios. Mis únicos aportes eran reportar bugs en algunos proyectos como Resin/Magnolia y participar en algunos foros.

Ahora, tengo mi proyectito, un widget /lifweb/ para usar Flot:

• http://code.google.com/p/flot-widget-liftweb/
• http://code.google.com/p/flot-widget-liftweb-example/
  

Un poco de defensa de SOA y XML

Otras malas noticias para SOA. Ahora declaran que su uso aumenta el costo de depurar sistemas. Eso es debido al aumento en la complejidad y por el hecho que el re-uso de los servicios no se esta dando como previsto (lo que habría permitido reducir los costos).

Voy a defender SOA en esta oportunidad. Creo que el problema proviene del hecho que cualquier sistema nuevo debe interoperar con sistemas pre-existentes. La interoperabilidad es un tema complejo y antes de SOA/Web Service/REST las soluciones eran caras, propietarias y requerían de ingenieros altamente especializados: quizás por eso, no se integraba tanto los sistemas como ahora. Entonces, creo que el costo de depuración aumento porque, ahora, hay capas de código a depurar que antes simplemente no existían.


XML bajo ataque. Google introduce Protocol Buffer el cual define un nuevo IDL y un protocolo binario para intercambio de datos en reemplazo de XML. Personalmente, no creo que Google tenga mucho éxito con esta iniciativa y tampoco se si es mejor que XML para los programadores. Este articulo tiene varios links relevantes y estoy 100% de acuerdo con la entrada de Ted Neward.

SOA no deja de intrigarme

Esta semana hubo dos noticias casi contradictorias:

• solamente 20% de los proyectos SOA tienen éxito
  
• El mercado SOA va a doblar en los próximo 4 años

Lo que más atrae la atención son las razones que hacen exitosos un proyecto SOA. Aquí esta el copy/paste del primer articulo:

• Business and IT reorganization, usually with a new CIO coming on board
• Sponsorship at the C-level or by the Board of Directors
• Agile/iterative development methodologies put into place
• Projects tied to and measured by business goals, not IT drivers
• Well-defined funding and maintenance models that balance the needs of service providers and consumers
• A simplified architecture, making it easier to access and manage quality data
• A culture of trust between business and IT

Parece que son proyectos tsunami que involucran toda la empresa y crean cambios radicales. Quizás por eso hay poco éxito: porque se requiere un liderazgo técnico y comunicacional poco frecuente. Por ejemplo, el hecho que un nuevo CIO tiene más posibilidad, me suena que es gracias al tiempo de credibilidad que una persona tiene poco tiempo después de asumir un cargo; luego te pasan la cuenta por todos los errores cometidos.

El punto 3, el de uso de metodologias agiles, es compatible con la forma que abordaría este tipo de proyecto: "pensar en grande, empezar chico".

Finalmente, no se si tendré el carácter necesario, para decir "primero, Ud tiene que renunciar" a un gerente de informática.

Tranquilo, no he abandonado Java...todavía

En una respuesta a mi ultima entrada, Jorge me pregunto porque no aprendí Ruby o Python en lugar de Scala. Es una buena pregunta y voy a tratar de responderla.

Primero voy a pedir permiso para contar mi ultimo gran aprendizaje tecnológico, o sea, cuando aprendí Java. Eso fue en mis tiempos "heroicos" cuando use Java en su versión 0.93a para hacer un sitió web. En la misma época:

• no existía Microsoft Internet Explorer,
• Netscape no soportaba las applet todavía: solamente Hotjava de Sun lo hacia.
• No existían las API's Java empresariales (Servlet, EJB, JNDI, JDBC, etc).
  
• No existía JVM para Windows y mucho menos para Linux, AIX, etc.
  

Entonces, era una aplicación CGI que llamaba a la JVM desde una shell en Sun Solaris. La aplicación Java realizaba cálculos que migre desde una biblioteca C++.

Estoy contando mi historia de viejo combatiente de la programación porque creo que refleja los ingredientes que se requieren para que un lenguaje sea exitoso:

• un grupo de programadores entusiastas dispuestos a arriesgarse,
  
• una tecnología que mejora significativamente lo que había antes. Es ultra sabido que Java mejora el uso de la memoria de C/C++ y simplifica la sintaxis de C++.

Pero, faltan otros ingredientes. Mi cliente era bastante conservador para sus decisiones tecnológicas, su infra-estructura era de tipo COBOL-CICS mainframe con algunas aplicaciones no criticas en MS-DOS y nada de cliente-servidor ¿Que hizo que este cliente me aguantará una innovación tan drástica? Super simple, la web: tenían que tener el sitio ¡ahora ya! y todo era nuevo para ellos de todas formas. La web fue la "killer application" que hizo posible el gran éxito de Java..

El último ingrediente, es la comunidad de empresas que Sun logro juntar: hasta Microsoft participo en el éxito inicial.

Basado en argumentos equivalentes, este blogger cree que Java va a morir de viejo antes de ser destronado por otro(s) lenguaje(s). Creo que tiene en gran parte razón y es por eso que no renuncio a Java.

¿Entonces, porqué hago el esfuerzo con Scala? Porque, a diferencia del blogger, creo que estamos a punto de ver otra "killer application" para la cual Java tiene defectos como lenguaje. En una entrada anterior, aposte que las bases de datos van a sufrir los efectos de un escalamiento en el volumen de transacciones y este mismo impacto va a llegar a los servidores de aplicación y sus lenguajes. Por otra parte, ya no se puede aumentar la frecuencia del reloj de la CPU, pero la ley de Moore sigue vigente y ahora aumenta el número de core: vamos a necesitar multi-threading en los desktop también. Por estas razones, se va a requerir lenguajes que facilitan la programación concurrente. Y eso es un punto debil para Java:

• el lenguaje usa "monitores" basados en lock. Es un modelo que tiene limitaciones conocidas
  
• Las framework y API's vienen al rescate del lenguaje y alivian el problema en el servidor: por ejemplo EJB provee escalabilidad "a bajo costo" (el programador no tiene que preocuparse de sincronizar el acceso a metodos). Todo eso funciona, mientras no se requiera paralelizar el procesamiento interno de cada requerimiento HTTP.

El lenguaje Erlang. ataca el problema de raíz: se basa en objetos que se comunican vía mensajes y sus threads no pueden compartir estado (un objeto mutable). STM es otra técnica muy de moda también. Cuando fui a mirar ejemplos para entender los conceptos, ¡no entendí nada de nada! Erlang y Haskell (donde encontré ejemplos de STM) son lenguajes funcionales que nunca había visto antes: completamente marciano para mi. Entonces, tenia que aprender a usar programación funcional y lo mejor que encontré fue Scala. Eso porque no tenia que renunciar:

• a la orientación al objeto,
  
• a la programación genérica,
  
• al estilo imperativo (aunque entendi que tenia que dejarlo poco a poco para obtener los beneficios del lenguaje),
  
• ¡al static typing! Eso es la razón principal de eligir Scala sobre Ruby, Python o cualquier lenguaje dinámico.
• a las biblotecas Java que ya conozco (como JPA),
• a la JVM y los servidores de aplicación que mis clientes saben administrar
  

Finalmente, Scala provee mecanismos equivalentes a Erlang a través de su biblioteca de Actores y Terracota esta dando el soporte de cluster.

En resumen:

• no veo ventaja significativa usar otro lenguaje para aplicaciones web. Java, JEE, sus IDE's y sus servidores de aplicación estan ok. Excepto si los clientes piden otra solución (como .Net, PHP, Ruby, Python), me quedo con Java.
• la interoperabilidad de Scala con Java permite fasear el aprendizaje,
• La programación concurrente es el talón de aquiles actual de Java (como el manejo de la memoria lo era para C y C++),
• la tormenta de transacciones es la "killer application" para algunos lenguajes y Scala también esta posicionado sobre este terreno.