Matt GodboltがC++を見せてくれたらRustに心変わりした理由

これ全部、PL設計コミュニティでは何十年も前から知られてるんだよ。ソフトウェアエンジニアリングの安全に関してイライラするのは2つ。1.「”実務家”」が「”理論家”」（プログラミング言語のPhD持ち）に対して持つ傲慢さ。2. よくテストされて研究された言語概念（Haskellの型クラス、つまりRustのtraitのことね）の導入の遅さ。
Rustが良い概念を選んで、独自の”実用的な”解決策を発明せずにうまくまとめ上げてるのはいいと思う。だって、それは「”実務家”」が「”理論的すぎる”」って見なすような一部のユースケースでひどく壊れちゃうんだから。

Rustはかなりうまい中間点を選んだと思う。Cみたいにヤバいunsafeじゃないし、メモリ安全性みたいな問題セットを取り除くことを選んだ。
一方で、Rustは理論的な最高点には行かなかった。それ以外はあまり保証してないし、人間の助け（unsafeブロック）にもちょっと頼ってる。

確かに、でも他の面でも実用的だよ。ADTは取り入れてるけど、関数curryingはそうじゃない、とかね。

curryingは大したことないと思うな、ただのシンタックスシュガーで、読みやすくなるかどうかわからない。ADTやclosuresみたいに重要なコアコンセプトじゃないしね。{ foo(%1, bar) }みたいな記法があったらいいな、それは |x| { foo(x, bar) }の代わりになるんだけど。
こんなのある言語知らないけど！

実務家が50年以上も提供されてるものを受け入れてないなら、それは良くないものってことだよ。
そういえばRustも「”理論的すぎる”」概念で苦労してるね。コミュニティが実務家に「概念は実際簡単で分かりやすい」ってガスライトしようとしてるけど、せいぜいちょっと成功してるくらいかな。

この手のC++に関する議論でよく、C++の問題の多くがC++が存在する前から知られてたって事実が抜け落ちてるのが変だよな。
いくつかの特定の分野を除けば、新しいプロジェクトでC++を使う理由は全くないし、正直言って今までもなかった。
もし何かの理由でRustが無理なら（俺もそういう一人だけど）、C++やCの落とし穴がない他の選択肢はたくさんあるぜ。

embedded programmingをやってるなら別だけどね…

embeddedは特定の分野の一つだと思う。
クライアントがプラットフォームに使ってるコンパイラをターゲットにするから、そこに選択肢はほとんどないんだよ。

Rustにcurryingがないの、ちょいちょい気になるんだよね。コンパイル時にできるはずなのに、なんでサポートしてないんだろ？たぶんvariadic genericsとかないとキレイにできないのかなー？

Mathematicaにはこれあるよ。具体例も載せてくれてるね。リンクで詳しい話も見れるよ。

うんうん、この記事はC++のダメなところを示す良い例だけど、Rustが特別すげーって例としてはそこまでかな。他の言語でも普通にできることだし。まあでもRustもちゃんとできる言語でよかったわ！

個人的にはcurryingってむしろヤバイ機能だと思うなー（きっと君もそう思うでしょ？）。JSでさ、あるファイルで引数一つ渡して、別のファイルで次の引数渡す、みたいなの見たことあるんだよ。マジひどかった。Scalaのimplicitsとかと並んで、マジで嫌いな機能。だいたいこういうのって変に使われるんだよね。

「専門家が50年以上採用しないならダメ」って意見、専門家の意見は信用しないな。JSとかPHPを選んできた彼らみたいに、人気なものを選ぶだけだよ。実用的だけど、本当に良いものが人気なくて無視され続ける可能性は全然あると思うんだ。

”50年以上採用されないならダメ”ってのは、C++の機能の人気とは全然関係ないと思うね。C++が良いのはエコシステム投資のおかげで、デザインじゃない。理想はF#とかC#。大事なのは”理論的すぎる”よりa)よく使うパターン、b)それを言語デザインでどう実装か。GoF本もC++だと言語機能になってないものに名前つけただけだし。

「Cにトランスパイルする」って場合さ、コードの特定の場所でパフォーマンスがボトルネックになった時って、どうやって最適化するの？

あの & はね、postfix演算子で、式を匿名関数に変えるんだよ。「Pure Functions」ってドキュメント見るといいよ。リンクも貼ってくれてるね。

これはRustに限った話じゃないけど、言語設計者がcurryingをわざと実装しない理由の一つは、関数呼び出し元がちょっと読みにくくなるからだよ。呼び出しの戻り値の型を理解するには、その関数が引数をいくつ取るかあらかじめ知ってる必要があるんだ。

Clojureにもこれあるよ
user=＞ (#(println %1 %2) ”Hello ” ”Clojure”)
Hello Clojure

K言語だと引数はデフォルトでx y zって名前になるから、こう書くだけだよ: { foo[x, bar] }

swiftにもこれあるよ { foo($0, bar) }

それがなんで違いになるのか分かんない。
生成されたCコードは、この場合ただのビルド成果物でしょ。コンパイラが内部でよく使うIRsみたいなもんだよ。Cで書かれたコードのホットスポットを最適化するときに、例えばgccのIRsを考えたりしないよね？Cのソースコードと生成されたasmコードを見るだけじゃん。もしZigがCにトランスパイルできるなら（-ofmt=cでできるけど）、同じようにZigのソースコードと生成されたasmコードを見るでしょ。

Rustでも関数をcurryできるよ。ただ構文糖衣がないから手動でやる必要があるんだ。でもそれは良いことだと思う。curryされた関数は引数を一つ取ってクロージャを返す関数で、それが連鎖する形になる。このクロージャの連鎖でのownershipとborrowingの扱いはややこしくなりやすいから、明示的にするのが大事なんだろうね。同じタスクならstructで引数をまとめて持ち運ぶ方が簡単な場合もあるよ。

Curryingはただの構文糖衣で、最初の引数をバインドして残りをそのまま渡すラムダみたいなもんだよ。同じくらいの簡潔さは別の方法でも達成できるんだ。例えば”pipeline”オペレーターとかね。そっちの方が可読性もあって拡張性も高い構文だよ。例: https://docs.rs/piping/latest/piping/

Elixirにもこれあるよ。近いやつね: &foo(&1, bar)

curryingは重要な概念で、構文糖衣なんかじゃないと思うよ。関数が引数を一つだけ取るってことだからね。OCamlみたいにfoo bar bazが(foo bar) bazと同じになるのがそれ。他の言語はエミュレートしてるだけかも。
君が探してる言語はきっとあるはずだけど名前忘れちゃったんだ。
OCamlにはpa_holesっていう構文拡張があって
(\ foo \1 bar)
これが
fun x -＞ foo x bar
になったんだよ。これはきっと他の言語に影響されたんだろうね。今はppxに置き換わってて、こんな拡張はもうできないかも。

俺も同じこと思ったわ〜。Mattの例で必要だったのって強い型付けじゃん？それC言語ファミリー以外の世界にはずーっと昔からあったのにね。

C++にもこれに似たのあるにはあるけど[1]、正直使わない方がいいやつね。
for_each(a.begin(), a.end(), std::cout ＜＜ _1 ＜＜ ’ ’);
あと、Scalaにもこういうのが第一級機能としてあるよ[2]。
[1]: https://www.boost.org/doc/libs/1_88_0/doc/html/lambda.html
[2]: https://scala-lang.org/files/archive/spec/3.4/06-expressions…

こういう記事読むの好きだけど、C++何十万行も書いた経験から言うと、意図しない型変換で困ることマジでない。たまにあっても一回実行で気づくし、ラッパー型使う手間と比べたら些細。ラッパー型はノイズ多いしメリット薄い。
Rustのborrow checkerも同じ。C++でもスマートポインターでメモリバグなんて稀だし、ロジックやアルゴリズムのバグが圧倒的に多い。些細な問題のためにコーディング変えたくないわ。Rustのborrow checkerない版欲しい。
俺のコード（数学アルゴリズム系）のせいかな？いや違うと思う。この意見が普通じゃないのが不思議。

＞ 意図しない型変換で困らない
C++erの95%が言うけど、C++のバグは大抵これ系の簡単なやつ。複雑なアルゴリズムならミスしても気づかないかもよ。
＞ ラッパー型はノイズ
俺はラッパー型は可読性のメリットだと思うね。何してるか分かりやすいし、プロトタイプで把握できる。
＞ メモリバグよりロジックバグが多い
みんな言うけど、研究（セキュリティバグ）だと逆。一番多いのはnullポインター、配列外参照、二重解放みたいな簡単なやつ。

これってソフト開発の社会学だよね。この業界にはマジで標準とか確立されたプラクティスがない。本か他社の真似くらい。質より速さな上層部の気まぐれに振り回されてる。
高品質なソフト書いても金になんないし、プロジェクトは品質を阻害することばかり。Rustみたいな言語は、それを技術で何とかしようっていう必死の試みなんだ。
ある意味成功してるんだろうけど、こういう記事見ると、ほとんどのプログラマーがいかにダメか、そもそもなんでRustみたいな「応急処置」が必要だったのかよく分かる。

そうかもね。でも、もっと良い言語とかリンターとか、他のツール改善を馬鹿にするのは違うと思うな。これらってすごく低コストで系統的に品質上げてくれるんだよ。業界全体がもっと積極的に良いツールや技術を取り入れようとしないのが信じられない。

業界全体はそうしてるけど、C++のエコシステムがそうじゃないだけ。

それは違うと思うな。C++はいろいろ古いし大変なこと多いけど、みんな無理のある制約の中でベストを尽くしてるんだよ。sanitizersとかclang-tidyみたいなのとか、コンパイラの解析機能の向上とか、かなり好評みたいだし。

これな。業界は直感やその場しのぎとエンジニアリングがごちゃ混ぜ。当たり外れ。
表向きは高品質って言うけど裏では速く作って壊す、アートだとか。VCが「vibe coding」とか。ソフト開発は一番バラつきが大きい分野で、会社によっては「ノリ」でやってる。
どうなるか興味深い。Quebec Bridgeみたいな事故起きる？Crowdstrikeの事故でもまだ足りない。分散型取引所のハックも同じ。
どこ向かってるか分からん。たぶん、「vibe coding」のせいで大事故起きて、VC責任問われて、規制始まるのを待ってる。

ソフト開発者は違うけど、Software Engineeringは違うよ。多くの国では専門的な称号だし、大学とかエンジニアはちゃんと認められないと法律的にその称号使えないんだから。

こういうのってあんまり関係ないと思うんだよね。大事なのは技術じゃなくてプロセスだよ。資格持ってる人でもヤバいコード書くの見まくったし、独学でもめっちゃ考えてシンプルに解く人も見たことある。特に傾向も感じないな。あ、でもPhDsだけは別。コードうまいPhDなんて一人しか知らないわ。

PhDがコード下手ってのは、チームで毎日長時間コーディングしてないからじゃない？PhDってのが原因じゃなくて、単にコーダーじゃないからだよ。（趣味でめっちゃコード書いてるPhDsは上手いかもね）。蛇に噛まれた時の手当を知らなくても医療のPhDは取れるみたいなもん。

今やってるプロジェクトは15年以上かかった巨大なC++の物理シミュレーションなんだけど、一番多くて診断が難しいバグは単位変換のミスだね。具体的なデータと比較してなかったら、多分見つけられもしなかったと思う。

C++には単位を扱うライブラリがいくつかあるよ。コンパイル時に型チェックするのはテンプレートを使えばできるし、constexprならもっと良い感じにできる。問題なのは、それぞれのライブラリが独自のルール持ってて、お互いに連携できないことだね。

僕もそういう単位型ライブラリを自分で作ったことあるんだけど、結局ダメだったんだ。表示する時に、何千もある型それぞれに違うAPI書くの、誰もやりたがらなくてさ。今のシステムは実行時に型が一つだけあって、コンストラクタで単位系を指定する形。でも、メートルとガロン足しちゃうと実行時エラーになるけどね。

えっと…なんで違うAPIが必要なの？UIに値を渡す直前に単位なしに変換すればよくない？それか、UIライブラリをパラメータ化して、どんな単位でも勝手に表示できるようにするとか。テンプレートから単位の文字列とか引っ張ってきて、例えばkg＜float＞の値をラベルにバインドしたら勝手に”42 kg”って表示するとかさ。

単位なしに変換しちゃうと、強い型のメリットが全部消えちゃうんだよね。それはトレードオフとして受け入れるかって話。あと、簡単に単位なしに変換できるってことは、本来単位が必要なところで単位なしを使っちゃいやすくなるってデメリットもあるんだ。単位システムの実装って色々あって、うちのプロジェクトだけでも3回失敗したんだよ。NDAで言えない理由もあるけど、これがうちにとっては一番の妥協点なんだ。君の問題は違うだろうから、自分で解決策見つけなきゃね。簡単な問題なら既存のでいいけど、複雑なら何が本当に欲しいのか考えないと。

他の要件があるのは分かるよ。ただ、元々言ってた表示の件は、単位が型システムにちゃんと反映されてても難しくないと思うんだけど。単位なしに変換すると型のメリット失うって言うけど、表示する直前にやれば問題なくない？数値もテキストにする時に変換するし、同じことだよ。MVVMなアプリなら、モデルとビューモデルの間とかね。そもそも単位付きシステムって、単位なしの値を取り出す機能が元々あるでしょ。同じ単位の1で割ればいいんだよ。F#だとこう書けるし。
let v = 10＜m/s＞ // m/s
let n = v / 1＜m/s＞ // 単位なし

＞ コードを一度実行しただけで気づく
そんなこと絶対ないって断言するわ。君はそういうミスしなかったのかもしれないけど、もししてたら絶対気づかずに済んだ時もあったはず。自分のコードとか他のプロジェクトで、そういう問題何回も見つけたもん。CONSTが0だから大丈夫だったfunc(0, CONST)が、誰かがCONSTを1に変えたらクラッシュするとかさ。Last Line Effectみたいな問題は、何年も気づかれないことだってあるんだよ。

友達がstdのコンストラクタ（多分stringで、charとintの引数を間違えるやつ）の引数ミスにみんなよく気づくって言ってたんだ。Googleのコードベースで探したら、そういう事例がめっちゃたくさん（数忘れたけど）見つかって、その多くがマジのバグだって確認できたらしい。そいつは修正に何か月もかけて、最後はチェック追加したと思う。だから、これは机上の空論じゃないよ。君だってこのミスしてるのに気づいてない可能性すらあるって。

その心配はわかるけど、clang-queryやclang-tidyでツール活用するのは難しくないし、コストも高くないよ。
一番の問題は、多くのC++エンジニアがツールを使わないこと。ツールに対して学習性無力感があるみたい。Rustは今、みんなのためにツールを整備するコアエンジニアがいるようだ。言語設計はさておき、この堅実なエンジニアリングを続けられるなら、すごく強いと思うね。

”トリッキーなアルゴリズムコード”での借用は簡単だよ。難しいのはライブラリを書く時。RustはC++にはない方法でAPIにそれをエンコードさせる。
”ちょっと考えればメモリエラーはほとんどない”って言うけど、借用チェッカーで苦労するなら、他人や将来の自分に強制できない制約に依存してるから。例えばC++のオブジェクトはデフォルトでスレッド安全じゃない。正しく効率的にしか使えないようには設計できないんだ。

この記事内容は経験あるC++プログラマなら当然なのに、多くのプログラマはそうじゃない。普通の会社は品質を下げて利益を出すから、Rustみたいなツールが必要になるんだ。
残念ながらRustはまだ平均的なプログラマには難しすぎるけど、間違いは厳しく指摘してくれる。関数型/メタプログラミング好きが集まる一方で、”みんなの言語”であることと矛盾してるよ。
仕事の少なさも問題だけど、まるで拘束具を着けてるみたいで、＜activity＞と同じくらい楽しいって懸念もあるね。

ScalaやKotlinであったように、Rustは職場で使うのを許されたHaskellなんだよ。そうやってああいうライブラリが生まれるんだ。

僕も同じ意見だよ：
＞Rustはまだ平均的なプログラマには難しすぎる
平均的なプログラマをRustに”オンボーディング”する一番いい方法は何だろう？複雑な構文を避けても生産的になれるのかな？それとも、”平均的なC++プログラマ”をクビにして超優秀なRustプログラマに置き換える必要があるのかな？

＞自分が遭遇する最も重要でない問題の一つを直すために、なぜコーディング方法を完全に変えたいと思うのか？
僕も同じ気持ちだよ。Rustには確かに良い特性や機能がたくさんあるけど、借用チェッカーが僕にとってはものすごく嫌なんだ。

FAANGとかでC++を大量に書いてて、もうC++が大嫌いだったんだ。
今後、本当の修正が出てくるか気になるね。このCppConのトーク：”To Int or to Uint, This is the Question - Alex Dathskovsky - CppCon 2024” https://www.youtube.com/watch?v=pnaZ0x9Mmm0 を聞くとC++は壊れてるみたい。1000個もルール覚えて一つ間違えたら危険、みたいなC++は嫌だ。意図的にオプトインしないとルール破れないC++がいい。
別のC++トークでRustクレートの約60％がunsafe Rustに依存してるって話があった。Rust批判じゃなく、unsafeにオプトインする安全なC++はRustのunsafeに似る可能性。

＞別のC++トークによると、Rustクレートの約60％がunsafe Rustに依存してるらしいよ。
それはちょっと違う話の出典かも。Rust FoundationのPainterという分析ツールによるとね。[０]：
＞2024年5月現在、約12.7万クレート中、unsafeを使うのは19.11％。直接unsafeクレートを呼ぶのは34.35％。そのほとんどはCやC++コードへの呼び出しだよ。
正直、stdlibとか含めたら60％はもっと高いかと思ってた。ハードウェアもunsafeだから、全てのRustコードはどこかでunsafeに依存してるって話もあるけどね。
[０]：https://github.com/rustfoundation/painter
[１]：https://rustfoundation.org/media/unsafe-rust-in-the-wild-not…

メモリ割り当てはunsafeだから、stdlibのどんなコンテナもどこかでunsafeを使うことになるよ。でもこれはsafe Rustがunsafeなしで役に立たないって意味じゃない－Rustの有用性は、unsafeな構造体の周りに安全なインターフェースを作れることなんだ。

そうだね、全く同感だよ。引用した統計と違って、60％って数字が何を包含してるのか（例えば依存チェーンのどのくらい下まで見てるかとか）具体性がなかったから、ちょっと混乱してたんだと思う。