現在の2018年のRustの多くの異なる目標が思い浮かびますが、ところで2017年は非常に早く私に渡されたので、私は次の質問を自問しました：2018年にRustの1つの目標を選択できたら、私は選びましたか
私は偏見があり、これが私の意見です：
2018年は、CまたはC ++で新しいプロジェクトの作成を開始する必要がある最後の年になります。
私はシステムプログラマー（ HPC ）であり、現在、作業用のプログラミング言語を選択する必要がある場合、CとC ++のどちらかしか選択できません。 Rustは、すべての小さなプロジェクトやプロトタイプで毎日使用しているとしても、私には十分ではありません。
なぜこの目標があり、他の目標はないのですか？ 実際、Rustはシステムプログラミングプレーンの外側にある多くのタスクに適しています。 ただし、これは非常に広い領域であり、既にかなり多数の他のPLがあり、
それらはさまざまなタスク（たとえば、GCを使用するものなど）に合わせてシャープにされ、特定のタスクにはRustよりも適しています。
一方、体系的な言語の領域はかなり狭く、関連する言語はCとC ++の2つだけです。 彼らが形成するコミュニティは数百万人の開発者であり、これらのプログラマーはRustにできることを望んでいます
前述の2つのPLを使用して解決するのと同じ問題を正常に解決します。
この言語を使用すると、GCを使用せずにメモリを安全に操作できますが、CおよびC ++開発者にとっては、Rustを使用すると妥協が余儀なくされます。 したがって、2018年はメモリを妥協することなく安全に作業できる1年である必要があります。そのため、2019年に専門的にunsafeコードを書いている人は誰も「XのためにRustを使用できません」と言うことはできず、同時に正しいこともできます。 私たちはすでに安全な言語を持っています。今年は、そのようなセキュリティを必要とする人々がRustを使用しない言い訳ができないように、そのような作業を実行する必要があります。 2019年にCまたはC ++で新しい低レベルのプロジェクトを書くと、人々は驚いて眉をひそめ、他に何もできなくなります。
この目標を達成するために、システムプログラミングのどの領域（金融取引の処理、スーパーコンピューターでの計算、デバイスドライバーの作成、OSカーネルのプログラミング、組み込みシステムのプログラミング、ゲーム開発、コンピューター支援設計（CAD）システム、
ブラウザ、コンパイラなど）に問題があり、それらを評価し、修正してRustを作成します
これらの分野に最も適した言語。
WebAssemblyで使用するには、Rustを並行して改善する必要があります。
スクリプティング、ウェブ開発、その他の分野向け。 しかし、私がしなければならなかった場合
今年の開発の主な目標を1つ選択してから、システムの分野を選択します
プログラミング。
PS：特定の機能をこの記事の主な焦点にしたくない
言語。 すでに作業中の言語の多くの機能がありますが、まだ不完全または不安定です。
言語に関連する：
- メモリモデル （C / C ++）
- コードでのアセンブラー挿入の使用
- 定数ジェネリック
- マクロ2.0
- 非同期プログラミングのサポート（async / await）
- alloca（C）
- 実行時に設定されたサイズの配列（VLA）（C）
ライブラリに関連：
- ストリーム反復子（C ++）
- SIMD命令の使用（C / C ++）
- 組み込みコンパイラー関数（組み込み）
- メモリアロケーター（C ++）
- メモリー不足（OOM）位置処理（C ++）
ツールキット：
- 不確実な動作の検出（UB）：実行時のUBの100％検出
- 貨物のテストによるコードカバレッジの決定
IDE（C / C ++）：
- 貨物との統合
- 自動補完
- 定義への移行
- 改名
- リファクタリング
- コードのフォーマット-これはすべて機能するはずです。
貨物：
- SSHトンネル経由で使用する
- インテリアミラー
- xargo / crossを単一の貨物にマージする
プラットフォーム：
- Cコードでのコンパイルサポート
- GCCをバックエンドとして使用
- CUDAサポート
- C ++コードとのRustの互換性の改善：テンプレート、概念、およびモジュール
これらの問題はそれぞれ、Rustコミュニティで多くの時間を費やしていることに注意してください。
ABIの互換性については言及しませんでした。比較的注意が払われていないからです。
特に、メモリモデルと未定義の動作に取り組むことは、Rustを独自のメモリモデルを持つCおよびC ++と区別できるものですが、未定義の動作（UB）を検出する方法はありません。 私の意見では、メモリモデルがないために、CやC ++よりも言語の安全性と予測性がはるかに低くなるとさえ言えます。
この記事の翻訳、校正、編集に貢献してくれたRustycrateコミュニティの皆さんに感謝します。 すなわち：mkpankov、ozkriff、Revertron。