Rust part33

**デフォルトの名無しさん** · 2025/08/15(金) 17:49:30.70

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part32
https://mevius.5ch.net/test/read.cgi/tech/1755057787/
Rust part31 https://mevius.5ch.net/test/read.cgi/tech/1751545806/
Rust part30 https://mevius.5ch.net/test/read.cgi/tech/1748392296/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2025/11/24(月) 10:45:36.91

>>882
なんのために制約キツくてコーティング面倒臭いRustを使っているのか、という話だわな。

Rustを採用するマネジメント層からすれば、トラブルの無い安定運用がRustに期待するところであって、Cloudflareみたいなサービス停止トラブルはあってはならない悪夢でしかない。その原因が無能コーダーが不用意に突っ込んだunwrapなんだから、管理側が「SafeRustではpanic禁止にしたい」と考えるのは当然じゃないんかね。

**デフォルトの名無しさん** · 2025/11/24(月) 10:54:15.58

>>881
>「panicは最小限度にしろ」「panicが発生するコードは全て明記して管理しろ」「管理できなければpanicさせるな」
クリティカルなサービスなら当然の要求な気がする
障害につながらない仕組みが用意されてるpanicと即障害になるpanicは扱いが違うだろうけど管理は必要
ポストモータムにある対策の4番目に該当する

>>882
最大限の努力をしないと無効な入力値が渡されただけでサービス全体が停止するシステムを作ってしまうようなら無能と言われても仕方ない

**デフォルトの名無しさん** · 2025/11/24(月) 11:23:49.40

>>883
ファイル名と配置のルールが変わっただけだぞ
エディタのクイックオープン機能なんかで同名ファイルが大量に並ぶのは見づらいというしょーもない理由

**デフォルトの名無しさん** · 2025/11/24(月) 12:50:03.58

>>883
非推奨化はしてないと思うが
インテグレーションテストから共有されるモジュールなんかは mod.rs 方式しか使えなかったりするし

**デフォルトの名無しさん** · 2025/11/24(月) 12:51:36.71

Rustが保証するのはメモリ安全であって、それ以上の機能を言語自体に期待してはいけないね

**デフォルトの名無しさん** · 2025/11/24(月) 13:52:56.65

3年かけて数多のスレを潰してようやく分かったか？

**デフォルトの名無しさん** · 2025/11/24(月) 15:25:42.29

今後Rustは使用必須のスタートラインに過ぎないからな

**デフォルトの名無しさん** · 2025/11/24(月) 17:08:28.30

Rustの次の言語に期待

**デフォルトの名無しさん** · 2025/11/24(月) 17:14:22.69

実際、Rust以降ってこれといった言語出てなくない？

**デフォルトの名無しさん** · 2025/11/24(月) 17:19:31.65

Rustより安全性の高い言語でないと企業が採用しない
Rustのような書きやすさと両立したプログラミング言語は出現しそうにない

**デフォルトの名無しさん** · 2025/11/24(月) 17:45:09.92

メモリの安全性だけでなくnull safetyやmatchのexhaustivenessなど堅牢なソフトウェアを作るための機能が言語に備わっている

にもかかわらずそれらバイパスする間違ったunwrapやpanicの使い方を「正しい」と思い込んでる人たちを少なからず作り出しているということと、その誤った使い方を構造的に防止する方法がないということがソフトウェアの安全性に対するRustの問題点

**デフォルトの名無しさん** · 2025/11/24(月) 18:01:28.20

unsafeの中以外は⊂（＾ω＾）⊃ ｾﾌｾﾌ!!