Azure CTO: 「新しいプロジェクトをC/C++で始めるのは、もうやめるべき時だ」 (twitter.com/markrussinovich) 22 ポイント 投稿者 xguru 2022-09-21 | 55件のコメント | WhatsAppで共有 GCのない言語がどうしても必要なシナリオなら Rust を使おう セキュリティと信頼性のため 業界は C/C++ を非推奨言語として宣言すべき 関連記事 Google、「ファームウェアでC/C++をRustに置き換えるのは簡単」 18 ポイント · 1件のコメント · 2024-09-10 ホワイトハウス、開発者にCとC++を避け「メモリ安全」言語の使用を促す 18 ポイント · 11件のコメント · 2024-02-29 Microsoft、主要なC#コードの書き換えに向けてRust開発者を募集 11 ポイント · 11件のコメント · 2024-02-05 Rustプログラミング言語［韓国語版］ 11 ポイント · 1件のコメント · 2019-12-26 2025年のRust: 基盤ソフトウェアを目指して 23 ポイント · 15件のコメント · 2025-08-20 55件のコメント ahwjdekf 2023-03-01 これまでRustを称賛しながら使っていた人たちも、asyncに触れると急に現実を思い知らされるとか。しかも、Rustではライブラリを作るなということなのか（あまりにも複雑で、面倒で、難しい）。そんな不満も出ているようですね kernel00 2022-10-03 マーク・ルシノビッチが誰なのかも知らずにけなす人もいるんですね……sysinternals tool suite と書籍 windows internals の著者です……Windows をリバースエンジニアリングしてツールを作っていたうちに、Microsoft フェローになった人ですよ…… ahwjdekf 2022-09-25 Rust狂信者たちの問題点を短い動画で皮肉った投稿 https://twitter.com/cmuratori/status/1367627549816152064?lang=en ahwjdekf 2022-09-25 Rust には、まだ正式な仕様すらないという…… functor 2022-09-29 C++には正式な仕様が"存在"はしていますが、すべての実装（gcc、clang、…）が不完全なんですよね lifthrasiir 2022-09-26 これはよくある議論ですが、実際に仕様をかなり読み込み、実装も何度も行ってきた立場からすると、仕様があるかないか自体にどれほどの意味があるのかはよく分かりません。 「仕様」にはさまざまな戦略があります。外から見える動作を中心に記述する方法と内部動作を記述する方法があり、自然言語を使うか、機械が読める方法（擬似コードや数学的定義など）を使うかに分かれます。Python や Rust の言語リファレンス文書のようなものは、外から見える動作を自然言語で記述した仕様です。ISO 標準などでよく見られるアプローチは、内部動作を自然言語で記述した仕様ですが、この内部動作が実際の実装のアプローチと一致する保証はありません。その代わり、その内部動作で実装された仮想的な実装と実際の実装が、外から見て同一に動作する、つまり observationally equivalent であれば標準に適合すると定義する形になります。ECMAScript は自然言語で記述されてはいますが、実際の構造は事実上、擬似コードを自然言語で書いたのに近い水準ですし、WebAssembly のように、内部動作を自然言語仕様と数学的定義の両方で提供している例もあります。 実装する側からすると、自然言語の仕様はどれも大差ありません。自然言語の仕様は実際の実装とは別に作られなければならないため、どうしても両者が乖離することがありますし、ミスが生じることも珍しくありません。外から見える動作のほうが実装しやすいか、内部動作のほうが実装しやすいかは状況次第であり、プログラミング言語の観点ではどちらか一方を選ぶべき明確な必然性は特にありません。そういう意味では、Rust にはすでに仕様が存在しており、別の代替実装が登場しうる程度には、その仕様は十分な情報を提供していると言ってよいでしょう。 単に ISO 標準になったかどうかで標準の成熟度を判断したいのであれば、私が ISO/IEC 18181-1 JPEG XL 標準で 100 件ほどのバグを見つけており（そのせいで 2nd amendment が遅れている）、という話をお伝えしておきます... xguru 2022-09-25 Hacker Newsでも800件を超えるコメントが付いていましたが……こちらも熱いですね… https://news.ycombinator.com/item?id=32905885 kayws426 2022-09-25 お疲れさまです。 一方で……ある人が好きな何かが攻撃されたとき、 その人の反応を解釈しようとする際に、その人の性格のせいにすることには注意すべきだ、という文章を見て、良い言葉だと思いました。というのも、実際の状況でそのような心持ちを保つのは難しいことだからでしょう。 ahwjdekf 2022-09-24 ツイートの返信の中に、印象的なものがありました。 People end up writing Rust code the "unsafe way". - 省略 - Rust was never meant to replace those. kayws426 2022-09-24 このあたりで、Mark Russinovich が誰なのか分かるリンクを貼っておきます。 https://en.m.wikipedia.org/wiki/Mark_Russinovich ahwjdekf 2022-09-24 もう一言。C++を使いながらしょっちゅうエラーを出してバグを作っていた人たちが、「これもう使えないな、最近話題のRustに行ってみようか……メモリエラーを気にしなくていいらしいし……」となっても、そういう人たちは結局同じです。Rustでも似たようなバグを作るでしょうし……そうしたらまた次はどの言語を学んでやってみようか、という人がたくさん出てくるでしょう。C++でポインタのデリファレンスすらまともにやったことがない人たちが、Rustを持ち上げているんです。 ahwjdekf 2022-09-24 そういう類いの人間は、Rust が強みとして掲げる所有権、reference、borrowing といったものをコンパイル時からエラーになって面倒だとして全部無視して、結局 unsafe を混ぜて C++ みたいに雑に使うだろう、ということです。 functor 2022-09-29 どうせ死ぬのに、なぜ生きるのですか？ これとほとんど同じレベルの論理ですね budlebee 2022-09-25 どうせ問題を起こす人はシートベルトも締めず、信号も無視するのだから、シートベルトや信号機には大した意味がないと主張しているのを見るような感覚ですね。 できる人は何をしてもうまくやるし、できない人は何をしてもできない、という主張はできるかもしれませんが、そういう論理でいくと道具の有用性についての議論自体が成り立たなくなります。 cr543l 2022-09-23 言語の難易度が高すぎるのが問題で、もっともな話ではありますね iolothebard 2022-09-23 Visual Rustが出たら認める -.-k binaryeast 2022-09-21 C/C++は、もう本当にラテン語のような位置づけになっていく気がしますね。学問のためなら誰でも学ぶべきですが、極めるのは不可能に近く、古い体系なので、今の基準で見ると不合理な部分も多いですし… dalinaum 2022-09-21 すべてがunsafeな言語は普通に使いながら、限定的にunsafeを使える言語についてはなぜ絶対にだめだと言うのか、面白いですね。 functor 2022-09-22 一種のストックホルム症候群だと思います williameom 2022-09-21 The Spirit of C 1. プログラマーを信頼する。 2. 必要なことを行うのを妨げない。 3. 言語は小さくシンプルに保つ。 4. 操作を行う方法は1つだけ提供する。 5. 移植性が保証されなくても、高速にする。 functor 2022-09-22 個人的には、1番から間違っている気がしますね（笑）。人間は生まれつきミスを起こしやすいので…… heal9179 2022-09-21 C++もスマートポインタやメモリプールを積極的に使えばいいのであって…… 思ったよりポインタを直接扱う場面は多くないと思います。 私は、thread-safeなコードは結局プログラマ本人の能力次第だと思います。 どんな言語を使っても、実力が十分でない場合は、 安全だけれど低性能、あるいは危険なコードといった様相が現れるんですよね。 hiyama 2022-09-23 プログラマーの能力に自動車の運転や飛行機の操縦を任せるなんて、あまりにも怖すぎますよね…… functor 2022-09-22 スレッドセーフなコードは結局のところプログラマー本人の能力次第だ、という考え方 <- 私はこの考えは危険だと思います。というのも、memory / thread safety は単にプログラムが落ちる、遅くなるというレベルの話ではなく、セキュリティ上の脆弱性に発展するため、これを個人の能力に任せるべきではないと考えるからです。 これを事前に防ぐためのさまざまな方法が研究されてきて、それらが成熟して Rust のような言語や他のツールとして生まれたわけですが、これを使わずに個人のせいにするには、ソフトウェアが日常生活に及ぼす影響はあまりにも大きくなったと思います。 mastotron 2022-09-21 人は人である以上、ミスを避けることはできませんし、どれほど優秀なプログラマーでもミスはするものです。メモリバグも結局はミスから生まれるわけですし…… 最近は、自力でうまくやることよりも、そもそもミスをしにくい環境を提供するほうが、よりよいアプローチなのではないかと思うこともあります。 ahwjdekf 2022-09-21 うちの会社でRustを使うなら、unsafeの使用は禁止だ。せめてこういうルールでもないと、言語レベルでサポートされている安全性を一度信じてみよう、とはならないでしょう。 でも、これって筋が通る話でしょうか？ mastotron 2022-09-21 もちろん、Rustを使う企業では、本当に必要な場合でなければ unsafe を使うべきではない、という合意があるはずです。それよりも、まずは実際にRustで書いてみることをおすすめします…… unsafe を使う場面が果たしてどれほどあるのかは、実際に使ってみないと分からないのではないでしょうか？ ahwjdekf 2023-02-15 tokio など有名なライブラリでは unsafe が大量に使われていた novemberoscar 2022-09-21 All or nothingで、Allでなければ何の価値もないとお考えのコメントがかなり多いですね unsafe / safeを明示的に区別・分離でき、メモリバグを100回出す人でも10回に減らせるという利点があるのに、とにかくunsafeがある / それでもメモリバグは発生する => だからC++より優れている点はない、と見るアプローチが現実的な判断なのか、私はよく分かりません 😅 ruinnel 2022-09-22 コメント数だけ見ればそうですが…… 「All or nothing」という意見の一人がコメントをたくさん書いている……というのが実情のようですね。 csjune 2022-09-21 私もこのコメントに同意します。物事を二元論的に見るほど、結局は自分が損をするだけです。 実務の現場では長所と短所を見極めたうえで、結果的に最もプラスになるものを選ぶものです。業界の特性上、今この瞬間はC/C++を使わざるを得ないのでなければ、Rustを使うことで得られる利点が大きいため、Rustが使われる領域は徐々に広がっているのだと思います。 Rustに移っていく人たちも別に愚かだからではなく、Rustを使ってみるとC++より結果的に優れた点があるからこそ、使い続けているのでしょうね（笑） alstjr7375 2022-09-21 Nothing... Everything functor 2022-09-21 Rustが Next C++ だということに同意しない人は、もう今ではほとんどいないでしょう。Linuxカーネルでも正式な言語として採用されたほどです。 ただ、Rustが本当に書きやすい言語なのかについては少し疑問です……。メモリ安全性の問題を未然に防ぐために行われる静的解析のおかげで、コンパイル時間はかなり痛いですし、ownership のようなセマンティクスも難しく、PythonやJavaのような汎用言語よりもはるかに多くの学習を要するからです。 dalinaum 2022-09-21 コンパイル時間は、LLVM自体の問題が大きいのでしょう。FacebookがLLVMのinstruction sel改善に力を入れているので、状況は良くなるはずです。 functor 2022-09-22 調べてみたら、本当にそうですね。私は ownership に関する型チェックに多くの時間がかかるのかと思っていましたが、LLVM バックエンドの比重が大きいですね…… ahwjdekf 2022-09-21 Rustが最初に出てきたとき、かなり興味を持って少し勉強してみたんですが……unsafeの項目を見てすぐにやめました。これをどうして学んで使う必要があるのか、どうしても合理的に納得できなかったんです。どうせ少しでも複雑なプログラムはunsafeを使わないといけないでしょう。だとしたら、Rustがあれほど誇る安全性は失われるわけです。これをなぜ使うんですか？ mastotron 2022-09-21 Rust では unsafe は低レベルなコーディングをするときに必要なだけで、一般的なアプリケーションを書くときにはほとんど使う機会がないと考えて差し支えありません。 そして、unsafe ブロック内でメモリの問題が発生したとしても、問題が発生する箇所は unsafe ブロックの中にあることが言語仕様として保証されているので、デバッグしやすいという利点もあります。 functor 2022-09-21 unsafe があるからといって「なんでこれを使うんですか？」と尋ねるくらいなら、そもそも C/C++ を使うべきではないのでは？ ahwjdekf 2022-09-21 C++も進化し続けていますし、unsafeを使うくらいなら、いっそC++を使えばいいのであって、わざわざRustを学んで使う必要性を感じないのです。 functor 2022-09-21 すべてのRustプログラミングでunsafeが必要なわけではありません。 unsafeが必要になるほど細かなメモリ操作は、通常はライブラリ開発側に切り出されているので、（おそらく最も需要が多いであろう）アプリケーション開発の段階ではunsafeを使う場面はほとんどないと思います。 C++も進化を続けているのは事実ですが、下位互換性のためのレガシーがあまりにも重いですよね。unsafe一つのせいで不満を感じるくらいなら、C++のあらゆる機能にも不満を感じそうですね（笑） alstjr7375 2022-09-21 だから unsafe は推奨されないんですよ。 safe を使えば、すべてが unsafe も同然な C/C++ より安全ですし。 https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf ahwjdekf 2022-09-21 unsafe という曖昧な仕組みがなければ、Rust は C++ の真の代替になり得るのかもしれません jjpark78 2022-09-21 FFI がもう少しだけ親切だったらいいのにと思います…。複合構造体を FFI 経由で外部ライブラリとやり取りしようとしたのですが、とてもつらかった記憶があります。 alstjr7375 2022-09-21 Rust から Rust への移行ですら簡単ではないので.. https://github.com/rodrimati1992/abi_stable_crates jjpark78 2022-09-21 MSがRustを積極的に支援している状況の延長線上で見れば、ごく自然な発言に思えます。 colus001 2022-09-21 あの頑固なトーバルズでさえRustを採用したのに、学ぶ人も減っている言語を、あえて使い続ける必要は感じません。 ahwjdekf 2022-09-21 メモリ関連のバグは、Rustを使ったからといってそう簡単になくなるものではない。バグを作る人間は、どんな言語を与えてもバグを量産する。C++を何の問題もなく効率的にうまく使っているのに、いったい何をなくすというのか。本当に、戦争でも起きそうな爆弾発言を軽々しくしてしまったものだ。 functor 2022-09-21 C/C++ が何の問題もなく効率的にうまく使われていると言うには、すでに歴史的に数多くのメモリ関連バグが C/C++ で発生してきましたし、今もどこかで発生しているはずです。（おかげで多くの PL/SE 研究者が食べていけてはいましたが） マイクロソフトの発表によれば、セキュリティバグの 70% がメモリ関連バグです（https://zdnet.com/article/… Chromium プロジェクトで調査した内容も似ていますが（https://chromium.org/Home/chromium-security/… 70% がメモリ関連バグでした。 jjpark78 2022-09-21 Windowsカーネルのバグの大半はメモリ関連のエラーで、 Rustで開発している部分についてはその手のエラーが劇的に減った、という以前の記事をどこかで見たことがあります。.. 言語の成り立ちそのものがreadonlyを積極的に推奨する設計なので、C++より安全な言語設計であることは否定できないと思います。 ただ、そのせいで聞いたこともない所有権という概念が登場して、プログラミングが難しくなりますが。 非常によく設計されたC++コードより、ざっくり作ったRustコードのほうが統計的にはより速く実行される、という性能上の利点もありますよね. lordang 2022-09-21 かなり炎上しかねない発言をしましたね。笑 個人的には、C++はあまりに古くなったせいで後方互換性に足を引っ張られ、モダンな進化が遅いと思います。 また、後方互換性を徹底しつつモダンなものを取り入れた結果、同じことをする方法があまりにも多くなって、初心者にとってさらに参入障壁になっていると思います。 私も今ではC++よりRustのほうが良いと思います。メモリ管理まわりのバグを見つけるのに目を真っ赤にしていた時代は、もう終わりです。 jjpark78 2022-09-21 そうですね……ゼロベースで始める開発プロジェクトなら、あえて C++ を選ぶ理由はありませんね…… kandk 2022-09-21 激しく共感 loblue 2022-09-22 Rustを使いたくても補助的に使うくらいで、業務ではまだ使う機会がないですね。 だからなかなか慣れないですし、少し手を離すと忘れてしまったりもして…… 確かに良いので使いたい気持ちはあるんですけど……（笑） koreacglee 2022-09-23 ヒープ利用効率のためのメモリプールを一度も書いたことのない連中が、RustだRustだとうるさく騒いでるな、ふん。 Azure CTOが業界標準を代表するほどの意見の持ち主ではないのはもちろん、Microsoftに限ってもマイクロソフトの立場を代弁する意見では決してなく、ただ急に何かに取りつかれて自分の主観的な考えをまくしたてているにすぎないのに……C++をまともにできない連中が、Rustならまともにできるのか？ まったく、口先だけの連中ばかりだな functor 2022-09-26 その話し方からして、下品さが隠しようもなく表れていますね。頑張ってください。
55件のコメント
これまでRustを称賛しながら使っていた人たちも、
asyncに触れると急に現実を思い知らされるとか。しかも、Rustではライブラリを作るなということなのか（あまりにも複雑で、面倒で、難しい）。そんな不満も出ているようですねマーク・ルシノビッチが誰なのかも知らずにけなす人もいるんですね……sysinternals tool suite と書籍
windows internalsの著者です……Windows をリバースエンジニアリングしてツールを作っていたうちに、Microsoft フェローになった人ですよ……Rust狂信者たちの問題点を短い動画で皮肉った投稿
https://twitter.com/cmuratori/status/1367627549816152064?lang=en
Rust には、まだ正式な仕様すらないという……
C++には正式な仕様が"存在"はしていますが、すべての実装（gcc、clang、…）が不完全なんですよね
これはよくある議論ですが、実際に仕様をかなり読み込み、実装も何度も行ってきた立場からすると、仕様があるかないか自体にどれほどの意味があるのかはよく分かりません。
「仕様」にはさまざまな戦略があります。外から見える動作を中心に記述する方法と内部動作を記述する方法があり、自然言語を使うか、機械が読める方法（擬似コードや数学的定義など）を使うかに分かれます。Python や Rust の言語リファレンス文書のようなものは、外から見える動作を自然言語で記述した仕様です。ISO 標準などでよく見られるアプローチは、内部動作を自然言語で記述した仕様ですが、この内部動作が実際の実装のアプローチと一致する保証はありません。その代わり、その内部動作で実装された仮想的な実装と実際の実装が、外から見て同一に動作する、つまり observationally equivalent であれば標準に適合すると定義する形になります。ECMAScript は自然言語で記述されてはいますが、実際の構造は事実上、擬似コードを自然言語で書いたのに近い水準ですし、WebAssembly のように、内部動作を自然言語仕様と数学的定義の両方で提供している例もあります。
実装する側からすると、自然言語の仕様はどれも大差ありません。自然言語の仕様は実際の実装とは別に作られなければならないため、どうしても両者が乖離することがありますし、ミスが生じることも珍しくありません。外から見える動作のほうが実装しやすいか、内部動作のほうが実装しやすいかは状況次第であり、プログラミング言語の観点ではどちらか一方を選ぶべき明確な必然性は特にありません。そういう意味では、Rust にはすでに仕様が存在しており、別の代替実装が登場しうる程度には、その仕様は十分な情報を提供していると言ってよいでしょう。
単に ISO 標準になったかどうかで標準の成熟度を判断したいのであれば、私が ISO/IEC 18181-1 JPEG XL 標準で 100 件ほどのバグを見つけており（そのせいで 2nd amendment が遅れている）、という話をお伝えしておきます...
Hacker Newsでも800件を超えるコメントが付いていましたが……こちらも熱いですね…
https://news.ycombinator.com/item?id=32905885
お疲れさまです。
一方で……ある人が好きな何かが攻撃されたとき、
その人の反応を解釈しようとする際に、その人の性格のせいにすることには注意すべきだ、という文章を見て、良い言葉だと思いました。というのも、実際の状況でそのような心持ちを保つのは難しいことだからでしょう。
ツイートの返信の中に、印象的なものがありました。
People end up writing Rust code the "unsafe way". - 省略 - Rust was never meant to replace those.
このあたりで、Mark Russinovich が誰なのか分かるリンクを貼っておきます。
https://en.m.wikipedia.org/wiki/Mark_Russinovich
もう一言。C++を使いながらしょっちゅうエラーを出してバグを作っていた人たちが、「これもう使えないな、最近話題のRustに行ってみようか……メモリエラーを気にしなくていいらしいし……」となっても、そういう人たちは結局同じです。Rustでも似たようなバグを作るでしょうし……そうしたらまた次はどの言語を学んでやってみようか、という人がたくさん出てくるでしょう。C++でポインタのデリファレンスすらまともにやったことがない人たちが、Rustを持ち上げているんです。
そういう類いの人間は、Rust が強みとして掲げる所有権、reference、borrowing といったものをコンパイル時からエラーになって面倒だとして全部無視して、結局
unsafeを混ぜて C++ みたいに雑に使うだろう、ということです。どうせ死ぬのに、なぜ生きるのですか？
これとほとんど同じレベルの論理ですね
どうせ問題を起こす人はシートベルトも締めず、信号も無視するのだから、シートベルトや信号機には大した意味がないと主張しているのを見るような感覚ですね。
できる人は何をしてもうまくやるし、できない人は何をしてもできない、という主張はできるかもしれませんが、そういう論理でいくと道具の有用性についての議論自体が成り立たなくなります。
言語の難易度が高すぎるのが問題で、もっともな話ではありますね
Visual Rustが出たら認める -.-k
C/C++は、もう本当にラテン語のような位置づけになっていく気がしますね。学問のためなら誰でも学ぶべきですが、極めるのは不可能に近く、古い体系なので、今の基準で見ると不合理な部分も多いですし…
すべてがunsafeな言語は普通に使いながら、限定的にunsafeを使える言語についてはなぜ絶対にだめだと言うのか、面白いですね。
一種のストックホルム症候群だと思います
The Spirit of C
個人的には、1番から間違っている気がしますね（笑）。人間は生まれつきミスを起こしやすいので……
C++もスマートポインタやメモリプールを積極的に使えばいいのであって……
思ったよりポインタを直接扱う場面は多くないと思います。
私は、thread-safeなコードは結局プログラマ本人の能力次第だと思います。
どんな言語を使っても、実力が十分でない場合は、
安全だけれど低性能、あるいは危険なコードといった様相が現れるんですよね。
プログラマーの能力に自動車の運転や飛行機の操縦を任せるなんて、あまりにも怖すぎますよね……
スレッドセーフなコードは結局のところプログラマー本人の能力次第だ、という考え方 <- 私はこの考えは危険だと思います。というのも、memory / thread safety は単にプログラムが落ちる、遅くなるというレベルの話ではなく、セキュリティ上の脆弱性に発展するため、これを個人の能力に任せるべきではないと考えるからです。
これを事前に防ぐためのさまざまな方法が研究されてきて、それらが成熟して Rust のような言語や他のツールとして生まれたわけですが、これを使わずに個人のせいにするには、ソフトウェアが日常生活に及ぼす影響はあまりにも大きくなったと思います。
人は人である以上、ミスを避けることはできませんし、どれほど優秀なプログラマーでもミスはするものです。メモリバグも結局はミスから生まれるわけですし……
最近は、自力でうまくやることよりも、そもそもミスをしにくい環境を提供するほうが、よりよいアプローチなのではないかと思うこともあります。
うちの会社でRustを使うなら、
unsafeの使用は禁止だ。せめてこういうルールでもないと、言語レベルでサポートされている安全性を一度信じてみよう、とはならないでしょう。 でも、これって筋が通る話でしょうか？もちろん、Rustを使う企業では、本当に必要な場合でなければ
unsafeを使うべきではない、という合意があるはずです。それよりも、まずは実際にRustで書いてみることをおすすめします……unsafeを使う場面が果たしてどれほどあるのかは、実際に使ってみないと分からないのではないでしょうか？tokio など有名なライブラリでは
unsafeが大量に使われていたAll or nothingで、Allでなければ何の価値もないとお考えのコメントがかなり多いですね
unsafe / safeを明示的に区別・分離でき、メモリバグを100回出す人でも10回に減らせるという利点があるのに、とにかくunsafeがある / それでもメモリバグは発生する => だからC++より優れている点はない、と見るアプローチが現実的な判断なのか、私はよく分かりません 😅
コメント数だけ見ればそうですが……
「All or nothing」という意見の一人がコメントをたくさん書いている……というのが実情のようですね。
私もこのコメントに同意します。物事を二元論的に見るほど、結局は自分が損をするだけです。
実務の現場では長所と短所を見極めたうえで、結果的に最もプラスになるものを選ぶものです。業界の特性上、今この瞬間はC/C++を使わざるを得ないのでなければ、Rustを使うことで得られる利点が大きいため、Rustが使われる領域は徐々に広がっているのだと思います。
Rustに移っていく人たちも別に愚かだからではなく、Rustを使ってみるとC++より結果的に優れた点があるからこそ、使い続けているのでしょうね（笑）
Nothing... Everything
Rustが Next C++ だということに同意しない人は、もう今ではほとんどいないでしょう。Linuxカーネルでも正式な言語として採用されたほどです。
ただ、Rustが本当に書きやすい言語なのかについては少し疑問です……。メモリ安全性の問題を未然に防ぐために行われる静的解析のおかげで、コンパイル時間はかなり痛いですし、ownership のようなセマンティクスも難しく、PythonやJavaのような汎用言語よりもはるかに多くの学習を要するからです。
コンパイル時間は、LLVM自体の問題が大きいのでしょう。FacebookがLLVMのinstruction sel改善に力を入れているので、状況は良くなるはずです。
調べてみたら、本当にそうですね。私は ownership に関する型チェックに多くの時間がかかるのかと思っていましたが、LLVM バックエンドの比重が大きいですね……
Rustが最初に出てきたとき、かなり興味を持って少し勉強してみたんですが……
unsafeの項目を見てすぐにやめました。これをどうして学んで使う必要があるのか、どうしても合理的に納得できなかったんです。どうせ少しでも複雑なプログラムはunsafeを使わないといけないでしょう。だとしたら、Rustがあれほど誇る安全性は失われるわけです。これをなぜ使うんですか？Rust では
unsafeは低レベルなコーディングをするときに必要なだけで、一般的なアプリケーションを書くときにはほとんど使う機会がないと考えて差し支えありません。そして、
unsafeブロック内でメモリの問題が発生したとしても、問題が発生する箇所はunsafeブロックの中にあることが言語仕様として保証されているので、デバッグしやすいという利点もあります。unsafeがあるからといって「なんでこれを使うんですか？」と尋ねるくらいなら、そもそも C/C++ を使うべきではないのでは？C++も進化し続けていますし、
unsafeを使うくらいなら、いっそC++を使えばいいのであって、わざわざRustを学んで使う必要性を感じないのです。すべてのRustプログラミングで
unsafeが必要なわけではありません。unsafeが必要になるほど細かなメモリ操作は、通常はライブラリ開発側に切り出されているので、（おそらく最も需要が多いであろう）アプリケーション開発の段階ではunsafeを使う場面はほとんどないと思います。C++も進化を続けているのは事実ですが、下位互換性のためのレガシーがあまりにも重いですよね。
unsafe一つのせいで不満を感じるくらいなら、C++のあらゆる機能にも不満を感じそうですね（笑）だから
unsafeは推奨されないんですよ。safeを使えば、すべてがunsafeも同然な C/C++ より安全ですし。https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf
unsafeという曖昧な仕組みがなければ、Rust は C++ の真の代替になり得るのかもしれませんFFI がもう少しだけ親切だったらいいのにと思います…。複合構造体を FFI 経由で外部ライブラリとやり取りしようとしたのですが、とてもつらかった記憶があります。
Rust から Rust への移行ですら簡単ではないので.. https://github.com/rodrimati1992/abi_stable_crates
MSがRustを積極的に支援している状況の延長線上で見れば、ごく自然な発言に思えます。
あの頑固なトーバルズでさえRustを採用したのに、学ぶ人も減っている言語を、あえて使い続ける必要は感じません。
メモリ関連のバグは、Rustを使ったからといってそう簡単になくなるものではない。バグを作る人間は、どんな言語を与えてもバグを量産する。C++を何の問題もなく効率的にうまく使っているのに、いったい何をなくすというのか。本当に、戦争でも起きそうな爆弾発言を軽々しくしてしまったものだ。
C/C++ が何の問題もなく効率的にうまく使われていると言うには、すでに歴史的に数多くのメモリ関連バグが C/C++ で発生してきましたし、今もどこかで発生しているはずです。（おかげで多くの PL/SE 研究者が食べていけてはいましたが）
マイクロソフトの発表によれば、セキュリティバグの 70% がメモリ関連バグです（https://zdnet.com/article/…
Chromium プロジェクトで調査した内容も似ていますが（https://chromium.org/Home/chromium-security/… 70% がメモリ関連バグでした。
Windowsカーネルのバグの大半はメモリ関連のエラーで、
Rustで開発している部分についてはその手のエラーが劇的に減った、という以前の記事をどこかで見たことがあります。..
言語の成り立ちそのものが
readonlyを積極的に推奨する設計なので、C++より安全な言語設計であることは否定できないと思います。 ただ、そのせいで聞いたこともない所有権という概念が登場して、プログラミングが難しくなりますが。非常によく設計されたC++コードより、ざっくり作ったRustコードのほうが統計的にはより速く実行される、という性能上の利点もありますよね.
かなり炎上しかねない発言をしましたね。笑
個人的には、C++はあまりに古くなったせいで後方互換性に足を引っ張られ、モダンな進化が遅いと思います。
また、後方互換性を徹底しつつモダンなものを取り入れた結果、同じことをする方法があまりにも多くなって、初心者にとってさらに参入障壁になっていると思います。
私も今ではC++よりRustのほうが良いと思います。メモリ管理まわりのバグを見つけるのに目を真っ赤にしていた時代は、もう終わりです。
そうですね……ゼロベースで始める開発プロジェクトなら、あえて C++ を選ぶ理由はありませんね……
激しく共感
Rustを使いたくても補助的に使うくらいで、業務ではまだ使う機会がないですね。
だからなかなか慣れないですし、少し手を離すと忘れてしまったりもして……
確かに良いので使いたい気持ちはあるんですけど……（笑）
ヒープ利用効率のためのメモリプールを一度も書いたことのない連中が、RustだRustだとうるさく騒いでるな、ふん。 Azure CTOが業界標準を代表するほどの意見の持ち主ではないのはもちろん、Microsoftに限ってもマイクロソフトの立場を代弁する意見では決してなく、ただ急に何かに取りつかれて自分の主観的な考えをまくしたてているにすぎないのに……C++をまともにできない連中が、Rustならまともにできるのか？ まったく、口先だけの連中ばかりだな
その話し方からして、下品さが隠しようもなく表れていますね。頑張ってください。