Rust on kenji.blog

Comparando la "Propiedad" y el "Préstamo" de Rust con los Punteros de C++

Sat, 12 Sep 2026 04:00:00 +0900

En la programación de sistemas moderna, equilibrar el rendimiento y la seguridad de la memoria es un desafío eterno. C++ ha reinado como el rey en este campo durante muchos años, pero recientemente, Rust ha estado amenazando su posición. La mayor característica de Rust radica en los conceptos de “Propiedad” (Ownership) y “Préstamo” (Borrowing), que garantizan la seguridad de la memoria en tiempo de compilación sin tener un recolector de basura (GC).

En este artículo, compararemos en detalle los punteros de C++ (punteros en crudo, std::unique_ptr, std::shared_ptr) y el modelo de propiedad de Rust, y explicaremos de manera exhaustiva mediante ejemplos de código y diagramas cómo el compilador de Rust (comprobador de préstamos o borrow checker) evita el uso después de la liberación (Use-After-Free) y las condiciones de carrera de datos (Data Race).

1. Fundamentos de la gestión de memoria: Pila y Montículo (Stack and Heap)

Para entender los conceptos básicos de la gestión de memoria, primero repasemos cómo los programas utilizan la memoria. El espacio de memoria se divide a grandes rasgos en “Pila” (Stack) y “Montículo” (Heap).

Pila (Stack)

Es el área donde se apilan las variables locales, etc., cuando se llama a una función. Tiene una estructura LIFO (el último en entrar es el primero en salir), y la asignación y liberación de memoria es extremadamente rápida. Aquí solo se colocan los datos cuyo tamaño se puede determinar en tiempo de compilación.

Montículo (Heap)

Aquí se colocan los datos cuyo tamaño se determina dinámicamente en tiempo de ejecución, o los datos que necesitan sobrevivir más allá del alcance (scope) de una función. Se accede a través de punteros (o referencias).

En C++ o Rust, que no tienen recolección de basura, el costo de gestión de la memoria del montículo puede modelarse mediante una fórmula matemática. Si el número total de objetos es $N$, el tiempo promedio de asignación es $T_{alloc}$, y el tiempo promedio de liberación es $T_{dealloc}$, entonces el costo total de gestión de memoria $C_{memory}$ es:

$$ C_{memory} = \sum_{i=1}^{N} (T_{alloc, i} + T_{dealloc, i}) + O_{sync} $$

Donde $O_{sync}$ es la sobrecarga del control de exclusión (mutexes u operaciones atómicas) en un entorno de múltiples hilos. Como Rust determina el momento de la liberación de memoria en tiempo de compilación, elimina por completo la reducción de rendimiento (Stop-The-World) debido a la recolección de basura en tiempo de ejecución, al tiempo que ejecuta $T_{dealloc}$ en un momento seguro y confiable.

graph TD A["Memoria del Programa"] --> B["Pila (Rápida, Tamaño Fijo)"] A --> C["Montículo (Dinámico, Más lento)"] B --> D["Variables Locales"] B --> E["Punteros/Referencias"] C --> F["Datos Asignados Dinámicamente"] E -.->|"Apunta a"| F

2. Punteros en C++: El compromiso entre libertad y peligro

Echemos un vistazo a la evolución de la gestión de memoria en C++.

La era de los Punteros en Crudo (Raw Pointers) y sus problemas

Los punteros en crudo (*) heredados de C ofrecen la máxima libertad, pero al mismo tiempo son un caldo de cultivo para errores graves como los siguientes:

Fuga de memoria (Memory Leak): Olvidar usar delete en la memoria asignada con new.
Puntero colgante (Dangling Pointer): Acceder a un puntero después de que la memoria ha sido liberada (después de delete).
Doble liberación (Double Free): Usar delete dos veces en la misma área de memoria.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// C++: Ejemplo de problemas con punteros en crudo
void rawPointerExample() {
 int* ptr = new int(10);
 // ... algún procesamiento ...
 delete ptr;

 // Acceso erróneo por segunda vez (Use-After-Free / Dangling Pointer)
 // El compilador de C++ no puede hacer que esto sea un error de compilación
 std::cout << *ptr << std::endl; // Comportamiento indefinido (Undefined Behavior)
}

La llegada de RAII y los Punteros Inteligentes (Desde C++11)

A partir de C++11, se estandarizaron los punteros inteligentes basados en el concepto de RAII (Resource Acquisition Is Initialization), y se desaconsejó el uso directo de punteros en crudo.

`std::unique_ptr`

Es un puntero que expresa la propiedad única. Cuando sale de su ámbito, la memoria se libera automáticamente. No se puede copiar, solo es posible el “movimiento” (move) de la propiedad (usando std::move).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// C++: std::unique_ptr
#include <memory>
#include <iostream>

void uniquePtrExample() {
 std::unique_ptr<int> p1 = std::make_unique<int>(42);
 // std::unique_ptr<int> p2 = p1; // Error de compilación (no se puede copiar)
 std::unique_ptr<int> p3 = std::move(p1); // Movimiento de la propiedad

 // La debilidad de C++: Después del movimiento, p1 se vuelve nullptr, pero el acceso en sí se puede compilar
 // Causará un bloqueo (segmentation fault) en tiempo de ejecución
 // std::cout << *p1 << std::endl;
}

`std::shared_ptr`

Es un puntero que permite que múltiples punteros compartan el mismo objeto. Utiliza el conteo de referencias (Reference Counting) para liberar la memoria cuando el conteo llega a 0. Dado que requiere operaciones de incremento/decremento atómicas, se produce una ligera sobrecarga de rendimiento (equivalente al $O_{sync}$ mencionado anteriormente).

3. Propiedad (Ownership) de Rust: Un cambio de paradigma

Rust ha situado el concepto de std::unique_ptr de C++ en el núcleo de la especificación del lenguaje, creando un “modelo de propiedad” mucho más estricto.

Las 3 reglas de la Propiedad

El sistema de propiedad de Rust se basa en tres reglas extremadamente simples:

Cada valor en Rust tiene una variable que se llama su propietario (owner).
Solo puede haber un propietario a la vez.
Cuando el propietario sale del ámbito, el valor se descarta.

En Rust, los recursos se “mueven” por defecto. A diferencia de C++, donde se debe especificar std::move, la propiedad se transfiere simplemente mediante la operación de asignación.

1
2
3
4
5
6
7
8


// Rust: Movimiento (move) de la propiedad
fn main() {
 let s1 = String::from("hello"); // Datos asignados en el montículo
 let s2 = s1; // La propiedad se mueve de s1 a s2

 // La mayor diferencia con C++: ¡El acceso a la variable después del movimiento es un "error de compilación"!
 // println!("{}, world!", s1); // Error de compilación: value borrowed here after move
}

Esta característica de “hacer que las variables sean inaccesibles en tiempo de compilación después de un movimiento” es una de las razones por las que Rust es más seguro que std::unique_ptr de C++.

sequenceDiagram participant S1 as "Variable s1" participant Heap as "Memoria del Montículo ('hello')" participant S2 as "Variable s2" S1->>Heap: "Asigna y Posee" Note over S1,S2: "let s2 = s1;" S1--xHeap: "Pierde la Propiedad (Invalidado)" S2->>Heap: "Toma la Propiedad"

4. Préstamo (Borrowing) y Referencias

Si la propiedad se mueve constantemente, tendríamos que devolver la propiedad cada vez que pasamos un valor a una función, lo cual es muy inconveniente. Aquí es donde entra el “Préstamo” (Borrowing). Equivale a los punteros y referencias de C++.

Hay dos tipos de préstamos en Rust:

Referencia inmutable (Immutable Reference): &T (Similar a const T& en C++)
Referencia mutable (Mutable Reference): &mut T (Similar a T& en C++)

La regla despiadada del comprobador de préstamos (Borrow Checker)

El compilador de Rust lleva incorporado un “comprobador de préstamos” que verifica la validez de las referencias. El comprobador de préstamos impone las siguientes reglas estrictas:

En cualquier ámbito dado, solo puede existir uno de los siguientes:

Una referencia mutable (&mut T)

Múltiples referencias inmutables (&T)

Este es un principio llamado “Múltiple Lectores O un solo Escritor” (Multiple Readers XOR Single Writer, MRSW). Puede expresarse matemáticamente usando el O exclusivo (XOR); para un estado $S$, el número de referencias inmutables $N_r$ y el número de referencias mutables $N_w$ deben cumplir con la siguiente restricción:

$$ (N_r \ge 0 \land N_w = 0) \oplus (N_r = 0 \land N_w = 1) $$

Gracias a esta regla, se eliminan completamente las condiciones de carrera de datos en tiempo de compilación. Una condición de carrera de datos ocurre cuando ① dos o más punteros acceden a los mismos datos simultáneamente, ② al menos uno de ellos realiza una escritura, y ③ no hay un mecanismo de sincronización. Rust previene esto destruyendo la condición ② en tiempo de compilación.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// Rust: Error de compilación por violación de la regla de préstamo
fn main() {
 let mut s = String::from("hello");

 let r1 = &s; // Préstamo inmutable (OK)
 let r2 = &s; // Préstamo inmutable (OK)
 // let r3 = &mut s; // ¡Error! No se puede crear un préstamo mutable si ya existe un préstamo inmutable

 println!("{}, {}", r1, r2);
}

5. Prevención de la invalidación de iteradores (Iterator Invalidation)

Veamos un error clásico, la “invalidación de iteradores”, como un ejemplo concreto donde el poder del comprobador de préstamos brilla más.

Invalidación de iteradores en C++ (Bloqueo en tiempo de ejecución)

Si se modifica un std::vector de C++ durante un bucle, es posible que la memoria subyacente se reasigne, convirtiendo las referencias en punteros colgantes.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


// C++: El error de la invalidación de iteradores
#include <iostream>
#include <vector>

int main() {
 std::vector<int> v = {1, 2, 3};

 // Obtener una referencia a un elemento del vector
 int& first = v[0];

 // Agregar un elemento (Si no hay capacidad suficiente aquí, se asigna una nueva área de memoria,
 // y la antigua área puede ser descartada)
 v.push_back(4);

 // ¡first podría estar apuntando a memoria ya liberada! (Comportamiento indefinido)
 std::cout << "The first element is: " << first << std::endl;

 return 0;
}

Defensa en tiempo de compilación por Rust

Escribamos exactamente la misma lógica en Rust.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// Rust: Prevención de la invalidación de iteradores en tiempo de compilación
fn main() {
 let mut v = vec![1, 2, 3];

 // Obtener una referencia inmutable (Inicio del préstamo)
 let first = &v[0];

 // ¡Error! Mientras `first` tenga un préstamo inmutable de `v`,
 // no se puede realizar el préstamo mutable requerido por `v.push`.
 // v.push(4);

 println!("The first element is: {}", first);
}

De esta manera, en Rust, “modificar un valor (préstamo mutable) mientras se está leyendo (préstamo inmutable)” está prohibido a nivel del compilador, por lo que errores fatales como el uso después de la liberación (Use-After-Free) y la invalidación de iteradores se capturan de forma fiable en tiempo de compilación.

graph LR A["Variable v (Propietario)"] --> B["Matriz en el Montículo [1, 2, 3]"] C["Referencia 'first' (&v[0])"] -.->|"Préstamo Inmutable"| B A -->|X "¡Préstamo Mutable Denegado!"| D["v.push(4)"] style C stroke:#00FF00,stroke-width:2px style D stroke:#FF0000,stroke-width:2px

6. Propiedad Compartida en Rust: `Rc` y `Arc`

Rust también proporciona una propiedad compartida equivalente a std::shared_ptr de C++, pero separa claramente los tipos para uso en un solo hilo y para uso en múltiples hilos.

Para un solo hilo: `Rc<T>` (Reference Counted)

Rc<T> es un puntero inteligente de conteo de referencias no seguro para hilos (non-thread-safe). Ya que incrementa y decrementa el conteo sin utilizar instrucciones atómicas, es extremadamente rápido dentro de un solo hilo. Sin embargo, si intentas enviarlo a otro hilo, resultará en un error de compilación (porque no implementa el rasgo Send).

Para múltiples hilos: `Arc<T>` (Atomic Reference Counted)

Cuando se comparte entre hilos, se usa Arc<T>, que realiza incrementos y decrementos de manera atómica. Tiene un costo equivalente a std::shared_ptr de C++.

Además, en C++, si varios hilos escriben simultáneamente en una variable compartida mediante std::shared_ptr, se producirá una condición de carrera de datos. Para prevenir esto, es necesario usar std::mutex manualmente de forma correcta.

Por otro lado, en Rust, no se pueden modificar los datos internos solo con Arc<T>. Si se necesita modificar, debe combinarse con Mutex<T>, que es un mutex.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


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

fn main() {
 // Combinación de recursos compartidos seguros para hilos y control de exclusión
 // Similar a std::shared_ptr<std::mutex> de C++, pero el Mutex encierra los datos
 let counter = Arc::new(Mutex::new(0));
 let mut handles = vec![];

 for _ in 0..10 {
 let counter_clone = Arc::clone(&counter);
 let handle = thread::spawn(move || {
 // Solo puedes obtener la referencia mutable interna (&mut i32) llamando a lock()
 let mut num = counter_clone.lock().unwrap();
 *num += 1;
 }); // El bloqueo se libera automáticamente mediante RAII cuando sale del ámbito
 handles.push(handle);
 }

 for handle in handles {
 handle.join().unwrap();
 }

 println!("Result: {}", *counter.lock().unwrap());
}

Lo que cabe destacar es que el Mutex<T> de Rust no es solo un mecanismo de bloqueo, sino que “encapsula los datos a proteger como un tipo”. Esto evita completamente a nivel de compilación el error de “acceder a los datos olvidando tomar el bloqueo”. El sistema está diseñado para que no puedas obtener el derecho de acceso (referencia) a los datos internos a menos que adquieras el bloqueo (lock()).

Conclusión: ¿“Inspección previa” por parte del compilador o “responsabilidad propia” por parte del desarrollador?

Los punteros y los punteros inteligentes de C++ proporcionan un alto grado de control y rendimiento a los desarrolladores, pero su uso correcto depende de la disciplina del desarrollador. Aunque la introducción de RAII y std::unique_ptr hizo que C++ fuera drásticamente más seguro, aún no puede prevenir por completo comportamientos indefinidos como el acceso después del movimiento y la invalidación de iteradores a nivel del lenguaje.

Por otro lado, Rust detecta estos errores en tiempo de compilación en lugar de en tiempo de ejecución, incorporando las reglas de Propiedad (Ownership) y Préstamo (Borrowing) en el compilador. Esta fuerte garantía de que “si compila, es seguro para la memoria” es la razón principal por la que Rust está ganando apoyo rápidamente en la programación de sistemas.

Luchar contra el comprobador de préstamos de Rust (Fight the borrow checker) puede ser un gran obstáculo para los principiantes, pero no es más que el compilador asumiendo estrictamente el cálculo complejo de “rastrear la vida útil del puntero” que los programadores de C++ tradicionalmente hacían en sus cabezas.

Si aprendes Rust después de entender la libertad y el peligro de los punteros en C++, deberías poder comprender más profundamente la filosofía detrás del modelo de propiedad: “por qué se diseñó de esta manera”.

Este artículo es un estudio comparativo sobre los métodos de gestión de memoria en C++ y Rust. Esperamos que te sirva de referencia para elegir el lenguaje adecuado según los requisitos de tu proyecto.

Ventajas y desventajas de aprender Rust como ingeniero de C++

Sat, 12 Sep 2026 03:00:00 +0900

Introducción: Un nuevo amanecer en la programación de sistemas

En la ingeniería de software moderna, C++ y Rust son los dos gigantes que lideran la vanguardia de la programación de sistemas. Durante muchos años, C++ ha reinado como el rey absoluto en áreas que extraen el máximo rendimiento del hardware, como sistemas operativos, dispositivos embebidos, motores de juegos y sistemas de comercio de alta frecuencia (HFT). Como ingeniero senior de C++, yo mismo he estado escribiendo código a lo largo de este viaje, empezando por la jungla de los punteros crudos en la era de C++98, pasando por la ola de modernización con C++11 (introducción de punteros inteligentes, expresiones lambda, auto), y continuando con la expansión masiva de las especificaciones en C++14/17/20.

Sin embargo, en los últimos años, Rust ha experimentado un ascenso dramático como solución a los problemas estructurales que enfrenta C++: específicamente la “falta de seguridad de memoria” que conduce a vulnerabilidades de seguridad (se dice que alrededor del 70% de los CVE son causados por la memoria) y la “complejidad interminable de especificaciones y comportamientos indefinidos (UB)”. Su adopción oficial en el kernel de Linux, y los proyectos de migración a gran escala a Rust por gigantes tecnológicos como Microsoft, Google y AWS, significan que no es solo una moda pasajera, sino un cambio de paradigma en la programación de sistemas.

En este artículo, compararé y explicaré exhaustivamente desde un punto de vista técnico y fundamental las “ventajas” y “desventajas” que un ingeniero de C++ puro ha experimentado al aprender profundamente Rust y usarlo en la práctica.

1. El cambio de paradigma en la gestión de memoria: de RAII a Ownership y Borrowing

RAII en C++ y los límites de los punteros inteligentes

Una de las mayores invenciones de C++ es RAII (Resource Acquisition Is Initialization). Este concepto, que consiste en asegurar los recursos en el constructor y liberarlos automáticamente en el destructor al salir del alcance (scope), liberó a los desarrolladores del temor a las fugas de memoria causadas por el uso manual de new y delete. A partir de C++11, se introdujeron std::unique_ptr y std::shared_ptr en la biblioteca estándar, lo que permitió expresar el concepto de propiedad (Ownership) en el código.

Sin embargo, los punteros inteligentes y la semántica de movimiento de C++ tienen una debilidad fatal: la verificación estática por parte del compilador es incompleta.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


#include <iostream>
#include <memory>
#include <string>

void consume(std::unique_ptr<std::string> ptr) {
 std::cout << "Consuming: " << *ptr << std::endl;
}

int main() {
 auto my_ptr = std::make_unique<std::string>("Hello, C++");

 // Mover (Move) la propiedad a la función
 consume(std::move(my_ptr));

 // Peligro: En C++, acceder a un objeto después del movimiento no causa un error de compilación
 // std::move es simplemente un cast a una referencia rvalue (T&&), y el compilador no bloquea su uso
 if (my_ptr) {
 std::cout << "Pointer is still valid?" << std::endl;
 } else {
 std::cout << "Pointer is null." << std::endl;
 }

 // std::cout << *my_ptr << std::endl; // Comportamiento indefinido por el uso de memoria después de ser liberada (Use-After-Free)
 return 0;
}

En C++, siempre existe el riesgo de acceder por error a un objeto que ha sido vaciado por std::move (un estado válido pero no especificado). Esto puede provocar bloqueos (crashes) en tiempo de ejecución o, en el peor de los casos, directamente vulnerabilidades de seguridad.

Propiedad (Ownership) en Rust y la defensa absoluta del Borrow Checker

Rust incorpora este concepto de “propiedad” en el diseño central del lenguaje, y realiza un análisis estático estricto mediante una característica del compilador llamada Borrow Checker.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


fn consume(s: String) {
 println!("Consuming: {}", s);
} // Aquí s sale del alcance, y la memoria es liberada (Drop)

fn main() {
 let my_string = String::from("Hello, Rust");

 // Mover la propiedad a la función. En Rust, la semántica de movimiento es el valor por defecto.
 consume(my_string);

 // ¡Error de compilación! Es absolutamente imposible acceder a la variable después de ser movida
 // println!("Is it still there? {}", my_string);
}

En Rust, en el momento en que se transfiere la propiedad de una variable, el compilador trata a la variable original de manera equivalente a un estado “no inicializado”, bloqueando completamente cualquier acceso posterior. Debido a esto, errores como “Use-After-Free (Uso de memoria después de ser liberada)” y “Dangling Pointer (Puntero colgante)” teóricamente no pueden pasar la compilación.

graph TD A["C++ std::unique_ptr"] --> B["std::move aplicado"] B --> C["Propiedad transferida"] C --> D["El puntero antiguo sigue siendo accesible"] D --> E["Posible comportamiento indefinido (UB)"] F["Rust Box / String"] --> G["Pasado por valor (Move)"] G --> H["Propiedad transferida"] H --> I["El compilador bloquea la variable antigua"] I --> J["Seguridad de memoria garantizada"]

Préstamo (Borrowing) y control de mutabilidad

Aún más poderosas son las reglas de “Préstamo (Borrowing)” que referencian recursos. En Rust se imponen las siguientes reglas:

En cualquier momento, solo puede existir uno de los siguientes casos: “Múltiples referencias inmutables (&T)” o “Una única referencia mutable (&mut T)”.
Una referencia no debe vivir más tiempo que el alcance de los datos originales (restricción de tiempo de vida - lifetime).

En C++, se pueden crear fácilmente múltiples referencias o punteros mutables para el mismo objeto, lo que provoca la destrucción de estados inesperados (como la invalidación de iteradores). Rust prohíbe esta combination de “Aliasing + Mutabilidad” a nivel de lenguaje para prevenir errores antes de que ocurran.

2. Diseño de memoria y la sobrecarga matemática de los punteros inteligentes

En la programación de sistemas, es esencial tener una comprensión precisa del diseño de la memoria. Comparemos std::shared_ptr de C++ con std::rc::Rc / std::sync::Arc de Rust.

std::shared_ptr en C++ gestiona los recursos mediante conteo de referencias, y por defecto aumenta y disminuye este conteo utilizando operaciones atómicas thread-safe (std::atomic). Su sobrecarga de memoria se puede formular de la siguiente manera:

$$ Overhead_{C++} = sizeof(T) + sizeof(ControlBlock) $$

Aquí, el $ControlBlock$ incluye el “Contador de referencias fuertes (Strong Ref Count)”, el “Contador de referencias débiles (Weak Ref Count)” y un “Eliminador personalizado (Custom Deleter)”. El problema es que, incluso en escenarios donde solo se usa un hilo (single-thread), la sobrecarga de las instrucciones atómicas (bloqueos en la línea de caché, etc.) ocurre incondicionalmente.

En contraste, Rust separa estrictamente los punteros inteligentes según su caso de uso.

Para un solo hilo: Rc<T> (Reference Counted)
Para múltiples hilos: Arc<T> (Atomic Reference Counted)

$$ Overhead_{Rc} = sizeof(T) + 2 \times sizeof(usize) $$ $$ Overhead_{Arc} = sizeof(T) + 2 \times sizeof(AtomicUsize) $$

En Rust, si se usa Rc<T>, que es exclusivo para un solo hilo, se puede evitar por completo la penalización de las operaciones atómicas (abstracción de costo cero). Y gracias al mecanismo de seguridad de hilos (thread-safety) que veremos más adelante, pasar Rc<T> a otro hilo por error es completamente prevenido por el sistema de tipos.

3. Seguridad de hilos (Thread-Safety): El impacto de “Fearless Concurrency”

En C++, la programación multihilo siempre ha estado acompañada del miedo a las condiciones de carrera (data races) y los bloqueos (deadlocks).

Peligros de los Mutex en C++ y la separación de datos

El std::mutex en C++ es simplemente para controlar la exclusividad en “un bloque de código específico (sección crítica)”, y no existe ningún vínculo a nivel de lenguaje entre “los datos que se deben proteger” y el “mutex”.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


#include <iostream>
#include <thread>
#include <mutex>
#include <vector>

std::vector<int> shared_data;
std::mutex mtx;

void worker() {
 // Incluso si el desarrollador olvida adquirir el bloqueo, compilará sin problemas
 // std::lock_guard<std::mutex> lock(mtx);
 shared_data.push_back(1); // ¡Condición de carrera fatal!
}

int main() {
 std::thread t1(worker);
 std::thread t2(worker);
 t1.join();
 t2.join();
 return 0;
}

En Rust, Mutex “posee” los datos

En Rust, Mutex<T> utiliza genéricos para encapsular (poseer) el tipo de dato T que protege. Para acceder a los datos, es absolutamente necesario invocar lock() y obtener un objeto guardia (guard object). Es sintácticamente imposible tocar los datos sin obtener el bloqueo.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


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

fn main() {
 // Los datos están completamente encapsulados dentro del Mutex
 let shared_data = Arc::new(Mutex::new(Vec::new()));
 let mut handles = vec![];

 for _ in 0..2 {
 // Clonar Arc (conteo de referencias seguro para hilos) para compartirlo entre hilos
 let data_clone = Arc::clone(&shared_data);
 let handle = thread::spawn(move || {
 // No se puede acceder al Vec interno a menos que se adquiera el bloqueo
 let mut data = data_clone.lock().unwrap();
 data.push(1);
 });
 handles.push(handle);
 }

 for handle in handles {
 handle.join().unwrap();
 }
}

Además, Rust cuenta con dos traits centrales que garantizan la seguridad del procesamiento concurrente.

Send: Tipos cuya propiedad puede transferirse de forma segura entre hilos.
Sync: Tipos a los que se puede acceder simultáneamente desde varios hilos de forma segura.

Por ejemplo, Rc<T>, que no es seguro para hilos, no implementa el trait Send. Por lo tanto, intentar pasarlo a thread::spawn resulta en un error de compilación instantáneo. Gracias a esta “Fearless Concurrency” (Concurrencia sin miedo), los desarrolladores se liberan del temor a los errores y pueden promover la paralelización de forma más agresiva.

Según la Ley de Amdahl (Amdahl’s Law), el rendimiento máximo teórico en relación a la parte paralelizable $P$ y el grado de paralelismo $N$ se expresa de la siguiente manera:

$$ S(N) = \frac{1}{(1 - P) + \frac{P}{N}} $$

Rust permite maximizar esta $P$ a través de refactorizaciones que pueden realizarse con extrema seguridad basándose en el sistema de tipos.

graph TD A["Seguridad de hilos en C++"] --> B["Depende de la memoria del desarrollador"] B --> C["Mutex desacoplado de los datos"] C --> D["Alto riesgo de condiciones de carrera silenciosas"] E["Seguridad de hilos en Rust"] --> F["Traits Send y Sync"] F --> G["Mutex posee los datos"] G --> H["Condiciones de carrera prevenidas en tiempo de compilación"]

4. Manejo de errores: Excepciones vs Tipos de Datos Algebraicos

El estándar de manejo de errores en C++ son las “Excepciones” (Exceptions). Sin embargo, las excepciones opacan el flujo de control y provocan penalizaciones de rendimiento (stack unwinding y sobrecarga de RTTI). En los sistemas embebidos y en los motores de juegos, suele ser común adoptar un diseño que devuelve códigos de error clásicos y deshabilita completamente las excepciones (-fno-exceptions). En C++23 se introdujo std::expected, pero tomará tiempo hasta que penetre en todo el ecosistema.

En Rust, el concepto de excepción no existe. Los errores se devuelven como “valores” puros y se representan mediante un enum (tipo de dato algebraico) llamado Result<T, E>.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


use std::fs::File;
use std::io::{self, Read};

// Con solo mirar el tipo de retorno, queda claro que puede ocurrir un error de IO
fn read_file_content(path: &str) -> Result<String, io::Error> {
 // Con el operador ?, si hay un error, hace un retorno anticipado inmediato, si es un éxito, extrae el contenido
 let mut file = File::open(path)?;
 let mut content = String::new();
 file.read_to_string(&mut content)?;
 Ok(content)
}

Este operador ? es revolucionario. Elimina la profunda anidación (pirámide de if) que ocurre al comprobar los códigos de error en C++, manteniendo un flujo de código limpio como el de las excepciones, a la vez que permite describir explícitamente en qué llamadas a funciones se propagan los errores.

5. Polimorfismo: De Funciones Virtuales y Plantillas a Traits

El polimorfismo en C++ se logra principalmente a través del despacho dinámico (dynamic dispatch) mediante herencia de clases y funciones virtuales (virtual), o despacho estático mediante plantillas (CRTP, etc.).

En el despacho dinámico, se inserta un puntero (vptr) a la tabla de funciones virtuales (vtable) en el objeto, lo que provoca una sobrecarga en la resolución del puntero al invocar la función.

$$ T_{dispatch} = T_{lookup\_in\_vtable} + T_{dereference} $$

Rust ha descartado la clásica “herencia de clases” orientada a objetos, adoptando en su lugar el concepto de “Traits” (similar a Concept de C++20, pero con más funcionalidades).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


trait Drawable {
 fn draw(&self);
}

struct Circle { radius: f64 }
impl Drawable for Circle {
 fn draw(&self) { println!("Drawing a Circle of radius {}", self.radius); }
}

// Despacho estático (Monomorfización, costo cero de sobrecarga)
fn draw_static<T: Drawable>(item: &T) {
 item.draw();
}

// Despacho dinámico (Objetos Trait)
fn draw_dynamic(item: &dyn Drawable) {
 item.draw();
}

La característica principal del despacho dinámico de Rust (dyn Trait) es que no tiene un vptr dentro de la estructura de datos, sino que utiliza un Puntero Gordo (Fat Pointer). El Fat Pointer mantiene un par con el “puntero a los datos” y el “puntero a la vtable”. Gracias a esto, es muy fácil implementar (extender) un Trait a un tipo definido en una biblioteca externa y aplicarle el despacho dinámico posteriormente.

6. Gestión de paquetes y sistema de construcción: La agonía de CMake y las bendiciones de Cargo

Una de las mayores debilidades de C++ es la falta de un administrador de paquetes estándar. La sintaxis incomprensible de CMakeLists.txt, la complejidad para resolver dependencias a través de find_package, y las diferencias en las rutas de las bibliotecas según el sistema operativo, han estado robando una enorme cantidad de tiempo a los ingenieros de C++.

Rust viene equipado de serie con Cargo, un sistema de construcción y administrador de paquetes de primer nivel a nivel mundial.

graph TD A["Entorno de construcción de C++"] --> B["CMakeLists.txt"] B --> C["Integración de vcpkg / Conan"] C --> D["Generar Makefiles / Ninja"] D --> E["Compilador (GCC/Clang/MSVC)"] F["Entorno de construcción de Rust"] --> G["Cargo.toml"] G --> H["Obtener dependencias de crates.io"] H --> I["rustc (Cargo build)"] I --> J["Binario listo para ejecutar"]

Con solo agregar una línea en Cargo.toml con el nombre y la versión de la biblioteca dependiente (crate), se resuelve, descarga y compila de forma totalmente automática, incluyendo sus dependencias transitivas. Además, herramientas esenciales para el desarrollo como pruebas (cargo test), generación de documentación (cargo doc), análisis estático (cargo clippy) y formateador (cargo fmt) están completamente integradas en este único comando. Esta comodidad es tan disruptiva que, una vez que la experimentas, no querrás volver al entorno de construcción de C++.

7. Desventajas y curva de aprendizaje al aprender Rust

Hasta ahora, he hablado de las ventajas de Rust, pero ciertamente existen “muros” y desventajas que un ingeniero de C++ enfrentará al implementarlo en la práctica.

1. La feroz lucha con el Borrow Checker

Si intentas implementar de la misma manera en Rust una estructura de datos que en C++ simplemente “conectabas de alguna manera con punteros crudos” (por ejemplo, listas doblemente enlazadas, estructuras de grafos, estructuras autorreferenciadas, etc.), la compilación fallará debido a las restricciones de propiedad y tiempos de vida. Para satisfacer al Borrow Checker, necesitas hacer envolturas complejas como Rc<RefCell<T>>, o rediseñar desde la raíz usando un asignador de arena (arena allocator) o una gestión basada en índices.

2. Largos tiempos de compilación

Aunque C++ también ralentiza la compilación al anidar plantillas, el tiempo de compilación de Rust (especialmente en un clean build desde cero) no es para nada corto. Esto se debe a la superposición de las potentes pasadas de optimización de LLVM, la expansión de macros y la monomorfización de genéricos, lo que convierte al tiempo de construcción en un cuello de botella en proyectos a gran escala. Durante el desarrollo, es indispensable ingeniárselas usando cargo check con frecuencia.

3. Interoperabilidad con bases de código de C++

La integración con el lenguaje C (FFI) es muy fluida, pero integrar Rust directamente en bases de código enormes de C++ existentes (aquellas que utilizan en gran medida clases, plantillas y funciones virtuales) es extremadamente difícil. En los últimos años, han evolucionado herramientas puente como cxx y autocxx, pero todavía hay un listón alto para una transición completamente fluida.

Conclusión: ¿Deberíamos migrar a Rust?

C++ seguirá desempeñando un papel importante en el desarrollo de motores de juegos y en la enorme infraestructura existente. Su modernización a través de C++20/23 también ha sido notable, volviéndose más seguro de escribir.

Sin embargo, para “proyectos de programación de sistemas creados desde cero”, siento que hoy en día es más difícil encontrar razones para no elegir Rust. Una vez que pasas la compilación, te liberas del miedo a los comportamientos indefinidos y a la corrupción de memoria, y puedes ejecutar un procesamiento concurrente seguro y con alto rendimiento; esta “certeza” de Rust mejora drásticamente el modelo mental del ingeniero.

Para los ingenieros de C++, aprender Rust no es solo memorizar una nueva sintaxis, sino la mejor experiencia para adquirir una nueva perspectiva sobre “cómo gestionar de forma segura la memoria y los hilos”. Te invito a experimentar la comodidad de Cargo y la severidad del Borrow Checker.