Swift y Rust: la memoria como contrato

Swift y Rust se presentaron en público con pocos meses de diferencia y con el mismo enemigo declarado: el recolector de basura. Ninguno de los dos aceptaba pausas impredecibles ni un tiempo de ejecución pesado, y ninguno estaba dispuesto a devolverle al programador el malloc y el free. La respuesta de Swift fue automatizar el conteo de referencias en tiempo de compilación y pagar el precio en tiempo de ejecución; la de Rust fue convertir la propiedad en un rasgo del tipo y pagar el precio en la cabeza de quien escribe. Comparar ambos lenguajes por su sintaxis es perder el tiempo: la diferencia real está en dónde cae la carga de la prueba, y esa única decisión explica casi todo lo demás.

Dos respuestas a la misma pregunta

Swift decide cuándo liberar mirando un contador. Cada referencia fuerte a una instancia de clase suma uno, cada referencia que muere resta uno, y el objeto se destruye en el instante exacto en que el contador llega a cero. El compilador inserta esas operaciones por ti; el programador solo interviene cuando el grafo de referencias tiene ciclos, porque un ciclo mantiene vivos mutuamente a dos objetos que ya nadie más alcanza.

final class Nodo {
    var valor: Int
    var siguiente: Nodo?        // referencia fuerte
    weak var anterior: Nodo?    // debil: rompe el ciclo
    init(_ v: Int) { valor = v }
}

var a: Nodo? = Nodo(1)          // cuenta = 1
let b = a                       // cuenta = 2
a = nil                         // cuenta = 1, el objeto sigue vivo

Rust decide quién libera mirando el tipo. Cada valor tiene un dueño único, asignarlo a otro nombre transfiere la propiedad, y el destructor corre al final del ámbito del dueño actual. No hay contador porque no hace falta: la respuesta ya está escrita estáticamente en el programa.

struct Nodo { valor: i32 }

fn consumir(n: Nodo) { /* n se destruye al terminar la funcion */ }

let a = Nodo { valor: 1 };
consumir(a);
// println!("{}", a.valor);   // error de compilacion: valor movido

Sobre esa base se levanta el borrow checker, cuya regla central cabe en una frase: en cada instante puedes tener muchos lectores o un único escritor, nunca ambos. Ese invariante —alias o mutación, jamás los dos a la vez— es lo que permite a Rust afirmar cosas que Swift no puede afirmar por la misma vía.

Lo que garantiza cada uno

Las garantías se parecen menos de lo que sugiere la etiqueta compartida de «lenguaje seguro en memoria».

La cuarta fila esconde una asimetría que casi nadie nota. Swift también prohíbe el acceso simultáneo exclusivo y no exclusivo a la misma variable, exactamente el invariante de Rust, pero solo puede demostrarlo estáticamente para variables locales; para propiedades de clase y globales inserta una comprobación en ejecución que aborta el proceso al detectar la violación.

var puntuaciones = [1, 2, 3]

func duplicar(_ v: inout [Int], usando otro: [Int]) { /* ... */ }

duplicar(&puntuaciones, usando: puntuaciones)
// acceso exclusivo y de lectura a la vez: error en compilacion si es local,
// captura en ejecucion si la variable es una propiedad

La fila decisiva es la tercera, porque revela que los dos lenguajes llegan al mismo destino por caminos distintos. Rust obtiene la ausencia de carreras gratis, como corolario de la regla de alias: si nadie puede tener un puntero mutable y otro lector a la vez, tampoco puede haberlos en dos hilos. Swift no dispone de ese teorema, así que construyó un sistema paralelo —dominios de aislamiento, actores y el protocolo Sendable— que verifica lo mismo con otra álgebra. La consecuencia práctica es que en Swift la seguridad de memoria y la seguridad frente a concurrencia son dos mecanismos separados que hay que aprender por separado, mientras que en Rust son una sola idea vista desde dos ángulos.

El precio de cada elección

Swift paga en ejecución. Cada retain y cada release son operaciones atómicas sobre un contador compartido, y aunque el optimizador de ARC elimina buena parte del tráfico y las convenciones de llamada distinguen argumentos prestados de argumentos consumidos, el coste residual es real y, peor aún, invisible: una línea inocente que pasa una clase a una clausura puede añadir dos operaciones atómicas que no aparecen en el código fuente. Por eso los perfiles de Swift en bucles calientes están tan a menudo dominados por swift_retain y swift_release.

Rust paga en compilación y en aprendizaje. El sistema de préstamos rechaza programas correctos que no sabe demostrar correctos —las estructuras autorreferenciales, los grafos, los patrones de observador— y obliga a reformularlos con índices, arenas o Rc con RefCell, que reintroducen comprobaciones en ejecución. Esa es la ironía central de la comparación: cuando un programa de Rust necesita de verdad propiedad compartida, la respuesta idiomática es Rc o Arc, es decir, exactamente el conteo de referencias que Swift aplica por defecto a todas sus clases. La diferencia no es el mecanismo, es quién elige y cuándo.

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

// Propiedad compartida y mutacion: ARC manual, con coste explicito
let compartido = Rc::new(RefCell::new(vec![1, 2, 3]));
let otro = Rc::clone(&compartido);          // cuenta = 2
otro.borrow_mut().push(4);                  // comprobacion en ejecucion

Swift está importando el modelo

Desde 2022 el lenguaje incorpora sistemáticamente piezas del vocabulario de Rust, y no por moda: las necesita para bajar al terreno donde ARC no es aceptable. Los tipos no copiables ~Copyable traen la semántica de movimiento única; los modificadores borrowing y consuming hacen explícita la convención de paso que antes era un detalle del compilador; el operador consume marca el último uso de un valor; Span y las dependencias de vida útil permiten pasar vistas sobre memoria sin copiar y sin que el compilador pierda de vista quién es el dueño.

struct Fichero: ~Copyable {
    let descriptor: Int32
    init(abriendo ruta: String) throws { descriptor = try abrir(ruta) }
    consuming func cerrar() { close(descriptor) }
    deinit { close(descriptor) }
}

let f = try Fichero(abriendo: "/tmp/log")
f.cerrar()          // consume el valor
// let g = f        // error: no se puede copiar ni usar tras consumir

La dirección contraria del intercambio también existe, aunque se comente menos: la biblioteca estándar de Rust ofrece Rc y Arc porque el modelo de propiedad única resulta insuficiente para grafos y observadores, y buena parte de su ergonomía moderna —inferencia de vidas útiles, préstamos no léxicos— consiste precisamente en pedir menos anotaciones al programador, que es la dirección en la que Swift partió.

El resultado es un lenguaje de dos velocidades: ARC como opción por defecto cómoda para el noventa por ciento del código, y propiedad explícita como opción para el diez por ciento que la necesita. Rust hace lo contrario: propiedad explícita por defecto y conteo de referencias como excepción declarada. Ambas curvas convergen en el mismo espacio de diseño, pero desde extremos opuestos, y esa asimetría se nota en qué resulta fácil escribir mal en cada uno.

flowchart TD
P[Liberar sin recolector de basura] --> S[Swift con ARC]
P --> R[Rust con propiedad]
S --> S1[Contador en tiempo de ejecucion]
S --> S2[Ciclos posibles, se anotan a mano]
S --> S3[Concurrencia segura por aislamiento]
R --> R1[Verificacion en compilacion]
R --> R2[Alias o mutacion, nunca ambos]
R --> R3[Concurrencia segura como corolario]
S1 --> C[Sin uso despues de liberar]
R1 --> C
style P fill:#f9e2af,color:#11111b
style C fill:#a6e3a1,color:#11111b