Swift é um Rust mais conveniente (2023)

 (nmn.sh)
2 pontos por GN⁺ 2026-02-01 | 1 comentários | Compartilhar no WhatsApp
  • Rust e Swift compartilham um sistema de tipos robusto e características de linguagens funcionais, e podem ser compiladas para código nativo e WASM por meio de compiladores baseados em LLVM
  • Rust começou como uma linguagem de sistemas de baixo nível e passou a oferecer recursos de alto nível, enquanto Swift começou como uma linguagem de alto nível e permite acesso de baixo nível
  • Swift usa tipos por valor e Copy-on-Write por padrão e implementa conceitos semelhantes ao modelo de ownership do Rust com uma sintaxe mais simples
  • Em tipos opcionais, tratamento de erros e enums recursivos, Swift envolve conceitos do Rust em uma sintaxe familiar da família C, oferecendo mais conveniência aos desenvolvedores
  • Swift está evoluindo como linguagem multiplataforma e pode ser usado também em Windows, Linux e ambientes embarcados, surgindo como alternativa ao Rust

Semelhanças e diferenças entre Rust e Swift

  • As duas linguagens incluem características de linguagens funcionais (enum tagged, expressões match/switch, genéricos, funções de primeira classe)
    • Rust oferece contagem de referências e controle de cópia por meio de Rc, Arc e Cow
    • Swift usa por padrão tipos por valor e Copy-on-Write e, quando necessário, oferece suporte a movimentação de ownership (move) e acesso a ponteiros unsafe
  • As duas linguagens usam compiladores baseados em LLVM, podendo ser compiladas em código nativo e WASM

Modelo de memória: Rust de baixo para cima, Swift de cima para baixo

  • Rust começou como uma linguagem de sistemas de baixo nível e passou a oferecer recursos de alto nível
  • Swift começou como uma linguagem de alto nível e, quando necessário, permite acesso de baixo nível
  • O modelo de memória padrão do Swift é de tipos por valor com Copy-on-Write, semelhante a Cow<> do Rust
    • Rust é rápido por padrão, mas exige lidar explicitamente com Cow<> quando ele é usado
    • Swift é simples por padrão e pode optar por movimentar em vez de copiar

Abordagem sintática do Swift: escondendo conceitos do Rust em estilo C

  • A instrução switch do Swift cumpre, na prática, a mesma função da expressão match do Rust
    • Suporta pattern matching e não tem fallthrough
  • O enum do Swift pode incluir métodos diretamente, permitindo um uso mais orientado a objetos do que no Rust
  • O tipo opcional (T?) é o mesmo conceito de Option<T> no Rust, e nil corresponde a None
    • Em Swift, é possível fazer unwrapping com segurança usando a sintaxe if let val
  • O tratamento de erros é semelhante ao tipo Result do Rust, e do-catch e try no Swift são a mesma estrutura envolta em uma sintaxe mais familiar

Diferenças no funcionamento do compilador

  • O compilador do Rust prioriza detecção de problemas e avisos e, por exemplo, força o uso de Box<> ao definir enums recursivos
  • Swift lida com enums recursivos apenas com a palavra-chave indirect, e o compilador automatiza o gerenciamento interno de ponteiros
  • Swift faz mais tratamento automatizado do que Rust, então o desenvolvedor precisa lidar menos diretamente com a estrutura de memória

Praticidade do Swift e extensibilidade da linguagem

  • Swift foi projetada para substituir o Objective-C, sendo uma linguagem maior e mais prática
    • Já inclui vários recursos, como classes/herança, async-await, actors, propriedades lazy, property wrappers e Result Builders
  • O design de “progressive disclosure” faz com que mais recursos apareçam à medida que o aprendizado avança

Equilíbrio entre conveniência e desempenho

  • Swift é uma linguagem fácil de começar e produtiva, enquanto Rust é uma linguagem rápida por padrão
    • Em Rust, “rápido é o padrão”; em Swift, “conveniência é o padrão”
  • Rust é adequado para sistemas, embarcados, compiladores e motores de navegador
  • Swift é adequado para UI, servidores e alguns componentes de sistemas operacionais, e as áreas de uso das duas linguagens estão se sobrepondo gradualmente

Expansão multiplataforma do Swift

  • Swift já não é mais uma linguagem exclusiva da Apple
    • Windows: a The Browser Company a usa para compartilhamento de código no navegador Arc
    • Linux: a Apple oferece suporte a Swift on Server e patrocina conferências
    • Embedded Swift: usado em pequenos dispositivos como o Panic Playdate
  • O blog oficial do Swift apresenta projetos para Windows, Embedded, Linux (Gnome) e Playdate
  • Swift também está melhorando a experiência de desenvolvimento fora do Xcode com extensão para VSCode, open source do LSP e mais

Limites do Swift e sua posição atual

  • O tempo de compilação é lento, assim como no Rust
  • A linguagem cresceu com o feature creep, e parte da sintaxe não é familiar
  • O ecossistema de pacotes é menos maduro que o do Rust
  • Ainda assim, Swift já é uma linguagem multiplataforma com estabilidade de ABI, Automatic Reference Counting (ARC), recursos para escolha de ownership e pacotes compatíveis com Linux
  • Swift está se consolidando como uma alternativa mais conveniente ao Rust e existe como opção atual, não como um futuro distante

Leituras relacionadas

1 comentários

 
GN⁺ 2026-02-01
Comentários do Hacker News

  • Concordo em grande parte, mas é nos detalhes que aparece o cerne do problema
    O Xcode é uma IDE tosca em projetos grandes, travando com frequência ao atualizar pacotes ou lidar com múltiplos targets. Mesmo tentando corrigir, não dá para aplicar patch em binário
    O sistema de build é muito mais fácil de lidar no Cargo do que no SPM. O sistema de macros ainda depende de geração de código externa
    Há linter e formatter, mas a qualidade é baixa. O Swift tem muitos penhascos de performance, e a inferência de tipos é bidirecional, ficando lenta em expressões complexas. Isso é especialmente problemático em casos de uso importantes como SwiftUI
    Como os imports são agrupados no nível do módulo, mudar um único arquivo já exige recompilar o módulo inteiro. A distinção entre classes e structs também é estranha por causa da compatibilidade com ObjC
    No fim, o Swift até pode ser uma linguagem mais fácil que Rust, mas por causa da imaturidade do ecossistema de ferramentas na prática não parece ser

    • Fiz um app pequeno em SwiftUI e foi muito difícil encontrar um vazamento de memória. Mesmo analisando com Instruments e vmmap, vazavam dezenas de MB por dia
      O modelo de memória semiautomático do Swift parece muito mais difícil de lidar do que em Rust ou Go
    • Se não for um app para iOS/macOS, dá para pular totalmente o Xcode e usar só a CLI swift, que já é boa o suficiente. Também funciona bem em Linux e Windows
    • Como Swift suporta LSP, também dá para desenvolver em VSCode, Zed, Sublime Text etc. Se não for desenvolvimento exclusivo para Apple, Xcode não é obrigatório
    • Em versões antigas do Swift, já tive build levando 30 minutos por causa de uma ou duas linhas de literal de dicionário
    • A maior parte dos problemas de velocidade de compilação pode ser mitigada com separação por pacote e especificação explícita de tipos. O SPM funciona melhor do que parece

  • Disseram que em Rust é preciso Box para representar uma estrutura em árvore com enum, mas na prática isso é desnecessário porque Vec já fornece referência para o heap

    • Como conheço bem Rust, o erro em si não me incomoda, mas fico preocupado se a explicação sobre Swift também estaria errada de forma parecida
      Em Rust, enum, struct, union e até tipos primitivos podem ter métodos. Por exemplo, dá para fazer chamadas como 'F'.to_digit(16)
      Dá até para anexar métodos a raw pointers. Acho que isso mostra o design moderno do Rust
    • Usam o enum do Swift como exemplo de açúcar sintático elegante, mas na prática o suporte a union types é fraco, então muitos desenvolvedores abusam de optional em vez de enum
    • É fácil confundir a diferença entre Vec e Box. Vec é um handle de tamanho fixo em tempo de compilação, e Box é necessário para lidar com tipos unsized
    • Testei no Rust 1.92 e funcionou bem sem Box
    • O próprio Vec<T> já é um handle de tamanho fixo que aponta para dados no heap, então não precisa de Box

  • Swift é uma linguagem legal, mas no lado do servidor ela convence pouco
    O ecossistema é pequeno e, comparado a Go ou Rust, não oferece muito ganho. O suporte no VSCode também é fraco e eu não quero usar Xcode
    O desenvolvimento de servidor já está ocupado por Python, TypeScript, Go e Rust. O ecossistema fechado da Apple também pesa

    • Já tive experiência criando um backend em Swift com integração direta com bibliotecas C. Funcionou bem sem FFI e o desempenho também foi bom
      A qualidade da IDE é melhor do que em outras linguagens, e acho que Rust é mais adequado para programação de sistemas
    • Fiz um projeto pessoal com Swift Vapor e senti falta de velocidade de compilação e testes em comparação com Go

  • Dizem que Swift agora é uma linguagem multiplataforma, mas no Linux ele ainda continua com um ecossistema centrado na Apple
    Documentação, tutoriais e bibliotecas são todos escritos tendo macOS como base. Fico me perguntando se alguém realmente usa Swift sem dispositivo Apple

    • A documentação da Apple não deixa claras as limitações no Linux, então passei por muita tentativa e erro
      Organizei em um blog o processo que vivi ao criar um cliente WebSocket
      Versão de 2023 / Versão de 2025
    • Desenvolvedores da Apple dizem que também é bom no Linux, mas na prática o ecossistema do Rust é muito superior
    • Tentei portar uma ferramenta CLI de Mac para Linux, mas foi mais rápido e fácil usar LLM para converter o código para Go
      O suporte a Android também é interessante, mas sinto que Kotlin já basta
    • Há muitos exemplos centrados na Apple, então surgem problemas ao fazer cross-compilation. Por exemplo, NSHashTable não existe fora das plataformas Apple
    • O Swift permite gerenciar versões do compilador com a ferramenta swiftly, parecida com o rustup, e o LSP também funciona bem
      Pessoalmente, mantenho bibliotecas com suporte até para Windows. Não é perfeito, mas está melhorando aos poucos

  • O switch do Swift é na prática uma expressão match. Só muda a sintaxe; ele faz pattern matching

    • Do ponto de vista de quem projeta linguagens, isso parece uma estratégia para manter a sintaxe tradicional de switch e reduzir a confusão dos desenvolvedores
      Introduzir um novo significado com sintaxe familiar induz uma transição gradual
      Essa abordagem leva a uma discussão interessante sobre até que ponto uma linguagem deve buscar um design opinativo

  • O núcleo do Rust é zero-cost abstraction. O Swift não segue esse princípio
    Muitos recursos do Rust foram projetados para obedecer a essa regra, e o modelo de ownership é um exemplo representativo

    • O modelo explícito de ownership do Rust evita em tempo de compilação erros de runtime que podem ocorrer com actor ou Task no Swift
      Há uma curva de aprendizado, mas isso melhora a eficiência no desenvolvimento
    • Swift também oferece um modelo de ownership, mas ele não é tão obrigatório quanto no Rust

  • Disseram que o navegador Arc usou Swift no Windows, mas depois da interrupção do desenvolvimento parece que esse trabalho relacionado também foi cancelado

  • O motivo de eu preferir Rust é que ele não tem dependência de big tech. Acho que a Apple pode abandonar o Swift

    • Mas a chance de a Apple abandonar o Swift é baixa. O Rust talvez seja até mais arriscado por depender mais da comunidade
    • A maior parte do software da Apple é escrita em Swift, então não há motivo para desistir dele
    • Go também está ligado ao Google, e C# à Microsoft. Como Swift também é open source, acho difícil criticá-lo com essa mesma lógica
    • Swift foi criado pela Apple, mas é mantido pela comunidade open source
      Isso também está indicado no artigo da Wikipédia

  • Aproveitando os recursos de reference counting do Rust, dá para obter praticidade sem migrar para Swift
    Com Rc, dá para ter referências compartilhadas imutáveis, e com interior mutability dá para implementar alterações baseadas em checagem em runtime
    Documentação de Rc, documentação de interior mutability

    • Em ambiente single-thread, usa-se Rc; em multithread, Arc. Graças ao trait Send, não acontece de usar Rc na thread errada
    • Mas a desvantagem é que o código fica verboso demais

  • Já criei ferramentas de análise e compiladores para Linux em Swift e Rust
    No Swift, o ARC facilita a gestão de memória; no Rust, é preciso pensar mais, mas a qualidade das ferramentas é muito melhor
    O suporte de Clippy e LSP é excelente, e o Swift traz muitos recursos nativos
    Ainda assim, como a comunidade Rust é maior, é mais fácil encontrar gente, e acho que Swift também tem potencial como linguagem substituta de C++