Rust part33

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

Cloudflareの件で今回やるべきだったのは、パニックする前に監視システム向けに
最高の重要度でログだかイベントだかを送ることでしょ

**デフォルトの名無しさん** · 2025/11/23(日) 17:51:52.37

>Enabling more global kill switches for features
>An outage like today is unacceptable.

当該サービスに限るなら公式が既に上記の見解を示しているかと
同様の障害時には「（ボット管理）機能を無効化する」が彼らの構え
つまり「安全に停止（パニック）する」よりも「可用性を優先すべき」がネットワークインフラを提供する立場としてのあるべき姿と見たわけだ

**デフォルトの名無しさん** · 2025/11/23(日) 17:54:30.97

>>870
こういう設計仕様決めれる人カッコいいわ
社内でも散々揉めたんだろうけどね

**デフォルトの名無しさん** · 2025/11/23(日) 18:19:01.62

うーん、別にボット管理だけが特別に落ちやすいってわけでもないだろうに、後知恵対策の感が否めないなあ
実際にその通りやるかはともかく、世間に納得されやすそうな分かりやすい対策案を記載したんだろ
根本的な問題は誤ったパラメータファイルをロールバックできる仕組みがなかったことで、
そこを何とかしない限り今後何でもかんでもフェールソフト設計にしなきゃいけなくなりそう

**デフォルトの名無しさん** · 2025/11/23(日) 19:14:51.30

>>870
限るならからあるべき姿まで語り出すのは飛躍
今回のは(可用性向上するための)ボット対策が悪さするなら止める方がマシなだけ

機密性やら完全性やら欠いても動かすかどうかは別問題
あるべき姿として可用性優先してるのではない

**デフォルトの名無しさん** · 2025/11/23(日) 19:34:48.38

>>873
つ >同様の障害時には

前後の文脈読まれたし
その上でより丁寧に書き直すなら以下になるかと
当該サービス（の当該案件）に限るなら、「安全に停止（パニック）する」よりも「可用性を優先すべき」がネットワークインフラを提供する立場としてのあるべき姿と見たわけだ

少なくとも以下の文章からは可用性をサービスの要と見ている節が読み取れるような気もするが
ただしだからといってそれが「機密性やら完全性やら欠いても動かすかどうかは別問題」と矛盾する趣意かは別問題

>An outage like today is unacceptable. We've architected our systems to be highly resilient to failure to ensure traffic will always continue to flow. When we've had outages in the past it's always led to us building new, more resilient systems.

**デフォルトの名無しさん** · 2025/11/23(日) 19:52:12.24

>>872
実際はボット管理で言えばくだんのフィーチャーファイルとやらによる「更新をしない」分岐とかでは（エラーログの通知、及びそれに伴う都度の運用判断することなどは前提として）
当該機能の性格上、頻繁な更新を要することが今回の騒動に拍車をかけた形だろうし（その部分だけで見れば「（前提をネストさせた上で、にもかかわらずそれを無視すれば）"落ちやすい"」）
それにしては肝心のファイル生成をする当のクエリをノールック（あるいは見たけどスルー）でDBの権限変更したのはあまりに杜撰と見る向きもあるが
ちなみに改善手順と銘打って記載列挙された中には、上記のファイルに関するくだりも見られ、要するに「内部生成されたファイルも外部のそれと同等に扱う」とのことらしい

- Hardening ingestion of Cloudflare-generated configuration files in the same way we would for user-generated input
- Enabling more global kill switches for features
- Eliminating the ability for core dumps or other error reports to overwhelm system resources
- Reviewing failure modes for error conditions across all core proxy modules

しかしあの規模の、世界的なインフラ最大手がまさかの現場猫案件かますとは
後知恵バイアスと言われてしまえばそれまでなのだが、それにしてもな感はある

**デフォルトの名無しさん** · 2025/11/23(日) 20:20:59.87

Cargoの管理ファイルがウザイな。
lib.rsまでは良しとしてmod.rsまで必要かえ？
PlatformIOのように全体一発でモジュールとクレート管理できんもんかね？

**デフォルトの名無しさん** · 2025/11/23(日) 20:57:42.13

Rustのモジュール設計ってPythonのパクり？

**デフォルトの名無しさん** · 2025/11/23(日) 23:28:58.23

>>867
前提の認識は合ってる

判断基準は>>852に書いたように「プログラムやサービスをこのまま動作させることが適当でないエラーが発生した状況」がプログラムコードのバグに起因する(としか考えられない)状況ならpanicが選択肢になる

プログラムコードのバグ以外に起因する状況ならpanicは選択肢にならない
エラーハンドリングをしてプログラムやスレッドの処理を終わらせる

**デフォルトの名無しさん** · 2025/11/23(日) 23:44:04.11

もっともCloudflareの事例はプログラムやサービスを停止させる必要はなくて古い設定値のままトラフィックを捌き続ければよかった

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

>>858
いや、プログラムが緊急停止した場合の対策が出来ない無能はシステムを運用すべきじゃない、だろ。

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

>>880
その発言だと開発のポカは運用でカバーできるのが前提になっているけど、panicみたいに緊急停止するような状況はどんなに上手く運用したとしても回避するのは困難かと。
しかもCloudflareの場合は
https://blog.cloudflare.com/ja-jp/18-november-2025-outage/
自動生成した設定ファイルが原因だから、コードに詳しい開発側じゃなければわからない。

これを「運用が無能だから発生した」とか言うんだったら、運用側は「panicは最小限度にしろ」「panicが発生するコードは全て明記して管理しろ」「管理できなければpanicさせるな」と要求するわな。

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

>>881
あのな、言いたい事は分かるし、プログラマはシステムが止まらないよう最大限の努力しろというのはその通りだが、超新星爆発や太陽フレアやコーヒーが零れるのは止められないからな。それを念頭に運用は速やかにシステムを復旧出来るようにしとけよ。それが出来ずにプログラムやプログラマを非難するだけの運用なら無能というはなし。

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

>>876
いらんからmod.rsは非推奨になったのでは
ディレクトリと同名ファイルで管理するようになって
Facadeパターンとして使いやすくなった

**デフォルトの名無しさん** · 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の中以外は⊂（＾ω＾）⊃ ｾﾌｾﾌ!!

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

>>894
理解できていないのは君だろ
null safetyは必ずnullチェックがなされることを指す
unwrapは必ずnullチェックをする安全な方法
安全でないのはnullチェックをしないunwrap_unchecked()

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

>>896
つまり他言語でも

*nullptr = 123;

で「終了」すればnull safetyだとの主張ですな

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

>>892
Zigがあるじゃん

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

>>897
それはnullチェックをしていないため安全でない
unwrapは必ずnullチェックをする安全な方法

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

>>898
何年前に出て、現在どれだけ使われてるの？

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

>>900
JavaScriptランタイムのBun
あと、SUSEがZigでSSHの再実装するらしい

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

>>901
聞いたのは個別具体な事例ではなく、どれだけ使われているか、つまり普及のいかんについてであるのと、あと出た時期Rustと変わんなくない？

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

Crate.ioには、std::fmt::Debugをインプリしていないクレートが一杯あるんやね。
UartDriverだけかと思いきや、結構ある。
Wrapper作ってのインプリ作業がマンドクセ。
でないと、クレート、モジュールの外部変数Mutex.setもできん。
いろいろ手間のかかる言語だ。

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

ラップして Debug を実装するだけならマクロでかなり自動化できると思う。
というかそういうクレートはありそう。知らんけど。

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

>>896
言語に機能は備わっているけど誤った使い方でそれを活用できていない人たちがいるという話に対して「unwrapは必ずnullチェックをする」という言語に備わった機能を紹介しても意味ないでしょ

ちなみにnull safetyは必ずnullチェックがなされることを指すわけではないよ
null safetyを実現するための一手段ではあるけれどね

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

>>903
これまで誰も困っていないのならば
あなたがおかしい可能性を疑ってみてはいかが

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

>>905
その件は一方的な特定の価値観によって「誤った使い方」と断言してる人がおかしい
まずケースバイケースであり更に同じケースでも価値観の相違がある話なので技術的な話ではない

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

>>907
ケースバイケースなのは当然の話なんだがunwrapの誤った使い方によって大障害につながったCloudflareのケースを念頭に話をしてるわけで

あれが「誤った使い方」と断言できない人がこんなスレだけで複数いることがRustの抱えてる問題

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

>>908
本気で言ってるなら正気を疑う
まず思い込みの前提から解放されよう

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

>>906
Rust API Guidelines でもパブリックな型にはDebugトレイトを実装することを推奨してるけど
https://rust-lang.github.io/api-guidelines/debuggability.html

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

>>908
その無理矢理な「Rustの抱えている問題」との書き込みからアンチらしき人にみえます

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

「所有権の複製」の人って
その発言の前はそもそもクソコードいっぱいこのスレに書いてた人よな？
あの人よくunwrap書いてたような記憶あるけど記憶違いかな

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

unwrap使わない人はassertも使わないのかな
条件が破れた時にpanicの発生源になるし

**デフォルトの名無しさん** · 2025/11/25(火) 00:13:09.71

除算は常にchecked_div使ってそう

**デフォルトの名無しさん** · 2025/11/25(火) 00:17:03.45

物事を点でしかとらえられない知的障害者が大勢いるのがよくわかってかなしい
早くAIに置換したい

**デフォルトの名無しさん** · 2025/11/25(火) 00:21:51.64

0か100か思考の例

**デフォルトの名無しさん** · 2025/11/25(火) 01:08:59.76

>>909
Cloudflareのunwrapの使い方が誤った使い方でないと思ってるならそう思う根拠を述べて反論できないの？

**デフォルトの名無しさん** · 2025/11/25(火) 03:59:13.06

>>917
あちこちでの議論くらい読め
Resultを返す関数の中で意図的にResultをunwrapしていることから
そこでエラーは起きないと確信していて起きたら停止すべき事態とみなしている
現実にもありえない重複行が発生してサイズオーバーという異常事態になっていた
あとは運用側の問題でありpanicによりどこで何が起きたか確実に判明して直ぐに対応できる話だがここでは対象外

**デフォルトの名無しさん** · 2025/11/25(火) 07:01:05.47

>>918
そのあたりはコーダーの都合であって、運用を危険にさらす理由にならない。

Cloudflareの場合で言うなら、
https://blog.cloudflare.com/ja-jp/18-november-2025-outage/
ボット管理モジュールのフィーチャー設定ファイルは長さに上限が無いにもかかわらず固定長のメモリに保存する仕様にしているのだから、固定長を超えるフィーチャー設定ファイルが来るのは当然ありえるケースとしてカバーする必要がある。それをコーダーの都合で雑にpanicさせて、なおかつ「panicのあとは運用側の問題」と放り投げるなら>881>884という話だわな。

**デフォルトの名無しさん** · 2025/11/25(火) 07:48:13.19

運用上マズい結果を招きかねないコードがそのまんまテストやレビューを通過していることから、これは組織体制の問題でもある
どのようなテスト結果をもってどのように承認されたのか、今回の事象に至る前提条件はその時に把握されていたのか、等が気になる

**デフォルトの名無しさん** · 2025/11/25(火) 07:52:14.10

>>919
理解できない人なのかな？
そんな憶測の話はどうでもいい
きりがない
重要なことは何を意図して今回のコードを書いているかどうか

今回はResultを返す関数の中で意図的にResultをunwrapしていることから
そこでエラーは起きないと確信していて起きたら停止すべき事態とみなしている
そして異常事態が実際に起きてここで食い止めることができている

もちろんこれらの事象が起きて事後知識を得た後には別の判断をする可能性がある
その一つがボット判断の無効化など異常事態でも動かし続けることを優先するだろう
これらの事後知識を得た後の話をしても意味がない

**デフォルトの名無しさん** · 2025/11/25(火) 08:15:03.85

>>921
コーダー視点からすればそうなのね。

それならなおさらのこと、マネジメント視点や運用視点からすればpanicは厳重に管理しなければならない対象ということになり、>881という結論になるわな。
さらに言えば>920の指摘の通りで、雑に実装された緊急停止コードがレビューでそのまま本番環境に投入されたのは組織体制の問題があるかもしれん。実際にはRustのバッドノウハウの普及遅れのせいだと思うけど。

**デフォルトの名無しさん** · 2025/11/25(火) 10:56:07.08

>>921
>そこでエラーは起きないと確信していて起きたら停止すべき事態とみなしている
めっちゃ憶測やん

**デフォルトの名無しさん** · 2025/11/25(火) 11:05:24.61

複おじの憶測が当たってても誤ったunwrapの使い方であることに変わりはないよね

**デフォルトの名無しさん** · 2025/11/25(火) 11:49:12.51

クラウドフレアって良く落ちるよね

**デフォルトの名無しさん** · 2025/11/25(火) 13:01:07.06

>>921
コードは（もっと言えば仕様も）意図を100%反映するものではない
コードにunwrap()があるからといってそこから背景の意図を一意に読み取れるとする前提は、ソフトウェア工学の現実にまったく即していない

**デフォルトの名無しさん** · 2025/11/25(火) 13:11:04.76

設定ファイルはデフォルトのものは用意出来なかったのだろうか
デフォルトの設定を使ったら動作変わるだろうけどそれよりはpanicのほうがマシということかな

**デフォルトの名無しさん** · 2025/11/25(火) 14:14:13.80

panicさせれば確実に問題を把握できるからベストだけど
どこでpanicしたかわかっているのに対応に時間がかかった運用体制がダメだよな

**デフォルトの名無しさん** · 2025/11/25(火) 14:28:01.35

リリースビルドでも行番号出るんだっけ？

**デフォルトの名無しさん** · 2025/11/25(火) 14:36:29.79

fmt::Debug実装されてないとき
Compile errorで落とすのをデフォに出来ないの

**デフォルトの名無しさん** · 2025/11/25(火) 14:43:06.35

>>877
pythonのモジュール設計はtcl/tkのパクリ

**デフォルトの名無しさん** · 2025/11/25(火) 15:49:19.46

>>910
だね。
例えば、UartDriverのインスタンスを関数外にグローバル変数(static)として設け、各関数でシェアする場合、
OnceLock<Mutex>などで排他する必要がある。
これをnew()内でmutex setしようとするとそのset関数にはunwrapも.exceptも使えない。
そこで、sft::fmt::DEBUGインプリメント推奨となる。

**デフォルトの名無しさん** · 2025/11/25(火) 16:57:37.23

>>930
一応要求される使い方では、COMPILE ERRORでニッチもサッチも行かなくなる。
unwrap()系必須の仕様は多い。

**デフォルトの名無しさん** · 2025/11/25(火) 18:06:26.30

refcellとかの内部可変性はズルいような感じする

**デフォルトの名無しさん** · 2025/11/25(火) 18:07:51.70

unwrap禁止おじさんw

**デフォルトの名無しさん** · 2025/11/25(火) 18:29:54.26

まぁ　クレートのラッパーにstd::fmt:DEBUG入れ込むのは、VScode　AIコパイロットで一度パターンを覚えてくれれば、楽になるが、あちきのようなvim使いにはテンプレートでやるしかない。
意外と手間がかかるのでマンドクサイ。

**デフォルトの名無しさん** · 2025/11/25(火) 18:43:51.50

>>928
ベストなわけあるか
握りつぶすのが最悪でその次に悪い対応

**デフォルトの名無しさん** · 2025/11/25(火) 18:50:48.51

>>927
わざわざデフォルト値にフォールバックする必要がないと思う
まさに今使ってる設定があるんだからそれを使い続ければいい
動作も変わらなず設定が無効な値に更新されないだけ

**デフォルトの名無しさん** · 2025/11/25(火) 19:15:28.03

まあRustだから安全ですよ
そんなに心配していません

**デフォルトの名無しさん** · 2025/11/26(水) 01:42:28.68

panic panic panic みんなが慌ててる
Rustは凄いぞ天才的だぞ将来楽しみだ

**デフォルトの名無しさん** · 2025/11/26(水) 02:55:05.14

認証せえ～！！