Adopción de Rust por parte del equipo de recomendaciones de Kakao

En el equipo de recomendaciones de Kakao están desarrollando una nueva plataforma para reemplazar la plataforma existente de machine learning.

Con Python, que es el lenguaje principal del equipo, había ciertas limitaciones para cubrir al mismo tiempo el rendimiento y la seguridad de las aplicaciones.

Introdujeron Rust en una aplicación de métricas de usuario y realizaron un proceso de validación para comprobar si era adecuado implementar la aplicación en Rust.

• Rust procesó las tareas aproximadamente 1.9 veces más rápido que Python
• En uso de memoria, Python consumió aproximadamente 4.5 veces más que Rust
• El uso de CPU de Python fue hasta 3 veces mayor que el de Rust, y en promedio alrededor de 2 veces mayor
• Aplicando asyncio de Python y tokio de Rust a las aplicaciones de cada lenguaje, e implementando el procesamiento asíncrono de la misma manera en un entorno de un solo hilo, la velocidad de procesamiento de mensajes de Rust fue aproximadamente 10 veces más rápida que la de Python.

Una de las grandes desventajas de Rust fue su alto costo de aprendizaje.

Incluso al desarrollar con Python, se exigían type annotations. Al implementar la aplicación de métricas de usuario en dos versiones, no sintieron una gran diferencia en el tiempo de desarrollo entre Python y Rust.

La mayor diferencia percibida en términos de productividad fue el tiempo de compilación. (incluyendo descarga de paquetes y tiempo de Docker)

• Rust estuvo alrededor de 340 segundos
• En el caso de Python, estuvo alrededor de 100 segundos

En Python, los datos creados por bibliotecas sin información de tipos toman el tipo Any, por lo que la verificación de tipos se ignora. Esto reduce la precisión de la verificación de tipos de todo el proyecto.

También hubo diferencias como que Python usa excepciones, mientras que Rust usa un tipo enum llamado Result.

Herramientas de desarrollo
En el caso de Rust, cargo ofrece muchas funciones de forma predeterminada.
Las herramientas de desarrollo de Python estaban más maduras y, con solo instalarlas, resultaban relativamente fáciles de usar.

[jongpak]

No tengo experiencia ni con Python ni con Rust, pero leyendo solo el artículo... no logro percibir una gran ventaja en adoptar Rust.

No es que Rust sea malo, sino que los experimentos realizados para introducirlo también me parecen débiles
(me parece una argumentación muy pobre afirmar que es varias veces mejor solo porque fue varias veces más rápido al procesar apenas 50 mensajes...)

Y además, ni siquiera se comparó con la misma lógica de procesamiento (sincrónico vs. asincrónico)...
[Una librería de Python que soporta procesamiento asincrónico de mensajes pero tiene pocas referencias] vs. [el lenguaje Rust, con un costo de aprendizaje alto y el riesgo de mantenimiento al depender de pocas personas]
Al poner esas dos situaciones sobre la mesa, también me pregunto si realmente se reflexionó seriamente sobre la sostenibilidad a futuro (al menos eso fue lo que me transmitió el artículo)

Por la naturaleza de ETL, parecería que hay muchos casos en los que se necesita probar rápido y con frecuencia, así que un build time de 100 segundos vs. 300 segundos suena como un cuello de botella importante para el desarrollo...
En el artículo se menciona que el incremental build es excelente, pero ese punto se reemplaza con un hipervínculo...

Seguramente en la práctica sí investigaron y evaluaron mucho, pero al menos por lo que transmite el artículo... de verdad no queda claro en qué mejoró adoptar Rust, cuál era el efecto esperado ni qué problema resolvió, y tampoco es fácil empatizar con esa decisión...

---

En lo personal, he visto casos en los que se elige una tecnología por ser "la tecnología de moda" últimamente, o para sumar una línea al currículum, pero al final en la mayoría de los casos el equipo ni siquiera puede mantenerla y termina quedando como deuda técnica.

• Por ejemplo, cuando la carga de trabajo es pequeña y no habría absolutamente ningún problema en procesarla de forma secuencial, pero aun así alguien insiste en que hay que usar Kafka o procesamiento asincrónico
• O cuando se aplica algo porque supuestamente el procesamiento asincrónico tiene tal o cual ventaja sin considerar la situación del equipo, y el resultado es que el troubleshooting se vuelve muy difícil y al final termina siendo otro legado más....
• O cuando dicen que adoptar el ooo que está de moda trae no sé qué beneficios... pero luego aparece otro ooo todavía más de moda y entonces aseguran que ahora ese es el bueno...

Claro, no digo que el artículo sobre Rust sea necesariamente así, y espero que no lo sea...
Pero después de vivir varias veces que quien termina pagando las consecuencias de una tecnología adoptada sin una reflexión seria es el propio equipo, siento que al leer este tipo de artículos de promoción tecnológica me vuelvo más cauteloso.

[ehlegeth]

Básicamente parece una tarea de ETL, pero me gustaría saber si no consideraron Java, que junto con Python también tiene fortalezas en este dominio, y si hubo alguna razón para descartarlo en comparación con Rust.

[kayws426]

Es una pena que parte del material de comparación de rendimiento se haya obtenido mediante pruebas a pequeña escala.

[ehlegeth]

El significado de las pruebas de rendimiento cambia mucho según la naturaleza de la carga de trabajo, así que es una pena que no haya una explicación sobre cómo se diseñó la prueba o cómo se obtuvieron las cifras.
Por ejemplo, me da curiosidad saber si después de procesar 5 millones de casos se tomó un promedio aritmético con base en el procesamiento de 50 casos; si fue así, cómo calcularon el uso de memoria, y cómo se midió la diferencia en el uso de CPU. (Supongo que el tiempo será wall-clock time, ¿no?)
Además, está la interpretación de que "al observar el uso de CPU, la mayor parte de la diferencia de rendimiento entre ambos lenguajes provino del consumo de mensajes de Kafka, que es una tarea de entrada/salida (Input Output, en adelante IO), y del almacenamiento de documentos en MongoDB". Pero en los resultados se dijo que el wall-clock time de Rust fue aproximadamente la mitad, mientras que el uso de CPU (CPU time?) fue 1/4.5, así que no me queda del todo claro si se refieren a una diferencia en la forma de implementar el I/O, o a una diferencia en el proceso de manejar datos de I/O que son CPU-intensive. La lógica me cuesta un poco entenderla. En realidad, es bien sabido que Rust tiene ventajas en tareas CPU-intensive, así que si fuera lo segundo, parecería que ni siquiera haría falta mencionar la diferencia de librerías. Más bien, si en el experimento hubiera sido una tarea CPU-intensive, debería haberse visto una diferencia mucho mayor, como en la comparación de implementaciones asyncio/tokio que también se menciona en el artículo; por eso, me parece que más bien habría que interpretar que la diferencia de rendimiento fue menor debido al I/O.