Melhor resposta
Definitivamente “Não” para o Swift 1, 2, 3. Mas talvez sim para o Swift 4 . De qualquer forma, ainda não estou muito otimista.
Presumo que o mercado-alvo do Rust sejam os programadores C / C ++.
O principal recurso do Rust é extrema segurança sem sobrecarga . Até agora, o Swift falha aqui. O Swift sempre envolve uma espécie de sobrecarga tanto no espaço quanto no tempo quando você usa ref-types. Isso é obrigatório e inevitável.
A sobrecarga é importante porque apenas “segurança” já está sendo fornecida por muitos idiomas. Por exemplo, C #. Qual é o verdadeiro concorrente real do Swift na minha opinião. C # já está fornecendo certo nível de segurança. E já foi substituído com sucesso C / C ++ em alguns segmentos do mercado, mas não completamente porque introduz um monte de sobrecarga. Tanto no espaço quanto no tempo. Embora o compilador Swift possa eliminar parte da sobrecarga RC, isso depende da sorte na otimização. Em algumas situações de azar, a sobrecarga torna-se enorme.
E o nível de segurança também é diferente. É o mesmo que ambas as línguas podem garantir nenhum ponteiro pendurado em contexto seguro. Mas isso é tudo o que o Swift pode fornecer, e esta é uma garantia muito fraca quando comparada ao que o Rust fornece. No nível do recurso, os tipos de referência do Swift podem vazar a qualquer momento e sempre precisam de cuidados humanos. O compilador não pode detectar referências cíclicas. O Swift também permite o compartilhamento ilimitado de memória mutável entre threads (devido à falta de simultaneidade nativa do idioma), o que significa que não há segurança na disputa de dados.
Em contraste, a propriedade exclusiva do Rust fornece garantia totalmente estática de nenhum vazamento de recursos. Nenhuma corrida de dados também é garantida estaticamente.
O que eu senti ao usar o Swift nos últimos anos é que a linguagem não é realmente segura quando se trata de gerenciamento de recursos e corrida de dados. E a sobrecarga de RC obrigatória é realmente uma grande preocupação em código de desempenho crítico. O Swift anuncia o desempenho dos tipos de valor, mas, na verdade, você sempre precisa usar alguns ref-types para alocar no heap com segurança. Swift anuncia a elisão RC inteligente do compilador, mas é baseada na sorte, portanto, custo zero garantido incomparável do Rust.
Por que a segurança é importante? Porque você não pode ser produtivo em um campo minado. Para ser produtivo, você precisa reduzir o que importa. No Swift, você sempre tem que se preocupar com os ciclos, a corrida de dados e a sobrecarga para não morrer porque ninguém se importa com eles. No Rust, o compilador pode cuidar disso para você. Você simplesmente esquece (muitos de) segurança e segue o compilador tudo o que ele reclama, então você está seguro. Assim como os usuários da linguagem GC não se importam com ponteiros pendentes.
Além disso, o determinismo importa. O rastreamento da vida útil do objeto raramente é necessário, mas às vezes é muito importante. O Swift RC fornece tempo `deinit`, mas como é propriedade compartilhada, o tempo de morte geralmente é muito vago. Esse tempo na propriedade exclusiva é relativamente mais claro do que RC.
A propriedade exclusiva também ajuda na manutenção, anotando o proprietário responsável. Na minha opinião, gerenciar um proprietário único é muito mais fácil do que gerenciar vários proprietários. Na verdade, o que eu sempre faço no Swift é apenas especificar o proprietário exclusivo implícito e rastreá-los manualmente por alguma convenção. Não seria bom se o compilador fizesse isso para você?
O Swift 4 está planejando apresentar vários novos recursos, como propriedade exclusiva, semântica de movimentação, modelo de ator e suporte interoperacional C ++. Mas não tenho certeza de como eles podem garantir o nível de segurança do Rust com os recursos da semântica da linguagem atual. Portanto, ainda não estou muito certo sobre o nível de segurança do Swift. A interoperabilidade C ++ pode ser um grande ponto de vendas. De qualquer forma, essa é quase a única razão pela qual eu acho que o Swift 4 pode ser um concorrente potencial do Rust para o mercado C / C ++.
O Swift também tem vantagens. Como convenção de nomenclatura mais sã (na minha opinião) e sintaxe clara (na minha opinião), IDE dedicado, desenvolvimento garantido e sustentabilidade pelo apoiador mais rico do mundo (mas isso também introduz a questão política da plataforma suportada). No geral, ele tem uma IU / UX melhor, mas ainda me sinto mais atraído pela segurança e beleza conceitual de Rust …
P.S. Na verdade, era possível fazer um ponteiro pendurado na versão inicial do Swift 2.x apenas com uma construção segura como `deinit` e fraco-ref. Mas não tenho certeza agora e no futuro.
P.S. 2. Parece que eles consertaram a brecha. No Swift 3, você obterá uma exceção de tempo de execução se tentar fazer uma referência fraca em `deinit`.
Resposta
Eu li recentemente sobre swift-3.x, mas eu sou fanboy do Rust há bastante tempo e * realmente * quero que o Rust tenha sucesso como linguagem de sistemas.
A resposta à sua pergunta será um sim condicional, por quê? Isso ocorre porque o swift sobrepõe um espaço significativo com ferrugem em termos de programação de aplicativo nativo.Há um grande contraste entre as linguagens em termos de filosofia de design e casos de uso em programação de sistemas (e alguns casos de uso em tempo real)
Rust é projetado nas filosofias C ++ para a maioria das partes, o que torna possível fazer computação de alto desempenho e compiladores insanamente otimizáveis (um nicho contra o qual não vi muitas linguagens modernas competirem)
- “Abstrações de custo zero”
- Este é especialmente significativo enquanto você está escrevendo kernels ou utilitários básicos porque eles precisam ser otimizados ao máximo possível para obter o último pedaço de desempenho.
- No swift, você pode talvez fazer a maioria das otimizações, mas não todas, é uma barreira de idioma para a quantidade de otimização que pode ser alcançada (por exemplo, suponho que poderíamos assumir com segurança que a maior parte da contagem de referência é atômica rapidamente, mas na ferrugem você pode escolher entre os tipos Rc e Arc, então não pague por o que você não usa).
- “O modelo de ponteiro Rust”
- Programa Rust Os s são projetados para eliminar a maioria das fontes de travamentos de seu código por meio de propriedade, empréstimo e semântica de movimentação, portanto, ele verifica estaticamente se qualquer recurso tem apenas um proprietário único em um determinado momento. Isso também torna as coisas mais fáceis para dois dos casos de uso abaixo.
- Como isolar partes do programa que podem falhar (não seguras)
- Como ter simultaneidade segura ao escrever código
- Swift é muito mais semelhante a C ++ neste aspecto, pois apenas expõe os ponteiros fortes (shared\_ptr), fracos (weak\_ptr) e não proprietários (intrusive\_ptr) para o programador e dá a eles o controle para (ab) usá-los em seu código, então definitivamente melhor controle do que Java, mas certamente menos segurança
- “Enumerações”
- Rust tem enums ricos que são semelhantes aos ADTs em Haskell (embora não tão poderosos), mas mesmo assim habilite um belo design de Finite State Machines (FSM) se você pensar em C, que tem um suporte muito pobre para escrever FSM.
- Swift também tem belas enumerações semelhantes a Java que eu acho que é muito mais poderoso, pois podemos definir comportamento para enums.
- “Fechamentos” – Este é o único recurso que distingue qualquer linguagem moderna das arcaicas. Ambos Rust e Swift suportam fechamentos, mas o modelo de ferrugem permite que você raciocine sobre a propriedade das variáveis “fechadas” e, assim, garante a segurança. Por outro lado, fechamentos de Swift podem trazer algumas surpresas até mesmo para programadores experientes.
- Os problemas com Rust
- Estruturas de dados muito simples, como listas duplamente vinculadas, não podem existir em ferrugem, só porque da semântica de propriedade (somos forçados a usar Rc / Arc para esta estrutura de dados simples) isso irrita algumas pessoas.
- De acordo com a experiência de programação, quando há um recurso em uma linguagem popular, as pessoas tendem a abusar deles, em Rust os blocos inseguros são definitivamente propensos a abusos para as pessoas que não estão dispostas a lutar contra o verificador de empréstimo, o que infelizmente constitui uma grande porcentagem
- Violações de imutabilidade na biblioteca padrão, se não código trivial precisa ser escrito em Rust, precisamos ter tipos de dados como Cell / RefCell que possam ser tecnicamente usados como backdoors contra a forte segurança que a linguagem parece fornecer. Dito isso, a biblioteca fornece uma grande quantidade de primitivos de segurança ao usar esses tipos de dados, então não atiramos no próprio pé.
- Finalmente Rust parece admitir que, embora seja mais seguro do que C ++, alguns dos os odiados recursos do C ++ também precisam ser incorporados para que possamos permitir a adoção e permitir que as pessoas escrevam códigos não triviais. Isso é triste, mas, infelizmente, a verdade também.
- Os problemas com o Swift
- O uso generalizado do ARC em todos os lugares – que é uma violação de “você não paga pelo que não faz use ”filosofia em C ++ (pode ser abordada no swift 5.x (consulte [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model) )
- Falta de primitivas assíncronas muito fáceis de usar live async / await / corroutines (que é o ponto de venda para linguagens como go), pode ser o swift 5.x resolver isso
- Às vezes “classe ”Declarações podem forçá-lo desnecessariamente a usar tipos de referência onde você pode realmente preferir um tipo de valor (estrutura)
- Traits in Rust é tecnicamente (na maioria dos casos) uma solução melhor para 3 entidades rápidas diferentes (extensões, protocolos e herança)
Então eu acho que definitivamente há um nicho para o swift ocupar, pessoas que são bons programadores de C ++ podem chegar ao Swift / Rust rapidamente. Mas eu acho que o Swift terá mais tração com desenvolvedores de aplicativos e programadores Rust with System. Seus respectivos nichos continuarão a existir, apesar da sobreposição significativa.