Swift es un Rust más conveniente (2023)

 (nmn.sh)
2 puntos por GN⁺ 2026-02-01 | 1 comentarios | Compartir por WhatsApp
  • Rust y Swift comparten un sistema de tipos sólido y características de lenguajes funcionales, y gracias a compiladores basados en LLVM pueden compilarse a código nativo y WASM
  • Rust comenzó como un lenguaje de sistemas de bajo nivel y luego incorporó funciones de más alto nivel, mientras que Swift comenzó como un lenguaje de alto nivel y permite acceso de bajo nivel cuando hace falta
  • Swift usa por defecto tipos por valor y Copy-on-Write, e implementa conceptos similares al modelo de ownership de Rust con una sintaxis más simple
  • En tipos opcionales, manejo de errores y enums recursivos, Swift envuelve conceptos de Rust con una sintaxis familiar de la familia C, ofreciendo mayor comodidad al desarrollador
  • Swift sigue evolucionando como lenguaje multiplataforma y puede usarse en Windows, Linux y entornos embebidos, por lo que surge como alternativa a Rust

Similitudes y diferencias entre Rust y Swift

  • Ambos lenguajes incluyen características de lenguajes funcionales (enum etiquetados, expresiones match/switch, genéricos y funciones de primera clase)
    • Rust ofrece conteo de referencias y control de copias mediante Rc, Arc, Cow
    • Swift usa por defecto tipos por valor y Copy-on-Write y, cuando es necesario, admite movimiento de ownership (move) y acceso a punteros unsafe
  • Ambos usan compiladores basados en LLVM, por lo que pueden compilarse a código nativo y WASM

Modelo de memoria: Rust de arriba hacia abajo, Swift de abajo hacia arriba

  • Rust parte como lenguaje de sistemas de bajo nivel y luego ofrece funciones de alto nivel
  • Swift parte como lenguaje de alto nivel y permite acceso de bajo nivel cuando es necesario
  • El modelo de memoria base de Swift son los tipos por valor con Copy-on-Write, similares a Cow<> de Rust
    • Rust es rápido por defecto, pero al usar Cow<> hay que manejarlo explícitamente
    • Swift es simple por defecto, y permite elegir mover en lugar de copiar

Enfoque sintáctico de Swift: ocultar conceptos de Rust con estilo C

  • La sentencia switch de Swift cumple prácticamente la misma función que la expresión match de Rust
    • Soporta pattern matching y no tiene fallthrough
  • El enum de Swift puede incluir métodos directamente, por lo que permite un uso más orientado a objetos que Rust
  • Los tipos opcionales (T?) son el mismo concepto que Option<T> en Rust, y nil corresponde a None
    • En Swift se pueden desempaquetar de forma segura con la sintaxis if let val
  • El manejo de errores es similar al tipo Result de Rust, y do-catch y try en Swift son la misma estructura envuelta en una sintaxis más familiar

Diferencias en el comportamiento del compilador

  • El compilador de Rust se centra en detectar problemas y advertirlos; por ejemplo, obliga a usar Box<> al definir enum recursivos
  • Swift maneja enums recursivos solo con la palabra clave indirect, y el compilador automatiza internamente la gestión de punteros
  • Swift automatiza más procesos que Rust, por lo que el desarrollador necesita lidiar menos directamente con la estructura de memoria

Utilidad práctica de Swift y extensibilidad del lenguaje

  • Swift fue diseñado para reemplazar Objective-C, por lo que es un lenguaje más grande y práctico
    • Incluye muchas funciones como clases/herencia, async-await, actors, propiedades lazy, property wrappers, Result Builders y más
  • Con un diseño de “divulgación progresiva (progressive disclosure)”, a medida que avanzas en el aprendizaje se van revelando más funciones

Equilibrio entre comodidad y rendimiento

  • Swift es un lenguaje fácil para empezar y productivo, mientras que Rust es un lenguaje rápido por defecto
    • En Rust “la rapidez es la base”; en Swift “la comodidad es la base”
  • Rust es adecuado para sistemas, embebidos, compiladores y motores de navegador
  • Swift es adecuado para UI, servidores y algunos componentes del sistema operativo, y las áreas de uso de ambos lenguajes se superponen cada vez más

Expansión multiplataforma de Swift

  • Swift ya no es un lenguaje exclusivo de Apple
    • Windows: The Browser Company lo usa para compartir código del navegador Arc
    • Linux: Apple apoya Swift on Server y patrocina conferencias
    • Embedded Swift: se usa en dispositivos pequeños como Panic Playdate
  • El blog oficial de Swift presenta proyectos para Windows, Embedded, Linux(Gnome) y Playdate
  • Swift también mejora la experiencia de desarrollo fuera de Xcode con una extensión para VSCode, open source del LSP y más

Limitaciones de Swift y su posición actual

  • El tiempo de compilación es lento, al igual que en Rust
  • El lenguaje creció por el feature creep, y parte de la sintaxis no resulta familiar
  • El ecosistema de paquetes es menos maduro que el de Rust
  • Aun así, Swift ya cuenta con estabilidad ABI, Automatic Reference Counting (ARC), funciones para elegir ownership y paquetes compatibles con Linux, como lenguaje multiplataforma
  • Swift se está posicionando como una alternativa más conveniente que Rust y existe como una opción actual, no como un futuro por esperar

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-02-01
Opiniones de Hacker News

  • En general estoy de acuerdo, pero en los detalles se ve el verdadero problema
    Xcode es un IDE tosco que se cuelga seguido en proyectos grandes al refrescar paquetes o manejar múltiples targets. Y aunque quisieras arreglarlo, no se puede parchear el binario
    El sistema de build es mucho más fácil de manejar con Cargo que con SPM. El sistema de macros todavía depende de generación de código externa
    Hay linters y formatters, pero su calidad es baja. Swift tiene muchos precipicios de rendimiento, y como la inferencia de tipos es bidireccional, se vuelve lenta en expresiones complejas. Esto pega especialmente en casos de uso importantes como SwiftUI
    Los imports están atados a nivel de módulo, así que aunque cambies un solo archivo hay que recompilar todo el módulo. La distinción entre clases y structs también se siente rara por compatibilidad con ObjC
    Al final, Swift podría ser un lenguaje más fácil que Rust, pero en la práctica no lo parece por la inmadurez de su tooling

    • Hice una app pequeña con SwiftUI y fue demasiado difícil encontrar una fuga de memoria. Incluso analizándola con Instruments y vmmap, se escapaban decenas de MB por día
      Siento que el modelo de memoria semiautomático de Swift es mucho más difícil de manejar que el de Rust o Go
    • Si no estás haciendo apps para iOS/macOS, se puede saltar Xcode por completo y usar solo el CLI de swift, y funciona bastante bien. También corre bien en Linux y Windows
    • Swift soporta LSP, así que también se puede desarrollar con VSCode, Zed, Sublime Text y otros. Si no haces desarrollo exclusivo para Apple, Xcode no es indispensable
    • En Swift viejo, alguna vez una o dos líneas de un literal de diccionario hicieron que el build tardara 30 minutos
    • La mayoría de los problemas de velocidad de compilación se pueden aliviar con separación por paquetes y tipos explícitos. SPM funciona mejor de lo que uno esperaría

  • Se dijo que en Rust hace falta Box para expresar una estructura de árbol con enum, pero en realidad no es necesario porque Vec ya da una referencia al heap

    • Como conozco bien Rust, el error en sí no me molesta, pero sí me preocupa si la explicación del lado de Swift también estará igual de equivocada
      En Rust, enum, struct, union e incluso tipos primitivos pueden tener métodos. Por ejemplo, se puede llamar algo como 'F'.to_digit(16)
      Incluso a un raw pointer se le pueden agregar métodos. Eso me parece parte del diseño moderno de Rust
    • Se pone como ejemplo el enum de Swift para decir que su azúcar sintáctica es buena, pero en la práctica el soporte de tipos unión es débil, así que muchos desarrolladores terminan abusando de optional en lugar de enum
    • Es fácil confundir la diferencia entre Vec y Box. Vec es un handle de tamaño fijo en compilación, mientras que Box hace falta para manejar tipos unsized
    • Lo probé en Rust 1.92 y funciona bien sin Box
    • Vec<T> en sí es un handle de tamaño fijo que apunta a datos en el heap, así que no hace falta Box

  • Swift es un lenguaje genial, pero del lado server-side convence poco
    El ecosistema es chico, y frente a Go o Rust no ofrece mucho para ganar. El soporte en VSCode también es flojo y no quiero usar Xcode
    El desarrollo de servidores ya está ocupado por Python, TypeScript, Go y Rust. El ecosistema cerrado de Apple también pesa

    • De hecho hice un backend en Swift integrado directamente con librerías de C. Funcionó bien incluso sin FFI y el rendimiento fue bueno
      Me parece que la calidad del IDE es mejor que en otros lenguajes, aunque para programación de sistemas Rust sigue siendo más adecuado
    • Probé Swift Vapor en un proyecto personal y me decepcionó que la velocidad de compilación y testing fuera más lenta que en Go

  • Se dice que Swift ya es un lenguaje multiplataforma, pero en Linux sigue siendo un ecosistema centrado en Apple
    La documentación, los tutoriales y las librerías están escritos pensando en macOS. Me pregunto si realmente hay gente usando Swift sin dispositivos Apple

    • La documentación de Apple no deja claras las limitaciones en Linux, así que hubo mucha prueba y error
      Resumí en un blog lo que pasé al hacer un cliente WebSocket
      Versión 2023 / Versión 2025
    • Los desarrolladores de Apple dicen que también va bien en Linux, pero en la práctica el ecosistema de Rust es muy superior
    • Quise portar una herramienta CLI para Mac a Linux, pero fue más rápido y más fácil convertir el código a Go con un LLM
      El soporte para Android también es interesante, pero siento que con Kotlin alcanza
    • Hay muchos ejemplos centrados en Apple, y eso causa problemas al hacer cross-compilation. Por ejemplo, NSHashTable no existe fuera de plataformas Apple
    • Swift permite manejar versiones del compilador con la herramienta swiftly, parecida a rustup, y el LSP funciona bien
      En lo personal mantengo librerías con soporte incluso para Windows. No es perfecto, pero va mejorando

  • El switch de Swift es básicamente una expresión match. Solo cambia la sintaxis, pero hace pattern matching

    • Desde la perspectiva de diseño de lenguaje, parece una estrategia para mantener la sintaxis tradicional de switch y reducir la confusión de los desarrolladores
      Introduce un significado nuevo con una sintaxis familiar para facilitar una transición gradual
      Este enfoque lleva a una discusión interesante sobre hasta qué punto un lenguaje debería perseguir un diseño fuertemente opinado

  • La clave de Rust es la zero-cost abstraction. Swift no sigue ese principio
    Muchas funciones de Rust fueron diseñadas para respetar esa regla, y el modelo de ownership es el ejemplo más representativo

    • El modelo explícito de ownership de Rust evita en build time errores de runtime que sí pueden aparecer con actor o Task en Swift
      Tiene una curva de aprendizaje, pero mejora la productividad de desarrollo
    • Swift también soporta un modelo de ownership, pero no lo impone tanto como Rust

  • Se dijo que Arc Browser usó Swift para Windows, pero después de la cancelación del desarrollo parece que ese trabajo relacionado también fue cancelado

  • Prefiero Rust porque no tiene dependencia de una gran corporación. Creo que Apple podría abandonar Swift

    • Pero es poco probable que Apple abandone Swift. Rust podría ser incluso más riesgoso por depender más de la comunidad
    • La mayor parte del software de Apple está escrita en Swift, así que no tienen motivo para dejarlo
    • Go también está atado a Google, y C# a Microsoft. Como Swift también es open source, me cuesta criticarlo con esa misma lógica
    • Swift fue creado por Apple, pero lo mantiene la comunidad open source
      Eso también está indicado en Wikipedia

  • Aprovechando las funciones de reference counting de Rust, se puede obtener comodidad sin pasarse a Swift
    Con Rc se logran referencias compartidas inmutables, y con interior mutability se pueden implementar cambios con chequeos en runtime
    Documentación de Rc, documentación de interior mutability

    • En entornos de un solo hilo se usa Rc, y en multihilo Arc. Gracias al trait Send, no pasa que uses Rc por error en el hilo equivocado
    • Pero tiene la desventaja de que el código se vuelve demasiado verboso

  • He creado herramientas de análisis y compiladores para Linux tanto en Swift como en Rust
    En Swift, ARC hace más cómoda la gestión de memoria; Rust exige pensar más, pero la calidad del tooling es muchísimo mejor
    Clippy y el soporte de LSP son excelentes, y Swift trae muchas cosas incluidas de base
    Aun así, como la comunidad de Rust es más grande, es más fácil encontrar gente, y también veo potencial en Swift como lenguaje sustituto de C++