Adoção do Swift interrompida – encerrado o issue sobre suporte ao Swift 6.0 no navegador Ladybird

 (github.com/LadybirdBrowser)
1 pontos por GN⁺ 2026-02-20 | 1 comentários | Compartilhar no WhatsApp
  • O projeto do navegador Ladybird organizou uma lista de problemas surgidos no processo de promover o suporte ao Swift 6.0 do estágio experimental para oficial, mas depois decidiu não seguir adiante com a adoção do Swift
  • Os principais obstáculos foram fatores ligados à interoperabilidade (Interop) entre Swift e C++, como incompatibilidades de ABI, dependências circulares em headers e impossibilidade de retornar certos tipos; vários itens foram corrigidos após o Swift 6.0.0
  • No sistema de build CMake também foram reportados problemas como incompatibilidade do deployment target no ambiente Swift + Ninja, erros no tratamento de install_name e opções de compilação incompatíveis
  • No próprio código do Ladybird, também foram confirmadas diversas instabilidades de build, como configuração de modulemap nos módulos AK e LibGfx, crashes do frontend do Swift e conflitos de namespace de tipos
  • Devido a essas limitações técnicas acumuladas, a integração com Swift foi interrompida, levando à decisão de manter o desenvolvimento centrado em C++

Problemas relacionados ao Swift

  • Havia vários bugs em nível de linguagem e ABI que precisavam ser resolvidos para tirar o suporte ao Swift 6.0 da fase experimental
    • Falha de assertion ao compilar o Swift open source por causa de incompatibilidade de versões do LLVM
    • Problema de incompatibilidade de ABI entre o compilador e o bridging header ao retornar Optional<CxxValueType>
    • Em ambientes Ubuntu 22.04, ocorrência de dependência circular de módulos do libstdc++ ao incluir o header <execution>
    • Inclusão de problemas de compatibilidade com C++23, como impossibilidade de retornar swift::Optional<swift::String> e falha ao carregar o header <chrono>
  • Parte dos problemas foi corrigida em releases posteriores ao Swift 6.0.0, mas alguns foram resolvidos apenas na branch main, sem refletir em versões estáveis
  • Em vários itens foram apresentadas “workarounds (formas alternativas de build)”, mas elas não representam uma solução completa

Problemas relacionados ao CMake

  • Na combinação de build com Swift e Ninja, o CMAKE_OSX_DEPLOYMENT_TARGET não era aplicado, gerando vários avisos
    • Era necessário definir manualmente CMAKE_Swift_COMPILER_TARGET
  • Ao ativar a política CMP0157, a configuração do diretório install_name era ignorada, exigindo correção manual
    • A correção relacionada deve ser portada para CMake 3.29 e 3.30
  • Havia também o problema de opções de link que o compilador Swift não entende serem repassadas por dependências externas

Problemas internos do projeto Ladybird

  • Ao configurar o clang module map dos módulos AK e LibGfx, ocorreram conflitos com headers do sistema
    • Ao incluir <math.h>, o build falhava por erro de reconhecimento de módulo
  • O frontend do Swift travava em builds de debug durante testes de contêineres AK
    • Só era possível contornar isso com build em modo release
  • Houve encerramento anormal do frontend do Swift por conflito de namespace do tipo String
    • Era necessário especificar explicitamente AK.String ou Swift.String
  • Ao usar o módulo Swift Testing, existiam crashes do frontend do compilador e o problema de não reconhecimento de CxxSequenceType em AK::StringView

Itens adicionais de melhoria

  • Quando uma função C++ retornava Optional<CxxType> no Swift, ocorria crash da aplicação
    • Como solução temporária, era usado o retorno de arrays com tamanho 0 ou 1
  • O SourceKit-LSP e o vscode-swift exigiam compile_commands.json no nível raiz
    • Isso podia ser resolvido com a criação de um link simbólico
  • Em ambiente Linux, havia o inconveniente de precisar adicionar manualmente o caminho <swift/bridging>

Questões não resolvidas

  • Não estava claro como passar para o Swift, sem cópia, tipos view de C++ ou byte slices
  • O Swift não reconhecia tipos próprios como AK::Optional e AK::HashMap como equivalentes aos tipos de std::
  • A forma de integrar o garbage collector do Swift com o gerenciamento de memória do Ladybird também permanecia indefinida

Este issue era um documento que registrava de forma sistemática os obstáculos técnicos para a integração do Swift 6.0, mas depois, com a interrupção da adoção do Swift pela equipe do Ladybird, o issue “Swift 6.0 Blockers” foi encerrado.

Leituras relacionadas

1 comentários

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

  • O commit que remove o Swift tem uma explicação adicional
    Inclui a mensagem: “Como não houve progresso por muito tempo, abandonamos a adoção de Swift e o removemos da base de código”
    O commit relacionado pode ser visto aqui

  • Usei Swift pela primeira vez em 2021 e fiquei surpreso, vindo de mais de 10 anos com C#/.NET
    Eu já achava C# complexo, mas Swift era uma linguagem muito mais complexa
    Principalmente ao criar APIs de backend ou camadas de acesso a dados, quase não havia material de referência
    Como o conhecimento sobre Swift está quase todo acumulado para plataformas Apple, fora disso a sensação era de ter que ser praticamente um desbravador

    • Nos últimos anos, linguagens simples como Python e Go reforçaram a ideia de que “complexidade é ruim”, mas eu acho que uma linguagem com mais expressividade pode ajudar na manutenção
      Como Larry Wall disse, a complexidade da ferramenta deve corresponder à complexidade do problema (menção a Raku)
    • Eu migrei de Objective-C para Swift por volta de 2018, e no começo pareceu uma melhora
      Mas regras como “struct passa por valor, class passa por referência” entravam em conflito com o princípio de “manter uma única fonte da verdade”, e isso fez o desenvolvimento ficar entediante e lento
      Por causa das best practices contraditórias do Swift, eu não progredia, e no fim percebi que muitos conselhos simplesmente não eram confiáveis
    • Também tive um problema em que o notebook superaquece toda vez que compilo templates do Vapor em um MacBook M1
    • Comigo foi parecido. Achei que aprenderia rápido, como Rust, mas não foi nada disso
      Havia açúcar sintático demais, e dezenas de formas de fazer a mesma coisa, então eu precisava consultar a referência da linguagem o tempo todo
    • Então fico curioso se no fim você voltou para C#/.NET

  • Independentemente da linguagem, espero que o Ladybird depois foque em uma implementação de JavaScript amigável ao usuário
    É um problema o JS ser usado para rastrear atividade do usuário, bloquear colagem ou coletar informação demais do dispositivo
    Reportar valores de spoofing padronizados entre usuários, como o Tor faz, parece que ajudaria na proteção de privacidade

    • Mas esse tipo de abordagem pode ser interpretado como detecção de bot em muitos sites, e o acesso pode acabar bloqueado
      Como opção com toggle tudo bem, mas como padrão acho difícil de adotar
    • Pessoalmente, eu jamais gostaria de usar um navegador que ignore padrões web e funcione por conta própria

  • A remoção de Swift é interessante. O motivo não foi explicado claramente, então fiquei curioso
    Se rodar no Linux, pretendo testar depois

    • Pelo que vejo, parece que desistiram por causa de conflitos de build recorrentes
      Havia problemas como o Swift não conseguir importar várias bibliotecas C++ de versões diferentes ao mesmo tempo, ou conflitos entre versões de operadores
      Swift é uma boa linguagem, mas deve ter sido complexo demais para adicionar depois a um projeto grande que já existia

  • Fico curioso sobre por que o Ladybird tentou Swift. Eu acharia que Rust teria uma interop com C++ melhor
    O GC do Swift também parece ruim para desempenho de navegador

    • Andreas Kling mencionou no Twitter que, entre “Swift vs Rust”, Swift era melhor em suporte a orientação a objetos e integração com C++
      link1, link2
    • É parecido com por que Rust é inconveniente em desenvolvimento de jogos. O borrow checker não combina bem com estruturas de referência cíclica
      Existem formas de contornar, mas a produtividade cai
    • Swift de fato tem uma interoperabilidade bem boa, como está na documentação de interop com C++
      Só que, ao que tudo indica, não foi suficiente para o Ladybird
    • Andreas Kling disse que Rust é desfavorável para desenvolvimento de GUI porque faltam recursos orientados a objetos
      Antes, eles até criaram uma linguagem chamada Jakt no SerenityOS, mas no fim parece que voltaram para C++
    • Lembro que Rust já tinha sido rejeitado por causa da hierarquia do DOM ou de questões de OOP
      A discussão anterior relacionada está neste post

  • Não é surpreendente, porque Swift é uma linguagem dependente demais da Apple
    Se você usar só a parte segura do C++ já é suficiente, e de fato a maioria dos navegadores é escrita em C++

    • Mas isso também significa apenas que todos os navegadores estão presos ao C++
      Chromium e Firefox estão substituindo partes gradualmente por linguagens mais seguras, e reescrever um navegador novo em C++ seria repetir erros do passado
      O uso de C++ é uma herança da era do KHTML em 1998
    • Não sei exatamente o que seria um “subconjunto moderno de C++ com segurança de memória”
      Inclui recursos modernos da STL como string_view? Ainda assim, continua longe de segurança de memória completa
    • Eu sei que Rust foi desenvolvido na Mozilla, mas fico curioso se a própria Mozilla é escrita em Rust
    • De qualquer forma, Swift dificilmente vence C++ em áreas que exigem alto desempenho
      Tirando alguns benchmarks, em programas reais ele quase sempre é mais lento

  • Uma pena ver o Swift ser removido. Então será que a linguagem própria Jakt volta a ser candidata?

    • O Ladybird já se separou do SerenityOS, e Jakt não é a linguagem deles
      Acho improvável que adotem uma nova linguagem
    • Pessoalmente, me preocupa que o projeto mude de direção com muita frequência
      Para um projeto mantido com patrocínio externo, isso dificulta a sustentabilidade no longo prazo
    • É frustrante não usarem Rust. Às vezes parece até uma obsessão por C++

  • No fim, acho que Swift não passa de uma linguagem-brinquedo da Apple
    A Apple não vai deixar ela crescer além disso

  • A UI do Ladybird no Mac é uma camada fina em cima do AppKit
    Ela é escrita em Objective-C++, não em Swift
    Veja o código-fonte

    • Eu fui a primeira pessoa a escrever aquele código
      Fiz isso muito antes da adoção de Swift, ainda na época do SerenityOS, então usei Objective-C++ simplesmente porque era a linguagem com a qual eu estava familiarizado

  • Quando anunciaram a migração para Swift no passado, eu critiquei
    Eu via o Swift como mal projetado, com compilação lenta e pouca chance de amadurecer como linguagem de sistemas
    Como também não havia especialistas, acho que essa decisão agora foi acertada

    • Swift parece open source, mas na prática a Apple segura todo o poder de decisão
      Recursos como Concurrency e Swift Testing também foram empurrados conforme as necessidades da Apple
      O trabalho multiplataforma em grande parte está sendo tocado separadamente por equipes pequenas
    • Eu reconheço os problemas do Swift, mas dizer que “não havia especialistas” é exagero
      Mesmo excluindo Chris Lattner, os líderes de Swift eram figuras reconhecidas na comunidade C++
    • O ponto principal do Swift, mais do que a linguagem em si, é a ABI padrão
      Seria bom se o ecossistema Rust passasse a oferecer suporte à ABI do Swift em FFI junto com C
    • Então fico curioso sobre qual linguagem você recomendaria
    • Go é parecido? Queria saber qual é hoje a opção de maior consenso