ベストアンサー
Swift 1、2、3では間違いなく「いいえ」ですが、Swift4ではおそらく「はい」です。とにかく、私はまだあまり前向きではありません。
Rustのターゲット市場はC / C ++プログラマーだと思います。
Rustの主な機能はオーバーヘッドのない非常に安全。今まで、Swiftはここで失敗します。 Swiftは、ref-typesを使用する場合、常に空間と時間の両方で一種のオーバーヘッドを伴います。これは必須であり、避けられません。
「安全」だけがすでに多くの言語で提供されているため、オーバーヘッドは重要です。たとえば、C＃。私の意見では、これはスイフトの実際の真の競争相手です。 C＃はすでに一定レベルの安全性を提供しています。また、市場の一部のセグメントではすでにC / C ++に置き換えられていますが、大量のオーバーヘッドが発生するため、完全には置き換えられていません。空間と時間の両方で。 SwiftコンパイラはRCオーバーヘッドの一部を取り除くことができますが、それは最適化の運次第です。不運な状況では、オーバーヘッドが大きくなります。
そして安全性のレベルも異なります。どちらの言語も、安全なコンテキストでダングリングポインタがないことを保証できるのと同じです。しかし、Swiftが提供できるのはそれだけであり、Rustが提供するものと比較すると、これは非常に弱い保証です。リソースレベルでは、Swift ref-typeはいつでもリークする可能性があり、常に人間のケアが必要です。コンパイラは循環参照を検出できません。 Swiftでは、スレッド間で可変メモリを無制限に共有することもできます（言語のネイティブ同時実行性がないため）。これは、データ競合の安全性がないことを意味します。
対照的に、Rustの一意の所有権は、リソースリークがないことを完全に静的に保証します。静的に保証されるデータ競合もありません。
ここ数年Swiftを使用しているときに感じたのは、リソース管理とデータ競合に関しては言語が実際には安全ではないということです。また、必須のRCオーバーヘッドは、パフォーマンスが重要なコードでは本当に大きな懸念事項です。 Swiftは値型のパフォーマンスをアドバタイズしますが、実際には、ヒープに安全に割り当てるには、常にいくつかのref型を使用する必要があります。 SwiftはコンパイラのスマートRCエリジオンを宣伝していますが、それは運に基づいているため、Rustのゼロコストが保証されています。
なぜ安全性が重要なのですか？地雷原で生産的になることはできないからです。生産性を高めるには、気にする必要のある作業を減らす必要があります。 Swiftでは、誰もあなたのことを気にかけていないので、殺されないように、常にサイクルとデータの競合とオーバーヘッドを気にする必要があります。 Rustでは、コンパイラーはこれを処理できます。あなたは（多くの）安全性を忘れて、それが文句を言うものは何でもコンパイラーに従うだけで、あなたは安全です。 GC言語のユーザーがダングリングポインタを気にしないのと同じように。
また、決定論も重要です。オブジェクトの存続期間の追跡が必要になることはめったにありませんが、非常に重要な場合があります。 SwiftRCは `deinit`タイミングを提供しますが、所有権が共有されているため、通常、死亡のタイミングは非常にあいまいです。一意の所有権のこのようなタイミングは、RCよりもはるかに明確です。
一意の所有権は、責任のある所有者に注釈を付けることでメンテナンスにも役立ちます。私の意見では、一意の所有者を管理することは、複数の所有者を管理するよりもはるかに簡単です。実際、私がSwiftでいつも行っているのは、暗黙の一意の所有者を指定し、何らかの規則に従って手動で追跡することです。コンパイラがこれを行ってくれるといいと思いませんか？
Swift 4は、一意の所有権、移動セマンティクス、アクターモデル、C ++相互運用サポートなどのいくつかの新機能の導入を計画しています。しかし、現在の言語セマンティクスの機能を使用して、Rustレベルの安全性をどのように保証できるかはわかりません。だから私はまだスイフトの安全レベルについてあまり前向きではありません。 C ++の相互運用は大きなセールスポイントになる可能性があります。とにかく、これがSwift4がC / C ++市場でRustの潜在的な競争相手になる可能性があると私が考える唯一の理由です。
Swiftにも長所があります。 saner（私の意見では）命名規則と明確な構文（私の意見では）、専用IDE、世界で最も裕福なサポーターによる保証された開発と持続可能性など（ただし、これはサポートされるプラットフォームの政治的問題ももたらします）。全体的に、UI / UXは優れていますが、それでもRustの安全性と概念的な美しさにもっと惹かれます…
P.S。実際、Swift 2.xの初期バージョンでは、 `deinit`やweak-refなどの安全な構造のみを使用してダングリングポインターを作成することができました。しかし、今と将来はわかりません。
P.S。 2.彼らは抜け穴にパッチを当てたようです。 Swift 3では、 `deinit`で弱参照を作成しようとすると、ランタイム例外が発生します。
回答
最近swift-3.xについて読みましたが、かなり長い間Rustのファンでしたが、私はRustがシステム言語として成功することを*本当に*望んでいます。
あなたの質問への答えは条件付きのはいです、なぜですか？これは、ネイティブアプリケーションプログラミングの観点から、swiftがかなりのスペースと錆と重なっているためです。設計哲学とシステムプログラミングのユースケース（および一部のリアルタイムユースケース）の点で、言語間には明確な対照があります。
Rustは、ほとんどの部分でC ++哲学に基づいて設計されているため、非常に高性能なコンピューティングとめちゃくちゃ最適化可能なコンパイラーを実行することが可能です（多くの現代言語が競合するのを見たことがないニッチ）
- 「ゼロコストの抽象化」
- これはカーネルまたはコアユーティリティを作成しているときに特に重要なのは、パフォーマンスの最後のビットを引き出すために可能な限り最大限に最適化する必要があるためです。
- すぐにほとんどの最適化を実行できますが、すべてではありません。は、達成できる最適化の量に対する言語の障壁です（たとえば、ほとんどの参照カウントは迅速にアトミックであると安全に想定できますが、錆びている場合はRcタイプとArcタイプのどちらかを選択できるため、料金を支払わないでください使用しないもの）。
- 「Rustポインタモデル」
- Rustプログラムは、所有権、借用、移動のセマンティクスを通じてコードからクラッシュの原因のほとんどを排除するように設計されているため、特定の時点でリソースに一意の所有者が1人しかいないことを静的に検証します。これにより、以下の2つのユースケースでも簡単になります。
- プログラムのクラッシュ可能な部分を分離する方法（安全ではない）
- コードを書くときに安全な並行性を持たせる方法
- Swiftは、強い（shared\_ptr）、弱い（weak\_ptr）、および所有されていないポインター（intrusive\_ptr）をプログラマーに公開し、それらを（ab）使用するための制御を提供するため、この点でC ++に非常に似ています。それらのコードは、Javaよりも確実に優れた制御ですが、確かに安全性は低くなります
- 「列挙型」
- Rustには、HaskellのADTに似た豊富な列挙型があります（それほど強力ではありませんが）が、それでもFSMの記述のサポートが非常に不十分なCについて考えると、有限状態マシン（FSM）の美しいデザインを有効にします。
- SwiftにはJavaに似た美しい列挙型もあり、定義できるのではるかに強力だと思います。列挙型の動作。
- 「クロージャー」-これは、現代の言語と古風な言語を区別する単一の機能です。 RustとSwiftはどちらもクロージャをサポートしていますが、Rustモデルを使用すると、「クローズオーバー」変数の所有権について推論できるため、安全性が確保されます。一方、Swiftのクロージャーは、経験豊富なプログラマーでもいくつかの驚きをもたらす可能性があります。
- Rustの問題
- 二重にリンクされたリストのような非常に単純なデータ構造は、Rustに存在できません。所有権のセマンティクス（この単純なデータ構造にはRc / Arcを使用する必要があります）のこれは一部の人々を苛立たせます。
- 人気のある言語に機能がある場合のプログラミング経験によると、人々はそれらを乱用します。Rustでは、安全でないブロックは、借用チェッカーと戦う意思のない人々にとって間違いなく乱用されがちです。これは、悲しいことに、大きな割合を占めます。
- 標準ライブラリの不変性の違反（そうでない場合）些細なコードをRustで記述する必要があります。Cell/ RefCellのようなデータ型を技術的に使用して、言語が提供する強力な安全性に対するバックドアとして使用できるようにする必要があります。ライブラリはこれらのデータ型を使用している間、多くの安全プリミティブを提供するので、私たちは足を踏み入れません。
- 最後に、Rustは、C ++よりも安全である一方で、いくつかの採用を許可し、人々が重要なコードを記述できるようにするために、嫌われているC ++機能も組み込む必要があります。これは悲しいことですが、残念ながら真実でもあります。
- Swiftの問題
- どこでもARCが広く使用されていることは、「自分がしていないことに対してお金を払わない」という違反です。 C ++での「使用」哲学（swift 5.xで対処される可能性があります（ [swift-evolution] RFC：保持サイクルの防止（メモリ所有モデル）を参照）
- 非常に使いやすい非同期プリミティブの欠如liveasync / await / coroutines（goのような言語のセールスポイントです）、5.xがそれに対処するのは迅速かもしれません
- 時々「クラス」 」宣言は、実際に値型（構造体）を好む可能性のある参照型の使用を不必要に強制する可能性があります
- Rustの特性は、技術的に（ほとんどの場合）3つの異なる迅速なエンティティ（拡張機能、プロトコル）に対するより良いソリューションです。 ＆継承）
つまり、迅速に占有するためのニッチは間違いなくあると思います。優れたC ++プログラマーである人は、Swift / Rustにすばやくアクセスできます。しかし、Swiftの牽引力はさらに高まると思います。とアプリケーション開発者とRustwithSystemプログラマー。それぞれのニッチは、大幅な重複にもかかわらず存在し続けます。