Meilleure réponse
Certainement «non» pour Swift 1, 2, 3. Mais peut-être que oui pour Swift 4 . Quoi quil en soit, je ne suis toujours pas très positif.
Je suppose que le marché cible de Rust est celui des programmeurs C / C ++.
La caractéristique clé de Rust est sécurité extrême sans frais généraux . Jusquà présent, Swift échoue ici. Swift implique toujours une sorte de surcharge à la fois dans lespace et dans le temps lorsque vous utilisez des ref-types. Ceci est obligatoire et inévitable.
La surcharge est importante car seule la «sécurité» est déjà fournie par de nombreuses langues. Par exemple, C #. Ce qui est à mon avis le véritable concurrent de Swift. C # offre déjà un certain niveau de sécurité. Et il a déjà été remplacé avec succès C / C ++ dans certains segments du marché, mais pas complètement car il introduit beaucoup de frais généraux. Dans lespace et dans le temps. Bien que le compilateur Swift puisse éviter une partie des frais généraux de RC, cela dépend de la chance sur loptimisation. Dans certaines situations malchanceuses, les frais généraux deviennent énormes.
Et le niveau de sécurité est également différent. C’est la même chose que les deux langues peuvent garantir l’absence de pointeur suspendu dans un contexte sûr. Mais cest tout ce que Swift peut fournir, et cest une garantie très faible par rapport à ce que Rust fournit. Au niveau des ressources, les ref-types Swift peuvent fuir à tout moment et ont toujours besoin de soins humains. Le compilateur ne peut pas détecter les références cycliques. Swift permet également le partage illimité de la mémoire mutable entre les threads (en raison du manque de simultanéité native du langage), ce qui signifie aucune sécurité sur la course aux données.
En revanche, la propriété unique de Rust fournit une garantie entièrement statique de labsence de fuite de ressources. Aucune course aux données nest également garantie statiquement.
Ce que jai ressenti en utilisant Swift ces dernières années, cest que le langage nest pas vraiment sûr en ce qui concerne la gestion des ressources et la course aux données. Et la surcharge RC obligatoire est vraiment une grande préoccupation dans le code critique de performance. Swift annonce les performances des types valeur, mais en fait, vous devez toujours utiliser certains types ref pour allouer en toute sécurité. Swift fait la promotion de lélision RC intelligente du compilateur, mais elle est basée sur la chance, donc un coût nul garanti incomparable de Rust.
Pourquoi la sécurité est-elle importante? Parce que vous ne pouvez pas être productif dans un champ de mines. Pour être productif, vous devez réduire ce dont vous avez besoin. Dans Swift, vous devez toujours vous soucier des cycles et des courses de données et des frais généraux pour ne pas être tué parce que personne ne se soucie deux pour vous. Dans Rust, le compilateur peut et soccupe de cela pour vous. Vous oubliez juste (beaucoup de) la sécurité, et suivez le compilateur tout ce quil se plaint, alors vous êtes en sécurité. Tout comme les utilisateurs du langage GC ne se soucient pas des pointeurs suspendus.
De plus, le déterminisme est important. Le suivi de la durée de vie des objets est rarement nécessaire, mais parfois très important. Swift RC fournit un timing «deinit», mais comme il sagit dune propriété partagée, le moment du décès est généralement très vague. Un tel timing dans la propriété unique est relativement bien plus clair que RC.
La propriété unique facilite également la maintenance en annotant le propriétaire responsable. À mon avis, gérer un propriétaire unique est beaucoup plus facile que gérer plusieurs propriétaires. En fait, ce que je fais toujours dans Swift, cest simplement spécifier le propriétaire unique implicite et le suivre manuellement par une convention. Ne serait-il pas bien que le compilateur fasse cela pour vous?
Swift 4 prévoit dintroduire plusieurs nouvelles fonctionnalités telles que la propriété unique, la sémantique de déplacement, le modèle dacteur et le support dinteropérabilité C ++. Mais je ne sais pas comment ils peuvent garantir le niveau de sécurité de Rust avec les fonctionnalités de la sémantique actuelle du langage. Je ne suis donc toujours pas très optimiste quant au niveau de sécurité de Swift. Linteropérabilité C ++ pourrait être un gros point de vente. Quoi quil en soit, cest presque la seule raison pour laquelle je pense que Swift 4 peut être un concurrent potentiel de Rust pour le marché C / C ++.
Swift a aussi des pros. Comme une convention de dénomination plus saine (à mon avis) et une syntaxe claire (à mon avis), un IDE dédié, un développement et une durabilité garantis par le soutien le plus riche du monde (mais cela introduit également le problème politique de la plate-forme prise en charge). Dans lensemble, il a une meilleure interface utilisateur / UX, mais je suis toujours plus attiré par la sécurité et la beauté conceptuelle de Rust …
P.S. En fait, il était possible de créer un pointeur suspendu dans la première version de Swift 2.x avec seulement une construction sûre telle que `deinit` et low-ref. Mais je ne suis pas sûr pour le moment et le futur.
P.S. 2. Il semble quils ont corrigé léchappatoire. Dans Swift 3, vous obtiendrez une exception dexécution si vous essayez de faire une référence faible dans `deinit`.
Réponse
Javais récemment lu sur swift-3.x mais je ai été fanboy de Rust pendant un bon bout de temps, et je * vraiment * veux que Rust réussisse en tant que langage système.
La réponse à votre question sera un oui conditionnel, pourquoi? En effet, Swift recouvre un espace significatif avec de la rouille en termes de programmation dapplication native.Il y a un contraste frappant entre les langages en termes de philosophie de conception et de cas dutilisation dans la programmation de systèmes (et certains cas dutilisation en temps réel)
Rust est conçu sur les philosophies C ++ pour la plupart des parties, ce qui rend possible de faire du calcul très haute performance et des compilateurs incroyablement optimisables (un créneau contre lequel je nai pas vu beaucoup de langages modernes rivaliser)
- «Abstractions à coût nul»
- Cest particulièrement important lorsque vous écrivez des noyaux ou des utilitaires de base, car ils doivent être optimisés au maximum possible pour obtenir le dernier bit de performance.
- En Swift, vous pouvez peut-être faire la plupart des optimisations mais pas toutes, là est une barrière linguistique à la quantité doptimisation qui peut être réalisée (par exemple, je suppose que nous pourrions supposer en toute sécurité que la plupart des comptages de références sont atomiques rapidement, mais dans la rouille, vous pouvez choisir entre les types Rc et Arc, alors ne payez pas pour ce que vous nutilisez pas).
- «Le modèle de pointeur Rust»
- Programme Rust s sont conçus pour éliminer la plupart des sources de plantages de votre code via la sémantique de propriété, demprunt et de déplacement, par conséquent, il vérifie statiquement que toute ressource na quun seul propriétaire à un moment donné. Cela facilite également les choses pour deux des cas dutilisation ci-dessous.
- Comment isoler les parties du programme susceptibles de planter (non sécurisées)
- Comment avoir une concurrence daccès sécurisée lors de lécriture de code
- Swift est beaucoup plus similaire à C ++ à cet égard car il expose simplement les pointeurs forts (shared\_ptr), faibles (low\_ptr) et sans propriétaire (intrusive\_ptr) au programmeur et leur donne le contrôle pour (ab) les utiliser dans leur code, donc certainement un meilleur contrôle que Java mais certainement moins de sécurité
- «Enumérations»
- Rust a des énumérations riches qui sont similaires aux ADT dans Haskell (bien que pas si puissantes), mais néanmoins activer une belle conception de machines à états finis (FSM) si vous pensez à C qui a un support très médiocre pour lécriture de FSM.
- Swift a également de belles énumérations semblables à Java qui, je pense, est beaucoup plus puissante puisque nous pouvons définir comportement pour les énumérations.
- «Closures» – Cest la caractéristique unique qui distingue tout langage moderne des langues archaïques. Rust et Swift supportent les fermetures, mais le modèle rust vous permet de raisonner sur la propriété des variables «fermées» et garantit ainsi la sécurité. Dautre part, les fermetures Swift peuvent créer quelques surprises même pour les programmeurs expérimentés.
- Les problèmes avec Rust
- Les structures de données très simples comme les listes à double liaison ne peuvent pas exister dans rust, simplement parce que de la sémantique de propriété (nous sommes obligés dutiliser Rc / Arc pour cette structure de données simple) cela irrite certaines personnes.
- Selon lexpérience de programmation quand il y a une fonctionnalité dans un langage populaire, les gens auront tendance à les abuser, dans Rust, les blocs non sécurisés sont définitivement sujets aux abus pour les personnes qui ne sont pas disposées à lutter contre le vérificateur demprunt, ce qui constitue malheureusement un pourcentage important
- Violations dimmuabilité dans la bibliothèque standard, si non- du code trivial doit être écrit en Rust, nous devons avoir des types de données comme Cell / RefCell qui pourraient techniquement être utilisés comme des portes dérobées contre la forte sécurité que le langage semble offrir. Cela dit, la bibliothèque fournit de nombreuses primitives de sécurité lors de lutilisation de ces types de données afin que nous ne nous tirions pas une balle dans le pied.
- Enfin, Rust semble admettre que, tout en étant plus sûr que C ++, certains des les fonctionnalités C ++ détestées doivent également être incorporées afin que nous puissions permettre ladoption et permettre aux gens décrire du code non trivial. Cest triste, mais hélas la vérité aussi.
- Les problèmes avec Swift
- Lutilisation omniprésente de lARC partout – qui est une violation du «vous ne payez pas pour ce que vous ne payez pas utiliser ”la philosophie en C ++ (peut être abordée dans swift 5.x (voir [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model) )
- Manque de primitives asynchrones très faciles à utiliser live async / await / coroutines (qui est largument de vente pour des langages comme go), peut-être que swift 5.x répondra à cela
- Parfois « classe ”Les déclarations peuvent inutilement vous forcer à utiliser des types de référence où vous pourriez en fait préférer un type valeur (struct)
- Traits dans Rust est techniquement (dans la plupart des cas) une meilleure solution pour 3 entités swift différentes (extensions, protocoles & héritage)
Donc, je suppose quil y a certainement un créneau à occuper rapidement, les gens qui sont de bons programmeurs C ++ peuvent accéder rapidement à Swift / Rust. Mais je pense que Swift aura plus de traction avec développeurs dapplications et Rust avec des programmeurs système. Leurs niches respectives continueront dexister malgré un chevauchement important.