Rustでまさかの生産性爆上げ！

君のコードの下に書かれたコードは、早めにreturnしないと実行されちゃうんだよ。あと8時に速報。
真面目な話、値の代入でスクリプトの実行が止まるって、なんでそう思ったの？TypeScriptの例は文脈が足りないのかもしれないけど、それを“データ競合”として提示するのは、なんか変だよ。

exit()とかexecve()とかの関数はすぐに実行を停止するから、リダイレクトもそうだと思う気持ちはわかるよ。

リダイレクトってのは代入なんだよ。どの言語でも、変数への代入で実行が止まったことなんて一度もないはずだろ。

ほら、Pythonの例を見てみろよ。
MagicRedirectクラスで、hrefに値がセットされたら“Redirecting to URL”って表示してexit()するようになってるだろ？
location.href = “https://example.org/”ってやったら、ちゃんとリダイレクトして実行が止まってるじゃんか。
これは代入で実行が止まる例だよ。

君、セッターをオーバーロードしてるだけだろ。可愛いことするね、俺もJavaScriptでやったことあるけど、これは反例にはならないと思うな。
これを普通のことだと考えるのは、元のブログ記事の考え方からしても変だよ。

これって、別に変なことじゃないんだよ。Pythonだとプロパティのセッターで何でもできる、ごく普通の例だよ。そういう設計なんだ。
例えば、Fooクラスのbarプロパティに値をセットしたら“bye”って表示してsys.exit()する例とか、
動的言語を認めないならC#でも同じようにできるじゃん。
これ、多くのプログラミング言語では、別に変わったことじゃないんだよ。

君もセッターをオーバーライドしてるだけだろ。俺は少数派かもしれないけど、これは完全に特殊なケースだよ。
代入演算子は副作用を持つべきじゃないし、論理学者としての俺の意見だけど、x = 5ってやったときに変なことが起こるかもしれないって意識しなきゃいけないなんて、根本的におかしいだろ。

君は“変数代入で実行が止まらない”から“代入演算子は副作用を持つべきじゃない”に主張を変えたね。
location.hrefは反例だし、他のツールや言語、ライブラリにもそういう例はたくさんあるんだよ。
理想と現実、実際にどう動くかを理解することが重要だね。
（悪い慣習だけど、現実に起こるし、作業環境をコントロールできない人もいる。）
location.hrefに副作用があるなら、それが即座に起こると考えるのは不合理じゃないよ。
そういうのが嫌なら、記事が言うように、そんなことが起こらない言語を選べばいいって話だね。

“どの言語でも変数代入で実行が止まったことなんてない”って君は言ってたけど、皮肉なことに、俺はまだ技術的には正しいんだよ。
C++、C#、Python、JavaScriptのどの例も、ゲッターとセッターを悪用したオブジェクトのプロパティへの代入であって、変数への代入じゃないからね（未定義動作の例は別だけど）。

window.location.hrefへの代入でブラウザが遷移するなんて、JavaScriptの実行が止まると思っちゃうよね。プログラミングでは仕様確認が基本だけど、この挙動は確かに変だから、勘違いするのも無理ないって話。

C言語で*(int*)0 = 0;ってやってみてよ。最近のCコンパイラはUBに対して変な挙動をするけど、昔はSIGSEGVでプログラムがちゃんと止まってたんだ。

セッターからの副作用は意外じゃないけど、ゲッターからの副作用は絶対ダメだよ。Rustってミュータビリティを強制するから、そういう期待をちゃんと扱える点でマジで便利だよね。

議論はプロパティ代入についてだよ。誰も指摘しなかったんだから、それが当たり前でしょ。今さら話をすり替えようとするなんて、正直言ってバカバカしいよ。

IBMのシステムではね、アドレス0が書き込み可能で常にゼロにマップされてたんだ。だからロードとストアの投機的実行も心配なしにできてたんだって。

C++ならoperator=をexit()呼ぶようにオーバーロードすれば、「プログラムが止まる変数代入」ってやつを実現できるぜ。

議論は=が変なことをするって話だよね。俺が言いたいのは、オーバーロードとか変なことしない限り、=って普通は変なことしないってこと。反論は全部非標準的な例ばっかりじゃん。だから=にデフォで変な副作用があるなんて思うのは絶対ありえないよ。

ソフトウェア開発って、知らないうちにたくさんの仮定をしてるんだよね。正しいのもあるけど、危険なのもあって、見極めるのがマジで難しい。hrefの件もAPIが誤解を生む余地があるから、たくさんの人がやっちゃうミスだろ。良いソフトウェア設計は、間違った使い方をしにくくすること。強い型とか、副作用がない純粋関数とか、デフォルト不変性とかがその基礎になるんだよ。

昔の組み込みシステムでは、0番地って普通にアクセスするアドレスだったんだよ。だから、一部のコードではNULLポインタアクセスが必要だったし、NULLにジャンプしてシステムをリセットするのも結構普通だったんだ。

Rustはミュータビリティだけを気にするんだよ。核ミサイルを発射したり、ハードディスクをフォーマットしたりするかまでは追跡しないからね。

OPはリダイレクトが同期処理だと思ってたみたいだけど、スクリプトの実行が止まるとは思ってなかったんだろうね。

うん、そうだね。どの言語でも普通そうは期待しないよ。Rustはミュータビリティと所有権の安全策を提供してくれるけど、それをどう使うかは君次第。非ミュータブルな関数呼んだ後でも、Rustで無理やり変更することもできるしね。紙ストローで人を殺すみたいなもんさ。

JavaScriptを15年使ってる俺でも、そういう挙動だと思ってたよ。

違うよ、君は間違ってる。親コメントの他のやつ読んでみてよ。もし同期だったら、POSIX exec()みたいにスクリプトは止まってたはず。OPがスクリプトが止まらないと思ってなかったなら、なんで彼は実行すべきじゃないコードに処理を続行させたんだ？彼はそれを止めるように直したのにさ。

それってそんなに明確じゃない気がするな。プログラム全体を終了させるだけのexitを呼ぶセッターも作れるわけだし。

だからね、intやboolみたいなプリミティブ型以外だと、代入でメモリ割り当てとかが必要になる場合があるんだ。そうなると、メモリ不足エラーでプログラムが落ちるとか、ヤバいことが起こる可能性もある。c++のunique_ptrとか見ると、代入が裏でいろんなことやってプロパティを保ってるよね。Rustとか他の言語も、保証のために特定の型で似たことするはずだよ。

代入演算子をオーバーロードして関数呼ぶようにして、それを使うのを「本当の代入」とは考えないかな。

正直、hrefの件は妥当な仮定だと思うな。APIデザインは残念だけど、あのAPIならスクリプトもそこで止まるって考えるのが自然だよね。俺はこういうのは常に防御的に書くタイプなんだ。location.hrefの正確な挙動は今日まで自信なかったけど、昔書いたコードがちゃんと処理されてたのは、return文を最初から入れてたからだよ。こういう防御的コーディングはヘイゼンバグを防ぐし、技術的に不要でも可読性を上げる良いスタイルだと思う。

不変性を保つための代入演算子のオーバーロードは分かるけど、このケースは組み込みc++出身の俺には実行が変に感じるな。演算子オーバーロードは好きじゃないし避けるべきだと考えてるよ。もうc++は使ってなくて、数年前からRust一筋さ。

昔は逆の挙動だったって確信してるよ。そうでなくても、最近何か変わって、”後で発生する”挙動がブラウザで増えたんじゃないかな。

JavaScriptのページ遷移って”noreturn”関数みたいに動作するべきだけど、そうじゃないんだよな。これ、すごく間違いやすいミスだよね。

ほら、上の方で前提について話してたでしょ？これのことだよ: https://man7.org/linux/man-pages/man3/atexit.3.html

多くのメリットって、静的型付けでコンパイルされる言語だからだよね？Java、Go、C++とかさ。TypeScriptはJavaScriptにコンパイルされるからちょっとややこしいけど、それでも問題ない。Rustはもっと厳密な型システムで追加のコンパイル時チェックがあるけど、タダじゃないし、学ぶのも読むのも大変だよね。

大体はそうだけど、Rustは型システムに所有権、排他的アクセス、スレッドセーフティ、sum typesとか、もっと多くの要素を追加してるんだ。所有権と借用のおかげで、データがどこでどう使われるか明確になるから、大規模なプログラムや外部ライブラリを使う時にめちゃくちゃ役立つよ。Go言語と比較すると、Rustのスレッドセーフティはデータ競合をコンパイル時に捉えられるから、デバッグがめちゃくちゃ楽になるんだ。

借用でイラつくのは、俺のデフォルトのやり方だと、できるだけ変数を変更しないようにしてるのに、Rustだと他の手続きに渡した後も使いたい場合、コピーやクローンを強制されることなんだ。これって、精神的にも構文的にもオーバーヘッドが大きいんだよな。FP言語だと、値を渡すだけで変更しない前提だから、そういう追加の手間は要らないし。要するに、変数を変更しないなら所有権なんて必要ないんだよ。変更する時だけ所有権の概念があればいいのに、変更しない時もずっと気にしてコードに持ち歩くのは嫌だね。

もし君が全ての静的型付け言語を一緒くたにしてるなら、union型（Rustのenumやsum type）と網羅的なパターンマッチングの真の価値をまだ理解してないのかもしれないな。「union-pilled」って呼んでるんだけど、これに慣れると他の静的型付け言語を受け入れられなくなるくらいすごいんだ。

君、Rustを実際に知らないんじゃない？Rustは非所有の借用も所有権も型システムで直接表現できるよ。
変更しない非所有の借用でクローン/コピー不要なのは fn foo(v: &SomeValue)
所有権の移動でクローン/コピー不要、変更なしは fn foo(v: SomeValue)
所有権の移動でfooが変更可能は fn foo(mut v: SomeValue)
Rustは君が求めてる表現力を全部サポートしてるはずだよ。もし同じ値の所有権を2つ持ちたいなら、定義上クローンするしかないけどね。システムエンジニアリング言語としてのトレードオフだよ。

enumsとmatch expressions、それにtagged unionsがRustの秘密のソースなんだよ。

このコードスニペットみたいに？（型定義とtokenizerのコードスニペット省略）ヒント、これRustじゃないからね。

Rustの秘密は、a) 70年代後半の重要な言語機能（Algol ’52になくて人気の言語系譜に欠けてたもの）と、b) C言語より速いベンチマークみたいな「パーティートリック」の両方を提供してることだよ。人々はb)で採用し始めて、a)のおかげでプログラミングが苦じゃないって感じ。ML系の言語がRust以前に普及しなかったのはプログラミング文化の残念な点だけど、Rustも採用されないよりはマシだよね。

値渡し（参照じゃない）だと値を借用しなきゃいけないから、呼び出し元で後から使えなくなる経験があるんだけど。参照渡しはまた別で、そっちだと使うのに構文的な手間がかかるんだよね。具体的な例を教えてくれない？

「値渡しで借用が必要」って、用語がごっちゃになってるね。借用は参照のときだけだよ。Copyできない値を渡すときはムーブなんだ。一般的に、Copyできないものは非mut参照で渡すのがベスト。そうすれば呼び出し元も後で使えるし、Rustの型システムとも相性いいんだ。全部cloneするんじゃなくて、Copyをderiveするか、参照を使おう。

ってことは、CopyやCloneがないと値渡しできないって認識で合ってる？他の言語みたいに、値渡ししても呼び出し元で使えるようにしたいんだけど。参照渡しだと構文が面倒だしね。Rustはミュータブルな値の場合だけ、呼び出し元で使えるか心配してくれればいいのに。SerdeのStructでStringが入ってるとCopyをderiveできないこと、よくあるよね。

70年代後半の言語機能って話だけど、線形型は89年まで研究されてないよ。Rustがメモリ安全を保証できるのは、GCなしで線形型に頼ってるからだしね。ML系言語がRustほど流行らなかったのは、「CPUやメモリの使用量、メモリ局所性が推論しにくい」って正当な理由があるんだ。GCが必要なのも一因だよ。

ModernMechも言ってたけど、RustのメリットはSum Typesとパターンマッチングがほとんどだよ。「ML系言語はCPUやメモリの使い方を推論しにくい」って言うけど、それってRustが使われるほとんどのケースでは、そこまで重要じゃないんだよね。

「RustのメリットはSum Typesとパターンマッチングのおかげ」って意見には疑問だな。Scala、OCaml、Haskellとか、同じ機能を持つ言語はたくさんあったけど、Rustみたいに人気にならなかったでしょ。Rustがこれだけ人気なのは、他の言語にはない独自の能力があるからだと思うよ。

「FP言語では値を渡す」って言ってたけど、それってRustでいうムーブのこと？参照渡しじゃないんだよね？

みんな、エフェクトシステムと型システムを区別するといいよ。エラーハンドリングとか所有権とかは、値の使い方に関わるからエフェクトとして捉えた方がわかりやすい。Javaは参照型メインだけど、それも別のエラーを生む。Swiftは排他性とか安全面でRustと良い勝負だし、所有権も追いついてるよ。あと、Rustのtraitとマクロはプログラマが制約を定義できるからすごいんだ。これで標準ライブラリも小さくなるしね。

そうそう、Rustだとそれはムーブって呼ばれるよ。ムーブすると、呼び出し元ではもうその値を使えなくなるんだ。でも、呼び出し先で値を変更しないなら、呼び出し後もその値を使いたいんだよね。Rustが、変更がない場合は値を自由に使えるようにしてくれたらいいんだけどな。変更があるならエラーでOKだよ。

Scala、OCaml、Haskellは関数型ファーストだけど、Rustがすごかったのは、それらの機能を命令型コアとうまく融合させたことだよ。これだけじゃ成功は無理で、企業のサポートや素晴らしいコミュニティ、そして運も必要だったんだ。Haskellは学術向けだし、OCamlは企業支援がなかった。ScalaはJavaのついでって感じだったから、Rustみたいに人気が出なかったのも納得だね。

ScalaはFPとOOPが混じった言語だね。モナドとかをガチでやるFP派もいれば、Li Haoyiのライブラリみたいにバランス重視の人も同じくらいいるんだ。Scalaは確かにニッチだけど、そういう立ち位置なんだろうね。

Swiftの型システムはRustと比べると使いやすさで劣るね。型チェッカーがタイムアウトして「リファクタリングしろ」って言ってくるのは、ジョークとしか思えないよ。よく平気な顔してリリースできたもんだよね。

俺も同じ不満だね。できないわけじゃないけど、代入するときはデフォルトでコピーかムーブになってほしいんだ。C++のSTLを使うときみたいな感じがいいな。

値への参照（つまり&T）を渡せばいいんじゃない？所有権が絶対必要なら、関数が所有値を返すか、Rc＜T＞みたいな共有所有権を使えばいいよ。GC付きの関数型言語だと、だいたい後者と同じことしてるね。

できるとは思うけど、そうするとすべてのプロシージャの引数に&を付けなきゃいけないし、プロシージャ内で参照を扱う構文にも対応しないといけないんだよね。

コピーできない型は、パフォーマンスの問題があるからコピーできないんだ（C++で巨大なベクターをコピーするみたいにね）。でもRustは代入で常にムーブがデフォルトだから、君の不満が分からないな。型がCopyを実装してれば、所有権が競合するときはRustが自動でコピーするよ。

Scalaの主な問題は、null値で実行時エラーが出る可能性があることだね。だからRustやHaskell、OCamlがパターンマッチングでくれるような実行時の安全性保証はないんだ。例えば、このScalaコードは実行時パニックになるよ: https://scastie.scala-lang.org/fnquHxAcThGn7Z8zistthw 。これはRustではコンパイルされない。ScalaはJVMでJavaを書かずにコードを書けるのが利点かな。

CopyもCloneもできない値を渡すことはできるけど、呼び出し先にムーブされて呼び出し元では使えなくなるよ。大きな型での値渡しはコストが高いんだ。他の言語は常に参照渡しで、君はそれを値渡しと混同してるみたいだね。Rustは君の望むようにはできないよ。関数の型チェックには、その関数のコードと他の型定義だけが必要で、内容は関係ないんだ。これはコードを読みやすくする良いルールだよ。

すべての静的型システムが同じくらい表現力豊かで安全とは限らないよ。JavaはObjectと実行時キャストに頼りがちだし、Goにはenumがない。C++のバリアントは後から追加されたから、使うときに落とし穴や使いにくさがあるんだ（安全アクセスにはtry/exceptが必要で、他の制御構造とは一緒に使えないんだ）。