Análisis del lenguaje de programación Rust: ¿vale la pena aprenderlo?

Pregunta a dos desarrolladores de Rust con experiencia si aprender Rust valió la pena y puedes recibir respuestas completamente opuestas. Uno te puede decir que no hizo nada por su carrera; otro puede decir que fue una de las mejores decisiones técnicas que tomó. Los dos pueden tener razón.

En esa contradicción está de verdad la pregunta «¿vale la pena aprender Rust?», y por eso un sí general no te sirve de nada. Rust es un lenguaje compilado cuyo subconjunto seguro impone reglas de seguridad de memoria en tiempo de compilación, sin necesitar un recolector de basura en tiempo de ejecución.

Así que me voy a comprometer con una respuesta, diré de qué condición depende y te mostraré lo que cuesta esa condición.

La versión corta

Vale la pena aprender Rust si estás construyendo algo de larga vida donde merece la pena pagar por que el compilador atrape toda una clase de bugs. No es para ti si necesitas sacar una app CRUD este mes, si estás aprendiendo a programar o si cuentas ofertas de empleo. 4 de 5, con puntos descontados por lo que cuesta antes de compensar.

• Lo que compras: en Rust seguro, las reglas de propiedad y préstamo convierten los bugs de use-after-free, double-free, referencias inválidas y data races en errores de compilación en vez de incidentes en producción. Ese es todo el argumento, y es bueno.
• Lo que pagas: el compilador te obliga a escribir decisiones de memoria que tu lenguaje actual toma en silencio, y al principio parece que la herramienta te pone trabas.
• La cuestión de la durabilidad está resuelta. Los mantenedores del kernel dieron por concluido el experimento de Rust en el Maintainers Summit de diciembre de 2025, y la etiqueta de «experimental» desapareció en Linux 7.0.
• La cuestión de la moda no está resuelta, y es otra pregunta distinta. Rust está en el puesto #10 del índice TIOBE de septiembre de 2026, frente al #18 de un año antes.
• Mi servicio de prueba en Rust necesitó mucha más memoria para compilar que para ejecutarse: llegó a cerca de 1 GB al compilar y en reposo usaba unos 3,5 MB.
• Es para ti si ya publicas software en otro lenguaje y estás construyendo algo donde un bug de memoria saldría caro, o si trabajas cerca del software de sistemas. No es para ti si tienes una fecha límite, empiezas desde cero o buscas el lenguaje con más ofertas de empleo.

Cómo se hizo este análisis: las cifras de compilación y ejecución son mías. Instalé Rust 1.98.1, escribí un pequeño servicio web con Axum y medí lo que costaba compilarlo y lo que costaba ejecutarlo. Todo corrió en un contenedor aislado, no en hardware dedicado, y es un solo proyecto, así que toma las cifras como un dato y no como una ley. Todo lo demás viene de fuentes primarias o fiables: el parche del kernel y la cobertura de LWN sobre él, las publicaciones de seguridad de Android de Google, el propio índice de TIOBE (con el comentario de abril según lo recogió Slashdot), Phoronix sobre la ventana de fusión de Linux 7.0, los registros CVE del kernel Linux sobre la vulnerabilidad de Binder, el comunicado de la propia Canonical y la encuesta de Stack Overflow de 2025. Leí el parche del kernel. No audité el código Rust del kernel. Y no llevo años escribiendo Rust, así que donde este análisis juzga el lenguaje en sí, se basa en profesionales que sí lo hacen, y los nombra.

Lo que te da el compilador

Dale a dos hilos una referencia mutable al mismo vector en Rust y el código no compila. No es una advertencia. No es un lint que puedas silenciar con prisas. No compila. Ese rechazo es lo que compras con Rust seguro: los bugs de use-after-free, double-free, referencias inválidas y data races pasan a ser errores de compilación en vez de incidentes en producción. La vía de escape de Rust (unsafe) puede saltarse algunas de esas garantías, así que no es una promesa absoluta sobre cualquier código Rust.

La propiedad significa que cada valor tiene exactamente un dueño responsable de liberarlo. El préstamo significa que puedes prestar referencias, pero el compilador sigue su tiempo de vida y no deja que ninguna sobreviva a aquello a lo que apunta, ni que un préstamo mutable conviva con otro. En Rust seguro, los bugs de use-after-free, double-free, referencias inválidas y data races los detecta el sistema de propiedad y de tipos antes de que el programa se ejecute.

No hay recolector de basura, y esa es la otra mitad del trato. Como la propiedad ya dice quién libera qué y cuándo, nada tiene que recorrer tu heap en tiempo de ejecución. Publicas un binario sin recolector dentro y no tienes pausas que ajustar.

El precio aparece en el mismo sitio que la garantía. Cada decisión de memoria que tu lenguaje actual toma en silencio por ti es una que Rust te pide que escribas: quién es dueño de esto, cuánto vive esa referencia, si algo más puede verla y si cruza la frontera entre hilos. El compilador no te está poniendo trabas. Se niega a adivinar.

Así que esta es la razón por la que alguien paga lo que pide Rust, y creo que se sostiene. Si la clase de bugs que elimina no es una que te preocupe, el resto de este análisis probablemente no te hará cambiar de opinión.

¿Sigue siendo Rust experimental o ya es infraestructura de producción?

Dejó de ser experimental en diciembre de 2025, y quienes le pusieron fin fueron los propios mantenedores del kernel. En el Maintainers Summit de 2025 concluyeron que Rust se había ganado su sitio en el kernel, en lo técnico y en lo social. Jonathan Corbet, de LWN, informó del consenso el 10 de diciembre de 2025: Rust en el kernel ya no es experimental.

Rust entró en el Linux principal con la v6.1 en 2022 precisamente para hacer ese experimento. El parche de Miguel Ojeda que quitaba la etiqueta llegó tres días después del Summit, y entró en la ventana de fusión de Linux 7.0.

«Pero el experimento ha terminado, es decir, Rust ha venido para quedarse.»

Miguel Ojeda, «rust: conclude the Rust experiment», LKML, 13 de diciembre de 2025

Por separado, y antes: la reescritura en Rust que hizo Google del driver Binder de Android, la capa IPC por la que se comunican los procesos de Android (constantemente), llegó a Linux 6.18, publicado el 30 de noviembre de 2025. No mezcles ese hito con el consenso del Summit. Es aquel en el que una empresa apostó un producto comercial por el Rust del kernel, no un grupo de mantenedores dando su bendición a la idea. Desde entonces, el Rust del kernel ha producido su primer CVE: CVE-2025-68260, una condición de carrera en ese mismo driver Binder que Greg Kroah-Hartman anunció el 16 de diciembre de 2025, introducida en la 6.18 y corregida en la 6.18.1. Los primeros informes se centraron en cuelgues, pero la puntuación posterior del equipo CVE del kernel Linux da a CVE-2025-68260 un 7,8 (alta) y describe una vía de escalada local de privilegios mediante corrupción de la memoria del kernel. El mismo driver (rust_binder) también ha acumulado más CVE desde entonces.

Android es donde las pruebas se vuelven numéricas. El blog de seguridad de Google afirmó en diciembre de 2022 que se habían descubierto cero vulnerabilidades de seguridad de memoria en el código Rust de Android, frente a aproximadamente 1,5 millones de líneas de Rust en AOSP y cerca del 21% de todo el código nativo nuevo de Android 13. Es una afirmación de 2022 con un alcance de 2022. Las publicaciones posteriores de Google dan la tendencia más larga: los problemas de seguridad de memoria supusieron el 76% de las vulnerabilidades de Android en 2019 y el 24% en 2024, con la cifra bruta bajando de más de 220 a unas 36 previstas. Esas cifras solo significan algo frente a la base que reemplazaron: C y C++ escritos por ingenieros muy buenos con herramientas muy buenas.

Dos señales más pequeñas apuntan en la misma dirección. El driver de GPU Apple AGX de Asahi Linux está en Rust, escrito por el proyecto Asahi Linux como trabajo de ingeniería inversa y no por Apple. La actualización de Canonical sobre rust-coreutils dice que Ubuntu 26.04 LTS incluye rust-coreutils 0.8.0 para la mayoría de las utilidades. Tres siguen en GNU coreutils (cp, mv, rm) porque el 22 de abril de 2026 aún había ocho problemas TOCTOU abiertos; Canonical apunta a la 26.10 para las utilidades restantes.

Este es el eje al que daría la nota más alta, y la razón es el tipo de compromiso que implica. Los mantenedores del kernel no «desconcluyen» experimentos, Google no deshace una reescritura de ese tamaño y Canonical no mete unos coreutils reescritos en una LTS para ver qué pasa. Pase lo que pase con la popularidad de Rust, alguien tendrá que mantener ese código durante años.

¿Está Rust muerto o solo se está estancando?

No. Rust igualó su mejor posición en TIOBE, el #13, en enero de 2026. Tres meses después había vuelto a caer al #16, y el CEO de TIOBE, Paul Jansen, escribió en abril de 2026, en un comentario que Slashdot citó en su momento, que el crecimiento de popularidad de Rust «parece estar estabilizándose» y que un puesto en el top 10 «ahora parece más lejano que antes».

Estaba describiendo cómo Rust alcanzaba su mejor posición de la historia en su propio índice, un puesto que había ocupado por primera vez en julio de 2024, y luego lo perdía.

El índice TIOBE de septiembre de 2026 sitúa a Rust en el #10, frente al #18 de un año antes, y por encima del #13 que TIOBE llamó su mejor posición de la historia en enero.

Mi lectura: el estancamiento fue real. Fue un bache, no un techo. Eso supera la versión de cada bando, porque «Rust se ha estancado» ahora es falso y «Rust solo sube» nunca fue cierto.

La advertencia corta en ambos sentidos, y el artículo de Slashdot ya la planteaba entonces: ¿podrían los rankings estar simplemente fluctuando con el ruido de un mes a otro en los resultados de los buscadores, que es lo que cuenta el índice? Si una caída de tres puestos en un trimestre era una prueba débil de que Rust se frenaba, una subida de seis puestos es una prueba débil de que está ganando. Tómalo como el tiempo, no como el clima.

La señal más fuerte sobre la percepción es la encuesta de Stack Overflow, donde Rust es una vez más el lenguaje de programación más admirado en 2025, con un 72%: gente que lo usó el último año y quiere seguir usándolo. Es intención de seguir, no adopción, y aquí es una señal más útil que la popularidad bruta si estás decidiendo si vas a disfrutar quedándote con el lenguaje.

El impulso es ambiguo, y le doy menos peso que a la durabilidad de antes, porque no estás invirtiendo en un ranking.

Lo que te cuesta aprender Rust

El coste llega pronto y de golpe. Código que Python, Java o C# ejecutarían sin problema es rechazado una y otra vez, por razones que parecen arbitrarias hasta que el modelo de propiedad hace clic, y no hay forma de aplazarlo. No puedes esquivar el borrow checker a base de publicar, como sí puedes esquivar no entender del todo tu ORM.

Esta es la parte que me sorprendió, y va al revés de lo que esperarías. En el hilo de r/rust «Struggling to learn Rust», la respuesta con más tirón replantea el problema como falta de familiaridad, no dificultad, y el hilo señala a los desarrolladores experimentados que vienen de lenguajes con recolector de basura como los que lo pasan peor. u/Voxelman lo dice claro: «Rust no es difícil. Es diferente.» En el mismo hilo describe su propio camino: C64 Basic, luego varios lenguajes imperativos, y un primer contacto con Rust que «fue de todo menos WOW» porque dejar los viejos hábitos le llevó tiempo.

Esa es la forma de la factura. Si llevas ocho años escribiendo Python, no estás aprendiendo un conjunto de reglas, estás renunciando a un conjunto de suposiciones sobre quién limpia detrás de ti. Alguien que sabe menos tiene menos que desaprender.

Otro patrón aparece una y otra vez en ese hilo, y convierte un error de orden en un problema de confianza: la gente se atasca no en Rust sino en elegir un framework web, intentando aprender el lenguaje a través de Axum o Actix antes de haber asimilado la propiedad. Como dijo u/jmartin2683, eso es «como intentar aprender ruby aprendiendo rails.»

Creo que la mayoría de las advertencias sobre el coste apuntan a lo que no es. Reserva práctica constante, no un fin de semana, y no tomes la frustración inicial como un veredicto sobre tu capacidad.

Rust necesita una máquina más grande para compilar que para ejecutarse

Este es el hallazgo que no esperaba: compilar este proyecto Rust necesitó órdenes de magnitud más memoria que ejecutarlo. Compilé un pequeño servicio Axum (Tokio con la feature full activada, serde, serde_json, tower, una ruta JSON, unas 60 crates en el árbol de dependencias) con rustc y cargo 1.98.1, con strip = true en el perfil release, y luego lo compilé desde cero dos veces:

# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --release

Limitado a un solo job de compilación (--jobs 1), el pico de memoria entre cargo, rustc y el enlazador quedó entre 464 MB y 527 MB según cuál de mis dos métodos de medición tomes (lo medí de dos formas porque el primer número parecía demasiado limpio), y tardó 113 segundos. Con el paralelismo por defecto en cuatro vCPU, el pico de memoria casi se duplicó hasta cerca de 1 GB y la compilación terminó en unos 35 segundos. La variable ahí es el paralelismo, no el proyecto. Más jobs significa más procesos rustc residentes a la vez, y por eso los compiladores son una de las pocas cargas de trabajo que aprovechan encantadas cada núcleo que les des durante minutos seguidos.

El programa final ocupa 1,3 MB sin símbolos y en reposo usa unos 3,3 a 3,6 MB de memoria.

Con el paralelismo por defecto, eso es de doscientas a trescientas veces más memoria para compilar que para ejecutar; limitado a un job, sigue siendo bastante más de cien. Dimensiona un servidor según lo que tu servicio Rust necesita en producción y puedes acabar con una máquina que no puede compilarlo, y el fallo no es un error limpio: es el OOM killer tumbando rustc a mitad de compilación, o un compilador machacando la swap durante veinte minutos. Hay dos respuestas que funcionan. Compilar en algún sitio con margen y desplegar el binario, el mismo patrón que tener una máquina de compilación aparte para el trabajo pesado con Docker. O compilar en la máquina y darle espacio: para un servicio de este tipo, un par de gigabytes de RAM y dos vCPU van sobrados. Cuando no es así, la vía de escape es --jobs 1 (sí, es más lento; ese es el precio).

Si la máquina en la que trabajas no tiene ese margen, nuestro VPS Linux autogestionado te da acceso root con facturación por horas o mensual y un sitio donde poner la compilación y devolverlo cuando termines, aunque sigue siendo un servidor que administras tú y no uno que se administra solo.

Un proyecto, una forma, una máquina. La máquina era un contenedor aislado compartido, no un servidor dedicado, con unos 2 GB de memoria disponibles, así que el pico sin límite estaba más cerca de su techo de lo que estaría en una máquina más grande. No son una constante universal: si tu árbol de dependencias es cuatro veces más grande o tu perfil release activa la optimización en tiempo de enlazado, espera cifras distintas. Árboles de dependencias más grandes, la optimización en tiempo de enlazado y el código con muchos genéricos pueden subir la memoria de compilación, así que no tomes mis mediciones como un techo universal.

Yo pondría esto en cómo trabajas, no en si aprendes el lenguaje. Conócelo antes de toparte con ello.

Quién debería aprender Rust

Tres situaciones en las que te diría que le dediques el tiempo: software de larga vida donde un bug de memoria sale caro, trabajo cercano al sistema operativo, y querer lo que pelearte con el compilador hace con tu forma de pensar en la memoria. Cada una tiene una razón por la que ese tiempo se recupera.

Ya publicas software en otro lenguaje y estás construyendo algo de larga vida donde un bug de memoria saldría caro. Un servicio que tiene que seguir en pie. Una librería de la que dependen otros equipos. Cualquier cosa donde un use-after-free signifique una revisión de incidente, no un stack trace en tu terminal. Este es el caso para el que se diseñó toda la garantía, y lo que pagas al principio se amortiza a lo largo de la vida de lo que construyes.

Trabajas cerca o dentro del software de sistemas. Drivers, trabajo con dispositivos, utilidades del sistema base, embebidos, cualquier cosa que esté debajo de un sistema operativo en vez de encima. La industria se ha comprometido aquí como no lo ha hecho en otros sitios, y aquí es donde las pruebas sobre seguridad de memoria son más sólidas.

Quieres el efecto secundario. Dos comentaristas de ese hilo de r/rust discrepan por completo sobre el valor de Rust para la carrera y llegan al mismo sitio aquí. u/tyler_church, que dice que no tuvo ningún impacto en su carrera, aun así le reconoce «quizá influencias sutiles en cómo escribo otros programas en otros lenguajes». u/SirKastic23, con dos años cobrando por escribir Rust, dice que amplió sus habilidades de programación de maneras que nunca esperó. Dos personas, no un estudio, pero es la recompensa que se mantiene aunque nunca escribas Rust profesionalmente: un cambio en cómo piensas, no una línea en el currículum.

Quién no debería aprender Rust

Tres situaciones en las que ese tiempo está mejor invertido en otra cosa: tienes una fecha límite este mes, estás aprendiendo a programar desde cero o eliges lenguaje por cuántas ofertas de empleo lo mencionan. La tercera es la que más se pregunta.

Tienes una fecha límite este mes para una app CRUD o un prototipo. Rust llega justo con el calendario equivocado para un trabajo que tiene que existir el viernes. Go es la opción obvia en su lugar si quieres un lenguaje compilado con compilaciones rápidas y gestión de memoria con recolector de basura, y no necesitas las garantías basadas en la propiedad de Rust.

Estás aprendiendo a programar desde cero. Este tema divide de verdad a la gente que vive de escribir Rust, y el desacuerdo en los hilos de r/rust va en ambas direcciones, así que mi postura es que darle a un principiante una moneda al aire es un mal consejo caiga del lado que caiga. Aprende primero cómo funciona una máquina en un sitio más indulgente, y luego vuelve y deja que el compilador lo afine.

Eliges lenguaje por cuántas ofertas de empleo lo mencionan. Aquí no te voy a dar una cifra, porque no encontré ningún dato de salario o de vacantes de Rust que remita a una fuente que yo defendería. Lo que u/crusoe describe en ese hilo de r/rust es un mercado con menos puestos y más especializados. Es un comentarista en un hilo, no datos del mercado laboral, así que no lo convertiría en la afirmación de que los empleos en Rust escasean en general. Si el volumen de empleo es tu factor decisivo, revisa las ofertas actuales en tu mercado objetivo antes de elegir el lenguaje.

Preguntas frecuentes