Supercharging Your Tooling With Rust

Hola, amigos. Me llamo Mael. Trabajo en Eficiencia de Desarrolladores en el equipo NTDX 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 empecemos.

Antes de continuar, un poco de historia sobre el proyecto, Yarn se originó en 2016 en la versión 0.x. 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 en que lo hicimos antes.

Eso era un problema, porque tal como lo veía, necesitábamos mantener Yarn no solo ahora, sino también durante los próximos diez años. Así que en ese momento, se decidió crear una nueva versión que tomaría todo lo que habíamos aprendido sobre cómo hacer un buen gestor de paquetes y lo pondría todo junto bajo una nueva implementación del mismo gestor de paquetes. 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 resistió la prueba del tiempo. Ahora, en 2026, estamos construyendo algo nuevo. Estamos construyendo Yarn 6, la próxima gran, gran versión de Yarn, que va a estar 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 nosotros, para el ecosistema. Entonces, ¿por qué lo estamos haciendo? Y esa es una muy buena pregunta. Y 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, ahora o 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 más rápido que PMPM.

Fue un buen desafío. Pero Yarn era muy rápido haciendo instalaciones típicas. Y construir características era fácil porque conocíamos la base de código de adentro hacia afuera. Así que, todo eso hizo una buena razón por la que deberíamos quedarnos en la base de código con la que estamos familiarizados. 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 anticipamos.

Y sé lo que puedes pensar. Sí, pero mil espacios de trabajo en el mismo monorepo, eso es demasiado. ¿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, 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 techo.

En algunos repositorios, Yarn podría tener más de un segundo de latencia. No parece mucho. Pero ten en cuenta que Yarn run a menudo ejecuta subprocesos que a su vez están ejecutando otros procesos de Yarn run que a su vez están ejecutando 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. Por supuesto, solo sucede en monorepos muy grandes. Pero como dije, queríamos tener una buena UX para todos.

Otra cosa es que teníamos ideas. Queríamos construir nuevas características en Yarn. Pero algunas de ellas necesitaban un rendimiento masivo. Una de ellas, por ejemplo, es la instalación perezosa. La idea es muy simple. 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 el gestor de paquetes manejando 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 perezosas 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 asumimos 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 tan frustrante que estamos construyendo cosas que solo funcionarán si trabajas en el proyecto de JavaScript. 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 estamos escribiendo para ejecutar auditorías funcionaría en JavaScript, pero no para personas que trabajan en 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, 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 más para replantearnos cómo imaginábamos que Yarn debía desarrollarse. 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 al siguiente nivel. Preparar Yarn, no solo para los diez años que vinieron, sino también para los diez años que están 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 tuvo una reacción tan fuerte del ecosistema. La primera es que tuvo demasiados cambios disruptivos. En ese momento, sentimos que, oh, dado que somos relativamente basados en código, ahora es el momento adecuado para intentar 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-g-yarn. Seguía siendo Yarn 1.x, pero significaba que mucha gente nos preguntaba, ¿cómo instalo Yarn 2? Era muy difícil darles una respuesta directa sin realmente hacer algo que arriesgara romper a las personas que usaban Yarn 1.x. Nos quedamos así por 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 equivocarse esta vez. 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, pasando sus argumentos, pasando sus comandos, y luego verificando que los resultados en el disco sean al generar 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 súper útil para esta reescritura. Porque entonces, también podríamos 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 el conjunto de pruebas de Yarn, casi 1,400 ahora están aprobando. 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 para esta reescritura? ¿Qué aprendimos de eso? Lo primero es que involucró 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 así es como abordamos esta reescritura. Aún así, incluso en ese momento, TypeDb 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, está bien, ¿cómo se escribiría eso en Rust? Porque no sé nada sobre Rust. Y luego, a veces era realmente malo. Y luego pude 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.

Pero 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 del propio Rust. La primera es que Rust tiene buenas herramientas. Cargo es realmente agradable. Y es en realidad 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 atrapadas en el limbo. A veces estás buscando, bien, ¿cómo puedo hacer este tipo de cosas? Y luego vas a GitHub y encuentras un problema sobre alguien diciendo, sí, eso ha sido implementado, pero es experimental. Así que, no puedes realmente usarlo. Y luego miras cuándo fue la última vez que se actualizó este hilo y ves que fue, oh, hace cinco años. Y eso es bastante frecuente cuando estás aprendiendo el idioma. Y puede ser un poco frustrante.

Dicho esto, Rust fue un gran lenguaje. Previno muchos problemas de concurrencia o de 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 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 yo solo necesitaba hacerlo de otra manera. ¿Es una reescritura impulsada por 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.

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 estés preparándote, tienes que prepararte para muchos problemas al hacer eso. Dicho esto, funcionó bien en nuestro caso. Pero solo porque fuimos muy perseverantes y 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 integrarlas? Eso fue algo preocupante cuando estaba haciendo eso porque en ese momento, estaba trabajando en Datadog. 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. 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 si 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 mucho tiempo, entonces tus usuarios pueden empezar a resentir eso. En nuestro caso, esto se compensó tratando de extender la reescritura durante un largo 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 esto uno por uno y terminaríamos obteniendo algo. Pero aún así, no teníamos esos resultados al principio. Y así, fue una especie de 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 reescribirse en Rust? Desde que Bal hizo eso, NPM está haciendo eso. Están reconstruyendo parte del gestor de paquetes. Especialmente los pasos de obtención y enlace para ser Rust. Todos los gestores de paquetes 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 al respecto. Y si eres un mantenedor, te diría que Rust no es una bala de plata. No hará que todo sea mágicamente mejor. Va a venir con su propio compromiso que vamos a tener que probar cómo desarrollas, y si estás usando IA o no. Si no estás usando IA, tendrás 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 conocerás verdaderamente 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, que fue en parte impuesta por no tener buenas opciones para hacerlo en ese momento, fue la correcta.

Hicimos toda una charla sobre YARN y una reescritura. 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 NPM. Así que YARN es mucho más rápido ahora. Y aún no hemos terminado. Todavía hay frutos al alcance 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. Así que estoy seguro de que vamos a traer la velocidad, para 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 más. Y esos escenarios son importantes, porque instalar un solo paquete es algo que muchos comentarios 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 hacerlo rápido y no tener que gastar un segundo y medio haciendo trabajo va a hacer tu vida mucho mejor en el IDE mientras escribes código.

Entonces, ¿fue este proyecto la elección correcta para YARN? ¿Fue esta reescritura lo correcto? La cuestión es que construimos el gestor de paquetes que necesitábamos para la próxima década. No me imagino haciendo otra reescritura por un tiempo muy, muy, muy largo. La cuestión es, bueno, 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 ahora, quizás recuerdes que al principio de esta charla, te hablé de 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 esta historia está llegando. Todavía estamos trabajando en eso. No está completamente claro. Probablemente no será 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. Y tus herramientas deberían ser universales 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 recibir tus comentarios sobre lo que pensaste de esta charla, por supuesto, pero también de esta reescritura, si estás interesado en Rust tú mismo, si tienes preguntas, no dudes en enviarlas, y estaré feliz de responder a todo eso. Que tengas un buen día.

La cuestión es, la cuestión es, la cuestión es...