escalabilidad de Scala sobre Java

Leí un artículo que dice que Scala maneja la concurrencia mejor que Java.

http://www.theserverside.com/feature/Solving-the-Scalability-Paradox-with-Scala-Clojure-and-Groovy

... la limitación de escalabilidad se limita específicamente al lenguaje de programación Java en sí, pero no es una limitación de la plataforma Java en su conjunto ...

Los problemas de escalabilidad con Java no son una nueva revelación. De hecho, se ha trabajado mucho para abordar estos mismos problemas, con dos de los proyectos más exitosos que son los lenguajes de programación llamados Scala y Clojure ...

... Scala está encontrando formas de evitar el hilo problemático y el paradigma de bloqueo del lenguaje Java ...

¿Cómo es esto posible? ¿Scala no usa las bibliotecas principales de Java que traen todos los problemas de enhebrado y bloqueo de Java a Scala?

Bueno, por supuesto que lo hace. ¡Y Java reutiliza toda la infraestructura proporcionada por JVM, que se escribió en C, y finalmente se ejecuta en código de máquina!

El objetivo de permitir que los desarrolladores dejen que sus aplicaciones escalen no es proporcionar más potencia bruta. Assembler ya tiene toda la potencia que permite su hardware, y ningún idioma puede proporcionar más. De hecho, el objetivo de los lenguajes de orden superior es restringir lo que los programadores pueden hacer en ellos. Eso suena horrible, pero el cuello de botella al escribir un código excelente, correcto y eficiente no es el modelo de cálculo. Son los cerebros de las personas que tienen que entender los programas escritos para la máquina. La experiencia ha demostrado que no somos lo suficientemente inteligentes como para comprender la solución teóricamente óptima de un problema de computación complejo; probablemente ni siquiera lo reconoceríamos si lo viéramos.

En el ejemplo concreto, el artículo presumiblemente significa que Scala proporciona bibliotecas y conceptos de nivel superior que facilitan a los desarrolladores comprender sus problemas desde la perspectiva de la concurrencia, por lo que el resultado final es mejor y más escalable que la codificación directa en Java ( o C, o ensamblador) habría sido. Eso no contradice el hecho de que Scala se ejecuta completamente sobre una máquina virtual Java. El JVM es un invento hermoso que permite escribir todo tipo de cosas ordenadas más fácilmente de lo que sería posible sin él, incluidos los marcos y las bibliotecas que facilitan aún más las cosas complejas. Increíble, ¿no es así?

Es una cuestión de soporte de la biblioteca. Java utiliza la construcción de subprocesos de bajo nivel para representar la concurrencia (esto es como el lenguaje ensamblador del mundo de concurrencia). Hay muchas bibliotecas y técnicas que puede usar para crear soluciones escalables además de estas, como usar el soporte proporcionado por el paquete java.util.concurrent y seguir las técnicas de Brian Goetz en su libro Java Concurrency in Practice. Scala ayudó a introducir cosas como el marco de Akka (también utilizable por Java ahora) que incluye algunas de estas mejores prácticas y soporte de biblioteca. Eso no quiere decir que Java el lenguaje no pueda ponerse al día (colecciones paralelas, etc.), como dice Kilian, todo se ejecuta en la JVM y, por lo tanto, en la JMM.

Además, los objetos de Java también son mutables de forma predeterminada y requiere un conocimiento no trivial para hacerlos efectivamente inmutables. Scala supuestamente hace que sea más fácil crear objetos inmutables

¿Scala no usa las bibliotecas principales de Java que traen todos los problemas de enhebrado y bloqueo de Java a Scala?

Bueno, sí, y si bloqueas Scala te enfrentarás a los mismos problemas. Sin embargo, el punto es que no debes hacerlo, ya que Scala te proporciona abstracciones que manejan este problema de una manera más segura.

Ahora, Scala hace dos cosas que realmente ayudan. Uno de ellos es el modelo de actor, que puede considerarse como un patrón de concurrencia, proporcionado por Scala como una biblioteca. Si eres un programador de Java, te sugiero que vayas al sitio de Akka y veas sus cosas de Java. Esta es la biblioteca que reemplazará la biblioteca de actores actual de Scala, y puede usarla desde Java.

La segunda cosa que Scala hace que ayuda es usar estructuras de datos inmutables. No hay nada que evite que Java use estructuras de datos inmutables String, por ejemplo, ¡es inmutable en sí mismo! Las estructuras de datos inmutables no sufren problemas de concurrencia ya que los hilos no pueden cambiarlos.

Hay otras cosas que se suman a estas, para crear soluciones completas, como agentes y stm (ambos disponibles de Akka), o pestillos (de Java).

Ahora, las dos cosas anteriores se pueden hacer en Java, como dije yo mismo. Puede usar Akka en Java, y puede escribir estructuras de datos inmutables en Java (o usar desde bibliotecas que las proporcionan). Sin embargo, Java dificulta el uso de estas cosas, ya que no admite tipos de orden superior, ni cierres y funciones de primera clase.

Entonces, aunque puede hacerlo, los programadores generalmente no lo harán porque, en Java, escribir dicho código es muy detallado (es decir, mucho más que el estándar para Java).

El pensamiento principal del artículo referenciado es:

La limitación de escalabilidad se limita específicamente al lenguaje de programación Java en sí, pero no es una limitación de la plataforma Java en su conjunto. De hecho, cuando los programas se escriben para aprovechar adecuadamente la plataforma Java subyacente, la escalabilidad lineal no es un problema.

Si lo que necesita es una escalabilidad masiva, siempre puede aprovechar los lenguajes JVM periféricos como Scala y Clojure

No puedo estar de acuerdo con esto. Usar lenguajes JVM como Scala implica:

1. utilizando soporte de tiempo de ejecución específico. Se puede acceder a este soporte directamente desde los programas Java.

2. sintaxis específica, que permite expresiones concisas para hacer que el acceso al soporte de tiempo de ejecución sea fácil y menos propenso a errores. Esto es cierto, y escribir en Java puro es más detallado y requiere más disciplina, pero la brecha no es tan dramática.

En resumen, Scala maneja la concurrencia mejor que Java debido al uso del modelo Actor. El modelo de actor bien puede emplearse en Java. Existen varias bibliotecas de actores para Java, incluida Akka (utilizada por Scala), por lo que no es imprescindible cambiar a Scala.

El uso del modelo de actor a través de Java puro tiene sus propias ventajas:

• depuración más fácil
• posibilidad de personalizar la biblioteca de actores utilizada. Esto es especialmente cierto cuando la biblioteca es compacta y por lo tanto comprensible, como esta de la mía: df4j