Swift est un Rust plus pratique (2023)

 (nmn.sh)
2 points par GN⁺ 2026-02-01 | 1 commentaires | Partager sur WhatsApp
  • Rust et Swift partagent tous deux un système de types puissant et des caractéristiques des langages fonctionnels, et peuvent être compilés en code natif et en WASM via un compilateur basé sur LLVM
  • Rust a commencé comme un langage système de bas niveau avant d’offrir des fonctionnalités de haut niveau, tandis que Swift a commencé comme un langage de haut niveau tout en autorisant l’accès au bas niveau
  • Swift repose par défaut sur les types valeur et le Copy-on-Write, et met en œuvre des concepts similaires au modèle de propriété de Rust avec une syntaxe plus simple
  • Pour les types optionnels, la gestion des erreurs, les enum récursifs, etc., Swift enveloppe des concepts de Rust dans une syntaxe familière de la famille du C, offrant davantage de confort aux développeurs
  • Swift est en train de devenir un langage cross-platform et peut aussi être utilisé sous Windows, Linux et dans des environnements embarqués, ce qui en fait une alternative montante à Rust

Similarités et différences entre Rust et Swift

  • Les deux langages incluent des caractéristiques des langages fonctionnels (enum tagués, expressions match/switch, génériques, fonctions de première classe)
    • Rust fournit le comptage de références et le contrôle de la copie via Rc, Arc, Cow
    • Swift utilise par défaut les types valeur et le Copy-on-Write, et prend aussi en charge si nécessaire le déplacement de propriété (move) et l’accès via des pointeurs unsafe
  • Les deux langages utilisent un compilateur basé sur LLVM, ce qui permet de compiler en code natif et en WASM

Modèle mémoire : Rust descend du bas vers le haut, Swift monte du haut vers le bas

  • Rust a commencé comme un langage système de bas niveau avant d’ajouter des fonctionnalités de haut niveau
  • Swift a commencé comme un langage de haut niveau tout en permettant un accès bas niveau quand c’est nécessaire
  • Le modèle mémoire par défaut de Swift repose sur des types valeur en Copy-on-Write, similaires au Cow<> de Rust
    • Rust est rapide par défaut, mais il faut gérer explicitement Cow<> lorsqu’on l’utilise
    • Swift est simple par défaut, et permet de choisir le déplacement plutôt que la copie
Publicité

L’approche syntaxique de Swift : des concepts de Rust masqués par un style C

  • L’instruction switch de Swift assure en pratique les mêmes fonctions que l’expression match de Rust
    • Elle prend en charge le pattern matching et n’a pas de fallthrough
  • Les enum de Swift peuvent inclure directement des méthodes, ce qui permet un usage plus orienté objet que dans Rust
  • Les types optionnels (T?) reposent sur le même concept que Option<T> en Rust, et nil correspond à None
    • En Swift, le déballage sûr est possible avec la syntaxe if let val
  • La gestion des erreurs ressemble au type Result de Rust, et do-catch ainsi que try en Swift sont la même structure enveloppée dans une syntaxe plus familière

Différences dans le fonctionnement du compilateur

  • Le compilateur Rust met l’accent sur la détection des problèmes et les avertissements et, par exemple, impose l’usage de Box<> lors de la définition d’un enum récursif
  • Swift gère les enum récursifs avec le seul mot-clé indirect, le compilateur automatisant la gestion interne des pointeurs
  • Swift automatise davantage de traitements que Rust, ce qui réduit le besoin pour les développeurs de manipuler directement la structure mémoire

Praticité et extensibilité du langage Swift

  • Swift a été conçu pour remplacer Objective-C, avec l’ambition d’être un langage plus vaste et plus pratique
    • Il intègre de nombreuses fonctionnalités comme classes/héritage, async-await, actors, propriétés lazy, property wrappers, Result Builders, etc.
  • Sa conception de « progressive disclosure » fait apparaître davantage de fonctionnalités au fur et à mesure de l’apprentissage
Publicité

Équilibre entre confort et performance

  • Swift est un langage facile à prendre en main et productif, tandis que Rust est un langage rapide par défaut
    • Rust : « la vitesse par défaut » ; Swift : « le confort par défaut »
  • Rust est adapté aux systèmes, à l’embarqué, aux compilateurs et aux moteurs de navigateur
  • Swift convient aux UI, aux serveurs et à certains composants de systèmes d’exploitation, et les domaines d’usage des deux langages se recoupent de plus en plus

L’expansion cross-platform de Swift

  • Swift n’est plus un langage réservé à Apple
    • Windows : The Browser Company l’utilise pour le partage de code du navigateur Arc
    • Linux : Apple prend en charge Swift on Server et sponsorise des conférences
    • Embedded Swift : utilisé sur de petits appareils comme le Panic Playdate
  • Le blog officiel de Swift présente des projets Windows, Embedded, Linux(Gnome), Playdate
  • Swift améliore aussi l’expérience de développement hors de Xcode avec une extension VSCode, l’open source de son LSP, etc.

Limites de Swift et position actuelle

  • Le temps de compilation est lent, comme pour Rust
  • Le feature creep a fait grossir le langage, et certaines syntaxes restent peu familières
  • L’écosystème de packages est moins mature que celui de Rust
  • Mais Swift dispose déjà de la stabilité ABI, du comptage automatique des références (ARC), de mécanismes de choix de propriété, et de packages compatibles Linux, ce qui en fait un langage cross-platform
  • Swift s’impose comme une alternative plus pratique à Rust, non pas comme une promesse pour l’avenir, mais comme une option disponible dès aujourd’hui

À lire aussi

1 commentaires

 
GN⁺ 2026-02-01
Réactions sur Hacker News

  • Je suis globalement d’accord, mais c’est dans les détails que le vrai problème apparaît
    Xcode est un IDE assez brut de décoffrage qui se fige souvent sur les gros projets lors du rafraîchissement des paquets ou de la gestion de multiples targets. Et même si on veut corriger ça, les binaires ne peuvent pas être patchés
    Le système de build est bien plus simple à manier avec Cargo qu’avec SPM. Le système de macros dépend toujours de génération de code externe
    Il existe des linters et des formatters, mais leur qualité est faible. Swift a beaucoup de falaises de performance, et son inférence de types bidirectionnelle devient lente sur les expressions complexes. C’est particulièrement visible dans des cas d’usage majeurs comme SwiftUI
    Les imports sont liés au niveau du module, donc même si on ne modifie qu’un seul fichier, il faut recompiler tout le module. La distinction entre classes et structures est aussi maladroite à cause de la compatibilité ObjC
    Au final, Swift pourrait être un langage plus simple que Rust, mais en pratique je n’en ai pas l’impression à cause de l’immaturité de son outillage

    • J’ai fait une petite app SwiftUI, et il était beaucoup trop difficile d’identifier les fuites mémoire. Même avec Instruments et vmmap, elle perdait encore plusieurs dizaines de Mo par jour
      Le modèle mémoire semi-automatique de Swift me semble bien plus difficile à maîtriser que celui de Rust ou de Go
    • Si ce n’est pas pour des apps iOS/macOS, on peut complètement se passer de Xcode et utiliser uniquement le CLI swift, ça fonctionne très bien. Ça marche aussi bien sous Linux que sous Windows
    • Swift prend en charge LSP, donc on peut aussi développer avec VSCode, Zed, Sublime Text, etc. Si on ne fait pas du développement spécifique à Apple, Xcode n’est pas indispensable
    • Sur d’anciennes versions de Swift, une ou deux lignes de littéral de dictionnaire pouvaient suffire à faire durer un build 30 minutes
    • La plupart des problèmes de vitesse de compilation peuvent être atténués avec une séparation par paquet et des annotations de type explicites. SPM fonctionne mieux qu’on ne pourrait le penser

  • Il était dit qu’en Rust il faut un Box pour représenter une structure d’arbre avec un enum, mais en réalité Vec fournit déjà une référence vers le tas, donc ce n’est pas nécessaire

    • Je connais bien Rust, donc l’erreur en elle-même ne me gêne pas, mais ça me fait me demander si l’explication côté Swift est aussi inexacte
      En Rust, les enum, struct, union, et même les types primitifs peuvent tous avoir des méthodes. On peut par exemple appeler 'F'.to_digit(16)
      On peut même attacher des méthodes à des raw pointers. Je trouve que ça illustre bien la modernité de la conception de Rust
    • L’exemple des enum en Swift met en avant un bon sucre syntaxique, mais dans la pratique la prise en charge des types union est faible, si bien que beaucoup de développeurs abusent des optional au lieu des enum
    • Il est facile de confondre Vec et Box. Vec est un handle de taille fixe à la compilation, tandis que Box est nécessaire pour manipuler des types non dimensionnés
    • Testé sur Rust 1.92, et ça fonctionne très bien sans Box
    • Vec<T> est lui-même un handle de taille fixe pointant vers des données sur le tas, donc il n’y a pas besoin de Box

  • Swift est un langage sympa, mais il est peu convaincant côté serveur
    L’écosystème est petit, et il n’apporte pas grand-chose par rapport à Go ou Rust. Le support VSCode est limité, et je n’ai pas envie d’utiliser Xcode
    Le développement serveur est déjà occupé par Python, TypeScript, Go et Rust. L’écosystème fermé d’Apple est aussi un frein

    • J’ai effectivement de l’expérience sur un backend Swift avec intégration directe de bibliothèques C. Ça fonctionnait bien sans FFI particulier, et les performances étaient bonnes
      Je trouve que la qualité de l’IDE est meilleure que dans d’autres langages, mais Rust reste plus adapté à la programmation système
    • J’ai essayé Swift Vapor sur un projet perso, mais j’ai été déçu par la vitesse de compilation et de test, inférieure à celle de Go

  • On dit maintenant que Swift est un langage cross-platform, mais sous Linux l’écosystème reste centré sur Apple
    La documentation, les tutoriels et les bibliothèques sont tous écrits avec macOS comme référence. Je me demande vraiment combien de gens utilisent Swift sans appareil Apple

    • La documentation Apple ne précise pas les limitations sous Linux, ce qui m’a valu beaucoup d’essais-erreurs
      J’ai résumé cette expérience de création d’un client WebSocket dans un billet de blog
      Version 2023 / Version 2025
    • Les développeurs Apple disent que c’est bien aussi sous Linux, mais en pratique l’écosystème Rust est largement supérieur
    • J’ai voulu porter un outil CLI pour Mac vers Linux, mais il a été plus simple et plus rapide de le convertir en Go avec un LLM
      Le support Android est intéressant aussi, mais Kotlin me semble déjà suffisant
    • Il y a beaucoup d’exemples centrés sur Apple, ce qui provoque des problèmes en cross-compilation. Par exemple, NSHashTable n’existe pas en dehors des plateformes Apple
    • Swift permet de gérer les versions du compilateur avec swiftly, un outil similaire à rustup, et LSP fonctionne bien aussi
      De mon côté, je maintiens même des bibliothèques compatibles jusqu’à Windows. Ce n’est pas parfait, mais ça progresse petit à petit

  • Le switch de Swift est en pratique une expression de match. Seule la syntaxe diffère, mais il s’agit bien de pattern matching

    • Du point de vue des concepteurs du langage, cela ressemble à une stratégie consistant à conserver la syntaxe historique de switch afin de réduire la confusion chez les développeurs
      L’idée est d’introduire une nouvelle sémantique à travers une syntaxe familière, pour favoriser une transition progressive
      Cette approche mène à une discussion intéressante sur le degré de conception prescriptive qu’un langage devrait assumer

  • Le cœur de Rust, c’est la zero-cost abstraction. Swift ne suit pas ce principe
    Beaucoup de fonctionnalités de Rust ont été conçues pour respecter cette règle, et le modèle de propriété en est un exemple central

    • Le modèle de propriété explicite de Rust permet d’éviter à la compilation des erreurs d’exécution qui peuvent survenir avec les actor ou les Task de Swift
      Il y a une courbe d’apprentissage, mais cela améliore l’efficacité de développement
    • Swift prend aussi en charge un modèle de propriété, mais l’impose moins fortement que Rust

  • On dit que le navigateur Arc a utilisé Swift sur Windows, mais après l’arrêt du développement, il semble que ce travail ait aussi été abandonné

  • Si je préfère Rust, c’est parce qu’il n’y a pas de dépendance à un grand groupe. Je pense qu’Apple pourrait abandonner Swift

    • Mais il est peu probable qu’Apple abandonne Swift. Rust pourrait au contraire être plus risqué, car il dépend davantage de la communauté
    • Une grande partie des logiciels d’Apple est écrite en Swift, donc ils n’ont aucune raison de l’abandonner
    • Go est lié à Google, C# à Microsoft. Comme Swift est aussi open source, je trouve difficile de le critiquer avec cette même logique
    • Swift a été créé par Apple, mais il est maintenu par une communauté open source
      C’est aussi indiqué dans cet article Wikipédia

  • On peut profiter du confort de Swift dans Rust grâce aux fonctionnalités de comptage de références sans avoir à migrer
    Avec Rc, on peut avoir des références partagées immuables, et avec l’intérieur mutable, on peut implémenter des mutations reposant sur des vérifications à l’exécution
    Documentation sur Rc, documentation sur l’intérieur mutable

    • En environnement mono-thread, on utilise Rc ; en multi-thread, Arc. Grâce au trait Send, on n’utilise pas Rc sur le mauvais thread par erreur
    • En revanche, cela a le défaut de rendre le code beaucoup trop verbeux

  • J’ai développé des outils d’analyse et des compilateurs pour Linux en Swift et en Rust
    Swift rend la gestion mémoire confortable grâce à ARC, tandis que Rust demande plus de réflexion mais offre une bien meilleure qualité d’outillage
    Clippy et le support LSP sont excellents, et Swift fournit beaucoup de fonctionnalités par défaut
    Cela dit, la communauté Rust est plus grande, donc il est plus facile de recruter, et je pense aussi que Swift a du potentiel comme langage de remplacement du C++