Rust part33

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

>>706
そのRust求人出してる企業一覧すごいな
知ってる企業がずらりと並んでいて感動した
Amazon
Microsoft
Cloudflare
xAI
Apple
Dropbox
Nvidia
Google
SpaceX
GitHub
Mozilla
Woven By Toyota
Discord
Disney
Fastly
Mercedes
Bloomberg
Bun
Toyota Connected
Figma
Astral
KSAT
LINE
Akamai
Meta
など

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

Rustスゲー！驚いた！驚いた！

**デフォルトの名無しさん** · 2025/11/17(月) 12:39:05.33

防衛産業だとDとかAdaとかのイメージ

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

何かに特化したプログラミングではないものを採用するところは、かなりレベルの高いプログラマーが多いところ。

**デフォルトの名無しさん** · 2025/11/17(月) 13:26:47.32

プログラミング言語は手段にすぎないと本当にわかっていない人間ほど、どうでもいいことにこだわって、メンテナンスを難しくしてしまう。それをメンテナンスを容易にしたと逆のことを言う。

**デフォルトの名無しさん** · 2025/11/17(月) 13:38:29.57

まともなIT企業ならRust求人を出すか内部で育てているだろうから当たり前の結果だろう

**デフォルトの名無しさん** · 2025/11/17(月) 16:02:02.11

こういうデータリテラシーの低いやつらはRustじゃなくPythonでもやったほうがよさそう

**デフォルトの名無しさん** · 2025/11/17(月) 18:32:10.14

>>690
Rubyにもuvみたいなrvってのが作られてるね

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

>>714
uv自体がcargoみたいなものとして作られてるのに
連鎖してるのか

**デフォルトの名無しさん** · 2025/11/17(月) 20:06:46.87

Rust文化が各言語のRust製ツールと共に各言語へ広がっていく

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

>>711
あるある
その時その時で良い言語を選べばいいのに些細などうでもいいことにこだわって保守性の低い古臭い言語を使い続ける人いるね
今なら保守性の高いRustが登場したのに

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

おもしろいじゃん

**デフォルトの名無しさん** · 2025/11/18(火) 09:35:50.76

>>707
ディズニーがRustを何に使うの？

**デフォルトの名無しさん** · 2025/11/18(火) 09:44:02.46

配信系じゃないか

**デフォルトの名無しさん** · 2025/11/18(火) 09:45:19.44

確かDisney+の配信フロントエンドがwasmでRustだったはず

**デフォルトの名無しさん** · 2025/11/18(火) 10:04:09.86

ディズニー求人
https://www.disneycareers.com/en/search-jobs?k=rust

**デフォルトの名無しさん** · 2025/11/18(火) 10:26:47.98

年収15万～20万ドルかよ

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

ESP32　ArduinoからRust変換はおもろかった。
App、Domain、Infrastructure構造のDDDで作ったプロジェクトだけど、純粋仮想関数(interface)もInjectionもRust移行がこんなに簡単なのかと驚いたもんだ。
ValueObjectも不要になったし、いろいろDDDには最適な言語。
まぁ　コンパイルは通ってもワーニングを無くす作業が大変だったのは言うまでもない。
ワーニングリストてんこ盛りでも動くところがなんだかなぁとはオモ。
Rustはオヌヌメだよ。　本当に。

**デフォルトの名無しさん** · 2025/11/18(火) 21:33:50.31

驚いた！

**デフォルトの名無しさん** · 2025/11/18(火) 23:38:02.37

>>724
その手の問題のほとんどがクラスを捨ててトレイトを採用すると解決するよね
純粋仮想関数という奇妙な名前を含めた概念もトレイトの『実装必須メソッド』とそれらを用いた特定の型に依存しない『デフォルト実装提供メソッド』の二つに整理されると使いやすくわかりやすい
依存性の注入や逆転も『トレイトを利用する型々⇔トレイト⇔トレイトを実装する型々』と最初から分離されて対応している
Value Objectもどこまで何をやるかで多少変わるけど基本的にはラッパーにPartialEq/EqやClone/Copyそしてバリデーション付き生成のTryFromなど基本トレイトを必要なだけ実装していくだけで大方の対応ができる

**デフォルトの名無しさん** · 2025/11/19(水) 00:21:53.18

iter().filter(...).map(...) みたいなのってデバッグ用のビルドだとすごく遅くない？
リリースビルドだと最適化されるんだろうけど、デバッグ時のことを考えると要素数が大きい場合は普通に for で書いた方が良いんだろうか

**デフォルトの名無しさん** · 2025/11/19(水) 04:26:37.69

libxml2がメンテナー不在状態になっちゃったらしいけど
これってRust採用に有利に働くのでは？
しかも、最後のメンテナーが「セキュリティバグ満載の趣味プログラムだから製品に採用してる大企業の方がおかしい」とか言い出してる

ま、Rustからlibxml2呼んで使ってた人もいるかもしれんが

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

>>728
これは追い風だな
自社開発せなあかんとなれば金払ってでも雇うだろうし

**デフォルトの名無しさん** · 2025/11/19(水) 10:14:56.27

https://blog.cloudflare.com/18-november-2025-outage/#memory-preallocation
ふう
今回もRust自体の問題じゃなくてRustを誤用したCloudflareの無能のせいでよかったよかった

**デフォルトの名無しさん** · 2025/11/19(水) 10:38:40.48

>>730
Cloudflareですら、本番環境で雑にunwrap()呼んでるんだから
この関数はもう許されたんだな

**デフォルトの名無しさん** · 2025/11/19(水) 11:21:56.78

>>731
Result返す関数内だから
.unwrap();
を
?;
にするだけなのにな

**デフォルトの名無しさん** · 2025/11/19(水) 11:50:56.97

そのままmainまで巻き戻ってエラー値でプロセス終了
panicじゃないからねって責任分散w

真面目に言語として対策するならResult::unwrap()をunsafeにする事だな

**デフォルトの名無しさん** · 2025/11/19(水) 12:57:15.96

>>733
設定ファイルの読み出しでエラーなのだから、続行することが悪なのであって、panicもしくはmainでエラー値を返して終了のどちらでも正しい。
このプログラムの異常終了を検知して、然るべき自動対応もしくは人間へアラートを発生させることが通常のシステム運用だ。

**デフォルトの名無しさん** · 2025/11/19(水) 16:36:17.53

>>733
unwrap()は必ずチェックをしてくれるsafeな関数
チェックをしないunwrap_unchecked()がunsafeな関数
後者はチェックが不要であることを人間が保証しなければいけない

**デフォルトの名無しさん** · 2025/11/19(水) 18:15:22.62

unwrap()じゃパニックした理由が分からんから、せめてexpect()を使うべきだったのでは？

**デフォルトの名無しさん** · 2025/11/19(水) 18:44:42.33

>>730
>今回もRust自体の問題じゃなくてRustを誤用したCloudflareの無能のせいでよかったよかった
こういうおバカな考え方をするやつにシステムプログラミングをさせてはいけない
絶対にダメ

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

そもそも「Rustを誤用した」箇所がないだろ
フェールセーフなシステム運用では異常時に異常なデータのまま動き続けることこそ最悪な惨事
パニックでプロセスが落ちてくれれば上位で必ず検知できてその対処ができる

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

Rcってスマートポインター自体はポインターとサイズ一緒で参照先にカウンターがあるんだよね

**デフォルトの名無しさん** · 2025/11/19(水) 22:57:00.67

>>739
スタック上のサイズは通常のポインターと同じだけど
スタック上のポインターだけを指して「Rcのスマートポインター自体」と呼ぶのはちょっと微妙

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

>>739
その通り
例えば64bit環境において
Rc<usize>はスタック上に64bit一つ分(ヒープを指す64bit)とヒープ上に64bit三つ分(強カウントと弱カウントとusizeの各64bit)
Rc<[usize]>はスタック上に64bit二つ分(ヒープを指す64bitと長さの64bit)とヒープ上に64bitが二つ＋長さ分(強カウントと弱カウントと[usize])
つまりスタック側にスライスの長さ用で＋１とヒープ側に強弱カウント用で＋２

**デフォルトの名無しさん** · 2025/11/19(水) 23:50:27.39

まーたフェイク垂れ流してんなw

**デフォルトの名無しさん** · 2025/11/19(水) 23:59:17.25

正しくても嘘だフェイクだと暴れるだけのおじさん

**デフォルトの名無しさん** · 2025/11/20(木) 02:07:52.80

ChromeはXSLT機能を廃止するらしい
件のlibxml2と同じ人がメンテしてて放棄されたlibxsltにセキュリティ問題があると見て

**デフォルトの名無しさん** · 2025/11/20(木) 05:14:44.24

Rustすごい！驚いた！

**デフォルトの名無しさん** · 2025/11/20(木) 10:18:35.91

Cloudflareの障害って半年前のGoogle Couldの障害と同じパターンじゃん
確か「Rustなら防げた」とかアホなこと言ってたやつがいたな

**デフォルトの名無しさん** · 2025/11/20(木) 10:22:16.48

>>736
実際にはパニックと同時に出るバックトレース以上の情報なんて書けないからいらないと思う
中身がおかしいです！それはわかってる。

**デフォルトの名無しさん** · 2025/11/20(木) 10:47:57.16

>>747
>中身がおかしいです！それはわかってる。
ファイルの中身がおかしいと特定するのに2時間もかかったのに？

**デフォルトの名無しさん** · 2025/11/20(木) 11:21:06.60

>>748
バックトレースでわかる、落ちたソース行と変数がわかっててもそれなりに調査がいる部位で
ここが落ちた原因はこのファイルです！加えてこのファイルがおかしい理由はこれです！って
人間様なら事前に言えるのかって話だけど・・・。しかも全てのunwrapで

**デフォルトの名無しさん** · 2025/11/20(木) 12:03:26.09

>>738
フェイルセーフを勘違いしてるな
雑にunwrapするのはこういうやつだろ

**デフォルトの名無しさん** · 2025/11/20(木) 12:37:12.92

>>738
> 上位で必ず検知できてその対処ができる

この手の信者が野放しのせいで#[no_panic]が通らない

**デフォルトの名無しさん** · 2025/11/20(木) 14:34:42.78

>>749
要するにバックトレースでは不十分だったということ
expectのメッセージがあれば解決がかなり早まった可能性が高い

ただ外部データを読み込んでその妥当性をチェックした結果のResultなんだからパニックさせるのが論外

**デフォルトの名無しさん** · 2025/11/20(木) 14:38:44.38

今回も前回もアホなこと言ってるやつは同じだね
https://mevius.5ch.net/test/read.cgi/tech/1748392296/807-n

**デフォルトの名無しさん** · 2025/11/20(木) 19:55:50.61

>>752
みんながパニックさせるのを正解と言ってるのに一人だけパニックさせるのが論外と主張するからには代案を書きなさいよ

**デフォルトの名無しさん** · 2025/11/20(木) 20:59:55.94

>>730
Rustに投資するマネジメント層からすれば、
「想定可能なケースでpanicするな」「終了するなら理由を明らかにしろ」「終了した後のことを考えろ」
あたりだよなぁ。

panicなんてシステムが異常になるレベルで初めて使うことを考えるようなもの。
コーダーには触らせたくないから、SafeRustはpanic禁止でいいと思うわ。

**デフォルトの名無しさん** · 2025/11/20(木) 21:09:11.15

ワイも unwrap は論外と思うやで。
ロジック的に失敗があり得ないから失敗の場合のことは書くのを省略するというのが unwrap の役割だろ。
失敗がないはずのところで失敗したならそれはロジックに誤りがあったということ。
つまりはバグだ。
プログラムにバグを書くのが正しいってことはない。

でも panic するのは正しいかもしれない。 (公開情報だけでは断言はできないけど。)
正しくないデータに対してプログラムが回復する余地がないなら終了するしか仕方ないし、
その問題にどう対処するかは運用の問題なので必要なログを残した上で終了するのは正しい。

特に今回の事例はメモリまわりの制御が絡んでいるということがある。
メモリが足りないままで続けるとあらたにメモリが必要な状況が生じて破綻するかもしれない。
エラーを返して上位レイヤで判断するのはロジック的には綺麗だがリソース不足の状況ではそうも言ってられない。

**デフォルトの名無しさん** · 2025/11/20(木) 21:24:39.80

>>756
Again, the limit exists because for performance reasons we preallocate memory for the features.
だから、コーダーでもコントロール可能な範囲じゃない？
こんなんじゃリーナスじゃなくてもpanic禁止言いたくなるわな。

**デフォルトの名無しさん** · 2025/11/20(木) 21:39:21.39

>>754
パニックさせるのが正解などというバカのことを言ってるのは複オジ一人だけじゃん
自分の意見を複製してもなりすまし書き込みしてもみんなが言ってることにはならないよ

**デフォルトの名無しさん** · 2025/11/20(木) 21:50:20.55

これは普通にpanicで正解でしょ
メモリを固定ではなくfeatureファイルに合わせて動的アロケーションするようにしていれば即障害にはならなかっただろうけど、
それはunwrapの是非とかの次元の話じゃないし、複おじの頭はそこまで回らないだろう

**デフォルトの名無しさん** · 2025/11/20(木) 21:50:58.54

続行不可能なのだからどこかで必ずpanicすることになる
C言語ならexit(non-0)
Rustはもっと賢いpanicがありそれを使う
他に手はない

**デフォルトの名無しさん** · 2025/11/20(木) 21:56:43.11

続行可能なら上位へエラーを返せばいいんだよね
続行不可能なら上位へエラーを返すより即panicさせるのが正しいよ
その方がバックトレース的にも有利

**デフォルトの名無しさん** · 2025/11/20(木) 22:04:24.95

続行可能／不可能はコーダーが判断することではないよ。ふつうにエラーを返せ。

**デフォルトの名無しさん** · 2025/11/20(木) 22:09:40.31

>>762
続行不可能なのにエラーを返してどうするの？
そこでpanicさせるしかないよ

**デフォルトの名無しさん** · 2025/11/20(木) 22:18:59.74

>>762
起動時に必要なデータなんだろうから、エラー返したところで上位でもどうしようもないでしょ
仮にエラーを無視してそのまま起動させたとして、不正な状態だからってリクエストを5xxで落とすのはまずいのはさすがに分かるよな?
Bot Managementというのがどれだけ重要なのかは知らないけど、
最悪それが機能してなくてもいいならエラー無視してそのモジュールの処理だけ飛ばすのは結果論としてはアリだったかも
でもそれ言い出したら極論何でもかんでもフェールソフトにしなきゃいけないから、それこそゆるふわ設計になりすぎてRustのメリットが薄れちゃうよ

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

もっと簡単にエラー科研のこやつは

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

アプデで改善しーやー

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

もう普通にtry catchでええ

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

Rustのプログラム開発デバッグそして運用実行時の問題発生で最も役立つ仕組みがpanicなのにそれを理解しないでpanicを毛嫌いしてる人がいる不思議～

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

>Rustのプログラム開発デバッグそして運用実行時の問題発生で最も役立つ仕組み

具体的になんの開発時にそう感じたの？

**デフォルトの名無しさん** · 2025/11/21(金) 02:04:51.36

>>764
>起動時に必要なデータなんだろうから

そーなん？どこ情報？

**デフォルトの名無しさん** · 2025/11/21(金) 02:19:37.89

>>764
公式は以下があるべき姿と見ているようだが

>Remediation and follow-up steps

>Remediation and follow-up steps
>Now that our systems are back online and functioning normally, work has already begun on how we will harden them against failures like this in the future. In particular we are（今後同様の障害が発生した場合に備え、以下を重点とするシステムを強化する取り組みに着手）:

> - 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（エラー状態の障害モードを見直す）

>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.（今回のような障害は容認できない、耐障害性の高い新しいシステムを構築するきっかけとなった）

https://blog.cloudflare.com/18-november-2025-outage/#remediation-and-follow-up-steps

>>768
そんなのサービス要件、用途、場面次第では
そもそもエラーの可能性を含意するResultを返していることを意にも介さず、ハンドリングしないのは言語の思想にもとるかと
パニックの好悪ではなく、サービス要件、場面に対してミスマッチだと指摘されているのでは

**デフォルトの名無しさん** · 2025/11/21(金) 02:41:53.57

panic禁止派がいるからでしょ
結局プログラムを終了させるなら深いところでpanicさせることでバックトレース情報を最大化しましょう

**デフォルトの名無しさん** · 2025/11/21(金) 03:02:34.17

panic禁止派って、正常な関数だと辿りつかない状態になったらどうすんの？
anyhowとかでthis is bugとかって返すの？

**デフォルトの名無しさん** · 2025/11/21(金) 03:12:36.25

それを議論して何か自分のためになることがあると思うの？

**デフォルトの名無しさん** · 2025/11/21(金) 03:19:36.71

てかたまに思うんだけどエラー処理てif文でよくね？

**デフォルトの名無しさん** · 2025/11/21(金) 04:06:05.39

>>771
Resultが返ってきた時にpanicさせることは立派なハンドリングだよ
例えば読み込み必須なデータファイルがopenできずにErrを返しプログラムが続行できないからpanicなど

**デフォルトの名無しさん** · 2025/11/21(金) 06:09:46.10

日本語翻訳があるんだから、少しは元記事に目を通せや。
https://blog.cloudflare.com/ja-jp/18-november-2025-outage/

cloudflareはエラーハンドリングに失敗して原因追求できずに大規模DDoS攻撃と誤認したんだろ。
このケースでpanicが正しかったとはとても思えない。

**デフォルトの名無しさん** · 2025/11/21(金) 07:16:25.89

現場コーダー（ここでエラーハンドリングしたらそのぶんテストしなきゃいけないな。
でも今日は早めに帰って家でゲームしたいんだよね。うーん…怖いけどunwrapするか。
なーに、下っ端は仕様書の前提をただ信じればいいだけさ。これでよし、帰ろっと。）
53日後…ウェブが死んだ

**デフォルトの名無しさん** · 2025/11/21(金) 07:27:20.23

>>773
「設計通りあれば辿り着きえない」なら assert や unreachable じゃないの？
expected でも良い
これは「どうエラーをハンドルするか」という問題ではなく「ソースコードの読み手に対し設計者の意図をどのように表明するか」という話な気もする

**デフォルトの名無しさん** · 2025/11/21(金) 07:46:53.00

https://doc.rust-jp.rs/book-ja/ch09-03-to-panic-or-not-to-panic.html

**デフォルトの名無しさん** · 2025/11/21(金) 08:17:21.30

>>777
後からは何とでも言えるが、開発時点でこういった失敗を想定して対処できたのか?って話
Googleも最近似たようなことやらかしてるんだからな
絶対に必要不可欠というわけでもなさそうな処理だが、かといって内部のパラメータさえ適切に設定されていれば無難に動くものなんだろうから、
こうした状況に対処するための設計上の強力なポリシー(おそらく今回のトラブルをきっかけに策定される)がない限り、
それが安易にクリティカルパスに組み込まれてしまうことは仕方ないように思える
逆にデフォルトのポリシーとしてフェイルソフトを優先するようなことをすれば、>>764の通りOptionalだらけのゆるふわ設計につながる

**デフォルトの名無しさん** · 2025/11/21(金) 09:00:31.31

>>781
>後からは何とでも言えるが、開発時点でこういった失敗を想定して対処できたのか?って話
むしろなんで想定できなかったのか不思議なくらいの稚拙な問題なんだが

**デフォルトの名無しさん** · 2025/11/21(金) 09:04:46.72

>>781
>逆にデフォルトのポリシーとしてフェイルソフトを優先するようなことをすれば、>>764の通りOptionalだらけのゆるふわ設計につながる
これも間違った考え方だな
「フェイルセーフ」の正しい理解と合わせて耐障害性設計の基本を学んだほうがいい

**デフォルトの名無しさん** · 2025/11/21(金) 09:27:12.92

>>781
>後からは何とでも言えるが、開発時点でこういった失敗を想定して対処できたのか?って話

Result「・・・」

**デフォルトの名無しさん** · 2025/11/21(金) 09:34:42.48

>>782
そう思うならさっさとそのクソブラック企業辞めてCloudflareかGoogleに転職したらどうだ
年収150万ドルは堅いぞ

**デフォルトの名無しさん** · 2025/11/21(金) 09:52:08.85

>>772
>結局プログラムを終了させるなら深いところでpanicさせることでバックトレース情報を最大化しましょう
Resultを上位に伝播させるのも面倒だし伝播させた後の対応も面倒だから雑にpanicで終了させましょうという話だな
こう考えるやつが少なからずいるようならRustを使う開発者の能力の問題だけでなくRust自身の問題ということになる

**デフォルトの名無しさん** · 2025/11/21(金) 10:02:37.01

想定可能なエラーでも続行不能ならpanicさせてバックトレース見ましょうみたいな運用がCloudflareの規模で成り立つわけないのにね

性能要件的にバックトレース無効にしてる可能性もある

**デフォルトの名無しさん** · 2025/11/21(金) 10:16:37.50

とにかく全部ハンドリングしようぜ
あらゆるケースを想定するべきだ

**デフォルトの名無しさん** · 2025/11/21(金) 10:30:47.14

設定に異常値が紛れ込んでもpanicで止めたくないならunwrapをunwrap_or_defaultあたりに替えとけばいいよ
とりあえず動く

**デフォルトの名無しさん** · 2025/11/21(金) 11:56:46.17

>>779
横からだがこの議題でpanicと呼ばれていることはpanic!を引き起こすassert!やunreachable!やexpectなどの総称でしょう

**デフォルトの名無しさん** · 2025/11/21(金) 11:59:34.90

>>789
それは最悪でしょ
異常値や情報不足のままプログラムが動作しないように止める役割がpanic
panicさせないプログラムは信用できない

**デフォルトの名無しさん** · 2025/11/21(金) 12:10:50.33

今回のCloudflareの件で言うとあそこでpanicさせなかったら
事前に確保したより大きなメモリ確保しようとしてプロセスがランダムにkillされたり
より意味不明な事態になったかもね

**デフォルトの名無しさん** · 2025/11/21(金) 12:38:52.46

panic肯定派は色々と分かっていないなぁ。

「続行不能ならpanicさせて緊急停止させるべき」というなら、緊急停止させた後のことも考えて状況を制御しろ。panicさせた後のことは分からん、と言うのならpanicさせるな。
それすら思いつかない無能コーダーが大半なんだから、無能コーダー向けのsafe rustはpanic禁止すべき。

**デフォルトの名無しさん** · 2025/11/21(金) 12:52:05.82

>>792
>Enabling more global kill switches for features

障害発生時の構えとして特定機能（今回でいうならボット管理）を無効化する考えを公式が示しているわけで
すなわちこれが本来あるべき姿、「unwrap任せで勝手にpanicする」のはネットワークインフラを提供する側としてありえない設計であると言っているのもしかりでは

>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/21(金) 13:18:58.19

>>794
panicは必要不可欠なものだという話をしている
unwrapでpanicしろなんて話はしていない

>>794
Cliudflareの話はしていない
panic禁止すべき！と書き込む頭のおかしい人がいるから話をしている

**デフォルトの名無しさん** · 2025/11/21(金) 13:22:16.60

>>791
上位でcatch_unwindはしてると思うけど延々と同じ異常値使ってpanic繰り返してた感じでしょ
自分もpanicで抜ける方が正しいと思うけどこれだけpanicに文句言う人が多いなら異常値無視して動かした方がよくね？
設定無視しても多少セキュリティに穴が開く程度だろうし

**デフォルトの名無しさん** · 2025/11/21(金) 13:35:17.28

>>795
安価付けてレスをするならせめて当該のレスツリーくらい把握されては
こちらが指摘かました >>792 氏は明確に今回のCloudflareに言及している
したがって「panicの要否」ではなく、「panicの適否」に対するそれなわけであり
「unwrapでpanicしろなんて話はしていない」んじゃなくって、今回当該サービスにおいてそうした実装がされていたんだよ現実に
その上で「panic禁止すべき！と書き込む頭のおかしい人」への反論をしたいのであれば、くだんのCloudflare大規模障害を文脈に含むレスに安価かますのは筋違いかと

**デフォルトの名無しさん** · 2025/11/21(金) 13:54:38.91

すまんな
何らかのミスでアンカが1つずれてた
>>794でなく>>793へのレス

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

おーらい

**デフォルトの名無しさん** · 2025/11/21(金) 14:57:18.03

unwrapがあったらリリースビルドが失敗するようにしてほしいよね

**デフォルトの名無しさん** · 2025/11/21(金) 15:31:33.26

rustのdrop traitってメモリー解放前の前処理を記述する場所で
dorpはメモリーを開放するというのは違うよね

**デフォルトの名無しさん** · 2025/11/21(金) 15:53:54.77

drop は明示的に呼出し (いわゆる早期 drop) てもそれ自体がメモリを解放するとは限らないが、言語機能と融合している特別なトレイトなのでメモリの解放のタイミングに影響を与えることはありうる。

**デフォルトの名無しさん** · 2025/11/21(金) 23:25:47.85

redditからの借り物
https://i.imgur.com/oEZoQJd.png

**デフォルトの名無しさん** · 2025/11/21(金) 23:56:05.84

そんなもんだ
過去を引きずる案件以外でC++を使う人は消えていく

**デフォルトの名無しさん** · 2025/11/22(土) 00:16:12.45

こんなもん完成に用途によるだろ
実際にそれ系本場の組み込みとかでの普及率こそ指標とするべきではないの？

**デフォルトの名無しさん** · 2025/11/22(土) 00:17:49.35

❌完成に
⭕完全に

**デフォルトの名無しさん** · 2025/11/22(土) 00:18:35.18

updateもカウント

https://www.reddit.com/r/rust/comments/1p2tfi1/media_new_releases_on_pypi_rust_vs_cc/
> But… I’m interested in those subsequent updates.

**デフォルトの名無しさん** · 2025/11/22(土) 01:07:20.55

>>789
>設定に異常値が紛れ込んでもpanicで止めたくない
入力値と設定そのものを混同してるよね？
設定に反映させるために読み込んだ入力値が必須条件を満たしてないだけであってアプリの振る舞いを左右する設定自体に異常値が紛れ込んでいるわけではないよ

**デフォルトの名無しさん** · 2025/11/22(土) 05:50:44.36

クラウドフレアでのやらかしでrustも失墜だね

**デフォルトの名無しさん** · 2025/11/22(土) 05:58:51.95

遅くて安全じゃないって最悪じゃん

**デフォルトの名無しさん** · 2025/11/22(土) 07:02:46.20

>>795
>793への返信かね。
panicは大多数のコーダーには不要で有害だという話をしている。
unwrapでpanicするようなコーダーには触れないようにしろという話だよ。

**デフォルトの名無しさん** · 2025/11/22(土) 07:04:22.51

>>809
安全性が示されただろ
どこに危険な問題があったんだ？

**デフォルトの名無しさん** · 2025/11/22(土) 08:36:23.79

>>811
Mutex使用禁止ということか

**デフォルトの名無しさん** · 2025/11/22(土) 08:57:51.52

>>812
安全性が反面、可用性とはトレードオフであることも示されたのかと
サービスの性格を正確に理解しないまま、言語の持つ安全性を盲信することは容易に問題となりうることも

**デフォルトの名無しさん** · 2025/11/22(土) 10:11:24.12

>>813
それは皮肉でもなんでもなくて、Mutexのlock().unwrap()は実際panicするからpanic厳禁派なら絶対NGよ
matchでlockの結果をチェックしないとダメ

**デフォルトの名無しさん** · 2025/11/22(土) 11:09:17.53

Rustのunwrap()というのはそもそも前提が壊れたらpanicするイディオムであるので、
もしpanic厳禁派を標榜するならケースバイケースで使っていいものではなく絶対にソースコード上に登場させてはならない

**デフォルトの名無しさん** · 2025/11/22(土) 12:33:52.35

unwrapの使い方なんてrustユーザー側の設計思想やリスク管理に依るものであって、結局は開発組織の質の問題よ

**デフォルトの名無しさん** · 2025/11/22(土) 12:59:01.17

unwrapの間違った使い方をしたり間違った使い方を正しいと思い込んでる人がこれだけいるんだから開発組織の質の問題として片付けられないよ

Rustの構造的な問題と言っていい

**デフォルトの名無しさん** · 2025/11/22(土) 13:01:14.64

>>814
安全性と可用性は両立ができる
両立が不可能なことは例えば分断時の可用性と一貫性など

**デフォルトの名無しさん** · 2025/11/22(土) 13:03:18.34

>>818
unwrap自体に間違った使い方なんてものはないよ
常に安全に用いることができる

**デフォルトの名無しさん** · 2025/11/22(土) 13:34:45.55

>>819
>両立ができる

「言語の持つ安全性を盲信することは容易に問題となりうること」を理解した上でそれらをどこまで両立させるかの見極めこそが、まさに設計の要では
両者がトレードオフであることを意識してこそ妥協点が見えるわけであり
でなくばいずれは一方が他方の隘路になるのかと
際限のない両立などに再現性はあるまいて

**デフォルトの名無しさん** · 2025/11/22(土) 14:08:27.01

unwrapとかシンプルすぎて誤用の余地ないだろ

**デフォルトの名無しさん** · 2025/11/22(土) 14:16:46.80

unwrapは未定義動作を生じないという意味においては安全
その結果として自動運転車が人混みに突っ込んだり原子炉がメルトダウンしたりしないことを保証するものではない

**デフォルトの名無しさん** · 2025/11/22(土) 14:55:39.41

分かってない人が多いけど、unwrap_or_default で安全サイドなデフォルト値で動かせば絶対に問題なんて起きないんだが
そのための設計だし初期値で動かないとしたらそもそも設計ミス
単にunwrap使ってそのままというのはダメ。世の中急に止めたら復旧大変なシステムとかもあるんでね

**デフォルトの名無しさん** · 2025/11/22(土) 15:08:23.48

ResultやOptionを返す関数を使用する前にそれがエラーやNoneになるようなケースがチェック済みで、改めて不要なエラー処理を書くのが面倒な時くらいかな、 unwrap を使うのは

**デフォルトの名無しさん** · 2025/11/22(土) 15:29:04.79

>>824
Mutexでunwrap_or_defaultを使う状況は俺にはちょっと思いつかないな

**デフォルトの名無しさん** · 2025/11/22(土) 16:34:26.43

>>822
これ見て久しぶりに思い出した
設計と実装の食い違いがあったら「この実装なら設計意図はこうであったはずだ、よって実装は正しい」とか言い出すような奴だった
そりゃあ誤用だなんて認められるわけないし話が通じるはずもないわな

**デフォルトの名無しさん** · 2025/11/22(土) 16:52:31.93

安全性を考えれば#[no_panic]的なものがあったほうがいいのは間違いない
だがRustで実現するのはもう不可能だろうから次の言語に期待する

**デフォルトの名無しさん** · 2025/11/22(土) 18:45:43.86

パニックにならずに落ち着いて死ぬような言語がほしいよな

**デフォルトの名無しさん** · 2025/11/22(土) 19:04:52.97

unwrapを禁止するようなコーディング規約ないの？

**デフォルトの名無しさん** · 2025/11/22(土) 19:42:01.39

unwrap()は必ずチェックをしてくれるsafeな関数
unwrap_unchecked()がチェックをしないunsafeな関数
後者はチェックが不要であることを人間が保証する形で用いる

**デフォルトの名無しさん** · 2025/11/22(土) 20:40:38.59

unwrap禁止の次はassertとかunreachableも禁止とか言い出しそうだな

let value = match opt_value {
Some(value) => value,
None => unreachable!(),
};

**デフォルトの名無しさん** · 2025/11/22(土) 21:12:35.60

不定値や未定値や異常値のままプログラムが進まないように
プログラムを安全に停止させるために確実にチェックしてくれるunwrap()がある
これを危険扱いする人がいるとは呆れる

**デフォルトの名無しさん** · 2025/11/22(土) 22:13:14.17

相手にされない三連休に三連投 by 複おじ

**デフォルトの名無しさん** · 2025/11/22(土) 23:23:19.76

>>824
頭おかしい
そんなデタラメなプログラミングするやつがいたらクビ
エラー時は上へ上げるかpanicのどちらか

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

>>835
そんなデタラメなプログラミングとは？

エラーを上へ上げた後どうするの？
panicさせた後どうするの？

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

Rustとしてvalidであるかどうか以外興味がないので知りません

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

> Rustに関してどう思ってますか？
> 正直C++から逃げた人たちが使ってる言語ってイメージですね

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

?でエラーを上に投げて最上部でunwrapしたときにパニックして途中のスタックトレース取れないんだけどどうしたらええの？

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

unwrap は実質的に assert だよ。
ロジック的に失敗するはずがないのに失敗したならその場でパニックさせるべき。
そしてプログラムを修正すべき。

巨大なシステムを突然死させるわけにいかないような場合にどうしても継続するなら最後までなんとかハンドリングしろ。
中途半端に上まで上げてから unwrap とかクソみたいなことをしたらもうどうしようもない。

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

いやいやいや
ヤベェやつしかいねーな

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

外部リソースをオープンしていたら、終了時にできる限りクローズさせるべきで、
エラーを上に上げるというのはクローズ処理までエラーを届かせるということ

panicさせる前にクローズ処理を呼び出すでもいいけど、大抵はクローズ処理を行うポイントは決まっていて、内部ロジックのあちこちで呼び出していいなんてことにはなっていないから、そのポイントまでエラーを届けることが必要になる

外部リソースへのアクセスがないロジックだけのプログラムなら、別にいきなりpanicで落としても問題なくて
あとはデバッグのしやすさのために、どうエラーメッセージを出すかだけの話になる

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

とんでもないプログラマーしかいないなこのスレ
システムは何があっても止めちゃダメなんだよ、不具合があるのは多くの場合は外部とのインターフェースなんだが、いちいち外部からのリクエストの不整合で止めたりしたら客先から鬼電来るの知らんのか？

とりあえず、デフォルト値でもいいから動き続けて様子を見てもらいつつ、その間に詳細な調査をするっていう帳尻合わせや時間稼ぎがないとフィールドのエンジニアからガンガンに怒られるよ

エラーの伝播はそりゃやりゃできればいいが、ログに痕跡残すだけでいいじゃろ。工夫しろ、規模が大きくなればなるほど確率的に何か障害は起きやすくなるけど全部バグを直さなくてもそれなりに動くシステムが健全なシステムだぞ

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

意図を明示するなら unwrap は是
意図を隠蔽するなら unwrap は非

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

>>843
障害の内容とシステム構成によるよ

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

>>842
panicでもデストラクタは呼ばれるから心配すんな
機構は例外と同じだ

https://doc.rust-lang.org/nomicon/unwinding.html

Unwinding

Rust has a tiered error-handling scheme:

If something might reasonably be absent, Option is used.
If something goes wrong and can reasonably be handled, Result is used.
If something goes wrong and cannot reasonably be handled, the thread panics.
If something catastrophic happens, the program aborts.

Option and Result are overwhelmingly preferred in most situations, especially since they can be promoted into a panic or abort at the API user's discretion. Panics cause the thread to halt normal execution and unwind its stack, calling destructors as if every function instantly returned.

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

Cloudflareとかだとabortにしてると思うんだよな

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

>>842
>外部リソースへのアクセスがないロジックだけのプログラムなら、別にいきなりpanicで落としても問題なくて
>あとはデバッグのしやすさのために、どうエラーメッセージを出すかだけの話になる
自分しか使わない趣味のプログラムならそれでいいけど
それ以外のプログラムでそんな雑なpanicしたらダメだよ

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

>>848
これな、プログラマー気取ってるけど要件定義すら怪しい人しかいないよここ
Rust以前の問題かもな。ム板なのに

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

>>848
そうですか、ではなぜダメなのかをご教授ください

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

雑魚のくせにテキトーなこと書いて複おじを調子づかせないでよ～

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

>>850
なぜダメなのかはCloudflareの障害事例を見たらわかるでしょ

原則としてpanicを発生させるコードが許されるのは
サービスを停止してでもプログラムコードのバグ修正が必要な状況のみ

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

対象コードのレビュー履歴を見てみたい
「なんか雑な気もするけどまあいいか」的なやり取りがあったりしたのかも

同様に件のファイルサイズ上限値の妥当性についても

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

旧アーキからエイヤとコピーした際に意図なく混入しただけなオチ

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

現に旧アーキ側ではくだんの障害によるクラッシュなどはしておらず
ただし、すべてのトラフィックに対しボット判定かましてしまい、正規のアクセスまでもがブロックされてしまったわけだが

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

問題なく動いてるフリさせといて異動でバイバイが有能だよ

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

>>843
>>とりあえず、デフォルト値でもいいから動き続けて

そんな酷いシステムはない
まずほとんどの場合にデフォルト値は存続しない

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

誰か>793にまともな反論できんのかな。

panicはプログラム緊急停止という重大な結果をもたらすから、緊急停止した後のことを制御できないなら使うべきじゃない。
このスレみたいに、それすら思いつかない無能コーダーが多いんだから、Safe Rustはpanic禁止すべき。

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

>>858
キチガイだな
誰も賛同しない相手にされない
その意見が通ることはない

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

>>852
Cloudflare って
>外部リソースへのアクセスがないロジックだけのプログラム
なの？

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

んなわけない
>外部リソースへのアクセスがないロジックだけのプログラム
そんなものは存在しないというか、作ることは可能だが実用上存在意義がない

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

>>860
>>842で君が書いてるのはpanicを発生させる時に外部リソースをオープン中で
クローズ処理などのリソース開放処理が必要な状態のプログラムという意味じゃないの？

そういう意味じゃないとすると外部入出力が一切ないプログラムなんて存在しないから
君の主張する「いきなりpanicで落としても問題ない」プログラムは存在しえないことになる

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

>>858
panic禁止は現実的に無理なんだけどunwrapの使用はclippyでかなり制限できるみたい
特に#![forbid(unwrap_in_result)]は使ったほうがいい気がしてきた

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

正しくは #![deny(unwrap_in_result)]だった

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

>>862
うん、そういう意味。

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

>>865
そういう意味ならCloudflareのは外部リソースへのアクセスがないロジックだけのプログラムと言える

でも外部リソースの後片付けをした後ならpanicしていいわけじゃないからpanicが許される状況かどうかの判断基準としては適切じゃないよ

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

>>866
> 外部リソースの後片付けをした後なら

ええと、話の前提として、プログラムやサービスをこのまま動作させることが適当でないエラーが発生した状況で、というのがあると思うんだが

今ここで話をしているのは、プログラムやサービスをこのまま動作させることが適当でないエラーが発生しうる箇所で、意図的に unwrapやpanicを使って終了させて良いか、そうでなくてエラーを上に上げるべきという意見が出たけどそれはどういうことか、という話だと思っていたんだけど違うのかな

それで >>842 で、外部リソースをオープン中ならその場で即終了するのはダメでクローズする必要がある、そのためにエラーを上に上げるべきで、そうでないならそこで終了しても問題ない、と答えたんだけど、それ以外にどんなケースや判断基準があるだろうか

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

いやTCPのコネクションを開いてるでしょ

**デフォルトの名無しさん** · 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
これまで誰も困っていないのならば
あなたがおかしい可能性を疑ってみてはいかが