ruby - ¿Escala Scala mejor que otros lenguajes JVM?

twitter scalability

Question

Esta es la única forma en que sé preguntarlo en este momento. Como lo entiendo, Scala usa la máquina virtual Java. Pensé que Jruby también lo hizo. Twitter cambió su middleware a Scala. ¿Podrían haber hecho lo mismo y usar Jruby?

¿Podrían haber comenzado con Jruby para empezar y no tuvieron sus problemas de escala que los hicieron pasar de Ruby a Scala en primer lugar? ¿No entiendo lo que es Jruby? Supongo que porque Jruby puede usar Java, habría escalado donde Ruby no lo haría.

¿Todo se reduce a los tipos estáticos frente a los dinámicos, en este caso?

Answer 1

Hay una discusión interesante de los propios desarrolladores de Twitter en los comentarios de esta publicación . Evaluaron las diferentes opciones y decidieron implementar el back-end en Scala porque: funcionaba más rápido que las alternativas de Ruby / JRuby y sentían que podían beneficiarse del tipado estático.

Answer 2

La escalabilidad no es una capacidad de lenguaje heredado. Estás hablando de velocidad.

Una mejor pregunta sería "¿Por qué Scala es más rápido que otros lenguajes JVM (o lo es)?". Como otros han señalado, se trata de un lenguaje estático frente a un lenguaje dinámico.

Answer 3

No en realidad no. No es que la JVM sea de alguna manera mágica y hace que las cosas escalen por sus poderes mágicos; es que Scala, como lenguaje, está diseñado para ayudar a las personas a escribir sistemas escalables. Que esté en la parte superior de la JVM es casi incidental.

Answer 4

Realmente no creo que el idioma sea el mayor problema aquí. Twitter creció increíblemente rápido, lo que siempre conduce a un desorden en el código. Y si hace una reescritura, es una buena idea buscar un idioma diferente, que le impida reconstruir sus propios errores y / o "reutilizar algunas partes". Además, Ruby no está diseñado para ese tipo de manejo de datos pesados ​​que hace el backend de Twitter. La interfaz sigue siendo Ruby, por lo que todavía la usan.

Answer 5

Scala es "escalable" en el sentido de que las bibliotecas pueden mejorar el lenguaje de forma que las extensiones parezcan formar parte del lenguaje. Es por eso que los actores se ven como parte del lenguaje, o por qué BigInt se ve como parte del lenguaje.

Esto también se aplica a la mayoría de los otros lenguajes JVM. No se aplica a Java, ya que tiene un tratamiento especial para sus tipos básicos (Int, Boolean, etc.) para los operadores, una sintaxis engorrosa que deja en claro lo que está construido en el lenguaje y qué es la biblioteca, etc.

Ahora, Scala es más performático que los lenguajes dinámicos en la JVM porque la JVM no tiene soporte para ellos. Los lenguajes dinámicos en JVM tienen que recurrir a la reflexión, que es muy lenta.

Answer 6

Scala es un lenguaje estáticamente tipificado. JRuby está tipado dinámicamente. Es por eso que Scala es más rápido que JRuby, aunque ambos se ejecutan en JVM. JRuby tiene que trabajar mucho en tiempo de ejecución (resolución de métodos, etc.) que Scala hace en tiempo de compilación. Sin embargo, para lo que vale, JRuby es una implementación muy rápida de Ruby.

Answer 7

Tienes que separar los diferentes significados de escalado:

1. Escalar en términos de aumentar el número de solicitudes por segundo que se pueden manejar con un aumento proporcional en el hardware
2. Escalar en términos de crecer una base de código sin que se convierta en un lío enredado

Scala ayuda en el primer punto porque compila código byte Java que es muy similar a Java y, por lo tanto, generalmente tiene el mismo rendimiento que Java. Digo "por lo general", porque en Scala hay algunos casos en los que la Scala idiomática causa una gran cantidad de boxeo donde Java idiomático no lo haría (esto está programado para cambiar en Scala 2.8).

El rendimiento es, por supuesto, diferente al escalado. El código equivalente escrito en JRuby también se escalaría, pero la pendiente de la línea sería más pronunciada: necesitaría más hardware para manejar el mismo número de solicitudes, pero la forma de la línea sería la misma. Pero desde una perspectiva más práctica, el rendimiento ayuda porque rara vez puede escalar de forma perfectamente lineal con respecto a la adición de servidores centrales o especialmente servidores, y tener un mejor rendimiento reduce la velocidad a la que debe agregar capacidad.

Scala ayuda con el segundo punto porque tiene un sistema expresivo de tipo forzado en tiempo de compilación y proporciona muchos otros medios para administrar la complejidad de su código, como mixins. Puede escribir código de espagueti en cualquier idioma, pero el compilador de Scala le dirá cuándo se rompen algunos de los fideos, mientras que con JRuby tendrá que depender únicamente de las pruebas. Personalmente he descubierto que para mí Python se descompone en aproximadamente 1000 LOCs estrechamente relacionados, y en qué punto tengo que refactorizar para reducir sustancialmente los LOC o hacer que la estructura sea más modular. Por supuesto, esta refactorización sería una buena idea independientemente de cuál sea su idioma, pero ocasionalmente la complejidad es inherente. Tratar con un gran número de LOCs estrechamente parejas no es fácil en ningún idioma, pero es mucho más fácil en Scala que en Python, y creo que la analogía se extiende también a Ruby / JRuby.