Rust en 2025: apuntando al software fundacional

• Rust celebra este año su décimo aniversario y se está consolidando como el lenguaje clave para desarrollar software fundacional en el futuro
• El software fundacional se refiere a la capa que sirve de base para todo, como kernels de sistemas operativos, plataformas en la nube, dispositivos embebidos y herramientas CLI
• Rust redujo la barrera de entrada al ofrecer rendimiento y confiabilidad al nivel de C/C++, junto con un sistema de tipos que garantiza seguridad de memoria
• La misión de Rust no se limita solo a la capa base; también está generando impacto en el desarrollo de aplicaciones de nivel superior mediante proyectos como Dioxus, Tauri y Leptos
• A futuro, planea enfocar sus inversiones clave en interoperabilidad entre lenguajes, expansión del sistema de tipos y fortalecimiento del ecosistema

---

La visión de Rust: software fundacional

• La visión central de Rust es hacer que el software fundacional sea más fácil de escribir y mantener
  • El software fundacional incluye kernels de sistemas operativos, infraestructura cloud, dispositivos embebidos y herramientas CLI que constituyen la base de todos los sistemas
  • Ya se está adoptando en diversos lugares como los kernels de Windows y Linux, el motor de búsqueda de VSCode ripgrep, Deno y el gestor de paquetes uv de Python
• En este tipo de software, rendimiento, confiabilidad y productividad son igual de importantes
  • Si la base falla, toda la capa superior se ve afectada, por lo que la estabilidad es esencial
  • Como una degradación de rendimiento termina limitando el rendimiento de las capas superiores, se necesita el menor overhead posible

Rendimiento, confiabilidad y productividad en el software fundacional

• El software fundacional, como todo software, tiene distintos requisitos, pero aquí todos los factores son todavía más importantes
  • La confiabilidad es la máxima prioridad. Si la base se rompe, todo lo que está encima falla
  • El overhead de rendimiento define el límite de rendimiento de las capas superiores, así que debe minimizarse
• Tradicionalmente había dos opciones para cumplir con estos requisitos
  • C/C++: ofrecen mucha libertad, pero exigen un nivel equivalente de perfección
  • Lenguajes de alto nivel como Java o Go: requieren formas especiales de programar para mantener el rendimiento, lo que limita el uso de abstracciones y comodidades
• Rust cambia este enfoque tradicional al combinar abstracciones de costo cero con un sistema de tipos que garantiza seguridad de memoria
• Se convierte así en una herramienta para escribir código de alto nivel de forma segura y, al mismo tiempo, alcanzar rendimiento de bajo nivel y estabilidad de memoria

Reducir la barrera de entrada y potenciar a los desarrolladores

• En presentaciones sobre Rust, a menudo se compara el sistema de tipos y las verificaciones estáticas con "espinaca": algo bueno, pero que no apetece consumir
• En la práctica, el sistema de tipos es una herramienta muy poderosa para los desarrolladores
• Los principiantes pueden aprender el sistema de tipos mientras adquieren una comprensión de estructuras de software exitosas
• Los expertos pueden detectar antes los errores en sus propios diseños estructurales

• La frase de Yehuda Katz: "Las abstracciones que construyo en un estado de concentración ayudan a mi yo futuro cuando esté cansado" resume muy bien esta idea

Áreas fuera del software fundacional

• Aunque la misión de Rust esté enfocada en el software fundacional, eso no significa que las demás áreas sean ignoradas
• Proyectos como Dioxus, Tauri y Leptos están expandiendo Rust hacia aplicaciones de más alto nivel, como GUI y páginas web
• La principal fortaleza de Rust está, en esencia, concentrada en el software fundacional, pero estos intentos no deben pasarse por alto

Metas ambiciosas y crecimiento

• Como el software fundacional requiere control detallado de bajo nivel, suele asumirse que la accesibilidad y la ergonomía no son tan importantes
• Pero precisamente porque ese nivel de control es necesario, la usabilidad se vuelve aún más importante
• Si se ayuda a los desarrolladores a concentrarse solo en las partes realmente importantes, la productividad puede mejorar mucho

• Los proyectos que impulsan el uso de Rust en niveles más altos ofrecen oportunidades para hacer la programación en Rust más cómoda
• Esas mejoras también se reflejan directamente en el desarrollo de software fundacional
• La clave es mejorar la usabilidad sin perder control ni confiabilidad

La importancia del soporte para todo el stack

• Otra razón por la que Rust puede hacer más agradable el desarrollo de aplicaciones de alto nivel es que permite construir todo el stack con una sola tecnología
• Muchos desarrolladores que al principio pensaban usar Rust solo en partes específicas, como servicios de data plane, terminan extendiéndolo a todas las áreas
• Esto se debe a que Rust ofrece alta productividad y permite compartir bibliotecas y código dentro de un solo lenguaje
• En esencia, el código simple sigue siendo simple sin importar el lenguaje en que se escriba

La experiencia de profundización iterativa

• Idealmente, la primera experiencia de un usuario con Rust debería ser simple, y a medida que el proyecto avanza, debería poder ampliar gradualmente un mayor nivel de control de manera local
• Suena sencillo, pero en realidad es un desafío muy difícil
• Muchos proyectos fracasan porque la barrera de entrada para principiantes es alta o porque aprender niveles mayores de control exige demasiado conocimiento
• Rust no siempre lo logra, pero sigue trabajando de forma continua para mejorar en este punto

Planes a futuro

• Este texto es el primero de la serie, y en cuatro entregas posteriores se presentarán las áreas de inversión necesarias para que Rust sea aún más apto para el software fundacional
  • Interoperabilidad fluida entre lenguajes (smooth language interop) y extensibilidad
  • Claridad de propósito mediante el sistema de tipos (clarity of purpose)
  • Fortalecimiento del ecosistema: mejores lineamientos, herramientas y uso de la Rust Foundation
  • En el último texto también se abordará la operación de la organización open source de Rust, con foco en cómo hacer que la contribución y el mantenimiento sean actividades lo más accesibles y agradables posible

[yeorinhieut]

Aunque Rust de alguna forma se vea bien, siento que es el único lenguaje que me da rechazo por su fandom tóxico (?).

[aer0700]

Ojalá C o C++ hubieran tenido un gestor de paquetes estándar. Siempre pienso eso cuando veo Cargo.

[cosine20]

Pero si la espinaca está buenísima....

[t7vonn]

Hoy en día, no hay lugar donde no se use Rust.

[lostid]

Aunque trabajo en una empresa bastante grande, no hay ningún área donde se use Rust. Por favor, no lo presenten de forma engañosa.

[t7vonn]

No me busques pleito

[bobross0]

Dios mío;;;;;;;

[crawler]

No busques pleito, por favor, da miedo

[shakespeares]

Uf ;;

[qwas5544]

Dios mío;;;

[lostid]

Dejando todo lo demás de lado, últimamente los ruslamistas me tienen al borde del colapso. En el mundo offline siguen siendo súper de nicho incluso dentro de las minorías, pero en línea ya son casi como ISIS... Ah, ojalá se juntaran en algún lado y se quedaran jugando solo entre ellos.

[ifmkl]

Entre los fanáticos de Rust, a menudo también hay muchos casos en los que uno duda si realmente ellos mismos lo están usando bien primero.

[skageektp]

Aun así... aman Rust, ¿verdad?
Pueden odiar al rustlam, pero por favor amen a Rust T_T

[taeunlee99]

Aunque les den una paliza con FFmpeg, salen con que todo el código debe escribirse en Rust y demás.

[GN⁺]

Comentarios de Hacker News

• Al hablar de software fundamental, considera que lo más lamentable de Rust es su ABI. Si se quiere construir un SO en Rust y ofrecer servicios abundantes, las aplicaciones deberían poder seguir usando las bibliotecas sin necesidad de recompilarlas aunque el SO se actualice. Windows resuelve esto con COM, Apple en su momento con el dynamic dispatch de ObjC (y ahora con el ABI de Swift), y Android con la JVM y bytecode. Rust, en la práctica, casi no soporta nada fuera de extern "C", así que el uso de bibliotecas dinámicas es limitado. Proveer un ABI sin una capa de VM (JVM, .NET) es extremadamente difícil, y como una vez fijados los detalles de implementación ya no se pueden cambiar nunca, entiende por qué no es prioridad. De hecho, los únicos casos exitosos de este modelo han sido Swift y COM. Si Rust adoptara un ABI completo, cree que estaría cerca de ser un lenguaje casi perfecto. (Además, gestionar dependencias en forma binaria reduciría mucho los tiempos de compilación)

  • Explica que la razón por la que Rust, en esencia, solo quiere introducir estabilidad de ABI opcional (opt-in) es su búsqueda de zero-cost abstraction. Un ABI estable viene acompañado de pérdida de rendimiento, como demuestra el caso de C++ (explicación sobre el ABI de C++). Para cargar plugins dinámicamente (dlopen) entre componentes en Rust existen herramientas como stabby y abi_stable, y funcionan bastante bien. Para una interoperabilidad más general entre lenguajes, crABI (propuesta de crABI) podría ser una alternativa futura. Aun así, no es un problema que Rust pueda resolver por sí solo; también requiere apoyo y colaboración de otras comunidades, como otros lenguajes y las distribuciones de Linux. También menciona que, como Rust es un lenguaje donde se eligen explícitamente las formas de I/O y asignación de memoria, quizá una estructura como la de Swift, donde todo se resuelve solo con bibliotecas compartidas, no encaje del todo.
  • Se está intentando resolver casi el mismo problema con Wasm Components. Si WebAssembly es un formato de instrucciones portable, entonces WebAssembly Components es un formato portable de ejecución/enlace. No es tan sencillo como repr(wasm)/extern "wasm", pero usando wit-bindgen o el target wasm32-wasip2, se puede usar sin demasiada dificultad. Video introductorio a Wasm Components
  • Expresa dudas sobre si esto realmente es necesario. Sería más cómodo poder pasar más tipos de “cosas” (slices, trait objects, etc.) como interfaces, pero en la práctica, con solo el ABI de extern "C" ya se puede hacer todo lo necesario. Y también ha visto propuestas para extender el ABI externo a más tipos
  • Dice haber visto en una conferencia de Rust una charla sobre este tema que tomaba muy fuertemente como referencia el enfoque de Swift. Supone que probablemente evolucione hacia ese lado más adelante
  • En realidad, eso ya existe. Se llama precisamente “C”

• Le encanta Rust, pero le gustaría que algunos problemas crónicos y molestos recibieran más atención

  • 1. Está el problema de los self-referencing struct. Por ejemplo, aunque se quiera guardar en el mismo struct un archivo fuente y su AST parseado, hoy no es fácil. Le gustaría tener algo como offset reference
  • 2. La orphan rule (regla de traits huérfanos). Entiende por qué existe, pero sigue siendo una regla molesta. Se puede sortear con nuevas funciones (¡a veces hace falta envolver algo 2 o 3 veces!), pero se pregunta si de verdad tiene que ser así
  • 3. Para obtener tiempos de compilación razonables, hay que dividir el proyecto en muchos crates pequeños. Entiende el motivo, pero el resultado no le convence. Un crate se trata como una sola unidad de compilación, y eso se debe a que se permiten dependencias cíclicas. Pero la mayoría del código en realidad no tiene dependencias cíclicas, así que le gustaría que esto fuera algo opt-in, o que los ítems/archivos dentro del crate se dividieran automáticamente en unidades de compilación según el grafo de dependencias
  • Solo escribió lo que se le vino a la mente, pero cree que hay más. Aun así, Rust es el mejor lenguaje de su vida, incluso como crítica constructiva
    • Señala que Rust no permite dependencias cíclicas entre crates, pero sí entre módulos dentro de un crate. Cree que la mayoría del código no tiene ciclos, pero, por ejemplo, cualquier módulo con un submódulo de tests ya cae en dependencia cíclica. Para separar bien las pruebas habría que definir todas las funciones de test en la raíz del crate, lo cual en la práctica es ineficiente
    • Coincide totalmente con los puntos 1 y 2. También agrega un posible punto 4: le gustaría que existieran partial self borrows (una función para que un método tome prestada solo una parte del struct). Sobre el punto 3, cree que antes hace falta mejor soporte para cosas como publicar varios crates a la vez
    • Sobre la orphan rule, pide que se explique mejor si se está diciendo que Rust necesita introducir una alternativa mejor, o si solo hace falta una función que permita reemplazarla
    • Coincide por completo con la orphan rule. Le gustaría que en los crates de aplicación se pudiera desactivar, o que al menos se relajara la regla cuando haya suficiente higiene garantizada, por ejemplo con proc macro

• Reflexionando sobre la expresión “Smooth, iterative deepening”, cree que Rust da demasiada importancia a la compatibilidad entre lenguajes, y que eso podría terminar aumentando la complejidad y poniendo en riesgo la seguridad. En estos casos, piensa que sería más útil reemplazar la parte más baja del sistema, como libc. Go casi no hace llamadas cross-language. Google fortaleció los cimientos desarrollando por su cuenta bibliotecas clave, mientras que en Rust hay una proliferación de bibliotecas base de distintas versiones y muchas están incompletas

  • Señala que uno de los problemas centrales de la informática en los últimos 20 años ha sido lograr que varios programas dentro de la misma máquina se comuniquen eficientemente. La mayoría intenta esquivar la base de DLL de Microsoft con código fuente y estado, mientras que los object request brokers como CORBA no lograron consolidarse. Lo mismo pasó con el RPC al estilo qnx. Por eso se sigue repitiendo el intento de unir a la fuerza cosas que en realidad no encajan bien
  • En realidad todo podría hacerse también con sockets, pero como los sockets son un flujo crudo de bytes, son una abstracción equivocada; aun así, se siguen usando porque resultan prácticos
    • A su parecer, lo que trata la publicación no es reemplazar de verdad las shared libraries cross-language al estilo DLL/COM/Wasm components, sino responder a la necesidad realista de migrar C++ a Rust de manera gradual. Para mejorar la seguridad de memoria del conjunto, la gran pregunta es “¿qué se hace con los programas existentes?”, y hoy el nivel de interoperabilidad entre Rust y C++ es insuficiente. Si ambos lenguajes pudieran colaborar fluidamente a nivel de código fuente, aumentaría mucho la posibilidad real de que Rust reemplazara una parte importante del espacio de C++
    • A veces parece que, con solo hacer coincidir sockets y protocolos, ya se obtiene casi la mejor abstracción cross-language posible. Entonces se pregunta cuál sería, en verdad, la abstracción ideal de llamadas entre lenguajes

• Destaca que “evitar asignaciones y evitar disparar el GC” no encaja con las ideas modernas de GC y JIT. En los GC modernos, en muchos casos casi no existe stop-the-world latency, y el principal factor del uso total de CPU del GC es la proporción entre resident set y tamaño del heap. El JIT tiene más oportunidades de optimización que el AOT y puede explorar de forma más agresiva (gracias a la optimización especulativa). Lo realmente importante no es el rendimiento en el peor caso degradado, sino el rendimiento promedio, además de la latencia de arranque/calentamiento y la sobrecarga de memoria. Además, no necesariamente la gestión manual de memoria es más eficiente, e incluso si el uso real de RAM se triplica, la diferencia de costo podría ser cero. También recomienda esta charla de la conferencia ISMM, que trata bien el tema

  • Pregunta más específicamente a qué se refiere eso de que el JIT ve más oportunidades de optimización. Al final, el JIT no deja de ser un complemento del AOT
  • Pregunta a qué implementación se refiere exactamente con eso de “GC moderno” en este contexto

• Considera que los comentarios marcados y la discusión apuntaron bien a los puntos clave. Preguntas como “hagamos un estándar del lenguaje con especificación formal” o “hacen falta varias implementaciones” son importantes en la práctica. En especial, dice que @infogulch señaló muy bien que, para que un lenguaje sea base de la industria, hace falta una especificación formal (comentario de referencia)

  • Responde con ingenio que no solo no está claro por qué lo marcaron, sino que en la práctica hay muchos casos de lenguajes que se volvieron base de la industria sin una especificación estándar o sin múltiples implementaciones. Por ejemplo, Ruby tiene un viejo estándar ISO, pero limitado a esa versión, y Python en la práctica toma la implementación misma como estándar. Lo mismo pasa con Rust, y desde la perspectiva de los usuarios mayoritarios no cree que eso sea motivo para cambiar de lenguaje
  • Por curiosidad buscó eso de “estándar formal del lenguaje” y encontró el documento de referencia rust-lang/reference. El proyecto Rust se toma muy en serio la especificación del lenguaje. En la reciente entrada de blog sobre la visión de la especificación explican en detalle el avance. El trabajo de especificación es enorme y difícil, pero sigue avanzando activamente al punto de que incluso en fin de semana se siguen fusionando PR al branch master
  • También espera que ayude el hecho de que ya se están desarrollando oficialmente compiladores alternativos de Rust como gccrs
  • Expresa una visión escéptica según la cual tanto los LLM como Rust, en el fondo, solo satisfacen a una parte de la gente y aportan una ligera mejora de productividad. Aun así, no está de acuerdo con la actitud irresponsable de ampliar su influencia dentro de la comunidad
  • Pide que se explique mejor qué significa exactamente “published language standard” y qué ayuda concreta aporta en la práctica
  • No tiene quejas con Rust en sí, pero le decepciona la actitud de algunos usuarios que no entienden la importancia de una especificación formal. La vida útil y la confiabilidad de cualquier sistema computacional dependen de qué tan formal sea su relación con la especificación. Si no hay una especificación clara, se depende por completo de “qué implementación funcionó por casualidad con cierta entrada”, y es peligroso construir sistemas sobre una base tan frágil. En computación, la especificación es el sistema mismo (la implementación no es más que una optimización secundaria)

• La gente a menudo incluso pone en duda la pregunta de si Rust debería tener una especificación, y cree que eso demuestra cuánta falta hace la verdadera ingeniería en la ingeniería de software

  • Cree que la ingeniería de software no es ingeniería de verdad. No hace falta construir tres veces un puente o un rascacielos para que salga bien, pero en software eso hasta puede ser una buena estrategia

• Sobre un comentario que decía que Rust es “un lenguaje que solo usan quienes quieren parecer programadores”, responde que en realidad él ama programar y que Rust fue una bocanada de aire fresco. No quiere ni pensar en volver al pasado en que C++ era un sufrimiento extremo. Y no considera importante ni el estándar del lenguaje (donación de la especificación de Ferrocene) ni la cantidad de implementaciones. Python y Java también funcionan bien dependiendo de una sola implementación central. C++ intentó soportar múltiples compiladores y lo único que logró fue agravar problemas complejos según la plataforma. No sabe a qué se refiere exactamente eso del “desastre” de cargo, y piensa que el lado de C++ era mucho más incómodo

  • Pregunta qué aspectos concretos son problemáticos en cargo
  • También agrega que duda de si la diversidad de estándares/implementaciones de un lenguaje es realmente tan importante, si no será demasiado pronto, y si Rust habría tenido tanto éxito como ahora si hubiera gastado energía en eso desde el principio. Le parece que el artículo no está proponiendo un reemplazo total de todo, sino resaltando el soporte o la idoneidad para ciertos casos de uso específicos
  • Piensa que cargo es actualmente el mejor package manager entre los grandes lenguajes del mundo. Aprendió muy bien de los puntos donde fallaron los gestores de paquetes anteriores, y es de los más pulidos y sólidos también como infraestructura. Puede que necesite pequeñas mejoras, como namespaces o builds completamente repeatable, pero poner el cargo actual encima de otro lenguaje sería casi imposible. Hay muy pocos lenguajes con una infraestructura de este nivel