Rust part33

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

>>576
sqlite担当へチャネルを使ってリクエスト
sqlite担当はそのチャネルに来たリクエストを次々と処理する

**デフォルトの名無しさん** · 2025/11/07(金) 17:22:18.89

>>577
iphone, androidで安定的に動く唯一のRDBであるsqliteがシングルスレッドでしか動かないからどうしようもないんですよ

>>578
自分も同じ結論に落ち着きました
本来なら非同期処理で書くべきようなことまで、ループ処理やタイムアウトを多用して同期で書くからムズムズするけど

**デフォルトの名無しさん** · 2025/11/07(金) 17:22:46.88

>>576
sqlx::SqlitePool

**デフォルトの名無しさん** · 2025/11/07(金) 17:36:37.18

>>580
ああっ。確かにsqlxを使う選択肢はありますね。失念してました
自分は実践でsqlxではなくrusqliteを技術選択しました
RDB用の単スレッドで動作させるならば、sqlxよりrusqliteの方が速いからです
別スレッドを立て、タスク管理をしてまでスループットを上げたいという条件下でsqlxは選びにくいと感じました

**デフォルトの名無しさん** · 2025/11/07(金) 17:38:03.28

>>576
sqliteは非同期には対応してないがマルチスレッドには対応していてシングルスレッド前提ではない
同時に書き込めるのは1コネクションだけなので書き込み処理を一つのスレッドにまとめる方法はよく採用されるけどそれをシングルスレッド前提と言ってる？

いずれにしろ非同期のラッパーを書いて同期部分は一箇所に隠蔽すればいいだけ
ラッパーが用意されてるライブラリもある

**デフォルトの名無しさん** · 2025/11/07(金) 17:39:57.53

>>577
バックエンドサーバーの話じゃなくてUIコード(フロント)から呼ばれるライブラリくらいの意味でバックエンドという言葉を使ってるのだと思う

**デフォルトの名無しさん** · 2025/11/07(金) 17:47:33.29

>>582 >>583
自分の言葉の選択の曖昧なところまで含めてすべてお見通しですね
Sqliteがシングルスレッド前提ではなく、制約がコネクションにかかること指摘ありがとうございます
同期のコードを集約して、非同期で包む方向で実装を進めていました。ライブラリについては調べてなかったです。有益な情報ありがとうございます
丁度そのあたりのコードで自作が増えて実装が複雑化しはじめていた頃なのでツールを調べてみます

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

いつから健全なスレになった

**デフォルトの名無しさん** · 2025/11/07(金) 20:31:07.75

sqliteて最近はcloudflareでも使われてるし最近流行ってるらしい🧐

**デフォルトの名無しさん** · 2025/11/07(金) 22:19:46.72

ワークロード的に明らかに問題が出ることが分かってるというのでなければ
とりあえずspawn_blockingを使うだけの方法から始めてもいいと思う

**デフォルトの名無しさん** · 2025/11/07(金) 22:33:36.98

>>582
彼の用途でそのマルチスレッド対応は意味がなくてスレッドMutexにより非同期タスクスケジューラのスレッドをブロックしてスケジューリング妨害となってしまう
つまりスレッドMutexではなくawaitで待つ非同期タスクMutexを使うべきだがsqliteは当然対応していない
そこでシングルスレッド前提で使う話なのかなと理解した
マルチスレッドで使う場合も非同期タスクとは別スレッドのsqlite用のスレッドプールを用意する形になるかと

**デフォルトの名無しさん** · 2025/11/08(土) 01:31:09.85

Debianのパッケージマネージャーであるaptが部分的にRustで書き直された影響で
RustがコンパイルできないマイナーなアーキテクチャがOSサポート停止になってしまうらしい
これは恨みを買うね

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

aptのメンテナーすごい判断したな
メリットの方が大きいと踏んだからだと思うが、ノイジー・マイノリティの影響力を舐めてるわ

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

実質的なメリットよりモチベーションの問題でしょ
DebianはLinux界隈の中では比較的大きな組織とはいえ所詮はコミュニティプロジェクト、
Rustを使えるならと活発に貢献してくれる若い奴1人のモチベ＝[ションは開発ｂｱける上で大ｂｫなファクターｂｾ
でも成演ﾊを享受するだｂｯのユーザーはｂｵばしば、大きｂﾈ企業の製品と涛ｯ等の体制や責粕Cがあるように滑ｨ違いしてるんｂｾよね
まｂRustの方はもｂﾍやコミュニテャBプロジェクトｂﾅはなく壮々たｂ髑蜉驪ﾆが顔を�Aね潤沢なリソ＝[スを有する組瑞Dなので、同様ｂﾌ言い訳は許さｂ黷ﾈいけどね

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

シェア低くてもサポートしてほしいなら、自分でフォークして保守せえやってのが本来のOSSだからな

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

https://lists.debian.org/deity/2025/10/msg00072.html

> alpha, hppa, m68k, and sh4

どうでもよ……

**デフォルトの名無しさん** · 2025/11/08(土) 17:35:27.61

詳しくないんだけど、サポート外になるCPUってどんなの？
古いPCに使われてるものなのか、それとも組込み機器など特定分野で使われてるものなのか
AMDやARMしか知らないから、実際どういうところが影響受けるのかいまいち想像が付かない

**デフォルトの名無しさん** · 2025/11/08(土) 17:37:34.34

>>594
誰も使ってないから気にしなくていいよ

**デフォルトの名無しさん** · 2025/11/08(土) 17:46:52.09

Cで書こうがRustで書こうがllvmではコンパイルできない感じ？

**デフォルトの名無しさん** · 2025/11/08(土) 18:37:24.47

>>588
意味なくないよ
マルチスレッド対応してるから
データをバッファに貯めてからまとめてDBに書くような処理を実行しながら
ユーザーアクションに応じたデータを同じDBから読み込んで表示するみたいなことが同時にできるわけで

とりあえず同期/非同期とシングルスレッド/マルチスレッドを区別しようよ
長時間かかる同期処理を通常の非同期タスクスケジューラにそのまま投げたらダメだということと
sqliteのマルチスレッド対応状況とは何の関係もないからさ

**デフォルトの名無しさん** · 2025/11/08(土) 18:51:24.50

そんな話は誰もしていなくて>>579氏はsqliteが非同期対応していないもどかしさを述べてるね
素直に let res = sqlite. request(x).await; と書きたい話だと思うよ

**デフォルトの名無しさん** · 2025/11/08(土) 19:28:31.98

シングルスレッドかつ同期 => 悪い
マルチスレッドまたは非同期 => 良い
シングルスレッドかつ非同期 => 書けない

非同期とマルチスレッドの二刀流のようなものが正解

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

Rustはマルチスレッド非同期がデフォルトだよ
事情があればシングルスレッド指定しても非同期使えるけど

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

>>600
Rustがじゃなくてtokioがじゃない？
言語そのものは非同期ランタイムなんて持ってないわけだし

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

いや、ほとんどの場合はマルチスレッド同期でじゅうぶん
なにかと非同期にしたがるのは意識高い系の所業

**デフォルトの名無しさん** · 2025/11/08(土) 21:44:26.91

昔はselectやpollで捌いていたけど
Rustの非同期タスクとtokioスケジューラで便利になったよ
意識が高いではなくプログラミングのしやすさと実用面から非同期が使われてるの

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

なんでも文字列で入出力したらGCの意識じゃなくて価値が低くなる
価値を高騰させろ
循環参照を考えろ

**デフォルトの名無しさん** · 2025/11/10(月) 20:26:15.74

rustのクレートは公式が作ってるやつかそうじゃないやつか区別する方法ある？

**デフォルトの名無しさん** · 2025/11/10(月) 20:35:29.89

クレート　←全て非公式
標準ライブラリ　←公式

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

どの言語でも
公式だから保証があるわけでもなく
公式だから非公式より良いとは限らず
公式の意味も範囲も様々だから拘ってもしょうがないよ

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

知覚は不完全なので
存在すること＝知覚されること
とは言えない
また、目に見えないものがあるから目は役に立たない、とも言えない

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

開発チームの人が作っているクレートなんかだと準公式くらいの立場のものはあるが、逆に言えばそこまで作っていて標準に入れないのは相応の理由があるのかもしれない。
個々に検証しないとわからん。

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

Rustは開発ルールがガチガチすぎるんよ
俺はその恩恵をただ受ける側だからいいけど作ってる神々は燃え尽きかかってる

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

だからまずC++で作ってそれからRustで作り直すのが正解

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

>>610
開発ルールがガチガチすぎるって何？
どこで誰が何をする時の話？

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

>>612
ごめん。ほとんど独り言のつもりで書いた
Rustプロジェクトが、破壊的変更禁止とメモリ安全とスレッド安全と型安全とゼロコスト抽象化のすべてに
妥協を許さない方針を取ってるの、冷静に考えると狂ってるなーと

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

それらを守らない言語があったらヤバくね？

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

時間を守らないっていう妥協をしてみるといい
それで、時間だけは絶対守れと言い出したらそいつが神々を疲弊させた狂人だ

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

おいどん、コンピュータさんて0か1しか分からないのになんでcやらrustとかあるのがわからない
機械語マスターすればreactだのrustだのの「流行り」に惑わされること、なくなるやん？😊

**デフォルトの名無しさん** · 2025/11/12(水) 15:55:18.49

CPU の設計理念にも流行はあるよ。

**デフォルトの名無しさん** · 2025/11/12(水) 16:34:57.41

>>616
機械語でプログラムを作ると異なるアーキテクチャのCPUで動かない
機械語でプログラムを作るよりRustで書いたほうが楽で保守性もいい
実行速度もよほど手動で頑張らない限りRustで書いた方が速い
その理由はコンパイラがループ展開や並列化を含めた様々な最適化をしてくれるため

**デフォルトの名無しさん** · 2025/11/12(水) 20:01:46.19

>>616
おう、0と1でモンハン作ってみようぜ！

**デフォルトの名無しさん** · 2025/11/12(水) 20:14:40.22

機械語と言っても日本語や英語のように多くの系統と方言があるからなあ

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

機械語でアプリを書くとなるとABIやカーネルコールの仕様も把握してないといけないしな

**デフォルトの名無しさん** · 2025/11/12(水) 23:27:09.63

Rustの中にインラインで機械語を書けて便利だよ
asm!
naked_asm!
global_asm!

**デフォルトの名無しさん** · 2025/11/12(水) 23:39:25.75

>>622
それ機械語じゃなくてアセンブリ言語な👈

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

それは同じ

**デフォルトの名無しさん** · 2025/11/13(木) 01:48:22.68

CPUは商品だから次々と流行らせるが
C言語はもう物を売るってレベルじゃねえし二転三転させる意味がない

**デフォルトの名無しさん** · 2025/11/13(木) 03:31:15.53

>>616
Hello World!を表示するだけのx86-64版Mach-Oバイナリの例だよ
これでモンハン書けと言われたら辞表提出するね
https://i.imgur.com/VQv4ClC.png
https://pastebin.com/W13JSs1a

**デフォルトの名無しさん** · 2025/11/13(木) 19:03:40.70

https://www.phoronix.com/news/sudo-rs-security-ubuntu-25.10
Ubuntu 25.10 で採用された Rust 版 sudo（sudo-rs）に中程度の脆弱性が2件見つかり、sudo パスワード漏えいの可能性などが指摘されている

安全神話が崩壊しちゃったね

**デフォルトの名無しさん** · 2025/11/13(木) 19:09:10.61

>>627
どういうタイプの脆弱性？
メモリ関係ではないの？

**デフォルトの名無しさん** · 2025/11/13(木) 19:40:16.39

>>628
パスワード入力中にタイムアウトすると
入力文字列を標準出力にエコーする普通の動作に戻ってしまった時にパスワードが画面に表示されてしまう漏洩リスクらしい

別問題としてPAMを扱うコードのunsafeまみれを指摘する人がいた
https://imgur.com/a/j2hu5qL

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

ソフトウェア設計上のミスは防げねえわな

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

須藤て別にc版でいいと思うけど既存のコードをristにするてメリットあるんかな
速度とか負荷とゆう点ではc rustてそんな変わらないんでしょ

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

>>631
sudoのC版はこれまでに無数の脆弱性が報告されてきていて今年の7月にもCVE-2025-32462とCVE-2025-32463が出ています
今後も対応のためにコードを修正する可能性があるため基本的なところでエンバグしないようRust版にするのもアリでしょう

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

>>627
Rustが安全って言われる理由を調べず、Rustならあらゆる脆弱性は起きないと主張されてると解釈する人は
ちょっと自頭が悪すぎるので、筋肉しか使わない末端の肉体労働者したほうがいいと思う

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

>>629
なんでそんな脆弱性を作っちゃったのかね？
Rust版特有の脆弱性なんだよね？

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

>>633
今は筋肉だけ使う肉体労働者はいらない

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

タイムアウトするとパスワードを表示するというプログラムを作ったわけか

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

rawモードがcookedに戻ればそうなるよな
パスワード入力中以外では正しい動作

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

仕様上もテスト設計上も基本的な状態遷移を整理できていないということだからかなり深刻なバグ
他にも同じ原因のバグがあると思って間違いない

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

Rustとは全く無関係な要因で一安心

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

よかった！Rustは安心安全なんだね！

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

ロジックの穴を潰すのは完璧な手法など存在せず、見つかる度に修正し続ける歴史の積み重ねだ。
最初から書き直すならその歴史もやりなおし。

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

Oct 9, 2020
Memory Safe ‘curl’ for a More Secure Internet
https://www.memorysafety.org/blog/memory-safe-curl/

4 years later

Dec 21, 2024
Curl Drops Support For Hyper Rust HTTP Backend Citing Little Demand
https://www.phoronix.com/news/Curl-Drops-Rust-Hyper-Backend

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

>>638
構造的な問題だな
バザール方式 + 質の低い開発者 => バグだらけのソフトウェア

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

逆にRustアンチの仕業と見做す信者はいそう

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

Rustが質の低い開発者を引き寄せる側面があるんだろう

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

言語に自分のアイデンティティを求めちゃう人は開発者として質が低いよね。
そしてRustがその手のタイプを引き寄せる傾向があるのは残念ながら事実。

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

言語にアイデンティティ持つような考え方は体育会系に多いだろうね
組織に対する忠誠心みたいなのと言語アイデンティティは同一だと言われるし
頭空っぽの体育会系Rustceanを追い出さないと質は下がる

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

結局、仕事では言語に選択肢無いので。
言語にこだわるのはプログラマーじゃなくて（私のような）言語オタク。
ただ、Rustは自動運転関連で自動車メーカーが注目してるので勉強だけはしておいた方が良い。
（GCで止まるわけにいかないし、メモリリークも出したくない分野）

言語オタクとしてはRustよりHaskellが好き。
中の人がMSに就職してからC#並みに速くなった。
（昔はコンパイラ言語なのにPythonと同程度だった）

でも実務だとPHP＋SQL＋HTML5ばかり…。
アルゴリズムとかよりSQL（を包んだPHPのメソッド)でいかに目的のデータを抽出するかの方が重要みたいな…。
なんかコレジャナイ感。

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

仕事だとjavaが多そうだけど文法もそうだけどspringのディレクトリ構成ゴミすぎて嫌になる
com exampleてなんやねん
ossでまったく使われてないからかなり嫌われてるんじゃろうなとは思うけど

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

JavaをやるってのはSpringをやることだと言っても過言じゃないぐらいあれ1強だからなあ
せめてRailsのパクりみたいなのがJavaでも幅効かせてたら、趣味でもメインにしてたかもしれない

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

>>645,646
フクリンのことか───────っ!!!!!

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

>>649
JavaはAndroidだろうがSpringだろうがディレクトリ構成にドメインをひっくり返したディレクトリ階層を使うだろう
その階層がクラス名にそのまま適用されてクラス名をユニークなものにする
デフォルトはcom exampleになってたりするけどちゃんとした開発ならばユニークなドメイン名を使う

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

Moving From Rust to Zigって記事に
Rustはコンパイル単位がクレートで、クソ遅いコンパイルを改善するためにクレートにまとめたいけど
論理的な構造とクレート単位にずれがあるとやりづらい
更にcrates.ioに公開すると、コンパイルの都合で分割した内部用クレートが公開用クレートと同じ並びに出てきて混乱を招く
って書いてあった

**デフォルトの名無しさん** · 2025/11/15(土) 07:40:31.46

会社でRustやらされてるヤツは負け組

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

みんなRustを使いたい

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

Rustを使いたい派がいるのか社内でRust製の試作がちょこちょこ出てきた

**デフォルトの名無しさん** · 2025/11/15(土) 19:16:17.52

まあ、営業的にもCやC++の組み込みをRustなら（実際は確率が低くなるだけだが）メモリリークが無いものに刷新できますよ！と営業トークできるからRust使えるプログラマーが確保できれば新規開拓しやすくなるやね。

**デフォルトの名無しさん** · 2025/11/15(土) 19:36:39.90

学生にとっても、著名なOSSにメモリ安全性で難癖付けて単純移植するだけで就活に使える実績を作れるからな
構造的に言語アイデンティティ君を生む宿命にある

**デフォルトの名無しさん** · 2025/11/15(土) 19:40:09.72

今どきの大学生はとりあえずTypeScriptとRustをやりPythonを常識程度に触るのがトレンド

**デフォルトの名無しさん** · 2025/11/15(土) 19:46:24.27

社内でRustをPRしたら、「似たようなもんだから」とC++のチームに異動させられて最悪の気分だわ

**デフォルトの名無しさん** · 2025/11/15(土) 20:32:38.21

塗り替えろって事だろう

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

>>659
Rustなんて何でもありだから、とりあえずPustなんていうやつは素人。

**デフォルトの名無しさん** · 2025/11/16(日) 08:48:05.53

そうだね。
Pustなんていうのは素人だね。

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

フリック入力ならじゃないのか？

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

>>664
フリック入力じゃないのか？

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

>>657
人材派遣みたいな企業でRust使うか？
発注側にとっても、リソースが足らないから外注してるわけで、そういう組織で開発者人口の少ない言語を選ぶのってリスクでしかなくね？

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

>>666
あ、そうね。
純粋なソフトハウスってそういう形態だったね。
医療機器メーカーとか自動車メーカーの開発陣を想定してた。
ソフトハウス的なところだとRustプログラマーの数だけでなく、そのメンバーで何が作れるのかも把握できないと商売にならんね。
ピンチはチャンスなので、自社で鉄板の環境構築するなり、ライブラリ整備して得意ジャンル持てば逆に強みになるだろうけど。

**デフォルトの名無しさん** · 2025/11/16(日) 22:08:25.71

>>96のRustのフリーランス単価が1位になった理由は需要が確実にあるのに人材が足りないためなの？

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

Rustの一番駄目なところはなぜか誰も使ってないところ

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

知能が低いとコンパイルを通せないか回避のためメモリをムダに豪快に使ったコードでバレてしまう恐ろしい言語

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

そんな欠陥言語なの？

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

実際スクリプト上がりの意識高い系なんかは
基礎の所有権すらさっぱりでcloneの嵐なコードを書いて、Rust使い気取ってそう

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

一生懸命clone減らして、ライフタイム注釈まみれの読みづらいコードに書き換えたところで
大して速くならないオチ

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

>>669
なぜか学習コストが高い（難しい）と思われているから。
Haskellも別に分からなくても良いモナドで似たような状態。
（もともと関数型言語自体が使われてないが）

それでもHaskellは関数型言語の中ではLispに次いで有名になったし、Rustもなんだかんだでシェア伸ばすと思われ。
ライブラリが揃わないうちは、そもそもライブラリが使えない環境の組み込みから伸びるかも。

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

というか、GCがあっても問題にならない分野じゃJavaやC#よりC/C++/Rustが速いって言っても、そんなに問題になるわけじゃないからわざわざ移行はしないかな。
Rustで重要なのは速度とGC無しのリアルタイム性とメモリ安全性の３つが高度にバランスが取れているから。

メモリリーク出したくないけどリアルタイム性が問われる分野以外はあまり移行する旨味が無い。
（移行するコストにメリットが見合わない）

なので医療機器や車載分野以外はスタートアップ企業が主になると思われ。

**名無し** ◆WBRXcNtpf. · 2025/11/16(日) 23:23:36.23

テテす

**名無し** ◆WBRXcNtpf. · 2025/11/16(日) 23:23:37.42

テテす

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

あ、ゲーム分野もか。
PS６（仮）みたいなコンシューマーだとメーカーが開発環境提供するから、メーカーがRustに積極的か否か。
PCゲームならC++より開発速度上がりそうだし、ワンチャンって感じか。

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

>>673
その視点が既に間違っている
ライフタイム注釈があると可読性が上がる

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

>>675
Rustで昔から最も開発が盛んで利用が多いのはWeb分野

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

Rust がゲーム作成に有用だとしたらゲームエンジン部分、下支え部分だと思う。
ゲームの面白さというのはやってみないとわからんということが多い。
設計してから具体化するというウォーターフォール的な開発ではなく大雑把に作ってから試行錯誤で細部を詰めていくのでメモリまわりのチューニングなんて後回しにしたい。

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

速さはjavaとかとそんな変わらんだろうけどハードウェアにかかる負荷は結構違う希ガス

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

Javaより速い遅いじゃなくて、クラウド環境でメモリケチりたいからRustなんじゃないの？

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

>>682
それはある。
クラウドはリソース消費量に課金されるからユーザーから見た性能が同じでもリソース消費を抑制できるほうが有利。

なんだかんだで「儲かる」のは広告業界なんだよ。
ウェブの世界のマネタイズは広告が中心。
Rust がウェブの世界で求められるのは Rust が開発に向いているというよりも、たとえ向いていなくてもコストをかけて性能を出せばそれ以上のリターンが見込めるという経済的な理由だと思う。
ある程度は向いていると思うけど、開発のしやすさとしては決定的にウェブ向きとは感じない。

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

ライバル同士のIT大手企業たちが超珍しく新言語に対して手を取り合って支持を表明した最大の理由は初めてウェブでちゃんと使える言語が登場したことが大きい
クラウドもCDNも何でもウェブベースなのでそこで実用的に使える言語を誰もが欲していた

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

各スクリプト言語のライブラリやツールが最近はRustで書かれるようになったね

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

>>680
でも大企業とかじゃなくてスタートアップかオープンソースのボランティアでそ。
求人情報に載るような分野としては多分Webよりそっちのが多くなる。
（見てないから分らんけど、現状でもその可能性はある）

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

開発しやすいRustへ流れてるな

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

>>687
思い込みが激しすぎ

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

>>686
PythonやNodeはたしかにそうだね
RubyやPerl、PHPはどうなんだろ？

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

>>687
大企業が採用したことが普及した決め手だよ

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

>>682
>>683
人を雇ってまでそこをケチる余裕がある企業はそうするかもね。
でも、すでにもう、一度作ってるのをRustで作り直してまでケチりたいと思う企業ってそんな多くない。

C/C++しか選択肢が無くて辛酸辛苦を舐め続けてきた組み込み分野の方がコスト掛けてでもRustに移行する圧力が上がりそうだし、組み込み分野に広がらないなら、他の分野でも大して広がらない。

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

>>668
高スキル層の求人しかないからだよ

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

>>689
そういう場所だもん。
妄想大爆発☆

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

色んな分野でRustが採用されていってるけどPythonやNode.jsの高速化ツールやライブラリでこんなにRust製が広まるとは驚いた

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

>>691
別にゼロサムゲームじゃないし、採用する大企業もあるだろうけど、多くの大企業で採用されているからソフトハウスもRustプログラマーを大量に確保しようって程には普及しないと予想してる。
Webアプリは別にOOP前提じゃないからRustでも良いんだろうけど、余程多くのアクセスが無い限りRustに移行するほどの旨味は無い。
大企業が～だったらElmだって楽天に採用されて、その後やっぱダメだわってなってる。
Elmそのものってよりシングルページアプリケーション(SPA)が原因だったみたいだけど。
なので、大企業に採用されたから注目は集めても、普及するに至るかは別問題。
Haskellだって今の台湾のデジタル大臣（オードリー・タン）が仕様を公開したPerl本家より速くHaskellでPerl6（言語仕様が違い過ぎて現在はRakuという別言語）の実装を完成させたのが注目されたが、それほどの開発効率を誇るHaskellが今どうなっているか。

すでに持っているコード資産を捨ててまで移行する価値がある分野は上記の医療機器や車載などの高付加価値の組み込み分野。
（ただ、言いたいのは私自身はRustの普及を望んでいる。その先に関数型言語の普及を夢見ているから）
（望み薄なのは言わずもがなだが、夢見ても良いぢゃない）

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

>>696
それらの言語がだめだったのは遅いポンコツ言語だったから
Rustがウェブ方面で企業に採用されたのは速くて使いやすい唯一の言語だから

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

>>697
もちろんWebだって速いに越したことはない。
だから伸びてもおかしくは無いけど、RailsやWordPressも依然として大きなシェアを持っている。
特にWordPressはもはやフレームワークを超えてブログや静的なただのHPを作る分にはアプリと言っていい。
PHPはどうしても使いたい人向けに残しているだけで、コーディング必要ない。
（もはやPHPはJavaのJVMみたいな位置付け）

WordPress本家はDLして使うスタンドアローン版とWebアプリ版を用意していて、Webアプリ版は「安全のため」PHPそのものを使えなくした。
（元はPHPのフレームワークだったのに）

ブログ作成専用のフレームワークという用途を限定していたから出来たことだけど、Webに求められる開発速度はすでにそういう次元まで来てる。
そしてレンタル鯖のことごとくがWordPressに別料金を取ってる。
フレームワークにお金請求してるのはWordPressしか見たことない。
それでもシェアが増え続けている。

実行速度より開発速度の方が重要だという証拠。

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

>>698
WordPressはリソースの無駄遣いだから追加料金がかかるのも仕方ないかと

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

>>698
それ意外にRustがぴったりの分野かもよ
ユーザーにとっては内部で動いてるものがPHP製かRust製か気にしないのだから世界中の電気代とハードウェアリソースを節約できるチャンスだったりして

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

>>700
バックエンドだけでお腹いっぱい
Rustでフルスタックはロクなのないや

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

>>701
何を言ってるの？
PHP版WordPressやPython版MezzanineのRust版が商機とエコを実現させる話だよ

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

Rustがマネジメント層で流行っているのはバッファオーバーランをやらかす無能コーダーを排除したいからじゃないの？
ビルド通らなきゃ成果０で報酬払わなくていいし。

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

コード資産の観点が無いのかコード資産を物ともしないスーパープログラマなのか意識的に無視してる(欲ボケ？)のか何なのだろ

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

Rustが一番使われてる分野はlinuxコマンドの置き換え

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

Rustの求人はここが毎月レポート出してるけど会社名とか見ると結構面白い
https://filtra.io/rust/jobs-report/oct-25
今月は防衛産業のAndurilが求人数トップだね

**デフォルトの名無しさん** · 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が正しかったとはとても思えない。