Supercharging Your Tooling With Rust

Hola a todos, mi nombre es Mael. Trabajo en Eficiencia de Desarrolladores en el equipo NGTX en Mistral.ai, y hoy quiero hablarles sobre Yarn en Rust, un proyecto al que he dedicado la mayor parte de mi tiempo estos últimos años. Les voy a contar mucho sobre ello, incluyendo por qué lo hicimos y cómo fue. Así que, comencemos.

Antes de continuar, un poco de historia sobre el proyecto, Yarn se originó en 2016 en la versión 0.x Moniker. Fue solo en 2017 que nos sentimos lo suficientemente seguros como para etiquetar Yarn como 1.x. Yo estaba allí, presioné ese maldito botón. Sin embargo, aproximadamente dos años después, en 2019, comencé a notar que habíamos aprendido tanto desde que comenzamos el proyecto que si fuéramos a crear un nuevo gestor de paquetes ahora, no lo haríamos de la manera que lo hicimos antes.

Y eso era un problema, porque tal como lo veía, necesitábamos mantener Yarn no solo ahora, sino también durante los próximos 10 años. Así que en ese momento se decidió crear una nueva versión que tomara todo lo que habíamos aprendido sobre cómo hacer un buen gestor de paquetes y lo reuniera bajo una nueva implementación del mismo gestor de paquetes. Y así nació Yarn 2. Por supuesto, esta versión vino con algunos problemas y vamos a cubrir algunos de ellos en las próximas diapositivas. Pero en general tuvo éxito, porque ahora estamos en 2016 y todavía estamos usando Yarn 2.

Por supuesto, evolucionó. Ahora estamos en Yarn 4, de hecho. Pero la base de código en sí misma ha resistido la prueba del tiempo. Y ahora en 2026, estamos construyendo algo nuevo. Estamos construyendo Yarn 6, la próxima gran, gran versión de Yarn, que será escrita en Rust.

Y ahora puedes preguntarte, ¿por qué estamos haciendo eso? Ya reescribimos Yarn una vez. Ya fue un poco doloroso para todos, para el ecosistema. Entonces, ¿por qué lo estamos haciendo? Esa es una muy buena pregunta. No puedo esperar para contarte todo sobre eso.

Primero, lo que hay que darse cuenta es que hoy Yarn es estable. Yarn es un software extremadamente estable. Es el ejemplo perfecto de no sorpresas. Si Yarn te dice que algo no funciona, entonces algo no funciona. Y al arreglarlo, no tendrás este mensaje de error en el futuro. Y tus colegas tampoco van a tener este error. Yarn es determinista hasta el extremo.

Rara vez tuvimos errores de instalación. Instalamos razonablemente rápido. Por supuesto, PMPM a veces era un poco más rápido que nosotros. A veces éramos más rápidos que PMPM. Fue un buen desafío. Pero Yarn era muy rápido en hacer instalaciones típicas. Y construir características era fácil, porque conocíamos la base de código de principio a fin.

Así que todo eso era una buena razón para mantenernos en la base de código con la que estábamos familiarizados, ¿verdad? Sí, pero de alguna manera habíamos alcanzado el techo de lo que podíamos construir con la base de código que teníamos sobre Yarn 4. Soportábamos, por ejemplo, monorepos con cientos de paquetes. Eso era genial. Pero no podíamos soportar espacios de trabajo con miles de repositorios.

Bueno, lo hicimos. Pero era mucho más lento de lo que anticipábamos. Y sé lo que puedes pensar. ¿Mil espacios de trabajo en el mismo monorepo?

¿Quién hace eso? La respuesta es que muchas, muchas empresas muy grandes están haciendo cosas así. Y no están, por supuesto, exponiendo su monorepo públicamente. Pero en privado, vinieron a nosotros y nos dijeron, oye, Mel, Yarn está funcionando bien. Pero ahora estamos empezando a sentir que se está volviendo un poco lento.

Y trabajamos con ellos para mejorar las cosas. Pero todavía enfrentábamos este límite. En algún repositorio, por ejemplo, Yarn podría tener más de un segundo de latencia. No parece mucho. Pero ten en cuenta que Yarn a menudo ejecuta subprocesos que a su vez ejecutan otros procesos de Yarn que a su vez ejecutan subprocesos.

Y si tomas todo eso de un segundo, puedes llegar a cinco, seis, siete segundos de latencia solo para ejecutar un script. Y eso es suficiente para la experiencia del usuario.

Otra cosa es que teníamos ideas. Queríamos construir nuevas características en Yarn. Pero algunas de ellas necesitaban rendimientos masivos. Una de ellas, por ejemplo, es la instalación lazy. La idea es que cuando estás ejecutando un script, si tu repositorio no está actualizado, si tus dependencias no están actualizadas, entonces el gestor de paquetes debería o tú instalar todas las dependencias faltantes sin que te des cuenta de que algo tenía que ejecutarse. Esto es especialmente importante para las personas que trabajan en un repositorio git. Porque al cambiar de una rama a otra, frecuentemente vas a tener diferencias entre tu árbol de dependencias. Y que el gestor de paquetes maneje esta tarea mental por ti significa que puedes concentrarte en lo que realmente importa.

Pero para que eso sea posible, necesitábamos que las instalaciones lazy fueran realmente rápidas para que ejecutar Yarn run no pareciera lento para nuestros usuarios porque pasarían algún tiempo instalando cosas en segundo plano. Así que queríamos que Yarn no solo fuera rápido, sino muy, muy, muy rápido. Mucho más rápido que cualquier cosa que existiera en el ecosistema. Otra razón por la que hicimos ese desafío y por la que pensamos que escribir Yarn era el momento adecuado es que siempre imaginé Yarn como un gestor de paquetes no solo para JavaScript, sino también para múltiples ecosistemas. ¿Qué pasa con Python? ¿Qué pasa con Rust?

Cuando estamos construyendo un gestor de paquetes, cuando estamos escribiendo características para ellos, es muy frustrante que estemos construyendo cosas que solo funcionarán si trabajas en un proyecto de JavaScript. Y en mi empresa, tenemos personas trabajando en JavaScript, pero también tenemos personas trabajando en Python. Otras personas trabajando en Rust. Otras personas trabajando en Go. Y cada uno de esos ecosistemas tiene un gestor de paquetes diferente. Y cualquier característica que pudiera implementar para los de JavaScript no sería utilizada por nadie más en la empresa. Y eso es algo frustrante. Porque cuando lo piensas, realmente no hay muchas razones por las que el código que escribimos para workspaces no funcionaría para personas que escriben en Python.

Y de manera similar, no hay una razón real por la que el código que estábamos escribiendo para ejecutar auditorías funcionaría en JavaScript, pero no para personas que trabajan con Go. Así que realmente imaginé un gestor de paquetes que pudiera soportar múltiples ecosistemas. Pero Node.js realmente no lo hizo fácil de hacer. Principalmente por problemas de distribución, por supuesto. Porque si estás distribuyendo Yarn en JavaScript, entonces significa que necesitas tener Node.js instalado, lo que significa que para desarrollar programas en Python o Go o Rust, necesitas tener Node.js instalado, lo cual no tiene mucho sentido para nuestros usuarios. Y luego, eso fue un incentivo adicional para repensar cómo imaginábamos que Yarn debía ser desarrollado.

Así que, por todas esas razones y más, tengo que ir rápido aquí. Sentimos que era el momento de reinventarnos, de intentar algo nuevo, de ir por el siguiente camino. Para preparar Yarn, no solo para los 10 años que vinieron, sino también para los 10 años que estaban por venir ahora. Así que, la primera vez que hicimos una reescritura en 2019, aprendimos un montón de cosas. Algo salió bien. Algunas cosas no salieron bien. Y no quería crear una nueva implementación de Yarn sin pensar cuidadosamente en el problema que enfrentamos entonces y cómo podríamos mitigarlos ahora. Ahora, hubo dos razones principales por las que Yarn 2.0 tuvo una reacción tan fuerte del ecosistema.

La primera es que tuvo demasiados cambios disruptivos. En ese momento, sentimos que, oh, ya que estamos escribiendo la base de código, ahora es el momento adecuado para intentar hacer algo, hacer las cosas de manera diferente, ¿verdad? Incorrecto. Ese no es el momento adecuado. Cuando estás haciendo una reescritura, las cosas ya son muy complicadas. Así que, si además de eso, también estás haciendo cambios disruptivos, estás alcanzando una masa crítica de dolor para tus usuarios, y ellos van a resentir eso. Ahora, el segundo problema es que hubo demasiada fricción. Parte de eso se debió a nuestro intento de hacer las cosas lo más fluidas posible para nuestros usuarios, lo cual es un poco irónico cuando piensas en eso.

Por ejemplo, realmente no cambiamos el binario que se instalaba con npm install dash nt Yarn. Seguía siendo Yarn 1.x, pero eso significa que mucha gente nos preguntaba, ¿cómo instalo Yarn 2.0? Era difícil darles una respuesta directa sin hacer algo que pudiera arriesgar romper a las personas que usaban Yarn 1.x. Nos mantuvimos así durante un largo tiempo, y solo ahora vamos a poder dar una buena respuesta a esa pregunta. Así que, eso era algo que era muy importante no hacer mal esta vez.

Ahora, ahora, ahora. También, otra cosa es que, en 2019, reescribimos Yarn desde cero. Reescribimos incluso la suite de pruebas. En 2026, las cosas son diferentes. No estamos realmente reescribiendo completamente desde cero, porque tenemos todas nuestras pruebas que escribimos en 2019 que podemos reutilizar ahora, lo que significa que es una especie de desarrollo basado en datos, porque ahora, gracias a una arquitectura de pruebas que diseñamos bien en 2019, podemos simplemente ejecutar la misma prueba exacta con Yarn 6, aunque la implementación sea completamente diferente, aunque ahora sea un binario de Rust. Nuestras pruebas simplemente ejecutan un binario, pasan su argumento, su comando, y luego verifican que los resultados en disco sean los esperados por Node.

js o el esperado, y este patrón ha funcionado tan bien para nosotros. La totalidad de nuestra prueba ha sido portátil de una base de código a otra. Eso ha sido de gran ayuda para esta reescritura. Porque entonces, también pudimos construir una interfaz de usuario ordenada para permitirnos rastrear el progreso, y voy a hablar sobre eso más adelante, pero rastrear el progreso es muy importante cuando estás haciendo un cambio de esta amplitud. Ahora, gracias a todo ese trabajo, sabemos que de las 1,500 pruebas que estaban originalmente en la suite de pruebas de Yarn, casi 1,400 ahora están pasando.

Eso es genial, porque no solo nos da una gran confianza de que la nueva reescritura va a funcionar para nuestros usuarios, también es muy motivador ver esos números subir a medida que hacemos más pares. Así que, realmente es matar dos pájaros de un tiro. Entonces, ¿cómo fue esta reescritura? ¿Qué aprendimos de eso? Lo primero es que implicó aprender un nuevo lenguaje. Sabes, el proyecto comenzó temprano durante el auge de la IA. En ese momento, no estábamos usando IA para todo, y eso cambió un poco cómo abordamos esta reescritura. Aun así, incluso en ese momento, TypedJPT y otras herramientas ya existían, y la pregunta dime cómo harías ese tipo de código, pero en Rust, ya era útil. Recuerdo que compartía frecuentemente fragmentos de JavaScript y preguntaba cómo se escribiría eso en Rust. Porque no sabía nada sobre Rust.

Y luego, a veces era realmente malo, y entonces podía ver que era muy malo, porque todavía tengo algún conocimiento común de cómo se supone que debe verse un buen código, y pude buscar más pistas en internet. Me dio pistas para entender exactamente lo que estaba sucediendo. También fue muy interesante ver mi competencia personal en Rust crecer a lo largo del proyecto. Recuerdo que en algunos casos, reescribí la misma parte de la base de código varias veces porque las escribí un mes, y luego al mes siguiente, volví a ese código y noté, oh, pero podría usar este nuevo constructo que aprendí durante esta otra tarea, y luego lo mejoré.

Eso no hizo que el desarrollo fuera más rápido, pero lo hizo mucho más divertido. También aprendí un par de cosas de Rust en sí. La primera es que Rust tiene un buen conjunto de herramientas. Cargo es realmente agradable, y es realmente un buen gestor de paquetes. Vengo de hace mucho tiempo del ecosistema de C++, y en C++, realmente no tienes un gestor de paquetes, un gestor de paquetes nativo. Tienes algunas opciones, pero todas son no estándar, lo que significa que cada proyecto está haciendo cosas diferentes. En Rust, no tienes eso, porque realmente han desarrollado un gestor de paquetes oficial, y lo están manteniendo bien, y puedes sentir eso.

Otra cosa que aprendí de Rust es que hay muchas características experimentales muy interesantes que están en el limbo. A veces estás buscando, bien, ¿cómo puedo hacer este tipo de cosa? Y luego vas a GitHub, y encuentras un problema sobre alguien diciendo, sí, eso ha sido implementado, pero es experimental, por lo que realmente no puedes usarlo. Y luego miras cuándo fue la última vez que este hilo fue actualizado, y ves que fue, oh, hace cinco años. Y eso es bastante frecuente cuando estás aprendiendo el lenguaje, y puede ser un poco frustrante.

Dicho esto, Rust fue un gran lenguaje. Previno muchos de los problemas de concurrencia o memoria compartida, especialmente mientras escribíamos más aspectos concurrentes de YARN, como, por ejemplo, obtener paquetes en paralelo o ejecutar resolución en paralelo. Todo este tipo de cosas tiene una cantidad bastante alta de peligros que podrían surgir si sigues malos patrones de código, y Rust nos permitió evitar muchos de esos problemas. Dicho esto, no vino sin costo, y requirió muchos cambios de modelo mental tratando de entender no solo cómo se suponía que debía funcionar el código, sino también cómo Rust quería que escribiéramos ese código.

La idea en Rust, por supuesto, es que el compilador te ayuda a hacer cumplir las reglas, pero esas reglas no siempre tienen sentido a primera vista, y a veces realmente tienes que pensar mucho para entender por qué el compilador se siente de cierta manera. Usualmente el compilador tiene razón, y yo estoy equivocado, pero en algunos casos, sucedió que el compilador simplemente no era lo suficientemente inteligente para hacer algo, y solo necesitaba hacerlo de otra manera. Ahora, un elefante en la habitación, ¿es una reescritura orientada a la IA? Como te dije, la reescritura de YARN se originó hace aproximadamente un año y medio, y en ese entonces, la IA no estaba donde está ahora, así que realmente usamos la IA con moderación, a diferencia de BUN, por ejemplo, que hace un par de semanas anunció que habían reescrito completamente su implementación de ZIG a BUN.

Eso no es lo que hicimos. Aquí, la mayor parte del código ha sido escrito a mano, por humanos, y considerando la complejidad de Rust, en realidad me siento bien con eso, porque dado que queremos mantener este código en el futuro, me siento más cómodo con una reescritura dirigida por humanos que hice, y que entiendo.

Dicho esto, la IA todavía se utilizó en algunos lugares, se utilizó para revisiones de código, alguna investigación sobre errores muy extraños, para que pudiéramos encontrar reproducciones, también construyendo algunas características experimentales, especialmente cerca del final del desarrollo, y portando algunas pruebas fáciles.

Ahora, estamos llegando a la conclusión de esta charla. ¿Algo salió mal durante la reescritura? Esa es una pregunta muy interesante. Cualquier reescritura es un trabajo muy difícil. Es un esfuerzo brutal. Probablemente te estés preparando, tienes que prepararte para muchos problemas al hacer eso.

Dicho esto, funcionó bien en nuestro caso, pero solo porque fuimos muy perseverantes, y que sabíamos dónde necesitábamos estar, y teníamos todas esas pruebas en las que podíamos confiar para saber dónde estábamos en el proceso de reimplementación. Otras cosas que podrían salir mal, bueno, si pasas tu tiempo escribiendo las cosas, ¿cuándo puedes realmente integrarlo? Eso fue algo preocupante cuando estaba haciendo eso, porque en ese momento, estaba trabajando en Datadog, y la cuestión es que, o estaba construyendo esta reescritura de Yarn, o estaba integrando la versión de Rust de Yarn dentro de la infraestructura de Datadog. Y hacer las dos cosas al mismo tiempo resultó muy difícil. Al final, logré hacerlo, pero requirió más tiempo del que había anticipado.

Otro problema con la reescritura es que, ¿puedes permitirte congelar tu rama principal durante varios meses, el tiempo para que realmente pases mucho tiempo trabajando en esa reescritura? Porque tus competidores no están haciendo eso. Ellos siguen sacando características, siguen corrigiendo errores, y si te quedas congelado por demasiado tiempo, entonces tus usuarios pueden empezar a resentir eso. En nuestro caso, esto se compensó tratando de extender la reescritura durante mucho tiempo, por eso tomó un año y medio, así que no congelamos completamente Yarn 4.x, y seguimos haciendo características y mejoras allí, pero puede ser un peligro, y no todos los proyectos están listos para hacer eso.

Y finalmente, el principal problema quizás de hacer una reescritura como esa es que durante los primeros meses, se siente un poco como caminar en el desierto. No tienes ningún resultado, y no estás completamente seguro de si va a funcionar. Teniendo las pruebas que teníamos, sabíamos que podíamos simplemente resolver las pruebas una por una y terminaríamos obteniendo algo. Pero aún así, no teníamos esos resultados al principio, y por lo tanto fue un salto de fe entrar en ese proyecto y esperar que todo funcionara de inmediato un par de meses después. Entonces, dado todo eso, ¿deberían todos los proyectos ser reescritos en Rust? Desde que Bion hizo eso, NPM está haciendo eso, están reconstruyendo parte del gestor de paquetes, especialmente los pasos de obtención y enlace para estar en Rust. Tienes todos los otros gestores de paquetes que están tratando de ir a Rust también. Hubo charlas sobre ESLint yendo a Rust en algún momento. Entonces, ¿deberían todos los proyectos ser Rust? Personalmente, sería cauteloso con eso, y si eres un mantenedor, te diría que Rust no es una bala de plata. No hará mágicamente mejor. Va a venir con su propio compromiso que vamos a tener que decir cómo desarrollas si estás usando IA o no. Si no estás usando IA, entonces vas a tener que estar familiarizado con cómo el compilador de Rust espera que escribas código, y eso lleva mucho tiempo. Si estás usando IA, entonces tienes que estar cómodo con el hecho de que nunca realmente conoces tu base de código. ¿Es algo con lo que estarás bien? Eso depende de ti decidir. En nuestro caso, ya que quería mantener esta base de código por un tiempo muy, muy largo, pensé que la elección que había hecho de no usar IA para hacer una reescritura completa, elección que fue en parte impuesta por no tener buenas opciones para hacerlo en ese momento, fue la correcta.

Hicimos una charla completa sobre YARN y una reescritura, pero supongo que tienes preguntas. ¿Cuáles son los rendimientos? ¿Cumplió en el lado del rendimiento? La respuesta es sí. YARN es más rápido que todo lo demás, incluyendo YARN 4.X, incluyendo PMPM, incluyendo, por supuesto, NPM. YARN es mucho más rápido ahora. Todavía no hemos terminado. Todavía hay oportunidades fáciles que no hemos tocado aún porque todavía estamos enfocados en hacer que todas nuestras pruebas sean rápidas, luego hacer la implementación en Windows, todo tipo de cosas. Estoy seguro de que vamos a reducir aún más el tiempo de instalación.

Algo más a tener en cuenta es que este no es el tiempo que mostré, o el promedio, a través de muchos escenarios, pero algunos escenarios superan. Como, por ejemplo, aquí, donde YARN solo toma menos de un segundo para hacer algunas instalaciones pequeñas, y esos escenarios son importantes porque instalar un solo paquete es algo que muchos comandos están haciendo. Cuando estás agregando, cuando estás haciendo un auto-import en VS Code, estás haciendo solo una instalación muy pequeña, así que hacerla rápida y no tener que pasar un segundo y medio haciendo trabajo va a mejorar mucho tu vida en el IDE mientras escribes código.

Entonces, ¿fue este proyecto la elección correcta para YARN? ¿Fue esta reescritura lo correcto para hacer? La cuestión es que construimos el gestor de paquetes que necesitábamos para la próxima década. No me imagino que hagamos otra reescritura por un tiempo muy, muy, muy largo. La cuestión es que la motivación y la resiliencia fueron clave para hacer que esto funcionara, y si no estás listo para hacer este trabajo arduo, entonces quizás reescribir tu proyecto en Rust no es exactamente lo que te recomendaría hacer. La cuestión es que, quizás recuerdes al principio de esta charla te dije sobre cómo YARN fue concebido para soportar JavaScript, pero no solo JavaScript, también Python, Rust, y todas las cosas.

La cuestión es que todavía estamos trabajando en eso. No está completamente claro. Probablemente no estará en la fecha de lanzamiento, pero YARN se está moviendo hacia esta dirección, y eso es increíblemente emocionante para mí porque siempre quise que el desarrollo fuera universal. Tu herramienta debería ser universal si realmente quieres poder profundizar en otros ecosistemas. La cuestión es, una última cosa, estoy escribiendo un montón de devlogs que se van a compartir tanto en BlueSky como en Twitter, y en nuestro canal de Discord, por supuesto. Así que, siéntete libre de unirte a nuestras comunidades allí, y me encantaría tener tus comentarios sobre lo que pensaste de esta charla, pero también de esta reescritura, si estás interesado en Rust tú mismo, si tienes preguntas, siéntete libre de enviarlas, y estaría feliz de responder a todo eso. Que tengas un buen día.