Swiftはより便利なRust（2023）

 (nmn.sh)
2 ポイント 投稿者 GN⁺ 2026-02-01 | 1件のコメント | WhatsAppで共有
  • RustとSwift はどちらも強力な型システムと関数型言語の特徴を共有し、LLVMベースのコンパイラ によってネイティブコードとWASMへコンパイル可能
  • Rust は低水準のシステム言語として始まり高水準の機能を提供し、Swift は高水準の言語として始まり低水準のアクセスを許可
  • Swiftは 値型とCopy-on-Write を基本とし、Rustの 所有権モデル に似た概念をより単純な構文で実装
  • オプショナル型、エラー処理、再帰的enum などで、SwiftはRustの概念を C系になじみやすい構文 で包み、開発者により高い利便性を提供
  • Swiftは クロスプラットフォーム言語として発展中 であり、Windows・Linux・組み込み環境でも利用可能になって Rustの代替として台頭

RustとSwiftの類似点と相違点

  • 両言語とも 関数型言語の特徴（タグ付きenum、match/switch式、ジェネリクス、第一級関数）を含む
    • Rustは Rc, Arc, Cow を通じて参照カウントと複製制御を提供
    • Swiftは基本的に 値型とCopy-on-Write を使い、必要に応じて 所有権の移動(move) と unsafeポインタアクセス をサポート
  • 両言語とも LLVMベースのコンパイラ を使用し、ネイティブコードとWASMへコンパイル可能

メモリモデル: Rustはトップダウン、Swiftはボトムアップ

  • Rustは 低水準システム言語 として始まり、高水準の機能を提供
  • Swiftは 高水準言語 として始まり、必要時に低水準アクセスを許可
  • Swiftの基本メモリモデルは Copy-on-Writeの値型 で、Rustの Cow<> に類似
    • Rustは基本的に高速だが、使用時に Cow<> を明示的に扱う必要がある
    • Swiftは基本的に単純で、コピーの代わりに移動を選べる

Swiftの構文的アプローチ: Rustの概念をCスタイルで隠す

  • Swiftの switch 文は事実上 Rustの match 式 と同じ機能を果たす
    • パターンマッチングをサポートし、fallthrough がない
  • Swiftの enum は メソッドを直接含める ことができ、Rustよりオブジェクト指向的に使える
  • オプショナル型(T?) はRustの Option<T> と同じ概念で、nil は None に対応
    • Swiftでは if let val 構文で安全にアンラップ可能
  • エラー処理 はRustの Result 型に似ており、Swiftの do-catch と try は なじみある構文で包んだ同じ構造

コンパイラ動作の違い

  • Rustコンパイラは 問題検出と警告 に重点を置き、たとえば 再帰的enum の定義時には Box<> の使用を強制
  • Swiftは indirect キーワードだけで再帰的enumを処理し、コンパイラが内部ポインタ管理を自動化
  • SwiftはRustより 自動化された処理 が多く、開発者が自分でメモリ構造を扱う必要が少ない

Swiftの実用性と言語拡張性

  • Swiftは Objective-Cの代替 を目標に設計され、より大きく実用的な言語
    • クラス/継承、async-await、actors、lazyプロパティ、property wrappers、Result Buildersなど多様な機能を内蔵
  • 「段階的公開(progressive disclosure)」設計により、学習が進むほどより多くの機能が現れる

利便性と性能のバランス

  • Swiftは 始めやすく生産性の高い言語、Rustは 基本的に高速な言語
    • Rustは「速さが標準」、Swiftは「利便性が標準」
  • Rustは システム・組み込み・コンパイラ・ブラウザエンジン に適する
  • Swiftは UI・サーバー・OSの一部コンポーネント に適しており、両言語の 活用領域は徐々に重なっている

Swiftのクロスプラットフォーム拡張

  • Swiftはもはや Apple専用言語ではない
    • Windows: The Browser CompanyがArcブラウザのコード共有に使用
    • Linux: AppleがSwift on Serverを支援し、カンファレンスを後援
    • Embedded Swift: Panic Playdateのような小型デバイスで使用
  • Swift公式ブログは Windows, Embedded, Linux(Gnome), Playdate プロジェクトを紹介
  • Swiftは VSCode拡張、LSPのオープンソース化 などにより、Xcode以外の環境でも開発体験を改善中

Swiftの限界と現在地

  • コンパイル時間 はRustと同様に遅い
  • 機能拡張(feature creep) により言語が大きくなり、一部の構文はなじみにくい
  • パッケージエコシステム はRustより未成熟
  • しかしSwiftはすでに ABI安定性、自動参照カウント(ARC)、所有権を選べる機能、Linux互換パッケージ を備えた クロスプラットフォーム言語
  • Swiftは Rustより便利な代替 として位置づけられており、待つべき未来ではなく現在の選択肢 として存在する

関連記事

1件のコメント

 
GN⁺ 2026-02-01
Hacker Newsの意見

  • 概ね同意だが、細部に問題の核心が表れている
    Xcodeは大規模プロジェクトでパッケージの再読み込みやマルチターゲット処理時によく固まる粗いIDEだ。直そうとしてもバイナリパッチができない
    ビルドシステムはCargoのほうがSPMよりはるかに扱いやすい。マクロシステムはいまでも外部コード生成に依存している
    リンターやフォーマッターは存在するが品質が低い。Swiftには性能の崖が多く、型推論が双方向なので複雑な式で遅くなる。SwiftUIのような主要ユースケースで特に問題になる
    importがモジュール単位で束ねられているため、ファイル1つだけ変えてもモジュール全体を再コンパイルしなければならない。クラスと構造体の区別もObjC互換性のせいで不自然だ
    結局、SwiftはRustより簡単な言語になり得るが、ツールチェーンの未成熟さのせいで実際にはそう感じられない

    • 小さなSwiftUIアプリを作ったが、メモリリークを見つけるのがあまりにも難しかった。Instrumentsとvmmapで解析しても、1日に数十MBずつ漏れていた
      Swiftの半自動メモリモデルはRustやGoよりずっと扱いづらいと感じた
    • iOS/macOSアプリでないなら、Xcodeを完全に飛ばしてswift CLIだけ使っても十分実用的だ。LinuxやWindowsでもよく動く
    • SwiftはLSPをサポートしているので、VSCode、Zed、Sublime Textなどでも開発できる。Apple専用開発でなければXcodeは必須ではない
    • 昔のSwiftでは、辞書リテラルが1〜2行あるだけでビルドに30分かかったことがあった
    • コンパイル速度の問題の多くは、パッケージ単位での分離と明示的な型指定で緩和できる。SPMは思ったよりまともに動く

  • Rustでツリー構造をenumで表現するときBoxが必要だと言っていたが、実際にはVecがすでにヒープ参照を提供するので不要だ

    • Rustをよく知っているので誤り自体は気にしないが、Swift側の説明も同じように間違っているのではと心配になる
      Rustのenum、struct、union、さらにはプリミティブ型にまでメソッドを持たせられる。たとえば'F'.to_digit(16)のような呼び出しができる
      さらにraw pointerにさえメソッドを付けられる。こうした点がRustの現代的な設計だと思う
    • Swiftのenumを例に出して糖衣構文が良いと言うが、実際にはunion型のサポートが弱いため、多くの開発者がenumの代わりにoptionalを乱用している
    • VecとBoxの違いは混同しやすい。Vecはコンパイル時にサイズが固定されたハンドルで、Boxはunsized型を扱うときに必要だ
    • Rust 1.92で試したところ、Boxなしでも問題なく動いた
    • Vec<T>自体がヒープデータを指す固定サイズのハンドルなので、Boxは不要だ

  • Swiftは素晴らしい言語だが、サーバーサイドでは説得力が弱い
    エコシステムが小さく、GoやRustと比べて得るものがない。VSCode対応も不十分で、Xcodeは使いたくない
    サーバー開発はすでにPython、TypeScript、Go、Rustが押さえている。Appleの閉鎖的なエコシステムも負担だ

    • 実際にSwiftでCライブラリと直接連携してバックエンドを作った経験がある。FFIなしでもうまく動き、性能も良かった
      他言語よりIDE品質は高く、システムプログラミングにはRustのほうが向いていると思う
    • Swift Vaporで個人プロジェクトをやってみたが、Goよりコンパイル・テスト速度が遅くて残念だった

  • Swiftはいまやクロスプラットフォーム言語だと言われるが、Linuxでは依然としてApple中心のエコシステムだ
    ドキュメント、チュートリアル、ライブラリがどれもmacOS基準で書かれている。実際にAppleデバイスなしでSwiftを使う人がいるのか気になる

    • AppleのドキュメントにはLinuxでの制約が明記されておらず、試行錯誤が多かった
      WebSocketクライアントを作りながら経験した過程をブログにまとめた
      2023年版 / 2025年版
    • Appleの開発者たちはLinuxでも良いと言うが、実際にはRustのエコシステムのほうがはるかに優れている
    • Mac向けCLIツールをLinuxに移植しようとしたが、LLMでGoコードに変換するほうがより速く簡単だった
      Android対応も興味深いが、Kotlinで十分だと感じる
    • Apple中心のサンプルが多いため、クロスコンパイル時に問題が起きる。たとえばNSHashTableはApple以外のプラットフォームには存在しない
    • Swiftはrustupに似たswiftlyツールでコンパイラのバージョン管理が可能で、LSPもよく動く
      個人的にはWindowsまでサポートするようライブラリを管理している。完璧ではないが、徐々に良くなっている

  • Swiftのswitchは実質的にmatch式だ。構文が違うだけで、パターンマッチを行っている

    • 言語設計者の立場から見ると、既存のswitch構文を維持して開発者の混乱を減らそうとする戦略に見える
      なじみのある構文で新しい意味を導入し、段階的な移行を促したのだ
      こうしたアプローチは、言語がどれだけ強い意見を持った設計を目指すべきかという興味深い議論につながる

  • Rustの核心はzero-cost abstractionだ。Swiftはこの原則に従っていない
    Rustの多くの機能はこの規則を守るために設計されており、所有権モデルがその代表例だ

    • Rustの明示的な所有権モデルは、SwiftのactorやTaskで起こり得るランタイムエラーをビルド時に防止する
      学習曲線はあるが、開発効率を高めてくれる
    • Swiftも所有権モデルをサポートしているが、Rustほど強制的ではない

  • ArcブラウザがWindows向けSwiftを使っていたと言われるが、開発中止以降、関連作業もキャンセルされたようだ

  • Rustを好む理由は、大企業への依存がないからだ。AppleがSwiftを捨てる可能性もあると思っている

    • だが、AppleがSwiftを捨てる可能性は低い。Rustのほうがむしろコミュニティ依存度が高く、より危ういかもしれない
    • AppleのほとんどのソフトウェアがSwiftで書かれており、手放す理由がない
    • GoもGoogle、C#もMicrosoftに結び付いている。Swiftもオープンソースなので、同じ論理で批判するのは難しいと思う
    • SwiftはAppleが作ったが、オープンソースコミュニティが維持している
      Wikipediaの記事にも明記されている

  • Rustの参照カウント機能を活用すれば、Swiftに移らなくても利便性を得られる
    Rcで不変の共有参照を、内部可変性でランタイムチェックベースの変更を実装できる
    Rcのドキュメント, 内部可変性のドキュメント

    • シングルスレッド環境ではRcを、マルチスレッドではArcを使う。Sendトレイトのおかげで、Rcを誤ったスレッドで使うことはない
    • ただしコードがあまりに冗長になる欠点がある

  • SwiftとRustでLinux向けの解析ツールとコンパイラを作ってみた
    SwiftはARCのおかげでメモリ管理が楽で、Rustはより多くの思考を要求するがツール品質ははるかに高い
    ClippyとLSP対応は素晴らしく、Swiftは標準搭載機能が多い
    ただしRustコミュニティのほうが大きいため人材を見つけやすく、SwiftもC++代替言語としての可能性があると見ている