¿Qué significa que Ubuntu esté usando Rust?

• La adopción de Rust por parte de Ubuntu muestra que Rust, dentro del ciclo de adopción tecnológica, está pasando de los early adopters a la etapa principal tras cruzar el abismo
• Canonical adoptó Rust como lenguaje predeterminado para nuevo software base, reemplazando usos de C, C++ y parte de Python, e invierte en el desarrollo de utilidades con seguridad de memoria tanto en dinero como en reputación
• Como los usuarios de la mayoría temprana (Early Majority) quieren "estándares de la industria" y compatibilidad con flujos de trabajo existentes, reemplazar utilidades de forma drop-in es una estrategia clave para cruzar el abismo
• Volvió a surgir el problema de ampliar la biblioteca estándar de Rust, y se reevalúa que el concepto de "Rust Platform", rechazado en 2016, podría en realidad ser adecuado para la mayoría temprana
• Una estructura que conecte la adopción con la inversión y la inclusión basada en empatía dentro de la comunidad open source son esenciales para la siguiente etapa de crecimiento de Rust

---

Cruzar el "abismo" de Rust varía según el área

• Que Rust haya cruzado el abismo dentro del Technology Adoption Life Cycle depende del área
• Dentro de Amazon, Rust ya está firmemente establecido para construir grandes data planes o agentes con conciencia de recursos, pero todavía existe la percepción de que es excesivo para el desarrollo general
• En el área de Safety Critical Software hay casos exitosos, pero la mayor parte de la industria sigue en modo de espera

La importancia de los "clientes de referencia"

• La clave para cruzar el abismo es conseguir clientes de referencia (reference customers)
• Los adoptantes tempranos compran al agente de cambio (change agent), pero la mayoría temprana quiere mejorar la productividad de las operaciones existentes y minimizar la discontinuidad
• Ver que una organización similar a la propia tuvo éxito es el factor más convincente para adoptar una nueva tecnología
• Un ejemplo de esto es que el éxito de Rust en el equipo de S3 resulta convincente para equipos de servicios a gran escala, pero no persuade de forma directa a equipos de servicios CRUD

La estrategia de adopción de Rust en Ubuntu (Canonical)

• En Rust Nation, el VP of Engineering de Canonical, Jon Seager, presentó la keynote "Rust Adoption At Scale with Ubuntu"
• Canonical había limitado sus lenguajes de desarrollo interno a Python, C/C++ y Go, pero recientemente añadió Rust y lo adoptó como lenguaje predeterminado para nuevo trabajo de base
• De forma similar a la keynote de Lars Bergstrom sobre la adopción de Rust dentro de Google, es un enfoque que combina visión y pragmatismo
  • Esa es precisamente la característica necesaria para pasar de los adoptantes tempranos a la mayoría temprana

Inversión en utilidades con seguridad de memoria

• Jon Seager mencionó que Ubuntu debe apoyar la creación de utilidades basadas en seguridad de memoria como una forma de "pay it forward"
• Canonical está financiando el desarrollo de sudo-rs y ntpd-rs de la Trifecta Tech Foundation, así como el trabajo de uutils en coreutils
• La idea es que Ubuntu pruebe y valide primero cosas nuevas para que luego otras distribuciones puedan beneficiarse
• Las utilidades drop-in que encajan directamente en los flujos de trabajo existentes cumplen con la necesidad de la mayoría temprana de minimizar la discontinuidad

Lo que piden los nuevos adoptantes: ampliar la biblioteca estándar

• Durante una cena, Jon Seager dijo que habría que revisar la política de biblioteca estándar pequeña de Rust
• Es una demanda que se repite desde hace años y, más que ofrecer simplemente una biblioteca estándar grande, se está pensando en una alternativa en forma de proyecto llamada "Battery Packs"
• La Rust Platform propuesta en 2016 —la idea de reconocer ciertos crates como una biblioteca estándar ampliada— fue rechazada en ese momento por los adoptantes tempranos, pero ahora se reevalúa como algo que podría ser apropiado para la mayoría temprana
  • En aquel entonces predominaba la idea de que bastaba con agregar dependencias en Cargo.toml

La necesidad de cambiar para crecer

• Para pasar de los adoptantes tempranos a la mayoría temprana, hace falta un mensaje de "estándar de la industria" y no de "state-of-the-art"
• Rust tuvo éxito en ganar reconocimiento dentro de la industria, y ahora debe convertirse en la mejor opción no por "lo que podría llegar a ser", sino por "lo que realmente es"
  • A veces estas dos cosas pueden entrar en tensión
• Para hacer marketing a pragmáticos se necesita paciencia, comprensión de los problemas de esa industria y asistir a conferencias del sector

Una estructura que conecte la adopción con la inversión

• La expansión de la adopción de Rust va acompañada de un aumento en la demanda sobre el proyecto Rust y su ecosistema
• Para organizaciones open source como Canonical, más importante que los $$ es construir relaciones y contribuir entre organizaciones
  • Los desarrolladores de Rust for Linux al principio recibieron ayuda de los maintainers de Rust, pero gradualmente empezaron a corregir errores por cuenta propia y los maintainers pasaron a un rol de mentoría
• Una tendencia interesante es que el financiamiento muchas veces proviene no de empresas que ya adoptaron Rust, sino de empresas que están evaluando adoptarlo
  • Los early adopters internos impulsan la adopción dentro de su organización y asignan presupuesto al desarrollo de capacidades "table stakes"
• Según Alexandru Radovici, del Rust Foundation Silver Member Directory, muchas empresas de software crítico para la seguridad tienen fondos para cubrir las brechas de Rust, pero no saben cómo utilizarlos

El rol del open source y la importancia de la empatía

• El open source es una excelente plataforma para cruzar el abismo, pero los grupitos (cliques) y las "tradiciones orales" pueden convertirse en barreras de entrada
• Una idea puede ser rechazada por usar la terminología equivocada, o una sola respuesta grosera puede hacer que un nuevo colaborador se retire
• Lo que más necesita Rust para su siguiente etapa de crecimiento es empatía en el open source (Empathy in Open Source)
• La clave es ir a los lugares donde Rust puede ayudar a las personas, apoyarlas y darles herramientas para que puedan avanzar

[GN⁺]

Comentarios de Hacker News

• Que Ubuntu use userland con licencias no GPL significa que podría permitir más TiVoization dentro del ecosistema Linux
  Si se combina con la dirección que impulsa Amutable del lado de systemd, podrían aparecer distribuciones Linux cerradas que el usuario no pueda modificar
  Desde la perspectiva empresarial, un entorno cerrado con verificación total de firmas puede resultar atractivo. La idea de un mundo donde hasta “ls” o “cd” sean de código cerrado se siente curiosamente apocalíptica

  • No es que util-linux o BSD vayan a desaparecer. Si no te gusta Ubuntu, simplemente no lo uses. Debian siempre fue mucho más estable
  • En realidad hay una razón por la que se le llamaba GNU/Linux. Android/Linux tampoco usa userland GPL, y la mayoría de los competidores en embebidos tampoco. Al final, Linux es solo el kernel
  • Viéndolo históricamente, quizá yo sea ingenuo, pero no creo que este cambio sea necesariamente malo. Prefiero las utilidades open source, pero también me parece bien que existan alternativas cerradas que respeten las especificaciones. Las empresas incluso podrían invertir más dinero en proyectos open source de esa forma
  • Sinceramente, Ubuntu me parece como el Apple de Linux, compitiendo más con marketing que con calidad. La familia Debian se usa porque cuesta poco mantenerla, y personalmente creo que Fedora y OpenSUSE son el futuro
  • Si este cambio hiciera que el 95% de los usuarios de Linux terminara usando el mismo OS, quizá tampoco sería algo tan malo

• El verdadero abismo (chasm) que Rust tiene que cruzar es el soporte de enlace dinámico con un ABI seguro
  Solo cuando se pueda modificar una librería manteniendo la seguridad y logrando estabilidad ABI al nivel de C, Rust podrá adoptarse de verdad en el mundo C/C++

  • Rust ya puede comunicarse mediante ABI de C. Ofrece enlace dinámico al mismo nivel que C++
  • La estabilidad ABI de C++ es uno de los principales factores que frenan la evolución del lenguaje. No se puede cambiar el layout de clases del STL, y los templates implementados en headers luego son difíciles de optimizar. Rust no debería soportar ese tipo de “stable ABI”
  • La eficiencia de Rust depende de la monomorfización en tiempo de compilación. Para construir un ABI, habría que considerar especialización en tiempo de enlace. No se trata solo de mover la generación de código al linker, sino de tratar con cuidado la “forma (shape)” de los parámetros de función
  • El enlace dinámico también ayuda a reducir tiempos de compilación en builds de depuración. Las librerías que no cambian no necesitan recompilarse, y el overhead en runtime es mínimo
  • Es una lástima que la comunidad Rust prefiera MIT antes que GPL. GPL favorece al usuario, MIT favorece a la empresa. Creo que el movimiento “Rewrite-it-in-Rust” se enfoca demasiado en expandir el lenguaje y no tanto en proteger al usuario

• Más que la adopción de Rust por parte de Ubuntu, el problema mayor es que todavía se procesan builds importantes con scripts curl|bash
  Se ve claramente en snapcraft.yaml de firefox-snap

  • Cuando alguien dice “curl|bash”, normalmente uno piensa en cambios aleatorios de configuración o en tocar el .bashrc, pero aquí simplemente se ejecuta un script de instalación de toolchain estático. Es una práctica noventera, pero relativamente segura
  • Hay muchas distribuciones cuya versión de Rust es demasiado vieja. El Rust de Debian o Ubuntu LTS está muy desactualizado, así que parecen preferir el enlace estático
  • Incluso si ejecutas algo con curl, está bien mientras verifiques correctamente el hash

• Me incomoda que el proyecto Rust Coreutils tenga licencia MIT
  Aunque a veces se critique la filosofía de la FSF, la GPL protege el open source. Si Canonical cambiara Ubuntu en general a MIT, no sé qué podría pasar

  • La GPL antes era poderosa, pero ahora muchas veces se convierte en MIT/BSD o en código comercial gracias a sistemas automáticos de lavado de copyright. La FSF tampoco tiene una solución
  • Las discusiones de licencias nunca terminan. La GPL limita la adopción, mientras que MIT es más flexible. Al final todo depende de cuál sea tu objetivo: si quieres OSS que cualquiera pueda usar, o si quieres impedir que las empresas se beneficien sin contribuir
  • Me pregunto qué “maldades” concretas se vuelven posibles porque Coreutils ahora sea MIT

• Por rust-coreutils no se podía instalar CUDA Toolkit. El issue relacionado está en los foros de NVIDIA

  • Por el hilo enlazado, parece que el problema era con gzip. No parece haber sido por dd
  • Sinceramente, rust-coreutils no tiene razón de existir. Lo primero que hay que hacer después de instalar Ubuntu es reinstalar los coreutils reales y sudo

• El concepto de “Crossing the chasm” es interesante. Además del caso de coreutils en Ubuntu, hay muchos otros abismos que Rust intenta cruzar
  Está Rust for Linux o Rust para la industria automotriz, pero por ahora parece quedarse a nivel de drivers

  • Rust se está expandiendo en varias direcciones. Ejemplos representativos son pyo3 (reemplazo para módulos de Python), Dioxus (framework web similar a React) y Ferrocine (compilador para automoción). El proyecto DARPA TRACTOR también está acelerando la adopción de Rust
  • Si miras el documento de Project Goals de Rust (enlace), puedes ver hacia dónde está invirtiendo esfuerzos la comunidad
  • Rust en sí es excelente, pero el problema es que parte de la comunidad se limita a “reescribir en Rust” software ya estable y apropiarse de la marca. Ubuntu también parece haber caído en ese tipo de virtue signaling

• La lógica de decir que la librería estándar se cambiará después es peligrosa. Los usuarios quieren sistemas estables y de alta calidad, no “abismos” por cruzar

  • En el caso de Rust, más que “cambiar” la stdlib, es fácil agregarle cosas. Sale una nueva versión cada 6 semanas, y en cada una se añaden más de 10 funciones. Ya hay cientos de funciones dentro de la stdlib

• La inmadurez del ecosistema Rust es un factor que frena su adopción. Muchos crates están en versiones previas a 1.0 o son apenas wrappers sencillos sobre C. En criptografía está bastante bien, pero cosas como SAML son difíciles de encontrar

  • No me preocuparía demasiado por las versiones pre-1.0. La cultura de seguir SemVer estrictamente hace que muchos retrasen declarar 1.0. También hay crates como libc, tan profundamente ligados al API, que son difíciles de versionar. Personalmente consulto listas curadas como blessed.rs
  • gettext llegó a 1.0 después de 30 años
  • El módulo cryptography de Python empezó a requerir toolchain de Rust, así que ya no se podía instalar en un entorno Termux. Es incómodo que hasta los proyectos de Python se vuelvan pesados por dependencias de Rust

• Hay un movimiento de “traducir por vibra” código C++ a Rust para cambiar la licencia. Por ejemplo, sudo-rs incluso tiene un peor historial de seguridad que la versión en C

  • La propaganda alrededor de Rust, la IA y la seguridad ya se volvió excesiva. Al principio me encantaba Rust, pero la controversia de la licencia MIT y la publicidad exagerada cada vez me cansan más

• La enorme librería estándar de .NET es realmente cómoda. La mayoría de las tareas se pueden hacer de forma estándar, y si hay alguna implementación rara, la mayoría empuja hacia la estandarización

  • Creo que la stdlib pequeña de Rust fue un error. La stdlib es la única dependencia que siempre está presente, así que aunque no sea perfecta, debería incluir más herramientas
  • Pero desde la perspectiva de un programador de sistemas, una stdlib grande puede ser un problema. .NET usa GC, así que no importa tanto, pero Rust o C++ también deben correr en entornos bare-metal. Una stdlib grande pesa en entornos con restricciones de memoria (<64K)
    El std/core de Rust ya es demasiado grande, así que en microcontroladores hacen falta trucos como weak symbol.
    Una stdlib pequeña favorece mantener la estabilidad del API y reducir la carga de mantenimiento. C++ sufrió mucho por este problema, así que Rust debería ser prudente