El sistema de ownership y borrowing constituye la base de las garantias de seguridad de memoria en Rust. A diferencia de los lenguajes con recolector de basura, Rust aplica reglas estrictas en tiempo de compilacion a traves del borrow checker, eliminando categorias enteras de errores -- desreferencias de punteros nulos, condiciones de carrera y errores de uso despues de liberacion -- sin costo alguno en tiempo de ejecucion. Cada valor en Rust tiene exactamente un propietario. Cuando el propietario sale del alcance, el valor se libera. El ownership puede transferirse (move) o prestarse temporalmente (borrow). Estas tres reglas reemplazan por completo al recolector de basura. ## Como la semantica de movimiento reemplaza al recolector de basura La mayoria de los lenguajes permiten que multiples variables apunten a los mismos datos en el heap. Rust adopta un enfoque diferente: asignar un valor del heap a otra variable lo *mueve*, invalidando el binding original. El compilador garantiza esto sin costo adicional. ```rust // move_semantics.rs fn main() { let original = String::from("interview prep"); let moved = original; // ownership transfers here // println!("{}", original); // compile error: value moved println!("{}", moved); // works fine } ``` Este mecanismo previene errores de doble liberacion. El tipo `String` asigna memoria en el heap, por lo que Rust asegura que solo una variable sea propietaria de esa asignacion en cualquier momento. Los tipos que residen exclusivamente en el stack, como `i32` o `bool`, implementan el trait `Copy` y se duplican en lugar de moverse. ```rust // copy_vs_move.rs fn main() { let x: i32 = 42; let y = x; // copy, not move -- i32 is Copy println!("x = {}, y = {}", x, y); // both valid let s1 = String::from("hello"); let s2 = s1.clone(); // explicit deep copy println!("s1 = {}, s2 = {}", s1, s2); // both valid after clone } ``` La distincion entre `Copy` y `Clone` resulta relevante en entrevistas tecnicas: `Copy` es implicito y economico (copia bit a bit), mientras que `Clone` es explicito y puede resultar costoso (asignacion en el heap). ## Prestamo con referencias inmutables Transferir el ownership en cada operacion haria que el codigo fuera impractico. El borrowing en Rust resuelve este problema prestando acceso a un valor sin transferir la propiedad. Una referencia inmutable (`&T`) permite acceso de solo lectura, y multiples referencias inmutables pueden coexistir sin restricciones. ```rust // immutable_borrowing.rs fn calculate_length(s: &String) -> usize { s.len() // read access through the reference } // s goes out of scope, but doesn't drop the String (not the owner) fn main() { let greeting = String::from("hello, Rust"); let len = calculate_length(&greeting); // borrow, don't move println!("'{}' has {} characters", greeting, len); // greeting still valid } ``` El simbolo `&` crea una referencia que toma prestado el valor. La firma de la funcion `&String` declara que `calculate_length` toma prestado sin adquirir la propiedad. Despues de que la funcion retorna, el llamador conserva la propiedad completa del dato. En cualquier momento dado, un valor puede tener: muchas referencias inmutables (`&T`), O exactamente una referencia mutable (`&mut T`). Nunca ambas simultaneamente. Esta regla previene condiciones de carrera en tiempo de compilacion. ## Referencias mutables y la regla de exclusividad Las referencias mutables (`&mut T`) otorgan acceso de escritura pero imponen exclusividad: solo puede existir una referencia mutable a un valor en un alcance determinado. Esto impide que dos fragmentos de codigo modifiquen los mismos datos de forma simultanea. ```rust // mutable_borrowing.rs fn append_greeting(s: &mut String) { s.push_str(", welcome to Rust!"); // modify through mutable ref } fn main() { let mut message = String::from("Hello"); append_greeting(&mut message); println!("{}", message); // "Hello, welcome to Rust!" } ``` La palabra clave `mut` aparece en tres lugares: el binding de la variable (`let mut`), el tipo de referencia (`&mut`) y el parametro de la funcion. Los tres son obligatorios. Intentar crear una segunda referencia mutable en el mismo alcance genera un error de compilacion. ```rust // exclusivity_rule.rs fn main() { let mut data = String::from("shared state"); let r1 = &mut data; // let r2 = &mut data; // compile error: second mutable borrow println!("{}", r1); // After r1's last usage, a new mutable borrow is allowed let r3 = &mut data; // this works -- non-lexical lifetimes r3.push_str(" updated"); println!("{}", r3); } ``` La edicion 2021 de Rust utiliza non-lexical lifetimes (NLL): un prestamo finaliza en su ultimo punto de uso, no al final del bloque de alcance. Esto hace que la regla de exclusividad sea mas ergonomica sin sacrificar la seguridad. ## Lifetimes: indicando al compilador cuanto viven las referencias Los lifetimes son el mecanismo de Rust para asegurar que las referencias nunca sobrevivan a los datos a los que apuntan. La mayoria del tiempo, el compilador infiere los lifetimes automaticamente mediante las *reglas de elision de lifetimes*. Las anotaciones explicitas se vuelven necesarias cuando multiples referencias interactuan entre si. ```rust // lifetime_annotation.rs fn longest<'a>(x: &'a str, y: &'a str) -> &'a str { if x.len() > y.len() { x } else { y } } fn main() { let result; let string1 = String::from("Rust ownership"); { let string2 = String::from("borrowing"); result = longest(string1.as_str(), string2.as_str()); println!("Longest: {}", result); // valid: both strings alive } // println!("{}", result); // would fail: string2 dropped } ``` La sintaxis `'a` es un parametro de lifetime, no un concepto nuevo -- anota relaciones que ya existen. La firma de la funcion expresa: "la referencia de salida no puede vivir mas que ninguna de las referencias de entrada." El compilador utiliza esta informacion para prevenir referencias colgantes. ## Structs con borrowing y limites de lifetime Los structs que contienen referencias deben declarar parametros de lifetime. Esto garantiza que el struct no pueda sobrevivir a los datos que referencia -- una fuente comun de punteros colgantes en C/C++. ```rust // struct_lifetime.rs struct Excerpt<'a> { text: &'a str, } impl<'a> Excerpt<'a> { fn summary(&self) -> &str { let end = self.text.len().min(20); &self.text[..end] } } fn main() { let article = String::from("Rust ownership model eliminates memory bugs"); let excerpt = Excerpt { text: article.as_str(), }; println!("Summary: {}", excerpt.summary()); } ``` El lifetime `'a` en `Excerpt<'a>` vincula la validez del struct al string subyacente. Liberar `article` antes que `excerpt` generaria un error de compilacion. Este patron resulta fundamental para el diseno de APIs seguras en Rust. Las preguntas sobre referencias colgantes aparecen con frecuencia en las entrevistas de Rust. La respuesta siempre es la misma: Rust las previene en tiempo de compilacion mediante el analisis de lifetimes. Sin verificaciones en tiempo de ejecucion, sin punteros nulos. ## Patrones de ownership en Rust del mundo real El codigo Rust en produccion se apoya en algunos patrones recurrentes de ownership. Reconocerlos acelera tanto el desarrollo como el rendimiento en entrevistas tecnicas. ```rust // ownership_patterns.rs fn process_and_return(mut input: String) -> String { input.push_str(" -- processed"); input } fn contains_keyword(text: &str, keyword: &str) -> bool { text.to_lowercase().contains(&keyword.to_lowercase()) } fn sanitize(input: &mut String) { *input = input.trim().to_string(); } fn main() { let raw = String::from("user input"); let processed = process_and_return(raw); let found = contains_keyword(&processed, "input"); println!("Contains 'input': {}", found); let mut padded = String::from(" spaces everywhere "); sanitize(&mut padded); println!("Sanitized: '{}'", padded); } ``` El primer patron toma ownership y retorna un nuevo valor -- util cuando se transforma un dato y el llamador ya no necesita el original. El segundo patron toma prestado de forma inmutable para inspeccion de solo lectura. El tercer patron toma prestado de forma mutable para modificacion en el lugar. La heuristica para elegir entre estos patrones es directa: prestar de forma inmutable por defecto, prestar de forma mutable cuando se necesita modificar, y transferir ownership solo cuando el llamador ya no requiere el valor. ## Errores del borrow checker y como resolverlos El borrow checker produce codigos de error especificos. Comprender los mas comunes transforma errores de compilacion frustrantes en correcciones directas. ```rust // common_fixes.rs fn main() { let mut scores = vec![90, 85, 78]; let first = scores[0]; scores.push(95); println!("First: {}, All: {:?}", first, scores); let name = String::from("Alice"); let greeting = format!("Hello, {}", name); println!("{} says {}", name, greeting); let outer; { let inner = String::from("temporary"); outer = inner; } println!("{}", outer); } ``` **Error E0502** -- no se puede tomar prestado como mutable porque tambien esta prestado como inmutable. La solucion consiste en finalizar el uso del prestamo inmutable antes de mutar. En el ejemplo, `scores[0]` copia el valor (ya que `i32` implementa `Copy`), por lo que no queda un prestamo activo al momento de llamar a `push`. **Error E0382** -- uso de valor movido. El macro `format!` toma prestado en lugar de mover, por lo que `name` sigue siendo valido despues de la llamada. Conocer que operaciones mueven y cuales toman prestado es clave para evitar este error. **Error E0597** -- el valor prestado no vive lo suficiente. La solucion es mover el valor en lugar de tomarlo prestado, extendiendo asi su lifetime. En el ejemplo, `outer = inner` transfiere el ownership fuera del bloque interno. Cada correccion sigue el mismo principio: reestructurar el codigo para que los prestamos y la propiedad se alineen con las reglas de Rust. Luchar contra el borrow checker generalmente indica un problema de diseno que causaria errores en otros lenguajes. Para patrones mas avanzados que involucran concurrencia y borrowing, los tipos de ownership compartido como `Arc` y `Mutex` se vuelven esenciales. ## Conclusion - Cada valor en Rust tiene un unico propietario; la propiedad se transfiere al asignar (semantica de movimiento) a menos que el tipo implemente `Copy` - Las referencias inmutables (`&T`) permiten acceso compartido de lectura; las referencias mutables (`&mut T`) imponen acceso exclusivo de escritura - El borrow checker previene condiciones de carrera y referencias colgantes en tiempo de compilacion con cero costo en tiempo de ejecucion - Los lifetimes anotan relaciones entre referencias -- describen restricciones existentes, no crean nuevas - Cuando el borrow checker rechaza codigo, la solucion es reestructurar el flujo de ownership en lugar de recurrir a `unsafe` - Practicar estos patrones con las [preguntas de entrevista de Rust](/blog/rust/rust-interview-questions) construye fluidez antes de las entrevistas tecnicas