La comunidad de Rust convirtió .clone() en un pecado moral. Ese dogma es tan peligroso como la incapacidad del Consejo Jedi para adaptarse. Ponemos la culpa bajo el microscopio: los números reales de rendimiento, el lint de clippy que la refuerza y la teoría de tipos que explica por qué Rust hace visible la duplicación.
Move, borrow, clone, Rc, Arc, Cow. Rust te da seis formas de sable laser para el ownership. Cada una contrarresta una amenaza concreta. Usar la forma equivocada contra el oponente equivocado no es solo inelegante, es fatal. Mapeamos cada estrategia a las situaciones donde brilla y donde falla catastroficamente.
La comunidad Rust trata .clone() como un code smell. A veces lo es. Pero la mayoría de las veces, el instinto de evitarlo cuesta más en complejidad de lo que el clone cuesta en nanosegundos. Diseccionamos qué hace clone realmente para cada tipo común, el espectro real de costes a lo largo de seis órdenes de magnitud, y por qué Clone y Copy no son la misma conversación.
Arrancamos una nueva serie migrando el adaptador CLI a una TUI con ratatui. Configuramos las nuevas dependencias, diseñamos la estructura de módulos bajo adapters/tui/, modelamos los modos de interacción como un enum para hacer los estados inválidos irrepresentables, y resolvemos el puzzle de ownership al clonar un repositorio en una sesión persistente.
Cerramos la serie explorando qué implica migrar de CLI a TUI con ratatui: cómo cambia el modelo de interacción, qué fricciones introduce Rust con ownership y &mut en un event loop persistente, y por qué la arquitectura hexagonal absorbe el cambio sin cirugía.
Mis primeras impresiones de Rust desde un enfoque de programación funcional (Scala y Haskell). Una mezcla de emoción, frustración y un cambio de paradigma en la forma de pensar.