Codigum

¿Cuánto tarda un equipo en aprender Rust?

2026-11-05T00:00:00+00:00

La pregunta que frena a muchos líderes técnicos no es si Rust es bueno, sino cuánto tiempo perderá el equipo aprendiéndolo. La mala noticia es que la curva es real. La buena es que hay datos, y son mejores de lo que dice la fama.

Lo que dicen los datos

La mejor referencia pública es una encuesta de Google de 2022, respondida por más de 1000 desarrolladores que habían escrito Rust ese año:

Encuesta a más de 1000 desarrolladores de Google que escribieron Rust en 2022. Son percepciones, no mediciones.

Más de dos tercios se sintieron capaces de contribuir a un proyecto en Rust en dos meses o menos.
Un tercio alcanzó la misma productividad que en otros lenguajes en ese plazo, y más de la mitad en cuatro meses.
El 85 % confía en que su código Rust es correcto, y el 77 % está satisfecho con su calidad.

El mayor problema reportado no fue el lenguaje, sino la velocidad de compilación: solo algo más del 40 % la consideró aceptable.

Cómo leer estas cifras

Antes de usarlas en un plan, tres matices:

No todas las empresas son Google. Hablamos de personas con mucha experiencia, buenas herramientas y compañeros que ya conocían el lenguaje.
Es lo que las personas dicen. Son percepciones en una encuesta, no mediciones de productividad.
Depende de dónde vienes. Quien viene de C++ ya entiende la memoria, y quien viene de Python o JavaScript debe aprender más conceptos, aunque suele hacerlo sin malos hábitos.

Como referencia, la encuesta State of Rust 2025, con 7156 respuestas completas, también sitúa los tiempos de compilación y el uso de recursos entre los retos que persisten.

Dónde se atascan los equipos

La sintaxis se aprende rápido. Lo que toma tiempo es cambiar la forma de pensar:

La propiedad y el préstamo. Los primeros días, el compilador rechazará casi todo. Es normal. Empieza por la guía de ownership.
Los tiempos de vida. Asustan más de lo que deberían. La mayoría del código no los necesita de forma explícita, como vemos en la guía de lifetimes.
Código asíncrono. Suma varios conceptos a la vez. Conviene dejarlo para cuando lo anterior esté asentado.
Traer patrones de otro lenguaje. Modelar con herencia o con muchos objetos que se apuntan entre sí trae problemas. Es mejor pensar en tipos.

Lo que más frena no es la dificultad, sino hacerlo a solas, sin nadie que revise el código.

El costo real

El error habitual es contar solo el curso. El costo principal es el tiempo con menor productividad. Una forma simple de estimarlo:

Un ejemplo con valores supuestos: cuatro personas, cuatro meses y una pérdida media del 30 % equivalen a 4,8 meses de una persona. A ese número se le suma la capacitación, y se le debe comparar el beneficio esperado: menos incidentes, menos infraestructura o mejor latencia.

Si la cuenta no da, ese es un resultado valioso. Las cinco preguntas antes de migrar ayudan a hacerla con honestidad.

Un plan de 90 días

Esto es lo que recomendamos para un equipo de 3 a 8 personas:

Días 1 a 30: fundamentos

Elegir un componente pequeño y medible, sin plazos críticos.
Seguir una ruta común, como nuestras ocho guías.
Formar a dos personas primero, para que acompañen al resto.
Instalar desde el día uno clippy, rustfmt y las herramientas del día a día.

Días 31 a 60: producción en pequeño

Construir el componente con pruebas y métricas, como en este microservicio.
Revisar en pareja todo el código, y dedicar tiempo a leer los errores del compilador.
Usar .clone() sin culpa: la eficiencia se ajusta después.

Días 61 a 90: evaluar

Desplegar con una salida gradual, y comparar con el sistema anterior.
Medir tres cosas: tiempo de entrega, incidentes y recursos.
Decidir con datos si Rust se extiende, se queda en ese componente o se abandona.

Abandonar también es un buen resultado, si sale barato y a tiempo.

Qué acelera la curva

Compilar con menos sufrimiento: usa cargo check mientras escribes, y bacon para ver errores al guardar.
Mentoría en el código real: un experto que revisa tus pull requests vale más que muchas horas de curso.
Empezar con un problema propio: los ejercicios abstractos se olvidan.

Corrode, una consultora especializada, afirma que la formación permite llevar a un equipo al ritmo en unos 2 meses en lugar de 4. Es una cifra comercial, no un estudio, así que tómala como referencia.

Los 7 fallos de memoria más comunes, ilustrados

2026-11-05T00:00:00+00:00

Imagina la memoria como una fila larga de casilleros numerados. Tu programa pide unos cuantos, guarda cosas en ellos y los devuelve cuando termina. Casi todo lo que puede salir mal se resume en tres preguntas: dónde escribes, cuándo usas lo que tienes y quién más lo está tocando.

Familia	Qué se rompe	Fallos
Espacio	Se usa un casillero fuera de lo reservado	Desbordamiento de búfer, lectura fuera de límites
Tiempo	Se usa un casillero que ya no es tuyo	Uso después de liberar, doble liberación, fuga de memoria
Valor	Se confía en algo que no existe	Puntero nulo
Concurrencia	Dos hilos tocan lo mismo a la vez	Carrera de datos

No son rarezas de laboratorio. En el CWE Top 25 de 2025, la escritura fuera de límites ocupa el puesto 5, el uso después de liberar el 7 y la lectura fuera de límites el 8. La cifra del 70 % de Microsoft habla de esta misma familia.

1. Desbordamiento de búfer (buffer overflow)

Analogía: guardas tanto en tu casillero que lo que sobra invade el del vecino.

Ocurre cuando se escribe más de lo que cabe en el espacio reservado. C no comprueba el tamaño por ti:

char nombre[8];
int es_admin = 0;
strcpy(nombre, entrada); // copia sin mirar cuánto cabe

Lo que sobra no desaparece: cae sobre lo que estaba al lado. Ilustración simplificada; la disposición real depende del compilador.

Si quien envía entrada elige bien los bytes, puede cambiar datos del programa e incluso desviar su ejecución. Por eso este fallo acompaña a la seguridad informática desde hace décadas.

En Rust, cada acceso por índice comprueba los límites. Si te pasas, el programa se detiene de forma controlada, sin pisar nada:

fn main() {
    let notas = vec![12, 15, 18];
    let i = notas.len();
    println!("{}", notas[i]); // pánico: index out of bounds
}

Detenerse es mejor que corromper datos, pero en un servidor sigue siendo una caída: la interrupción de Cloudflare de noviembre de 2025 fue justamente un pánico en código Rust. Por eso conviene preguntar antes de acceder:

fn main() {
    let notas = vec![12, 15, 18];
    match notas.get(3) {
        Some(nota) => println!("{nota}"),
        None => println!("Esa posición no existe"),
    }
}

2. Lectura fuera de límites (out-of-bounds read)

Analogía: pides ver tu casillero, y te muestran también los tres siguientes.

Aquí no se daña nada, y justamente por eso es peligroso: el programa sigue funcionando mientras entrega lo que no debería.

El programa confía en la cifra que le dan, y entrega lo que haya al lado. Nada falla ni deja rastro evidente.

El caso más famoso es Heartbleed (CVE-2014-0160), en OpenSSL. Un atacante podía indicar una longitud mayor que la real y recibir el contenido de la memoria del servidor, incluidas claves y contraseñas.

En Rust se aplica la misma comprobación de límites del caso anterior: un rebanado o un índice fuera de rango no devuelve memoria ajena.

3. Uso después de liberar (use-after-free)

Analogía: devuelves la llave del casillero, pero conservas una copia. Otra persona ya guardó allí sus cosas.

Es uno de los fallos más explotados, porque quien ataca puede intentar controlar qué ocupa esa memoria.

El puntero parece válido, pero la memoria ya pertenece a otra parte del programa.

Este código en C compila, aunque es incorrecto:

char *s = malloc(16);
free(s);
s[0] = 'x'; // uso después de liberar

En Rust el compilador comprueba que ninguna referencia viva más que el dato. Es el trabajo de los tiempos de vida:

fn main() {
    let r;
    {
        let s = String::from("hola");
        r = &s;
    } // `s` se libera aquí
    println!("{r}"); // error[E0597]: `s` does not live long enough
}

El error aparece antes de ejecutar el programa.

4. Doble liberación (double free)

Analogía: dos personas devuelven la misma llave. El registro de casilleros queda con una entrada falsa, y más tarde el mismo casillero se asigna a dos personas.

Dos variables creen ser responsables del mismo bloque, y ambas lo devuelven.

char *a = malloc(16);
char *b = a;
free(a);
free(b); // el mismo bloque, por segunda vez

En Rust cada valor tiene un único dueño, así que solo uno puede liberarlo. Intentarlo dos veces no compila:

fn main() {
    let s = String::from("hola");
    drop(s);
    drop(s); // error[E0382]: use of moved value: `s`
}

5. Puntero nulo (null pointer dereference)

Analogía: te dan una llave con un número de casillero que no existe.

Su creador, Tony Hoare, lo llamó su "error de mil millones de dólares". El problema de fondo es que cualquier referencia podría no apuntar a nada, y nada en el tipo lo avisa. En C suele terminar en una caída. En Java aparece como NullPointerException.

El problema no es que algo falte, sino que nada avise de que puede faltar.

En Rust las referencias seguras nunca son nulas. Lo que puede faltar se declara con Option, y el compilador impide usarlo sin revisar:

fn buscar(id: u32) -> Option<String> {
    if id == 1 { Some(String::from("Ana")) } else { None }
}

fn main() {
    match buscar(7) {
        Some(nombre) => println!("{}", nombre.len()),
        None => println!("Cliente no encontrado"),
    }
}

Lo explicamos paso a paso en la guía de Option y Result.

6. Carrera de datos (data race)

Analogía: dos cajeros consultan el mismo saldo a la vez, y cada uno anota su propio resultado. Una de las dos operaciones desaparece.

Ninguno de los dos hilos hizo algo incorrecto por sí solo. El error está en el momento.

Es el fallo más difícil de reproducir: puede aparecer una vez cada millón de ejecuciones, y desaparecer justo cuando lo depuras.

En Rust este código no compila, porque el hilo podría tocar saldo mientras el programa principal también lo usa:

use std::thread;

fn main() {
    let mut saldo = 100;
    let hilo = thread::spawn(|| saldo += 10); // error[E0373]
    saldo -= 20;
    hilo.join().unwrap();
}

La versión correcta hace explícito cómo se comparte el dato. Sin tomar el candado, ni siquiera se puede acceder al valor:

use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    let saldo = Arc::new(Mutex::new(100));
    let copia = Arc::clone(&saldo);

    let hilo = thread::spawn(move || *copia.lock().unwrap() += 10);
    *saldo.lock().unwrap() -= 20;

    hilo.join().unwrap();
    println!("{}", saldo.lock().unwrap()); // siempre 90
}

Rust evita las carreras de datos, pero no evita los interbloqueos ni otros errores de lógica en la concurrencia.

7. Fuga de memoria (memory leak)

Analogía: pides casilleros y nunca los devuelves. Nadie resulta afectado hoy, hasta que no quedan casilleros.

Nada se corrompe. El servicio solo crece, hasta que el sistema lo detiene. Ilustración, no medición.

No es una vulnerabilidad de memoria en sentido estricto, pero tumba servicios. Y aquí Rust no promete tanto: el Libro lo dice con claridad, las fugas son seguras en memoria y evitarlas por completo no es una de sus garantías. Son difíciles de provocar por accidente, porque la memoria se libera sola al salir de alcance, pero un ciclo de Rc lo consigue:

use std::cell::RefCell;
use std::rc::Rc;

struct Nodo {
    siguiente: RefCell<Option<Rc<Nodo>>>,
}

fn main() {
    let a = Rc::new(Nodo { siguiente: RefCell::new(None) });
    let b = Rc::new(Nodo { siguiente: RefCell::new(Some(Rc::clone(&a))) });
    *a.siguiente.borrow_mut() = Some(Rc::clone(&b));
    // `a` y `b` se sostienen entre sí: nunca se liberan
}

Los lenguajes con recolector de basura también pueden fugar memoria, si una lista o una caché conserva referencias que ya nadie necesita.

Comparación por lenguaje

Fallo	C y C++	Java, C#, Go, Python	Rust seguro
Desbordamiento de búfer	Posible	Error en ejecución	Pánico en ejecución
Lectura fuera de límites	Posible	Error en ejecución	Pánico en ejecución
Uso después de liberar	Posible	Evitado por el recolector	No compila
Doble liberación	Posible	No aplica	No compila
Puntero nulo	Posible	Error en ejecución	No compila
Carrera de datos	Posible	Posible	No compila
Fuga de memoria	Posible	Posible	Difícil, pero posible

"Rust seguro" importa: el código marcado como unsafe queda bajo tu responsabilidad, y los errores de lógica o de autorización siguen siendo posibles en cualquier lenguaje.

Java, C#, Go y Python resuelven buena parte de esta tabla con un recolector de basura, a cambio de trabajo en tiempo de ejecución. Ese costo tiene sus propias consecuencias, y las explicamos en Recolector de basura vs. Rust.

21 pisos por las escaleras: la historia del origen de Rust

2026-11-05T00:00:00+00:00

Es 2006. Graydon Hoare tiene 29 años, trabaja como programador en Mozilla y vive en Vancouver. Al volver a su apartamento encuentra el ascensor fuera de servicio. Su software se ha colgado, y no es la primera vez.

Vive en el piso 21.

2006, Vancouver. Según MIT Technology Review, no era la primera vez que ese ascensor fallaba.

Mientras sube, según contó MIT Technology Review, piensa que es ridículo que quienes trabajan con computadoras no puedan hacer un ascensor que funcione sin colgarse. Y sabe por dónde suele venir el problema: muchas de esas caídas nacen en cómo un programa usa la memoria.

Software como ese suele estar escrito en lenguajes como C o C++, que permiten crear código pequeño y rápido, pero también facilitan esos errores. Podría haberse quedado en una queja. Hoare hizo otra cosa: abrió su portátil y empezó a diseñar un lenguaje que permitiera escribir código pequeño y rápido sin esos fallos.

Un proyecto personal

Durante tres años, Rust fue un proyecto paralelo. El nombre tampoco salió de un comité. Viene de un grupo de hongos, las royas, que a Hoare le parecían sobrediseñados para sobrevivir. En el fondo, era una declaración de intenciones.

Mozilla apuesta por él

En 2009, Mozilla decidió patrocinar el proyecto. Sus directivos vieron que Rust podía ayudarles a construir un mejor motor de navegador, un software complejo y propenso a fallos de memoria peligrosos. La empresa empezó a pagarle a un equipo para trabajar en él a tiempo completo.

El día que Rust dejó atrás el recolector de basura

Este es quizá el detalle más sorprendente: Rust tuvo recolector de basura. En 2013, el equipo lo retiró del lenguaje.

Fue una decisión enorme. Sin él, Rust dependía por completo de sus reglas de propiedad y préstamo para garantizar la seguridad de la memoria. A cambio, ganaba algo que casi ningún lenguaje seguro ofrecía: rendimiento predecible, sin un proceso ajeno trabajando en segundo plano.

Ese mismo año, Hoare se apartó del proyecto. Lo que había empezado como una idea personal ya era de una comunidad.

De la versión 1.0 al kernel de Linux

Diecinueve años entre un ascensor averiado y el kernel de Linux.

La versión 1.0 llegó el 15 de mayo de 2015. Era una promesa de estabilidad: el código escrito entonces seguiría compilando. Luego vinieron las pruebas de fuego. En 2017, una parte del motor de Firefox ya estaba en Rust. En 2020, Dropbox y Discord contaban sus reescrituras. En 2021, AWS, Google, Huawei, Microsoft y Mozilla crearon la Rust Foundation, y el lenguaje dejó de depender de una sola empresa.

Hoy Rust está en Android, Windows, Linux y la infraestructura de la nube.

Lo que nos deja esta historia

Vale la pena mirar la historia completa. Rust no surgió de un plan estratégico ni de un laboratorio, sino de alguien que se negó a aceptar que el software tuviera que fallar así.

Hay también una lección más incómoda. Los fallos de memoria no eran un secreto en 2006. Todo el sector los conocía y los trataba como el costo inevitable de hacer software rápido. Rust demostró que ese costo no era inevitable: se podía tener control y seguridad a la vez.

Cada vez que un error así se evita antes de compilar, alguien, en algún lugar, no tiene que subir veintiún pisos a pie.

Huella de carbono del software: cómo el código eficiente reduce emisiones

2026-11-05T00:00:00+00:00

El software no tiene chimenea, pero decide cuántos servidores se encienden y durante cuánto tiempo. Por eso ingeniería y sostenibilidad suelen perseguir lo mismo: hacer el mismo trabajo con menos recursos.

Del código a las emisiones

El código está al inicio de la cadena, y por eso influye en todo lo que viene después.

La Green Software Foundation lo plantea así: la electricidad es un indicador indirecto del carbono, de modo que el objetivo es usar la menor energía posible por unidad de trabajo.

El tamaño del problema

Según la Agencia Internacional de la Energía, los centros de datos consumieron unos 415 TWh en 2024, alrededor del 1,5 % de la electricidad mundial. Su proyección es que se duplique con creces hacia 2030.

Consumo eléctrico de los centros de datos. El dato de 2030 es una proyección de la AIE.

Cómo estimar tu huella

La cuenta básica cabe en una línea:

El PUE mide el consumo adicional del centro de datos, como la refrigeración: con 1,5, cada 10 kWh de cómputo consumen 15 kWh de la red. La intensidad de carbono indica cuánto CO₂ emite cada kWh, y cambia mucho según el país.

Un ejemplo con valores supuestos: 20 servidores a 300 W, PUE de 1,5 y 0,4 kg de CO₂ por kWh.

Paso	Cálculo	Resultado
Energía al año	20 × 0,3 kW × 8760 h	52 560 kWh
Con el centro de datos	52 560 × 1,5	78 840 kWh
Emisiones	78 840 × 0,4	31,5 t de CO₂

Si el mismo trabajo se hace con 10 servidores, la cifra baja a unas 15,8 toneladas, y la factura de esos servidores también se reduce a la mitad. Es una simplificación: un servidor real no consume siempre lo mismo. Sirve para ver qué variables mandan.

¿Cuánto influye el lenguaje?

Sobre esto hay un dato muy citado, y conviene leerlo con cuidado. Un estudio de 2017 comparó la energía de 27 lenguajes en diez problemas de referencia.

Lenguaje	Energía relativa a C
C	1,00
Rust	1,03
C++	1,34
Python	75,88

Amazon lo llevó al debate público en Sustainability with Rust, de 2022. Allí señala que C y Rust fueron aproximadamente un 50 % más eficientes que Java y un 98 % más que Python, y sostiene que su adopción amplia podría reducir a la mitad la energía de cómputo. También cuenta el caso de Tenable, que al reescribir un componente de JavaScript a Rust redujo un 75 % el uso de CPU y un 95 % el de memoria.

Ahora, lo que esas cifras no dicen:

Son programas de referencia, no tu sistema. Tu aplicación probablemente pasa mucho tiempo esperando a la red o a la base de datos.
La energía sigue al tiempo de ejecución. Un estudio de 2024 concluye que el lenguaje no tiene un efecto significativo en la energía más allá del tiempo de ejecución, y critica que estos rankings se interpreten como causa directa.
Amazon no midió energía en esos casos. La infiere de CPU, memoria y servidores. Además, patrocina el proyecto Rust.
El ahorro puede consumirse. Si el cómputo se abarata, es posible que se use más.

La conclusión práctica es más sobria y más útil: Rust ayuda cuando reduce los servidores que necesitas. Si no los reduce, no cambia tu huella.

Por dónde empezar

Ordenadas por lo que suelen aportar, estas son las palancas:

No hacer trabajo innecesario. Tareas duplicadas, datos que nadie consulta, ambientes encendidos sin uso.
Ajustar la capacidad. Un servidor desocupado sigue consumiendo. Es mejor menos máquinas, mejor aprovechadas.
Mejorar lo que más se ejecuta. Un algoritmo mejor, menos copias de datos, buena caché.
Cambiar el lenguaje de la ruta crítica. Aquí entra Rust, junto con el ahorro de memoria frente a un recolector de basura.
Elegir dónde y cuándo ejecutar. Una región con energía más limpia, o tareas por lotes en mejores horarios.
Alargar la vida del hardware. Si tu software pide menos, los equipos duran más, y fabricarlos también emite.

Un argumento de negocio

Rara vez hace falta un presupuesto de sostenibilidad para esto. La eficiencia se paga sola, porque el mismo cambio aparece en la factura de la nube. Y si tu empresa reporta emisiones, tendrás una cifra medida que mostrar, en lugar de una promesa.

Eso sí, mide antes de anunciar. Un ahorro de CPU es un dato. Una reducción de emisiones es un cálculo con supuestos, y debe presentarse como tal.

Tu primer microservicio en Rust, y cuánto rinde de verdad

2026-11-05T00:00:00+00:00

Hay muchas comparaciones de rendimiento en internet. Esta la hicimos nosotros, con código que puedes copiar. Construimos un microservicio pequeño, lo medimos frente a tres alternativas y publicamos también lo que no favorece a Rust.

Qué vamos a construir

Un servicio que devuelve clientes en JSON, con un endpoint de salud, registro estructurado y apagado ordenado. Son las piezas básicas de un servicio de verdad.

El ejemplo no usa base de datos: así medimos el servicio y no otra cosa.

Requisitos

Necesitas Rust instalado. Crea el proyecto:

cargo new clientes
cd clientes

Las dependencias

Este es el Cargo.toml. El perfil de compilación final importa: optimiza al máximo y deja un binario pequeño.

[package]
name = "clientes"
version = "0.1.0"
edition = "2024"

[dependencies]
actix-web = "4"
anyhow = "1"
clap = { version = "4", features = ["derive"] }
mimalloc = { version = "0.1", default-features = false }
serde = { version = "1", features = ["derive"] }
serde_json = "1"
thiserror = "2"
tokio = { version = "1", features = ["full"] }
tracing = "0.1"
tracing-actix-web = "0.7"
tracing-subscriber = { version = "0.3", features = ["env-filter"] }

[build-dependencies]
chrono = { version = "0.4", features = ["clock"] }

[profile.release]
opt-level = 3
lto = true
codegen-units = 1
panic = "abort"
strip = true
debug = 0

Cada pieza cumple una función:

Paquete	Para qué sirve
`actix-web`	El servidor HTTP
`tokio`	El entorno asíncrono
`serde`, `serde_json`	Convertir a JSON
`tracing`	Registro estructurado
`clap`	Argumentos de línea de comandos
`anyhow`, `thiserror`	Manejo de errores
`mimalloc`	Un asignador de memoria rápido

El código

src/cli.rs define los argumentos. Con -v muestra la versión y con config imprime la configuración:

use clap::{Parser, Subcommand};

pub const PKG_NAME: &str = env!("CARGO_PKG_NAME");
pub const PKG_VERSION: &str = env!("CARGO_PKG_VERSION");
pub const GIT_HASH: &str = env!("GIT_HASH");
pub const BUILD_DATE: &str = env!("BUILD_DATE");
pub const PKG_ARCH: &str = env!("ARCH");

#[derive(Parser)]
#[command(name = "clientes", about = "Microservicio de ejemplo", disable_version_flag = true)]
pub struct Cli {
    /// Muestra la versión y termina
    #[arg(short = 'v', long = "version")]
    pub version: bool,

    #[command(subcommand)]
    pub command: Option<Commands>,
}

#[derive(Subcommand)]
pub enum Commands {
    /// Muestra la configuración como JSON
    Config,
}

pub fn get_version() -> String {
    format!("{PKG_NAME} {PKG_VERSION} ({GIT_HASH} {BUILD_DATE}) {PKG_ARCH}")
}

src/main.rs contiene el servicio. Fíjate en los errores: AppError define qué respuesta recibe el cliente, y un cliente inexistente devuelve un 404 en JSON. Al recibir SIGTERM o Ctrl+C, el servicio termina lo que tiene en curso antes de apagarse.

mod cli;

use std::collections::HashMap;

use actix_web::{App, HttpResponse, HttpServer, ResponseError, get, http::StatusCode, web};
use anyhow::{Context, Result};
use clap::Parser;
use serde::Serialize;
use tracing_actix_web::TracingLogger;

use cli::{Cli, Commands, get_version};

#[global_allocator]
static GLOBAL: mimalloc::MiMalloc = mimalloc::MiMalloc;

#[derive(Serialize)]
struct Config {
    host: String,
    port: u16,
    workers: usize,
}

impl Default for Config {
    fn default() -> Self {
        let workers = std::env::var("WORKERS")
            .ok()
            .and_then(|v| v.parse().ok())
            .unwrap_or_else(num_cpus);
        let port = std::env::var("PORT")
            .ok()
            .and_then(|v| v.parse().ok())
            .unwrap_or(8080);
        Self { host: "127.0.0.1".into(), port, workers }
    }
}

fn num_cpus() -> usize {
    std::thread::available_parallelism().map_or(1, |n| n.get())
}

#[derive(Clone, Serialize)]
struct Cliente {
    id: u32,
    nombre: String,
    activo: bool,
}

#[derive(Debug, Serialize)]
struct ErrorBody {
    error: String,
    message: String,
}

#[derive(Debug, thiserror::Error)]
enum AppError {
    #[error("cliente {0} no encontrado")]
    NoEncontrado(u32),
}

impl ResponseError for AppError {
    fn status_code(&self) -> StatusCode {
        StatusCode::NOT_FOUND
    }

    fn error_response(&self) -> HttpResponse {
        let status = self.status_code();
        HttpResponse::build(status).json(ErrorBody {
            error: status.canonical_reason().unwrap_or("error").to_string(),
            message: self.to_string(),
        })
    }
}

type Clientes = web::Data<HashMap<u32, Cliente>>;

#[get("/salud")]
async fn salud() -> &'static str {
    "ok"
}

#[get("/clientes/{id}")]
async fn cliente(id: web::Path<u32>, datos: Clientes) -> Result<web::Json<Cliente>, AppError> {
    let id = id.into_inner();
    let cliente = datos.get(&id).cloned().ok_or(AppError::NoEncontrado(id))?;
    Ok(web::Json(cliente))
}

fn init_logger() {
    tracing_subscriber::fmt()
        .with_env_filter(
            tracing_subscriber::EnvFilter::try_from_default_env()
                .unwrap_or_else(|_| tracing_subscriber::EnvFilter::new("info")),
        )
        .with_target(true)
        .with_thread_ids(false)
        .compact()
        .init();
}

async fn shutdown(handle: actix_web::dev::ServerHandle) {
    use tokio::signal::unix::{SignalKind, signal};

    let mut sigterm = signal(SignalKind::terminate()).expect("no se pudo escuchar SIGTERM");
    tokio::select! {
        _ = sigterm.recv() => {}
        _ = tokio::signal::ctrl_c() => {}
    }
    tracing::info!("shutdown signal received, initiating graceful shutdown");
    handle.stop(true).await;
}

#[actix_web::main]
async fn main() -> Result<()> {
    let cli = Cli::parse();
    if cli.version {
        println!("{}", get_version());
        return Ok(());
    }

    let config = Config::default();
    if let Some(Commands::Config) = cli.command {
        println!("{}", serde_json::to_string_pretty(&config)?);
        return Ok(());
    }

    init_logger();
    tracing::info!(version = %get_version(), "starting service");

    let total: u32 = std::env::var("CLIENTES")
        .ok()
        .and_then(|v| v.parse().ok())
        .unwrap_or(1000);
    let datos: HashMap<u32, Cliente> = (1..=total)
        .map(|id| (id, Cliente { id, nombre: format!("Cliente {id}"), activo: id % 2 == 0 }))
        .collect();
    let datos = web::Data::new(datos);

    let servidor = HttpServer::new(move || {
        App::new()
            .wrap(TracingLogger::default())
            .app_data(datos.clone())
            .service(salud)
            .service(cliente)
    })
    .workers(config.workers)
    .disable_signals()
    .bind((config.host.as_str(), config.port))
    .with_context(|| format!("failed to bind to port {}", config.port))?
    .run();

    tracing::info!(host = %config.host, port = config.port, "server running");
    tokio::spawn(shutdown(servidor.handle()));
    servidor.await.context("server error")?;
    tracing::info!("server shutdown complete");
    Ok(())
}

Por último, build.rs graba en el binario el commit, la fecha y la arquitectura, para saber siempre qué versión corre en producción:

use std::process::Command;

fn main() {
    let git_hash = Command::new("git")
        .args(["rev-parse", "--short", "HEAD"])
        .output()
        .ok()
        .and_then(|output| String::from_utf8(output.stdout).ok())
        .map(|s| s.trim().to_string())
        .filter(|s| !s.is_empty())
        .unwrap_or_else(|| "unknown".to_string());
    let build_date = chrono::Utc::now().format("%Y-%m-%d").to_string();
    let arch = std::env::var("CARGO_CFG_TARGET_ARCH").unwrap_or_else(|_| "unknown".to_string());

    println!("cargo:rustc-env=GIT_HASH={git_hash}");
    println!("cargo:rustc-env=BUILD_DATE={build_date}");
    println!("cargo:rustc-env=ARCH={arch}");
    println!("cargo:rerun-if-changed=.git/HEAD");
}

Compilar y probar

cargo build --release
./target/release/clientes

Desde otra terminal, con xh o curl:

xh :8080/clientes/500

{ "id": 500, "nombre": "Cliente 500", "activo": true }

Cómo lo medimos

Para generar carga usamos oha:

oha -z 10s -c 64 http://127.0.0.1:8080/clientes/500

Escribimos el mismo endpoint en Go, Node.js y Python, y en todos usamos un solo núcleo, para que la comparación sea justa. Node y Python ya funcionan así por defecto. Rust y Go se limitaron con WORKERS=1 y GOMAXPROCS=1.

Ver el método completo y el código de las alternativas

Equipo: MacBook Pro con Apple M4 Max, 14 núcleos y 36 GB de memoria, macOS. El generador de carga corrió en la misma máquina.
Versiones: Rust 1.96.1 con Actix Web 4.18.1, Go 1.27.3 con net/http, Node.js 26.8.1 con node:http, Python 3.9.6 con FastAPI 0.128.8 y Uvicorn 0.39.0.
Prueba de capacidad: 10 s, 64 conexiones.
Prueba de carga fija: 15 s a 2000 peticiones por segundo, con corrección de latencia.
Repeticiones: tres por servicio; mostramos la mediana.
Sin TLS, base de datos ni red real.

Go:

package main

import (
	"encoding/json"
	"fmt"
	"net/http"
	"os"
	"strconv"
)

type Cliente struct {
	ID     int    `json:"id"`
	Nombre string `json:"nombre"`
	Activo bool   `json:"activo"`
}

func main() {
	datos := map[int]Cliente{}
	total, err := strconv.Atoi(os.Getenv("CLIENTES"))
	if err != nil {
		total = 1000
	}
	for id := 1; id <= total; id++ {
		datos[id] = Cliente{id, fmt.Sprintf("Cliente %d", id), id%2 == 0}
	}
	http.HandleFunc("GET /clientes/{id}", func(w http.ResponseWriter, r *http.Request) {
		id, _ := strconv.Atoi(r.PathValue("id"))
		c, ok := datos[id]
		w.Header().Set("Content-Type", "application/json")
		if !ok {
			w.WriteHeader(http.StatusNotFound)
			w.Write([]byte(`{"error":"no encontrado"}`))
			return
		}
		json.NewEncoder(w).Encode(c)
	})
	http.ListenAndServe("127.0.0.1:8082", nil)
}

Node.js:

import http from 'node:http';
const datos = new Map();
const total = Number(process.env.CLIENTES ?? 1000);
for (let id = 1; id <= total; id++) datos.set(id, { id, nombre: `Cliente ${id}`, activo: id % 2 === 0 });
http.createServer((req, res) => {
  const m = req.url.match(/^\/clientes\/(\d+)$/);
  const c = m && datos.get(Number(m[1]));
  if (!c) { res.writeHead(404, { 'content-type': 'application/json' }); return res.end('{"error":"no encontrado"}'); }
  res.writeHead(200, { 'content-type': 'application/json' });
  res.end(JSON.stringify(c));
}).listen(8081, '127.0.0.1');

Python:

from fastapi import FastAPI, HTTPException

app = FastAPI()
datos = {i: {"id": i, "nombre": f"Cliente {i}", "activo": i % 2 == 0} for i in range(1, 1001)}


@app.get("/clientes/{id}")
async def cliente(id: int):
    if id not in datos:
        raise HTTPException(status_code=404, detail="no encontrado")
    return datos[id]

Primer resultado: un servicio pequeño

Con 1000 registros, esto es lo que obtuvimos:

Medición propia: mediana de tres ejecuciones con un núcleo y 1000 registros. Mayor es mejor en capacidad; menor es mejor en memoria y CPU.

Con 1 núcleo	Rust	Go	Node.js	Python
Capacidad máxima (pet/s)	104 567	101 489	90 580	14 024
Memoria (MB)	4,7	15,5	65,9	38,5
CPU a 2000 pet/s	6,6 %	8,0 %	8,1 %	34,5 %
Latencia p50 a 2000 pet/s (ms)	0,13	0,11	0,12	0,39
Latencia p99 a 2000 pet/s (ms)	1,72	1,27	1,27	3,64
Tamaño del binario (MB)	3,4	9,4	n/a	n/a

Lo que dicen estos números:

En latencia no hay ganador. A carga moderada, Rust, Go y Node.js están empatados. Las diferencias del p99 entran en el ruido de la medición.
La capacidad está cerca. Rust, Go y Node.js superan las 90 000 peticiones por segundo en un núcleo. Muy pocos servicios llegan a eso.
La memoria es la gran diferencia: Rust usa un tercio que Go y unas catorce veces menos que Node.js.
Python queda atrás, pero no es lento para muchos casos. Sigue atendiendo 14 000 peticiones por segundo. Si haces veinte, da lo mismo.

Conviene decirlo sin rodeos: si este fuera tu sistema, ninguna de estas cifras justifica por sí sola una migración.

Segundo resultado: muchos datos en memoria

Aquí es donde se separan los caminos. Repetimos la prueba con 5 millones de registros en memoria y 20 000 peticiones por segundo, durante 25 a 30 segundos. Es el caso difícil para un recolector, como explicamos en esta nota.

Medición propia. Menor es mejor. Rust gana en memoria; Node.js, en latencia con un núcleo.

5 millones de registros	Rust	Go	Node.js
Memoria real (MB)	408	865	875
p99 con 1 núcleo (ms)	2,2 a 10,9	81 a 127	2,1 a 2,9
p99.9 con 1 núcleo (ms)	6,8 a 37	152 a 206	5,6 a 28
p99 con 4 núcleos (ms)	2,3	2,6	n/a
p99.9 con 4 núcleos (ms)	5,3	17,4	n/a

Mostramos rangos porque hicimos cuatro ejecuciones con un núcleo, y variaron bastante. Con cuatro núcleos hicimos solo una, de modo que esas cifras son orientativas.

Este resultado nos parece más útil que uno que solo elogie a Rust:

Go con un núcleo sufre. Su p99 sube a más de 80 ms, unas 40 veces lo normal. Es lo que predice su guía oficial: el recolector recorre los datos vivos y necesita CPU. Con un solo núcleo, compite con las peticiones.
Con 4 núcleos, casi desaparece. El p99 de Go baja a 2,6 ms. Antes de reescribir, a veces basta con darle CPU, aunque esos núcleos también se pagan.
Node.js sorprendió. Su p99 igualó o superó al de Rust. Una explicación probable es que V8 separa objetos jóvenes y viejos, y no recorre todos los datos en cada ciclo. No perfilamos este punto, así que tómalo como hipótesis. No todos los recolectores se comportan igual.
Rust no fue el más estable en p99. Varió de 2,2 a 10,9 ms, y no investigamos la causa. Su p99.9 fue el mejor en la prueba con cuatro núcleos, pero Node.js estuvo a su nivel en algunas ejecuciones.
La memoria se mantiene: Rust necesitó menos de la mitad que Go y que Node.js para los mismos datos.

Una lección sobre medir: ps nos mostró 360 MB para Node.js, porque no contaba la memoria comprimida por macOS. Con footprint, eran 875 MB. Por eso ese dato de la tabla difiere de lo que verías en ps.

Qué significa para tu negocio

Si lo traducimos a decisiones:

Servicios sencillos: no migres por rendimiento. Cualquiera de estas opciones te sirve.
Muchas instancias pequeñas: aquí la memoria pesa. Un servicio de 5 MB frente a uno de 66 MB cambia cuántos caben en un servidor, y cuánta energía consumes.
Grandes datos en memoria con poca CPU: ahí es donde un recolector puede dar picos, y donde Rust ofrece más margen.
Python en la ruta crítica: suele ser el cambio con más retorno, y no siempre exige reescribir todo. Mira cómo migrar por partes.

Lo que esta prueba no dice

Un benchmark es una foto, no un veredicto:

El endpoint casi no hace trabajo. Un sistema real pasa la mayor parte del tiempo en la base de datos y en la red.
El generador de carga compartió máquina con el servicio, lo que añade ruido.
macOS no es tu servidor de producción, y Python 3.9 no es la versión más reciente.
Limitar a un núcleo favorece a Node.js y Python, que por defecto usan uno, y perjudica a Go, que está pensado para usar varios.
No ajustamos parámetros como GOGC ni la memoria de V8.

Por eso lo más valioso de esta nota no son las cifras, sino el método. Repite la prueba con tu endpoint, tus datos y tu carga.

Noticias de Rust: Bun, Ubuntu, Astro, Git y Linux lo adoptan

2026-11-05T00:00:00+00:00

Si necesitas una foto de lo que está pasando con Rust, aquí va. Reunimos las noticias más importantes de 2025 y 2026, cada una con su fuente original, y aclaramos qué cambió de verdad, porque los titulares suelen exagerar.

Fecha	Noticia
Oct. 2026	Ubuntu 26.10 completa sus utilidades básicas en Rust
Jul. 2026	Bun migra de Zig a Rust
Jun. 2026	Git activa Rust por defecto
Jun. 2026	Astro 7 reescribe su compilador en Rust
Abr. 2026	Linux 7.0 quita a Rust la etiqueta experimental
Abr. 2026	Rust llega al módem del Pixel 10
Mar. 2026	Astral, creadora de uv y Ruff, acuerda unirse a OpenAI
Ene. 2026	WhatsApp distribuye Rust a miles de millones de dispositivos
2026	Chrome retira FreeType de su motor
Nov. 2025	Android baja del 20 % en fallos de memoria
Oct. 2025	Turbopack, por defecto en Next.js
Fines de 2025	APT anuncia que dependerá de Rust
Sep. 2025	Cloudflare reescribe su sistema central

Ubuntu: las utilidades básicas ya están en Rust

Pocos comandos son tan básicos como ls, cp o sudo. Ubuntu los está cambiando por versiones en Rust, y lo hizo por etapas.

Ubuntu 25.10: sudo-rs pasó a ser el sudo por defecto, y rust-coreutils empezó a dar las utilidades básicas. cp, mv y rm siguieron siendo de GNU por errores pendientes.
Ubuntu 26.04 LTS: esos cambios llegaron a la versión de soporte extendido, la que usan muchos servidores. Sus notas mencionan mejoras importantes de rendimiento, por ejemplo en base64.
Ubuntu 26.10: publicado el 15 de octubre de 2026, ya ejecuta sus utilidades básicas por completo sobre uutils, incluidos cp, mv y rm. También suma Sequoia PGP, una implementación de OpenPGP en Rust, a su archivo principal.

Por qué importa: son programas de hace décadas, instalados en millones de máquinas. El matiz es que gpg sigue disponible, y Ubuntu documenta cómo volver a las versiones de GNU. No fue un cambio sin dificultades: por eso tomó varias versiones.

Bun: de Zig a Rust en semanas

Es probablemente la noticia más llamativa del año. Bun, un entorno de ejecución de JavaScript, anunció en julio de 2026 que dejaba Zig: la versión 1.3.14 fue la última en ese lenguaje, y la 1.4 es la primera en Rust. Bun pertenece a Anthropic desde diciembre de 2025.

La razón no fue el rendimiento, sino la clase de errores. Muchos de sus fallos eran usos después de liberar, dobles liberaciones y memoria olvidada en rutas de error, los mismos que ilustramos aquí. Como resume el artículo: los errores del compilador son mejor ciclo de retroalimentación que una guía de estilo.

Las cifras que publicó Bun:

Medida	Resultado
Código original	535 496 líneas de Zig
Código en Rust	Unas 780 000 líneas, cerca del 4 % en `unsafe`
Rendimiento HTTP	Entre 2,8 % y 4,8 % mejor
Tamaño del binario	Cerca de 20 % menor
Memoria en una prueba de 2000 compilaciones	De 6745 MB a 609 MB
Regresiones conocidas	19, todas corregidas

Lo que hay que leer con cuidado:

La migración fue una traducción masiva, apoyada en asistentes de IA y en su suite de pruebas. Según Bun, tomó 11 días y cerca de USD 165 000 en API, frente a un estimado de tres ingenieros durante un año. Son cifras de la propia empresa, cuya dueña vende esa IA.
Cerca del 20 % de Bun sigue en C++, y sigue usando JavaScriptCore, BoringSSL y SQLite. No todo está en Rust.
Una traducción directa no equivale a código bien diseñado, y 19 regresiones son un recordatorio de que estos cambios tienen costo.

Lo analizamos desde otro ángulo en Rust y código generado por IA.

Git: Rust pasa a ser requisito

Git, la herramienta que usa casi todo desarrollador, está adoptando Rust de forma gradual. Según su documentación:

Git 2.49: empezó la adopción, de forma opcional.
Git 2.55: activó Rust por defecto. Si falta en la máquina que compila, la compilación falla, aunque todavía se puede desactivar.
Git 3.0: Rust será obligatorio para compilar.

El matiz: esto afecta a quien compila Git, no a quien lo usa. No es una reescritura: el proyecto avanza por partes, y prepara el código xdiff. Además, Git aclara que evaluará el impacto en las distribuciones, y que podría aplazar la exigencia.

Astro 7: un compilador nuevo

Astro 7 salió el 22 de junio de 2026 con un compilador .astro reescrito en Rust, que reemplaza al anterior en Go. Su proceso de Markdown también pasó a Sätteri, escrito en Rust, y Vite 8 incorpora Rolldown como empaquetador.

Algunos titulares dicen que Astro "migró su núcleo a Rust", y conviene precisarlo: migraron piezas clave, mientras que la configuración, los complementos y tu código siguen en JavaScript o TypeScript.

El dato más interesante es otro. Las compilaciones completas mejoraron entre 15 % y 61 %, pero el compilador nuevo por sí solo aportó cerca del 6 % en la documentación de Astro, porque, según el equipo, rara vez es el cuello de botella. Es una buena lección: cambiar de lenguaje ayuda poco si no atacas el cuello de botella. Lo mismo vimos al medir nuestro microservicio.

Linux 7.0: Rust deja de ser un experimento

En diciembre de 2025, la cumbre de mantenedores del kernel dio por concluido el experimento con Rust, y Linux 7.0 lo hizo oficial al retirar esa etiqueta.

El matiz: Rust sigue siendo opcional, se usa sobre todo en controladores nuevos, y muchos subsistemas aún ofrecen poca o ninguna interfaz. El kernel no se está reescribiendo.

Pixel 10: Rust en el módem

Google integró un analizador de DNS en Rust en el firmware del módem del Pixel 10, el primer Pixel con un lenguaje seguro en memoria en ese componente.

Por qué importa: el módem procesa datos no confiables que llegan por la red, y es una superficie de ataque remota. Es otro ejemplo del patrón más rentable: no reescribir todo, sino proteger el componente que recibe datos peligrosos.

Astral y OpenAI

En marzo de 2026, Astral, creadora de uv y Ruff, acordó unirse al equipo de Codex de OpenAI, y se comprometió a mantener sus herramientas abiertas. No encontramos confirmación del cierre de la operación, de modo que la presentamos como un acuerdo.

Por qué importa: en pocos meses, dos empresas de IA se han acercado a herramientas de desarrollo hechas en Rust: Anthropic compró Bun, y OpenAI acordó sumar a Astral.

WhatsApp: la mayor distribución de Rust

Meta reemplazó 160 000 líneas de C++ por 90 000 de Rust en wamedia, la biblioteca que revisa archivos multimedia. Llega cada mes a miles de millones de dispositivos, y Meta la considera el mayor despliegue global de una biblioteca en Rust.

Por qué importa: ese código procesa automáticamente archivos no confiables, justo donde un fallo de memoria es más peligroso.

Chrome retira FreeType

Chrome reemplazó FreeType con Skrifa, escrita en Rust, para procesar fuentes, y en Chrome 145 lo retiró de Blink. Google reporta 39 errores encontrados al probar el código nuevo, ninguno crítico para la seguridad.

Android baja del 20 %

En noviembre de 2025, Google informó que los fallos de memoria bajaron del 20 % de las vulnerabilidades de Android por primera vez. Lo explicamos en El 70 %.

Next.js adopta Turbopack

Next.js 16 convirtió a Turbopack, escrito en Rust, en su empaquetador por defecto en octubre de 2025. Vercel habla de compilaciones de producción de 2 a 5 veces más rápidas, según sus propias pruebas.

APT dependerá de Rust

A fines de 2025, un mantenedor de APT anunció que el gestor de paquetes de Debian tendría dependencias obligatorias de Rust, no antes de mayo de 2026, para procesar con más seguridad formatos como .deb y .tar.

El matiz: fue el anuncio de un mantenedor, no una declaración oficial de Debian, y generó críticas. No confirmamos en qué estado está hoy.

Cloudflare: FL2, y un tropiezo

En septiembre de 2025, Cloudflare contó la reescritura en Rust de su sistema central. Reportó respuestas 10 ms más rápidas en la mediana y menos de la mitad de CPU que el sistema anterior.

Dos meses después, una caída del 18 de noviembre se originó en un pánico en ese mismo código, por un unwrap(). Rust evita fallos de memoria, no errores de lógica ni malas decisiones de operación.

Qué tienen en común

Mirando el conjunto, hay cuatro patrones:

Se empieza por lo expuesto: parsers, módems y archivos no confiables. Lo vimos en WhatsApp, el Pixel y Chrome.
Casi nadie reescribe todo. Linux, Git, Astro y Bun conservan otros lenguajes.
El motivo principal suele ser la seguridad o el mantenimiento, más que la velocidad.
La IA abarata las migraciones, pero no reemplaza las pruebas ni el criterio.

Hay también una lectura menos entusiasta: que otros adopten Rust no significa que a ti te convenga. Apple, por ejemplo, persigue la seguridad de memoria con Swift. Cada caso resolvía un problema concreto. Antes de seguirlos, responde las cinco preguntas antes de migrar, y revisa quién usa Rust para encontrar casos parecidos al tuyo.

Actualizaremos esta nota cuando haya novedades importantes.

Recolector de basura vs. Rust: pausas, picos y latencia

2026-11-05T00:00:00+00:00

Todo programa debe devolver la memoria que ya no usa. La pregunta no es si cuesta, sino quién paga, cuánto y en qué momento. Esa respuesta define cómo se comporta tu sistema bajo carga.

Esta nota no busca declarar un ganador. Para muchísimos sistemas, un recolector moderno es la decisión correcta. Pero si tu negocio depende de responder siempre a tiempo, conviene entender dónde nacen los picos.

Tres formas de devolver la memoria

Las tres liberan memoria. Cambia quién decide y cuándo ocurre.

Manual, como en C: tú decides cuándo liberar. Es rápido y predecible, pero un error produce estos fallos.
Recolector de basura, como en Java, Go o C#: un proceso busca lo que ya no se usa y lo recupera más tarde. Es seguro y cómodo.
Propiedad, como en Rust: el compilador decide dónde liberar, y lo escribe en el programa. El Libro de Rust lo resume así: al salir de alcance, el valor se libera.

Cómo trabaja un recolector de basura

La idea central es la alcanzabilidad: si ningún camino lleva a un objeto, nadie podrá volver a usarlo.

Marcar: recorrer todo lo que se alcanza desde las raíces. Barrer: recuperar el resto.

Los recolectores actuales son mucho más sofisticados que este esquema. Trabajan en paralelo a tu programa, dividen los objetos por edad y compactan la memoria. Python combina otra técnica, el conteo de referencias, con un recolector para los ciclos.

El costo no es solo la pausa

Se suele hablar de las pausas, pero son solo uno de tres costos:

Memoria. El recolector necesita espacio para trabajar. En Go, duplicar GOGC duplica la memoria adicional y reduce a la mitad el costo de CPU: es un intercambio explícito. Con el valor habitual de 100, el montón puede crecer hasta cerca del doble de los datos vivos.
CPU. Marcar objetos es trabajo real. La misma guía de Go indica que el recolector usa el 25 % de los recursos de CPU durante la fase de marcado.
Variación. El trabajo llega en momentos que tu código no eligió, y compite con las peticiones en curso.

Un recolector necesita holgura para trabajar. Ilustración conceptual, no medición.

Por qué aparecen los picos

Go hace casi todo su trabajo de forma concurrente, y sus pausas completas son breves. Aun así, su guía enumera varias fuentes de latencia: las pausas breves entre fases, los retrasos de planificación por el 25 % de CPU, las rutinas que deben ayudar al recolector cuando se asigna mucha memoria y el costo extra de escribir punteros durante el marcado.

Ilustración conceptual, no medición. El tamaño de los picos depende del recolector, del montón y de la carga.

El tiempo de un ciclo crece con los datos vivos y con la cantidad de punteros por recorrer. Por eso las cachés grandes en memoria son el caso difícil: cuanto más útil es la caché, más trabajo le das al recolector.

Qué le pasa al flujo del sistema

Aquí está lo que más se subestima: una pausa no solo retrasa a quien estaba siendo atendido. Las peticiones siguen llegando, se acumulan y hay que atenderlas después, con la capacidad que sobra.

Con un 70 % de carga, una pausa de 50 ms afecta unos 167 ms de tráfico. La cola dura más que la pausa.

Cuanto más cargado está el sistema, menos capacidad libre tiene para recuperarse. La misma pausa duele mucho más al 90 % que al 50 %.

Pausa 50 msPeticiones por segundo 1000Carga del servicio 70 %

Peticiones retenidas: 50
Tiempo en vaciar la cola: 117 ms
Peticiones afectadas: 167

Simulador con un modelo simplificado: cola = peticiones × pausa, y se vacía con la capacidad libre. La animación va en cámara lenta. Prueba subir la carga a 90 %.

La regla es sencilla. Con una carga u, la cola tarda en vaciarse la duración de la pausa multiplicada por u / (1 − u). Una pausa de 50 ms toma 50 ms más en vaciarse al 50 % de carga, y 450 ms al 90 %. Un sistema real es más complejo, pero la tendencia se mantiene.

El promedio esconde el problema

Si mides solo el promedio, nunca verás esto. Por eso se usan percentiles: p99 es el tiempo por debajo del cual está el 99 % de las peticiones. Dicho de otro modo, 1 de cada 100 tarda más.

La mediana y el promedio cuentan la historia de la mayoría. El p99 cuenta la de quien sufre. Ilustración conceptual.

Un p99 alto no es un detalle estadístico. En un servicio con un millón de peticiones al día, son diez mil respuestas lentas diarias, y suelen concentrarse en los momentos de mayor carga, cuando más importan.

Con muchos servicios, el pico deja de ser raro

Una acción de un usuario suele tocar varios servicios, y su respuesta es tan lenta como el más lento. Jeff Dean y Luiz Barroso lo describieron en The Tail at Scale:

Porcentaje de peticiones de usuario con al menos una respuesta lenta, si cada servicio se demora en 1 de cada 100 llamadas: 1 − 0,99ⁿ. Es aritmética, no una medición.

Lo que en un servicio parecía raro, en un sistema de cien servicios le pasa a la mayoría de las peticiones.

Un caso real: Discord

El caso más citado es el de Discord. Su servicio Read States, escrito en Go, guardaba decenas de millones de registros en una caché y mostraba picos periódicos de latencia. Discord los atribuyó al recolector: debía recorrer toda la caché, y Go fuerza una recolección al menos cada dos minutos. Reducir la caché aliviaba los picos, pero empeoraba el p99, porque más consultas iban a la base de datos.

Al reescribirlo en Rust, los picos desaparecieron. Con optimizaciones, superó a la versión anterior en latencia, CPU y memoria. Según un artículo de AWS, la versión en Rust fue más de 10 veces más rápida en general y redujo 100 veces las peores latencias.

Conviene leerlo con cuidado:

Se trata de un servicio concreto, con un patrón muy favorable a Rust.
Usaba Go 1.9, y el artículo es de 2020. Go ha seguido mejorando.
Los propios autores aclaran que no recomiendan reescribirlo todo en Rust.

Otro caso: Apple, de Java a Swift

El problema no es exclusivo de Go, y la solución no siempre es Rust. En 2025, Apple contó que migró de Java a Swift el servicio que revisa contraseñas filtradas. Tras ajustar el recolector G1, seguía viendo pausas prolongadas bajo carga. Con Swift reportó cerca de un 40 % más de capacidad, memoria de cientos de megabytes por instancia, frente a decenas de gigabytes en Java, y latencias menores a 1 ms en el 99,9 % de las peticiones.

Es un caso publicado por la empresa creadora de Swift, pero la lección es general: en servicios muy exigentes, una gestión de memoria determinista puede cambiar el resultado, sea con Rust o con otro lenguaje.

Cómo libera Rust

En Rust no hay un proceso aparte. El punto de liberación queda fijado al compilar:

fn main() {
    {
        let reporte = vec![0u8; 1024];
        println!("{} bytes", reporte.len());
    } // `reporte` se libera aquí, en este punto exacto

    println!("La memoria ya se devolvió");
}

Por eso el costo es predecible: ocurre siempre en el mismo lugar del código, y lo paga la operación que creó el problema, no una petición ajena. Lo explicamos en la guía de ownership.

Lo medimos nosotros

Quisimos comprobarlo. En nuestro microservicio de ejemplo, con 5 millones de registros en memoria y un solo núcleo, el p99 de Go subió a más de 80 ms. Con 4 núcleos bajó a 2,6 ms. Node.js, también con recolector, se mantuvo cerca de 2 ms con un núcleo. La conclusión es que no todos los recolectores se comportan igual, y que los recursos disponibles cambian el resultado.

Rust también puede tener picos

Sin recolector no hay magia. Estas son las fuentes habituales de picos en Rust:

Liberar estructuras enormes. Soltar un mapa de un millón de entradas toma tiempo, y ocurre justo en esa línea.
Bloquear el hilo en código asíncrono. Una operación lenta dentro de una tarea detiene a las demás que comparten ese hilo.
Contención en candados. Un Mutex muy disputado produce colas, en cualquier lenguaje.
Reservar memoria en la ruta crítica. El asignador tampoco es gratis.
El mundo exterior. La red, el disco y la base de datos no saben en qué lenguaje escribes.

La diferencia es que estos costos están a la vista, en tu código, y puedes moverlos de lugar:

use std::collections::HashMap;
use std::thread;

fn main() {
    let cache: HashMap<u64, String> =
        (0..1_000_000).map(|i| (i, i.to_string())).collect();

    // Liberar un millón de entradas toma tiempo.
    // Se entrega a otro hilo para no frenar la petición en curso.
    thread::spawn(move || drop(cache));

    println!("La petición sigue su curso");
}

Los recolectores modernos son muy buenos

Sería deshonesto comparar Rust con los recolectores de hace quince años. ZGC, de Java, hace su trabajo costoso de forma concurrente, sin detener los hilos de la aplicación más de un milisegundo, con pausas independientes del tamaño del montón y para montones de hasta 16 TB.

Eso cambia la discusión, pero no la elimina. Las pausas casi desaparecen, aunque el trabajo sigue existiendo: la misma documentación de ZGC advierte que demasiados hilos del recolector le quitan CPU a la aplicación, y recomienda que el sistema nunca supere el 70 % de uso de CPU.

Comparación directa

Aspecto	Recolector moderno	Rust
Quién libera	Un proceso en tiempo de ejecución	El compilador lo fija en el código
Cuándo	Cuando el recolector lo decide	Al salir de alcance
Pausas	Desde breves hasta menos de 1 ms, según el recolector	Sin pausas de recolección
CPU	Trabajo adicional y continuo	Sin ese trabajo; el costo es la liberación puntual
Memoria	Necesita holgura	Cerca de los datos vivos
Latencia de cola	Depende de la carga y de la configuración	Más predecible, sin estar garantizada
Productividad inicial	Alta	Menor, con curva de aprendizaje real
Contratación	Mercado amplio	Mercado más pequeño
Ajuste	Parámetros del recolector	Diseño del código

Cuándo el recolector es la mejor opción

Si tu duda concreta es entre dos lenguajes, mira Rust vs. Go. Quédate con tu recolector si:

Tu sistema pasa la mayor parte del tiempo esperando a la base de datos o a la red.
Tus objetivos de latencia se miden en cientos de milisegundos.
Tu equipo domina el lenguaje, y el costo de infraestructura no es un problema.
No has medido el problema. Sin datos, una migración es una apuesta.

Rust empieza a tener sentido cuando el p99 o el p99.9 es un requisito del negocio, cuando manejas muchos datos en memoria o cuando el costo de CPU y memoria se nota en la factura. También reduce la huella de carbono, en la medida en que reduce servidores.

Qué medir antes de decidir

Los percentiles, no el promedio. p50, p95, p99 y p99.9, por servicio y bajo carga real.
El tiempo de recolección. Actívalo con GODEBUG=gctrace=1 en Go o con -Xlog:gc en Java.
Si los picos coinciden. Compara los picos de latencia con los ciclos del recolector. Si no coinciden, el problema está en otra parte.
La configuración. Prueba primero a ajustar el recolector y a reducir asignaciones. Suele ser mucho más barato que migrar.
Un solo componente. Si decides cambiar, elige el servicio más crítico y compara. Las cinco preguntas antes de migrar ayudan a ordenar esa decisión.

Rust vs. Go: cómo elegir sin fanatismos

2026-11-05T00:00:00+00:00

Rust y Go se comparan todo el tiempo, y es normal: ambos son modernos, compilan a binarios nativos y se usan para servicios de red. Pero nacieron para resolver problemas distintos. Elegir bien depende menos del lenguaje que de tu problema.

La diferencia de fondo

Go se diseñó para que equipos grandes escriban servicios concurrentes con poco esfuerzo: un lenguaje pequeño, compilación rápida y un recolector de basura que se encarga de la memoria.

Rust se diseñó para dar el control de C++ con garantías de seguridad: sin recolector, con un compilador que comprueba mucho más antes de ejecutar. Esa exigencia es su costo, y también su beneficio.

No es una competencia: cada uno optimiza algo distinto.

Aspecto	Go	Rust
Memoria	Recolector de basura	Propiedad, sin recolector
Seguridad de memoria	Sí	Sí, salvo en `unsafe`
Carreras de datos	Posibles; hay detector en ejecución	No compilan en Rust seguro
Valores nulos	Existe `nil`	`Option`, comprobado al compilar
Errores	Valores que se revisan por convención	`Result`, y el compilador avisa si lo ignoras
Velocidad de compilación	Muy rápida	Más lenta
Curva de aprendizaje	Días o semanas	Semanas o meses
Binario	Incluye el entorno de ejecución	Sin entorno de ejecución obligatorio
Uso en embebidos	Limitado	Muy adecuado

Rendimiento: lo que importa de verdad

En tareas limitadas por CPU, Rust suele sacar ventaja. Pero la diferencia que más se nota en producción no suele estar en el promedio, sino en la memoria y en la latencia de cola.

La guía oficial del recolector de Go es muy clara sobre esto: el recolector usa el 25 % de la CPU durante el marcado, y puede obligar a las rutinas a ayudarlo si se asigna mucha memoria. Si tu servicio guarda muchos datos en memoria, ese trabajo crece. Fue justo el caso de Discord.

Para ver el orden de magnitud, en nuestro microservicio de ejemplo medimos Rust, Go, Node.js y Python con el mismo endpoint.

Ahora bien, si tu servicio pasa casi todo el tiempo esperando a la base de datos, lo que ganes en el lenguaje apenas se notará. Mide antes. Astro lo mostró en 2026: al cambiar su compilador de Go a Rust ganó cerca de un 6 % en la compilación de su documentación, porque ese paso rara vez era el cuello de botella.

Concurrencia: dos filosofías

Go tiene una de sus mejores ideas en las gorrutinas: lanzar una tarea es tan simple como escribir go.

go procesar(pedido) // simple y directo

Rust usa async y await, normalmente con Tokio. Es más explícito, tiene más conceptos y más detalles que aprender. Lo que recibes a cambio es que el compilador impide compartir datos de forma insegura entre hilos.

use std::thread;

fn main() {
    let pedido = String::from("A-100");

    // `move` transfiere el dato al hilo: el compilador
    // no permite que el hilo original lo siga usando.
    let hilo = thread::spawn(move || println!("Procesando {pedido}"));

    hilo.join().unwrap();
}

En Go, compartir un mapa entre gorrutinas sin protección compila sin aviso, y puede fallar en producción. Por eso existe go test -race, que es muy útil, pero solo detecta las carreras que ocurren durante la prueba. En Rust, ese error no llega a compilar.

Productividad: menos diferencia de la que se cree

Lo habitual es asumir que Go siempre será más productivo. Los datos disponibles son más matizados. En la conferencia Rust Nation 2024, Lars Bergstrom, de Google, comentó que los equipos de Rust eran tan productivos como los de Go en reescrituras comparables, y el doble que los de C++.

Conviene leer esto con prudencia: es una charla, no un estudio publicado, y Google no es una empresa promedio. Lo razonable es asumir que Go gana al inicio y que la distancia se reduce cuando el equipo domina Rust. Compilar sigue siendo más lento: en la encuesta interna de Google, solo algo más del 40 % consideraba aceptable la velocidad del compilador.

Contratación y ecosistema

Aquí Go suele llevar ventaja. Hay más perfiles disponibles, y cualquier persona con experiencia en backend aprende el lenguaje rápido. Su biblioteca estándar cubre muy bien HTTP y JSON, y buena parte de la infraestructura en la nube, como Kubernetes o Docker, está escrita en Go.

Rust exige formar a tu equipo o competir por menos perfiles. En cambio, llega a lugares donde Go no entra con facilidad: embebidos, navegador, sistemas operativos y bibliotecas para otros lenguajes.

Cuándo elegir cada uno

Elige Go si:

Tu prioridad es entregar servicios de red rápido, con un equipo que rota o crece.
La lógica de negocio pesa más que el rendimiento.
Tu latencia objetivo se mide en decenas de milisegundos o más, y no tienes grandes cachés en memoria.
Trabajas en el ecosistema de Kubernetes.

Elige Rust si:

El p99 o la memoria son requisitos del negocio.
Haces trabajo intensivo de CPU: procesar datos, comprimir, analizar, cifrar.
Procesas datos no confiables en la ruta crítica.
Necesitas llegar a embebidos, WebAssembly o bibliotecas para Python o Node.js.
Un fallo sale muy caro, y prefieres pagar esa seguridad en tiempo de desarrollo.

No tienes que elegir uno solo. Muchas empresas combinan ambos: Go para la mayoría de servicios y Rust para los pocos componentes donde cada milisegundo o cada gigabyte cuenta.

La pregunta correcta

No es "¿cuál es mejor?", sino "¿qué problema tengo, y cuánto me cuesta?". Si aún no lo sabes, mide primero.

Rust y código generado por IA: el compilador como revisor

2026-11-05T00:00:00+00:00

Los asistentes de código cambiaron el problema. Antes costaba escribir software, y ahora cuesta más saber si lo escrito es correcto. Por eso la revisión pasó a ser el cuello de botella.

Rust tiene aquí una propuesta interesante, y merece analizarse sin exagerar.

Lo que sabemos sobre el código generado

Veracode analizó en 2025 80 tareas de programación con más de 100 modelos. En el 45 % de los casos, el código introducía una vulnerabilidad. Java tuvo la peor tasa, con más del 70 %, y Python, C# y JavaScript quedaron entre el 38 % y el 45 %. Según la empresa, los resultados no mejoraban con los modelos nuevos.

Dos advertencias: Veracode vende herramientas de seguridad, y sus pruebas se centraron en errores como inyección y cross-site scripting. Pero el mensaje general es razonable: el código generado se parece al que aprendió, incluidos sus errores.

El compilador no se cansa

Un revisor humano se fatiga. Revisa bien las primeras cien líneas y peor las mil siguientes. El compilador de Rust revisa siempre igual, y rechaza clases enteras de errores antes de llegar a una revisión:

Cada etapa automática deja menos carga para la última, que sigue siendo humana.

Esto crea un ciclo útil con la IA. Si el asistente genera código con un problema de propiedad, el compilador lo rechaza con un mensaje preciso. El asistente lo lee y lo corrige. El ciclo ocurre antes de que una persona mire el código.

Hay evidencia de que funciona, con matices. RustAssistant, un trabajo de Microsoft Research, conecta un modelo con el compilador y reporta cerca del 74 % de errores de compilación reales corregidos. Pero otro trabajo sobre traducción de C a Rust advierte que los mensajes del compilador no bastan por sí solos: hacen falta instrucciones de reparación guiadas.

El caso más llamativo es Bun, que en 2026 pasó de Zig a Rust con asistentes de IA, y con su suite de pruebas como red de seguridad. Lo presentó con una idea muy cercana a esta nota: los errores del compilador son mejor ciclo de retroalimentación que una guía de estilo. Aun así, reportó 19 regresiones.

Y hay un riesgo sutil: corregir un error de compilación no significa que el programa haga lo correcto. A veces el fallo solo se traslada a una etapa posterior, y resulta más difícil de encontrar.

Lo que el compilador sí detecta

Fallos de memoria en código seguro.
Carreras de datos.
Casos no tratados en un match.
Valores opcionales usados sin comprobar.
Errores ignorados, con una advertencia si no usas un Result.

Lo que el compilador no detecta

Aquí es donde se equivocan quienes prometen de más. Rust no sabe qué debería hacer tu programa, de modo que estos errores pasan sin aviso:

Autorización ausente: una ruta que debería exigir permisos, y no lo hace.
Lógica de negocio equivocada: un descuento mal calculado compila perfectamente.
Inyección SQL: si concatenas texto, Rust no te salva. Usa consultas parametrizadas.
Secretos en el código: una clave escrita en el repositorio compila sin problemas.
Dependencias inventadas o maliciosas: los asistentes pueden sugerir paquetes que no existen, y alguien podría registrarlos después.
unsafe innecesario: un modelo puede usarlo para "resolver" un error del compilador. Es la señal de alarma más clara.

Una configuración sensata

Si tu equipo usa asistentes, esto cierra buena parte del riesgo. Lo primero es prohibir unsafe en el código propio. Con esta línea, cualquier bloque unsafe deja de compilar:

#![forbid(unsafe_code)]

fn main() {
    println!("Este proyecto no permite código unsafe");
}

Si de verdad necesitas unsafe, aíslalo y audítalo. Lo segundo es endurecer el control de calidad en integración continua:

cargo fmt --check
cargo clippy --all-targets -- -D warnings
cargo nextest run
cargo deny check
cargo audit

Cada comando atiende un riesgo:

Comando	Qué revisa
`cargo fmt --check`	Formato uniforme, para que el diff sea legible
`cargo clippy`	Patrones incorrectos o sospechosos
`cargo nextest run`	Las pruebas
`cargo deny check`	Licencias y fuentes permitidas de dependencias
`cargo audit`	Vulnerabilidades conocidas en dependencias

Encuéntralas todas en nuestra caja de herramientas.

Cómo revisar lo que escribe un asistente

La revisión humana no desaparece, pero cambia de foco. Si el compilador ya cubrió la memoria, la persona puede concentrarse en lo importante:

La intención: ¿resuelve el problema correcto?
La autorización: ¿quién puede ejecutar esto?
Los límites: ¿qué pasa con datos vacíos, enormes o maliciosos?
Las dependencias nuevas: ¿existen, se mantienen, las necesitas?
Las pruebas: ¿comprueban algo, o solo repiten la implementación?
Cada unsafe, unwrap y clone: ¿tiene justificación?

Entonces, ¿Rust es mejor para la IA?

Lo honesto es decir que no hay un estudio concluyente sobre si el Rust generado es más seguro en general. Lo que sí está claro es el mecanismo: más errores detectados por una máquina significa menos carga para quien revisa. El costo es que el asistente tardará más ciclos en conseguir que compile, y que necesitas personas que entiendan lo que aprueban.

La IA no elimina la necesidad de criterio, sino que la vuelve más valiosa.

Seguridad de software y regulación en Latinoamérica: qué exigen de verdad

2026-11-05T00:00:00+00:00

Las regulaciones de ciberseguridad están llegando al código. Ya no alcanza con un firewall y una política en PDF: cada vez más, una auditoría pregunta cómo desarrollas, cómo pruebas y cómo tratas tus vulnerabilidades.

Esta nota resume qué piden algunas normas relevantes para la región. Es una guía de ingeniería, no asesoría legal: cada norma tiene alcance, plazos y excepciones que debes validar con tus especialistas.

Primero, lo que no dicen

Ninguna de estas normas obliga a usar Rust ni un lenguaje seguro en memoria. Quien diga lo contrario te está vendiendo algo.

En Estados Unidos, la guía de NSA y CISA de 2025 sí recomienda estos lenguajes como la mitigación más completa contra esa clase de fallos, pero es una recomendación, no una obligación.

Lo que sí hacen las normas es exigir controles, pruebas y evidencia. Y ahí es donde tus decisiones técnicas pesan.

Comparación rápida

Marco	A quién aplica	Foco en software
SBS 504-2021 (Perú)	Sector financiero supervisado	Desarrollo seguro, pruebas, API, terceros
Ley 29733 (Perú)	Quien trata datos personales	Protección de datos, oficial de datos en ciertos casos
Ley 21.663 (Chile)	Servicios esenciales y operadores de importancia vital	Sistemas de gestión, reporte de incidentes
BCB 538 (Brasil)	Instituciones reguladas por el Banco Central	Controles mínimos, pruebas de intrusión, Pix
Ley de Ciberresiliencia (UE)	Productos con elementos digitales en el mercado europeo	Seguridad en diseño, vulnerabilidades, reportes

Perú: la SBS y el desarrollo seguro

El Reglamento SBS 504-2021 es, para el sector financiero, el documento clave. Su artículo 12 pide incluir prácticas de seguridad en la planificación, el desarrollo y la operación, e implementar procedimientos con prácticas de desarrollo seguro. Estos son los puntos más útiles para un equipo técnico:

Control de cambios: limitar quién modifica el código fuente, con un estricto control (art. 12, num. 5, lit. c).
Pruebas antes de producción: técnicas, funcionales y de seguridad de la información (lit. e).
Ambientes separados: desarrollo, pruebas y producción (num. 3, lit. c).
API: prácticas de desarrollo seguro, revisión de codificación segura, análisis de vulnerabilidades y pruebas de penetración (art. 21).
Terceros: evaluar amenazas en lo que proveen, definir responsabilidades y, en la nube, verificar certificaciones (art. 22 a 24).

El reglamento no fija un estándar de código ni una herramienta específica. Te deja elegir, pero debes poder demostrar que lo haces. Además, tiene regímenes distintos según la entidad, y fue modificado por la Resolución 01515-2021, de modo que conviene revisar la versión vigente.

Fuera del sistema financiero, el nuevo reglamento de la Ley 29733, en vigor desde 2025, refuerza las obligaciones sobre datos personales.

Chile: la Ley Marco de Ciberseguridad

La Ley 21.663 creó la Agencia Nacional de Ciberseguridad. Distingue deberes generales, como reportar incidentes, de deberes específicos para los Operadores de Importancia Vital, como implementar un sistema de gestión de seguridad de la información.

La agencia ha publicado nóminas de esos operadores, y las multas pueden llegar a 20 000 UTM, con hasta el doble para esos operadores. Si das servicios a uno de ellos, es probable que sus exigencias te lleguen por contrato.

Brasil: el Banco Central tras el caso C&M

En 2025, un ataque a C&M Software, proveedora conectada al sistema financiero, desvió al menos R$ 800 millones, según reportes de prensa. La lección fue incómoda: el eslabón débil era un tercero. En diciembre de ese año, el Banco Central publicó la Resolución BCB 538, que endurece los requisitos para las entidades reguladas. Según resúmenes jurídicos, incluye grupos de controles mínimos, pruebas de intrusión anuales y el aislamiento de los ambientes de Pix.

Si desarrollas para banca o pagos, esto te incumbe aunque no estés en Brasil: es probable que marque tendencia en la región.

Europa: una razón para exportadores

Si vendes software a Europa, presta atención a la Ley de Ciberresiliencia. Según Jones Day, desde el 11 de septiembre de 2026 los fabricantes deben reportar vulnerabilidades explotadas e incidentes graves, con una alerta en 24 horas. La mayoría de las demás obligaciones aplican desde el 11 de diciembre de 2027.

Para una empresa latinoamericana que exporta software, esto dejó de ser un tema lejano.

La evidencia que sí puedes preparar

Todas estas normas convergen en lo mismo. Aquí tienes una lista práctica, útil en cualquier jurisdicción:

Seis cosas que una auditoría suele preguntar, escritas como evidencia que puedes preparar.

Cómo ayuda Rust

Rust no te da cumplimiento, pero reduce trabajo y riesgo en varios puntos:

Elimina una clase de vulnerabilidades en el código seguro, antes de llegar a las pruebas. Vimos cuáles.
Hace visible el riesgo: el código unsafe queda marcado y se puede auditar.
Facilita el control de dependencias: con Cargo.lock, cargo audit y cargo deny puedes bloquear versiones y documentar lo que usas.

Sigue siendo necesario todo lo demás: autorización, cifrado, gestión de secretos, registro, respuesta a incidentes. Y como vimos en Evidencia, cambiar de lenguaje no siempre es lo más urgente.

Por dónde empezar

No empieces por reescribir nada. Empieza por saber dónde estás: qué sistemas son críticos, qué depende de terceros y qué evidencia te falta. Ese inventario suele ser más valioso que cualquier herramienta.

unsafe en Rust: qué es, cuándo usarlo y cómo auditarlo

2026-11-05T00:00:00+00:00

Cuando alguien dice que Rust es seguro, la respuesta típica es: "pero tiene unsafe". Es cierto. Y entender qué significa es la diferencia entre confiar a ciegas y confiar con criterio.

Por qué existe

El compilador de Rust es conservador. Rechaza todo lo que no puede demostrar que es correcto, incluso programas correctos. Y hay trabajo que por naturaleza no puede comprobar: hablar con el hardware, llamar a código en C o construir las propias estructuras de la biblioteca estándar.

Sin unsafe, Rust no podría hacer eso. Vec, por ejemplo, gestiona memoria manualmente por dentro, y te ofrece por fuera una interfaz segura.

Qué permite de verdad

Aquí está el malentendido más común. unsafe no apaga el verificador de préstamos ni el resto de comprobaciones. Solo da acceso a cinco operaciones:

Desreferenciar un puntero crudo.
Llamar a una función o método unsafe.
Acceder a una variable estática mutable o modificarla.
Implementar un trait unsafe.
Acceder a los campos de una union.

Todo lo demás se sigue comprobando dentro del bloque. Y fuera de él, si solo escribes Rust seguro, no deberías encontrar comportamiento indefinido.

La idea central: abstracciones seguras

La regla de oro es encerrar unsafe en una función pequeña y exponer una interfaz segura. Quien la usa no puede provocar un error, y la responsabilidad queda en un solo lugar.

Quien llama no puede provocar el error: el riesgo vive en un solo lugar, marcado y documentado.

Este ejemplo devuelve el último elemento de una lista. Comprueba la condición antes de entrar en la zona unsafe:

/// Devuelve el último elemento, si existe.
fn ultimo(lista: &[i32]) -> Option<i32> {
    if lista.is_empty() {
        return None;
    }

    // SAFETY: `lista` no está vacía, de modo que `len() - 1`
    // es un índice válido.
    Some(unsafe { *lista.get_unchecked(lista.len() - 1) })
}

fn main() {
    println!("{:?}", ultimo(&[1, 2, 3])); // Some(3)
    println!("{:?}", ultimo(&[]));        // None
}

Fíjate en el comentario SAFETY. Explica por qué la operación es correcta. Es una convención muy extendida, y Clippy puede exigirla con undocumented_unsafe_blocks.

Por cierto, en un caso real bastaría con lista.last().copied(). Es un ejemplo para mostrar la forma, y demuestra lo primero que debes preguntarte: ¿de verdad lo necesitas?

Cuándo se justifica

Sí suele estar justificado en:

Interoperabilidad: llamar a bibliotecas en C o C++, como vimos en la guía de adopción en C++.
Hardware: escribir registros en un microcontrolador o un driver.
Estructuras de datos a bajo nivel: cuando la biblioteca estándar no cubre tu caso.
Rendimiento comprobado: solo si una medición muestra que importa.

No se justifica para:

Callar al compilador. Si el verificador se queja, casi siempre tiene razón. Es el error típico de quien empieza, y de los asistentes de IA.
Optimizar por intuición. El compilador suele eliminar las comprobaciones de límites cuando puede demostrar que sobran.
Evitar diseñar bien. Dos referencias mutables al mismo dato son un problema de diseño.

El caso de Android: un recordatorio útil

unsafe puede fallar. Google documentó el caso de CVE-2025-48530, un fallo en código unsafe de CrabbyAVIF, una biblioteca de Android para imágenes AVIF. Podría haber sido grave, pero se detectó antes de publicarse y un componente adicional, el asignador Scudo, lo habría hecho inexplotable.

Son dos lecciones a la vez. Rust no es una garantía absoluta, y por eso sigue haciendo falta defensa en profundidad. Pero los fallos se concentran en zonas pequeñas y conocidas, en lugar de repartirse por toda la base de código.

Cómo auditar `unsafe`

Si heredas un proyecto o evalúas una dependencia, este es un proceso razonable.

1. Localízalo. Es una de las grandes ventajas de Rust: el riesgo está marcado.

grep -rn "unsafe" src/

2. Prohíbelo donde no haga falta. Con #![forbid(unsafe_code)] el compilador rechaza cualquier bloque unsafe. Úsalo en todos los módulos que no lo necesiten.

3. Pásalo por Miri. Miri es la herramienta oficial que ejecuta tus pruebas e identifica comportamiento indefinido.

rustup +nightly component add miri
cargo +nightly miri test

Solo detecta lo que tus pruebas ejercitan, de modo que no reemplaza una revisión.

4. Revisa cada bloque con estas preguntas:

¿Hay un comentario SAFETY que explique por qué es correcto?
¿Las condiciones se comprueban antes, o dependen de quien llama?
¿Puede una entrada externa romper esas condiciones?
¿Hay una alternativa segura de costo similar?
¿La función pública es segura sin importar cómo se use?

5. Revisa tus dependencias. Tu proyecto puede no tener unsafe, y aun así heredarlo de otras bibliotecas. Herramientas como cargo audit y cargo deny ayudan a vigilar lo que entra.

Lo que debes recordar

Cuando alguien te diga que Rust no sirve porque tiene unsafe, recuerda la alternativa. En C, todo el programa es unsafe, sin marcar. En Rust, la zona peligrosa tiene nombre, se puede buscar con grep y cabe en una revisión.

Eso no elimina el riesgo. Lo vuelve manejable.

Quién usa Rust: empresas, proyectos y plataformas

2026-11-05T00:00:00+00:00

Rust ya no es una promesa. Está en el kernel de Linux, en Android, en Windows, en la infraestructura de la nube y en herramientas que millones de personas usan a diario, muchas veces sin saberlo.

Esta página reúne qué hace cada empresa con Rust, y enlaza siempre a una fuente propia. Lo más reciente está en Noticias de Rust.

Dónde se usa Rust

Es poco común que un mismo lenguaje cubra tanto terreno:

Un mismo lenguaje, desde un microcontrolador hasta un centro de datos.

Hay dos razones. Rust no necesita un entorno de ejecución ni un recolector de basura, y en sistemas embebidos la memoria dinámica es opcional. Además, Cargo ofrece las mismas herramientas para compilar, probar y distribuir en todos esos entornos.

En qué plataformas funciona

La política oficial clasifica las plataformas por nivel de garantía:

Nivel	Qué significa	Plataformas
1	Garantizado que funciona: se prueba tras cada cambio	Linux y Windows en x86-64 y ARM64, macOS en Apple Silicon
2	Garantizado que compila	Android, iOS, WebAssembly, RISC-V, microcontroladores ARM Cortex-M

Empresas

Empresa	Qué hace con Rust
Microsoft	Regiones GDI de Windows en el kernel. OpenVMM y OpenHCL en Azure. Es el lenguaje principal del código nuevo de Azure Boost.
Google	Unos 5 millones de líneas en Android. En Chrome, analizadores de PNG, JSON y fuentes. Partes de Fuchsia.
Amazon (AWS)	Firecracker, la base de Lambda y Fargate. Bottlerocket, s2n-quic y Aurora DSQL.
Cloudflare	Pingora, que atiende más de un billón de peticiones al día, y FL2, la reescritura de su sistema central.
Meta	Biblioteca de medios de WhatsApp, distribuida a miles de millones de dispositivos. El servidor de control de versiones Mononoke.
Mozilla	Stylo, el motor CSS de Firefox.
Discord	Read States, servicio migrado desde Go. Lo analizamos en esta nota.
Dropbox	Nucleus, su motor de sincronización.
Figma	La parte de mayor rendimiento de su servidor multijugador.
1Password	La biblioteca compartida de sus aplicaciones.
Shopify	YJIT, el compilador JIT de Ruby.
Vercel	Turbopack, el empaquetador por defecto de Next.js.
Canonical	Utilidades básicas con uutils y `sudo-rs` en Ubuntu.
Astro	Compilador `.astro` y procesador de Markdown desde la versión 7.
Git	Rust activado por defecto, y obligatorio para compilar en Git 3.0.
Signal	libsignal, usada por sus aplicaciones y sus servidores.

¿Y Apple?

Es la gran ausente, y vale la pena explicar por qué. No encontramos ninguna publicación ni repositorio de Apple que confirme Rust en sus productos. Lo que circula son ofertas de empleo y rumores, así que no la incluimos en la lista.

Lo interesante es que Apple persigue el mismo objetivo por otro camino. En 2025 explicó que usa Swift, su propio lenguaje seguro en memoria, para código nuevo y reescrituras puntuales, junto con protecciones de hardware en el iPhone 17. Y Rust funciona muy bien para quien desarrolla en sus equipos: macOS en Apple Silicon es una plataforma de nivel 1.

Proyectos

Todos estos proyectos abiertos tienen Rust como lenguaje principal en su repositorio, y estaban activos en noviembre de 2026.

Sistemas operativos y virtualización

Proyecto	Qué es
Linux	Rust dejó de ser un experimento en el kernel. Es opcional, y ya hay drivers como `nova-core`.
Redox OS	Sistema operativo tipo Unix, escrito desde cero.
Asterinas	Kernel compatible con Linux.
Firecracker	Micromáquinas virtuales para funciones en la nube.
OpenVMM	Monitor de máquinas virtuales de Microsoft.
Bottlerocket	Sistema operativo de AWS para contenedores.

Embebidos y firmware

Proyecto	Qué es
Embassy	Framework asíncrono para microcontroladores.
Tock	Sistema operativo para dispositivos con pocos recursos.
Hubris	Sistema operativo para microcontroladores, de Oxide Computer.

Frameworks y bibliotecas

Proyecto	Qué es
Tokio	Entorno asíncrono, base de gran parte del ecosistema.
Axum, Actix Web, Rocket	Frameworks web.
Hyper	Implementación de HTTP.
Serde	Serialización de datos.
Rayon	Paralelismo de datos.
Leptos, Dioxus	Interfaces web y multiplataforma.
Tauri	Aplicaciones de escritorio y móviles.
Bevy	Motor de videojuegos.
PyO3	Puente entre Rust y Python.

Herramientas de línea de comandos

Proyecto	Qué es
ripgrep	Búsqueda en archivos. Es el motor de búsqueda de muchos editores.
fd, bat	Alternativas modernas a `find` y `cat`.
sudo-rs, uutils	`sudo` y utilidades básicas de sistema.
fish, Nushell	Intérpretes de comandos.
Starship	Línea de comandos personalizable.

Herramientas de desarrollo

Proyecto	Qué es
Cargo	Gestor de paquetes de Rust.
uv, Ruff	Gestor de paquetes y analizador para Python.
Biome, SWC, Rolldown	Herramientas para JavaScript y TypeScript.
Deno, Bun	Entornos de ejecución de JavaScript.

Aplicaciones

Proyecto	Qué es
Zed, Helix	Editores de código.
Alacritty	Terminal con aceleración gráfica.
Servo	Motor de navegador.
Typst	Sistema de composición de documentos.
RustDesk	Escritorio remoto.

Datos e infraestructura

Proyecto	Qué es
TiKV	Base de datos distribuida de clave y valor.
Polars	Análisis de datos tabulares.
Qdrant	Base de datos vectorial.
Meilisearch	Motor de búsqueda.
Materialize	Base de datos de flujos en tiempo real.
Neon	Postgres en la nube.
Vector	Canalización de datos de observabilidad.
Linkerd	Proxy de malla de servicios.

Blockchain

Es un sector donde Rust encaja bien: un fallo puede costar dinero real, y el código se ejecuta a alta velocidad.

Proyecto	Qué es
Reth, Lighthouse	Clientes de Ethereum, de ejecución y de consenso.
Agave	Cliente validador de Solana.
Polkadot SDK	Kit para construir cadenas de bloques.

Lo que esta lista no dice

Usar Rust no significa reescribirlo todo. Casi todas estas empresas lo adoptaron por partes. Figma, por ejemplo, solo movió la parte más exigente.
Rust no evita todos los fallos. La caída de Cloudflare del 18 de noviembre de 2025 se produjo por un pánico en código Rust. Un error de lógica sigue siendo un error.
Rust no es la única salida. Apple resuelve el mismo problema con Swift, y varios lenguajes con recolector también son seguros en memoria.
Cada lenguaje tiene su lugar. Python sigue siendo ideal para explorar datos, y muchas aplicaciones de negocio van muy bien con Java o C#.
Esta lista envejece. Es una foto de noviembre de 2026. Enlazamos las fuentes para que puedas revisarlas.

Si estás pensando en adoptar Rust, empieza por la evidencia y por las cinco preguntas antes de migrar.

El 70 %: qué es la seguridad de memoria y por qué importa

2026-11-04T00:00:00+00:00

En 2019, Microsoft publicó un dato incómodo: alrededor del 70 % de los CVE que asigna cada año son fallos de seguridad de memoria. No son errores de un equipo descuidado, sino el resultado de décadas de software en C y C++, escrito por excelentes ingenieros.

Google vio un patrón parecido, y la NSA citó ambos casos al recomendar lenguajes seguros en memoria.

Qué es un fallo de memoria

Un programa guarda datos en memoria y accede a ellos por su dirección. Hay un fallo cuando lee o escribe donde no debe. Dos ejemplos clásicos:

Desbordamiento de búfer: se escribe más allá del espacio reservado, y se pisan datos vecinos.
Uso después de liberar: se usa memoria que ya se devolvió al sistema, y que quizá ya contiene otra cosa.

El puntero parece válido, pero la memoria ya pertenece a otra parte del programa.

Este código en C compila, aunque es incorrecto:

char *s = malloc(16);
free(s);
s[0] = 'x'; // uso después de liberar

Un atacante que controle lo que ocupa esa memoria puede llegar a leer datos o a ejecutar su propio código. Hay más fallos de esta familia, y los ilustramos uno por uno en Los 7 fallos de memoria más comunes.

Qué cambia con Rust

La misma idea no compila en Rust:

fn main() {
    let r;
    {
        let s = String::from("hola");
        r = &s;
    } // `s` se libera aquí
    println!("{r}"); // error[E0597]: `s` does not live long enough
}

El error se detecta antes de ejecutar el programa, sin importar lo cansado que estuviera quien lo escribió. Es la diferencia entre pedir cuidado y hacer imposible el error.

Los resultados

Android es el caso más documentado. Google informa que los fallos de memoria bajaron del 20 % de sus vulnerabilidades por primera vez en 2025, a medida que el código nuevo dejó de escribirse en C y C++.

Los límites

Rust no resuelve todo:

El código marcado como unsafe queda bajo tu responsabilidad. Android tuvo un fallo de este tipo (CVE-2025-48530), detectado antes de su publicación.
Los errores de lógica, de autorización y las dependencias comprometidas siguen siendo posibles.
Java, C#, Go y Python también son seguros en memoria, gracias a un recolector de basura que tiene su propio costo. Esta cifra describe sobre todo a C y C++.

La seguridad nunca depende de una sola decisión. Pero eliminar una clase entera de errores desde el diseño es de las pocas mejoras que no se desgastan con el tiempo.

Cómo adoptar Rust en un sistema C++ existente

2026-11-03T00:00:00+00:00

Reescribir un sistema grande de C++ de una sola vez es arriesgado y rara vez es necesario. Una estrategia gradual reduce el riesgo desde la primera entrega.

Empieza por el código nuevo

Google observó en Android que las vulnerabilidades de memoria se concentran en el código nuevo. Por eso, escribir las funciones nuevas en un lenguaje seguro en memoria puede aportar mucho sin tocar el código antiguo y ya probado.

Prioriza por exposición

No todo el código tiene el mismo riesgo. Empieza por lo que recibe datos no confiables: parsers, decodificadores, protocolos de red y límites entre procesos.

Elige cómo conectar ambos lenguajes

Una frontera pequeña y clara: es lo único que ambos lados deben acordar.

cxx genera puentes seguros entre Rust y C++ a partir de una interfaz declarada.
bindgen genera enlaces a partir de cabeceras C y C++, lo que suele ser útil con APIs amplias.
Una frontera C explícita es más manual, pero también más estable y fácil de auditar.

Mantén la frontera pequeña y bien definida. Cada cruce es código unsafe que hay que revisar.

Envuelve lo inseguro

Encierra el código unsafe en módulos pequeños que expongan una interfaz segura, y documenta qué condiciones debe cumplir cada bloque.

Rust no elimina todo el riesgo. Google informó de un desbordamiento de búfer en código Rust unsafe de Android (CVE-2025-48530), detectado antes de llegar a una versión pública.

Integra la construcción

Define desde el inicio cómo convivirán CMake o Bazel con Cargo, cómo se ejecutarán las pruebas de ambos lenguajes y cómo se gestionarán las dependencias. Muchos retrasos vienen de aquí, no del lenguaje.

Mide el avance

Registra vulnerabilidades, reversiones y tiempo de revisión antes y después. Esos datos permiten decidir si conviene ampliar la adopción.

Cómo migrar de Python a Rust sin reescribir tu aplicación

2026-11-03T00:00:00+00:00

No necesitas elegir entre Python y Rust. Casi siempre conviene usar los dos: Python para orquestar y Rust para las pocas rutas donde se concentra el costo.

Herramientas como Polars, Ruff y uv siguen esta idea: se usan desde el ecosistema de Python, con un núcleo escrito en Rust.

1. Mide antes de migrar

Rust no arregla un problema que no has localizado. Perfila tu aplicación con carga real, usando una herramienta como py-spy, y busca funciones de CPU que dominen el tiempo total.

Si el tiempo se va esperando a la base de datos o a la red, Rust no ayudará mucho. Corrige primero las consultas, los índices o la arquitectura.

2. Elige una función pequeña y pura

El mejor primer candidato tiene tres rasgos:

Consume mucha CPU.
Tiene entradas y salidas simples.
Tiene pruebas, o es fácil escribírselas.

Parsers, validadores, transformaciones de datos y cálculos numéricos suelen encajar bien.

3. Exponla como un módulo de Python

Una frontera pequeña y clara: es lo único que ambos lados deben acordar.

PyO3 permite escribir extensiones nativas, y maturin las empaqueta. Desde Python, se importa como cualquier otro módulo:

use pyo3::prelude::*;

#[pyfunction]
fn total_centavos(montos: Vec<i64>) -> i64 {
    montos.iter().sum()
}

#[pymodule]
fn nucleo(m: &Bound<'_, PyModule>) -> PyResult<()> {
    m.add_function(wrap_pyfunction!(total_centavos, m)?)?;
    Ok(())
}

import nucleo

nucleo.total_centavos([1250, 800, 4300])

Cruzar la frontera entre Python y Rust también cuesta tiempo, porque se convierten datos. Por eso es mejor pasar lotes de trabajo que llamar a Rust una vez por cada elemento en un bucle.

4. Verifica la equivalencia

Ejecuta la versión antigua y la nueva con las mismas entradas y compara los resultados. En producción, puedes correr ambas en paralelo durante un tiempo y usar solo la antigua para responder, hasta tener confianza.

5. Decide si seguir

Compara el resultado con la métrica que definiste al inicio. Si la mejora justifica el costo, pasa al siguiente componente. Si no, detente: una migración parcial que resuelve el problema ya es un buen resultado.

¿Vale la pena migrar a Rust? Cinco preguntas antes de decidir

2026-11-03T00:00:00+00:00

Rust es una gran herramienta, pero migrar cuesta tiempo, dinero y atención. Antes de decidir, conviene responder cinco preguntas.

1. ¿Qué problema concreto quieres resolver?

"Queremos usar Rust" no es un objetivo. "Reducir la latencia del cálculo de riesgo" o "eliminar una clase de vulnerabilidades en nuestro parser" sí lo son.

Si no puedes medir el problema, tampoco podrás saber si lo resolviste.

2. ¿De qué lenguaje vienes?

La respuesta cambia por completo el argumento:

Desde C o C++, la seguridad de memoria es el beneficio principal.
Desde Java, C# o Python, ya tienes seguridad de memoria. El beneficio estará en el rendimiento, los picos de latencia, el consumo de recursos o la robustez del diseño.

Migrar desde Java "por seguridad" suele ser un mal argumento. Una auditoría de la aplicación probablemente dará más resultados.

3. ¿Dónde se va realmente el tiempo?

Si tu sistema pasa la mayor parte del tiempo esperando a la base de datos, un lenguaje más rápido cambiará poco. Mide primero.

4. ¿Quién mantendrá el código?

Rust tiene una curva de aprendizaje real. Sin un plan para formar a tu equipo, dependerás de quienes lo escribieron. Inclúyelo en el costo desde el inicio.

5. ¿Puedes migrar por partes?

Las migraciones que mejor funcionan empiezan con un componente pequeño y medible. Si tu sistema no se puede separar, quizá el primer proyecto sea modularizarlo.

Lo que Rust no resuelve

Rust evita muchos errores de memoria y carreras de datos, pero no impide los errores de lógica, los problemas de autorización ni las dependencias comprometidas. Sigue siendo necesario revisar, probar y auditar.

Entonces, ¿cuándo sí?

Rust suele tener sentido cuando se dan estas condiciones:

Tienes código crítico expuesto a datos no confiables, en C o C++.
El rendimiento o el costo de infraestructura es un problema medido.
Puedes empezar por un componente acotado.
Tu equipo está dispuesto a aprender.

Si no se cumple ninguna, lo más honesto es no migrar.