Rust part30

**デフォルトの名無しさん** · 2025/05/28(水) 09:31:36.60

公式
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 part29
https://mevius.5ch.net/test/read.cgi/tech/1746200850/

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

**デフォルトの名無しさん** · 2025/06/13(金) 18:16:39.57

特定の言語でプログラムが書けるみたいな狭義かつ低次のプログラミングスキルは特定メーカーのワープロでタイピングができるとか特定メーカーの表計算ソフトが使えるとかそういうのと同じコモディティ化したスキルになっていく

大事なのは特定の言語に依存しないメタなプログラミングスキルのほう

**デフォルトの名無しさん** · 2025/06/13(金) 18:27:02.35

それはそうだけど個別言語スレで言うことじゃないすぎる

**デフォルトの名無しさん** · 2025/06/13(金) 18:27:31.78

>>778
コーディング能力は既に人間の方が下だから、下等な我々が細かく指示出すより、
ブラックボックスの仕様から好きに実装していただいて説明してもらった方がよい

**デフォルトの名無しさん** · 2025/06/13(金) 19:32:43.29

コモディティ化してもしなくても偶然にすぎない
偶然の産物は観察や考察するよりも編集してカットしたほうがいい
しかし編集すればするほど雑音が増えると思ってる人達にはそれができない

**デフォルトの名無しさん** · 2025/06/13(金) 19:45:58.10

>>779
その通り
特にRustも使えないと今後はプログラマ失格

**デフォルトの名無しさん** · 2025/06/13(金) 22:56:19.01

jemallocはマジで終了だってさ
https://jasone.github.io/2025/06/12/jemalloc-postmortem/

**デフォルトの名無しさん** · 2025/06/13(金) 23:27:33.59

>>784
終わってない、とかほざいてた人はどうなん？

**デフォルトの名無しさん** · 2025/06/13(金) 23:44:49.92

>>784
2017年にFacebookを去った時点で手を引いて現Meta管轄なんだな

**デフォルトの名無しさん** · 2025/06/14(土) 00:01:13.21

>>786
その記事の内容を読んでそういう感想なら死んでるのと変わらない

**デフォルトの名無しさん** · 2025/06/14(土) 13:57:15.87

形式的には Meta が管理下に置いていたプロジェクトであるというのは間違いではないでしょ。
その上で Meta は全然やる気がなくなってるというだけで。 (少なくとも Jason の視点ではそう見えている。)

**デフォルトの名無しさん** · 2025/06/14(土) 14:50:51.36

凄腕のエンジニア達が長い時間をかけて育ててきたjemallocといえども、
アリーナアロケーションのようなアプリケーション依存の原始的な手法には敵わないってのは虚しい話だな
特にRust信者はともすると小手先の技巧にかまけて視野が狭くなりがちだから気をつけなければならない

**デフォルトの名無しさん** · 2025/06/14(土) 15:08:08.30

jemallocがMETAの管理下に入ってMETA寄りの機能を実装する開発方針に切り替わった
そして一般よりの機能を削減して一般からそっぽを向かれた
作者自身も一般からの需要にが付いていなかった

結局jemallocはMETA向けに局所最適化されてそこから一般向けに戻すにはかなりの人員と労力が必要だけど
それに見合うだけのメンテナーも資金もどこからも出てこない
実質死んでますよと

こういう内容

**デフォルトの名無しさん** · 2025/06/14(土) 15:13:02.44

資金力があるところに吸収されて開発されてもそれが必ずしも良いことではないと言うことだ
吸収する側には目的があって吸収して機能を実装し終わったらそれでもう満足なんだ

**デフォルトの名無しさん** · 2025/06/14(土) 15:48:51.99

万能なメモリアロケータは実現不可能
どういう用途に効率を特化するかで無数に分かれる

**デフォルトの名無しさん** · 2025/06/14(土) 15:53:14.56

>>789
最適なタイミングでまとめて確保と解放するアリーナ方式が最も性能出るのは自明

**デフォルトの名無しさん** · 2025/06/14(土) 19:21:21.54

mRNAワクチンの“新たな懸念”接種済み妊婦の子どもに「異常タンパク質構造」血中で確認★2 [Gecko★]
2025/06/14(土) 15:48:24.59
https://asahi.5ch.net/test/read.cgi/newsplus/1749883704/

・ワクチン問題になっている

**デフォルトの名無しさん** · 2025/06/14(土) 20:11:15.75

jemallocがRustから外されて各OSの標準アロケーターに戻った理由も重要だよね

**デフォルトの名無しさん** · 2025/06/14(土) 22:46:25.65

性能は用途により一長一短
特定のアロケータが標準だとバイナリサイズで不利なため

**デフォルトの名無しさん** · 2025/06/15(日) 00:30:17.16

#[global_allocator]標準化が1.28でjemalloc非標準化が1.32だな
外した理由はブログで書いてる
https://blog.rust-lang.org/2018/08/02/Rust-1.28/#global-allocators
https://blog.rust-lang.org/2019/01/17/Rust-1.32.0/#jemalloc-is-removed-by-default

**デフォルトの名無しさん** · 2025/06/15(日) 00:56:18.63

システム開発言語であるのにシステムのメモリアロケーターを使っていない

**デフォルトの名無しさん** · 2025/06/15(日) 00:59:44.98

Rustにおけるシステムプログラミングというのは「ケチ臭いプログラミング」と読み替えるとよい
必ずしも低レベルであることを意味しない

**デフォルトの名無しさん** · 2025/06/15(日) 09:10:25.99

jemalloc使用するとメモリが300kb消費されると
rustプログラム一個につき300kb

**デフォルトの名無しさん** · 2025/06/15(日) 21:04:59.71

組み込み開発はRust一択

**デフォルトの名無しさん** · 2025/06/15(日) 21:27:38.86

WEB開発もERust一択

**デフォルトの名無しさん** · 2025/06/15(日) 21:37:03.14

今日もRustで組み込み開発しちゃった

**デフォルトの名無しさん** · 2025/06/15(日) 22:40:54.62

俺はC++で開発し続けているが。

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

組込みデバイスのRustのサポート状況ってどうなん？
少し前にNVIDIAのJetsonを触ったことがあるんだけと、SDKやサンプルはC++が基本だったと思う
(例えばJetson multimedia APIというのがあって、デバイス付属のGPUで動画をエンコードする等ができるんだけど、これはC++のクラスを使うAPIだから他の言語からFFIしづらい)

こういうのがRustに対応するようになるまでは、この分野はまだしばらくC++中心になるんじゃないかと思う
ラズパイなんかはRustの話も聞くし、できることは増えてると思うけど

**デフォルトの名無しさん** · 2025/06/16(月) 02:15:29.18

メジャーなCPUならそれなりに対応してると思う
https://doc.rust-lang.org/beta/rustc/platform-support.html

SDKは需要とベンダーのやる気次第

**デフォルトの名無しさん** · 2025/06/16(月) 05:39:40.78

ヌルポ😳😳

Google Cloud、世界中のリージョンが影響を受けた大規模障害、原因は管理システムがヌルポインタ参照でクラッシュしたこと
2025年6月16日
https://www.publickey1.jp/blog/25/google_cloud_3.html

**デフォルトの名無しさん** · 2025/06/16(月) 06:07:30.55

記事あんま理解できてないけどヌルポインタってそんなにまずいもんなの？
コンパイラーが検出してくれるし、スコープから外れた変数はドロップされるからそもそも参照されないかと思ってた

**デフォルトの名無しさん** · 2025/06/16(月) 06:43:29.69

ヌルポインタ参照って
プログラムをCとかunsafeとか使わずにRustで全て作ってるとしたら起き得ないことであってる？

**デフォルトの名無しさん** · 2025/06/16(月) 08:20:04.56

>>808-809
ヌルポインタの問題は型の非互換性、本質的には機能の非互換性の問題。

古いJavaで顕著だけど、ヌルポインタは何の機能もサポートしないのにコンパイル時はほとんどすべての型に化けることができるから、コンパイル時に問題を発見できずに実行時に問題になることがある。
本来なら互換性を保つためにヌルオブジェクトとかを使うべきだけど、言語で禁止しているわけではないので、低能力コーダーとか無能ライブラリアンとかはヌルポインタを返す関数とかを作って問題になる。

safe rust は基本的にヌルポインタを使えないので、このようなトラブルになることは少ないかと。

**デフォルトの名無しさん** · 2025/06/16(月) 11:48:14.62

問題の本質はヌルポじゃないだろ
publickeyの人はそれがわかってない

てかGoogleの品質管理体制も杜撰すぎるな

**デフォルトの名無しさん** · 2025/06/16(月) 12:21:10.35

ガッ！

**デフォルトの名無しさん** · 2025/06/16(月) 12:30:45.07

空白のフィールド含んだだけでクラッシュとかよく分かんないよ
俺がテストせずにこのプログラムをリリースさせた責任者だったら会社に残れないな。明らかにテスト捏造してるから
——
新しいポリシーデータには意図せず空白のフィールドが含まれており、これをサービスコントロールが読み込んで実行したところ、ヌルポインタ参照となりクラッシュが発生します
——

**デフォルトの名無しさん** · 2025/06/16(月) 13:38:36.81

要は不具合を引き起こす特定のパターンがあり、テストで発見されなかったってことだろ
たまたま結果としてヌルポでクラッシュしただけで、仮にヌルポの可能性に気づけていたとしてもそれ自体がバグの原因でない以上、
問題のパターンが別の形で障害を起こしていた可能性を否定できないな

**デフォルトの名無しさん** · 2025/06/16(月) 14:56:07.05

もしRustで実装していれば、パニックですんでいたのにな

**デフォルトの名無しさん** · 2025/06/16(月) 15:28:10.23

今回の事態を招いた最も重大な要因は「リリース手続きの欠陥」であって、ヌルポ参照という"クラッシュに至る個別の事象"に着目した対策に終始するのは悪手（ヌルポ参照以外の要因で本件のような事象が再発しても良いのか、という問いにyesと答えることに他ならない）

**デフォルトの名無しさん** · 2025/06/16(月) 15:38:50.32

>>814
>要は不具合を引き起こす特定のパターンがあり、テストで発見されなかったってことだろ

特定のパターンというか「新機能のために新しく適用する全世界共通のポリシーデータ」と「新機能」の組み合わせでクラッシュするんだから本番環境に適用するポリシーデータでは一切テストしてなかったってことでしょ

feature flagがなければステージングでのテストも行わず本番と同時適用ってのも意味がわからない

**デフォルトの名無しさん** · 2025/06/16(月) 15:40:30.06

>>815
パニックでも結果は同じ

**デフォルトの名無しさん** · 2025/06/16(月) 16:50:55.12

>>815
Rustで実装していればOption型になる
unwrapしない限りpanicは起きない

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

JavaはTとOption<T>を区別しないからStringでもnull検査パスしてるか分からんのよね
誰かが検査してると思ってたら誰も検査してなかったり逆に至る所で何重にも検査されてたり

**デフォルトの名無しさん** · 2025/06/16(月) 17:56:55.33

>>819
今回のやつはRustで実装しててもunwrapしてたケースだろう

>>820
Javaの場合は@Nullableみたいなアノテーション使ってビルド時にチェッカーを走らせる

**デフォルトの名無しさん** · 2025/06/16(月) 18:02:11.42

>>821
Optionをunwrapしていいのは常にSome自明時と
異常時にpanicで落ちていい時のみ

**デフォルトの名無しさん** · 2025/06/16(月) 18:48:18.73

>>822
後者に該当

ポリシーデータから必須項目が欠落しているような状態はヌルポを発生させたプログラマーから見ればプログラムを即停止すべき異常事態という認識

**デフォルトの名無しさん** · 2025/06/16(月) 19:02:14.08

Rustはわりとunwrapというかコンテキスト外し一般を使う人が多い印象があるね
そのあたりはやはりベターC++という感じがする

**デフォルトの名無しさん** · 2025/06/16(月) 19:03:13.08

>>823
異常時に停止してよい時のみpanicが使われて暴走やセキュリティの穴を防止するんだよ

**デフォルトの名無しさん** · 2025/06/16(月) 19:04:58.04

>>824
落ちてはいけないプログラムでそんなことする人はいないよ

**デフォルトの名無しさん** · 2025/06/16(月) 19:45:53.03

>>823
panicにするかどうかを決めるのはサーバーを実装する側じゃなくてサーバーを使うユーザー側だろ。
Linusじゃないけど、サーバー側がランタイムエラーでパニックを発生させるのは根本的に問題がある。単にエラーを返すべき。

**デフォルトの名無しさん** · 2025/06/16(月) 19:53:50.09

Rustは絶対安心安全なんだよ

**デフォルトの名無しさん** · 2025/06/16(月) 22:35:10.42

>>827
もちろんあるべき姿としてはエラーを返すなりフォールバックさせるなりすべき
だけど現実はヌルポでエラーも返さずクラッシュさせてたわけでRustに置き換えればpanicで落としてたのと同じようなもの

つまりRustを使っていれば防げたかというと今回のケースは防げなかった可能性が高いということ

**デフォルトの名無しさん** · 2025/06/16(月) 23:23:51.15

Rustを使えば防げただろう

**デフォルトの名無しさん** · 2025/06/16(月) 23:25:29.39

>>824
そういう時はこれ

[lints.clippy]
unwrap_used = "deny"

**デフォルトの名無しさん** · 2025/06/17(火) 07:28:54.01

>>829
ならpanicさせる>823の考えは間違いだね。

rustも安全性を標榜するならpanic禁止モードを用意すべきだわ。

**デフォルトの名無しさん** · 2025/06/17(火) 08:53:29.58

DoS攻撃脆弱性でregexのCVEがあったけど
関連サービスの事を無視して自分勝手にpanicしちゃったら同じ脆弱性だよね

**デフォルトの名無しさん** · 2025/06/17(火) 09:28:01.71

ヌルポ騒動が起きるたびにRustの重要性が引き上がる

**デフォルトの名無しさん** · 2025/06/17(火) 09:35:12.84

>>834
ポリシーの内容をチェックして。受け入れ可能じゃなければResultでテキトーにErr返したら済んだんじゃないの？

パニックさせる必要ほんとにあったと思ってる？

**デフォルトの名無しさん** · 2025/06/17(火) 10:10:19.32

>>835
それでもこの件では障害になることには違いないのでは
クラッシュはしないかもしれないが

**デフォルトの名無しさん** · 2025/06/17(火) 10:27:20.42

Rustで書くなら関数は必ずResultもしくはOptionを返すことになり、上位で処理される

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

>>837
>>822にもあるけど
> Optionをunwrapしていいのは常にSome自明時と
その「自明」をコンパイラが静的分析するか>>831がデフォルトじゃないかぎり
隠れ unsafe

**デフォルトの名無しさん** · 2025/06/17(火) 10:35:09.70

>>838
unwrapは使われない
?オペレータで上位へ委託するか
match / if let等で処理される

**デフォルトの名無しさん** · 2025/06/17(火) 10:41:17.77

このGoogleの件に関して言うなら、ポリシーの読み込み失敗即ちロールバックなんだろうからpanicは妥当
起動時に必須の環境変数が無い場合にpanicさせるようなもんだね

**デフォルトの名無しさん** · 2025/06/17(火) 10:46:12.73

panicで全体を止めたくない時はUnwindSafeな処理単位をcatch_unwindで実行すればいい
使ったことないけど

**デフォルトの名無しさん** · 2025/06/17(火) 10:51:31.79

>>832
ヌルポでクラッシュさせてたのは間違いではなかったとでも？

>>823はヌルポでクラッシュさせてた人たちの認識
その人たちが仮にRustを使ってたら同じようにpanicで落とすだけ
つまりRustを使っていたとしても障害は防げないという話

それに今回の障害を見てエラーハンドリングしていれば問題なかったと考えるのは短絡的すぎる
一番の問題点は一サービスの一コンポーネントがクラッシュしただけであらゆるサービスが全面的にダウンしたという点にある
だからあらゆるコンポーネントを絶対panicしないように作ろうとするよりも一コンポーネントがpanicしたとしても全面的なシステムダウンに繋がらない仕組みを作ろうと考えることが今回のような障害を防ぐための第一歩

**デフォルトの名無しさん** · 2025/06/17(火) 10:56:21.14

>>842
まともなシステムはそれだな
プロセスが落ちてもハンドリングされる

**デフォルトの名無しさん** · 2025/06/17(火) 10:58:00.04

異常状態のままプロセスが走り続けるよりもpanicなどでプロセス終了が正しいシステム構築

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

異常状態のまま動き続ける言語よりさ
panic or エラー処理されるRustが良い結論は変わらんよね

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

>>842
Google Cloud APIのコントロールプレーンのコアコンポーネントはさすがに一サービスの一コンポーネントとかいうレベルじゃないよ
OSのカーネルみたいなもん
こんなのヘタに誤動作を続けられたら会社が吹き飛ぶようなセキュリティ事故に繋がる可能性もあるわけで、死んでくれた方がマシ

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

ワンワンパニック

**デフォルトの名無しさん** · 2025/06/17(火) 12:50:17.15

Javaで
if (value == null) {
throw AppException();
}
を書き忘れるのとRustで
let Some(value) = opt_value else { return Err(AppError); }
の代わりに
let value = opt_value.unwrap();
と書くのは発生リスクが全然違うと思うんだけど
Javaでうっかりnullチェックを忘れる人はRustでもうっかりunwrapを使うものなのか？

**デフォルトの名無しさん** · 2025/06/17(火) 13:10:12.25

>>848
本人判断で「自明」と決めつけて意図的にunwrapを使うのでは

**デフォルトの名無しさん** · 2025/06/17(火) 13:36:52.80

>>822によれば
本人判断で「panicで落ちていい」と決めつけて意図的にunwrapを使うパターンもある

**デフォルトの名無しさん** · 2025/06/17(火) 14:21:36.03

>>848
Rustでは必要により明示的にpanicさせる.unwrap()とコードを書いた時のみpanicが起きる
意思が必要

**デフォルトの名無しさん** · 2025/06/17(火) 15:48:15.44

>>846
クラッシュしたのはコントロールプレーンの一部であるポリシーチェックシステムのさらにその一部のバイナリ
もっと言えば問題が起きたのはそのまた一部のクォータチェック部分

クォータチェックができなければGCPの全サービスを落とすべきというビジネス判断としてはなくはないがIncident Reportを見る限りGoogleはそうは考えてない

**デフォルトの名無しさん** · 2025/06/17(火) 16:05:37.54

Rustにしとけ
続行不可能で意図的にpanicさせるか
きちんとResult/Option処理するかになる

**デフォルトの名無しさん** · 2025/06/17(火) 16:27:46.74

リリースしてから実際にポリシー変更が発生するまでの2週間、
テストやりこんで最後のバグだしするまでの時間とみなすか、
リリースヨシ！と思ってたかだよな

リリース後も2週間頑張ってテストやったけど境界条件探すの下手くそで見つけられませんでした、で通るかな。自分のことのようにゾッとする

**デフォルトの名無しさん** · 2025/06/17(火) 17:05:59.65

>>854
プログラムの変更とポリシーデータの変更は責任者も管轄組織もプロセスも違うんだと思う
ポリシーデータのほうはビジネスよりの組織が管轄というのはよくある話
なのでDev的にはリリースヨシ！

改善点の2点目に「Regardless of the business need for ～」とあるからOpsはBizの政治力で本来とは違うプロセスを強制させられたのかもしれない

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

ここに内部事情を含めていろいろ書いてあった
https://news.ycombinator.com/item?id=44274563

**デフォルトの名無しさん** · 2025/06/18(水) 00:29:09.64

ここでの議論と同じだね
Rustでpanicするの明示的にpanicを起こすコードを書いたときだけ

**デフォルトの名無しさん** · 2025/06/18(水) 01:06:16.44

>>857
>Rustでpanicするの明示的にpanicを起こすコードを書いたときだけ

ここでもHNでもそんな議論はされてない
ただ複オジが連呼してるだけ

**デフォルトの名無しさん** · 2025/06/18(水) 01:09:01.01

さっさとC++捨ててRustにすれば防げたのにな

**デフォルトの名無しさん** · 2025/06/18(水) 01:12:36.99

>>858
初心者は今回のこのまとめを見るといい
https://news.ycombinator.com/item?id=44281839

**デフォルトの名無しさん** · 2025/06/18(水) 02:58:44.97

Googleの事案なんてどうでもよくてインシデントにかこつけてRustの布教がしたいだけ
だから何を書いても無駄

**デフォルトの名無しさん** · 2025/06/18(水) 06:20:38.83

Rustを採用していれば防げた事案

**デフォルトの名無しさん** · 2025/06/18(水) 09:57:10.50

>>848
本質は同じ

書き忘れではなくロジカルな思い違いもある
ここでnulｌはないやろとここErrはないやろは同じで思い込みだから

言語によって優劣とかじゃなく人間の限界がある

**デフォルトの名無しさん** · 2025/06/18(水) 10:09:02.91

>>863
全く違う
unwrap()はNone時にpanicを起こすための関数
書き忘れでpanicしない

**デフォルトの名無しさん** · 2025/06/18(水) 10:20:51.18

＞　書き忘れではなくロジカルな思い違いもある

**デフォルトの名無しさん** · 2025/06/18(水) 10:31:14.78

panicさせてはいけないプログラムでpanicさせる関数を呼ぶバカはいない
reviewでもバレる

**デフォルトの名無しさん** · 2025/06/18(水) 10:49:25.62

メモリリークさせてはいけないぷろぐらむでめもりりーくさせるばかはいない！

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

Rustを使えばメモリリークも未定義動作もなく安全安心よ

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

haskellと比べて、unwrapが気軽に使えすぎる気はする

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

ErrやNoneの時にpanic!を呼びたい場合が多いからunwrapがある
呼びたくないのに使うのは痴呆

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

index out of boundsやdivide by zeroをはじめ意図せずpanicを起こすケースなんていくらでもある

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

panicはcatchできるし
そのthreadが死ぬだけだし
困らんよな

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

>>871
panic禁止のプログラムのためにpanicしない方法が用意されていますよ
勉強しましょう

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

>>860
視野の狭い末端プログラマーの視点だな
システム全体が見えていない

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

>>873
視野の狭い末端プログラマーの視点だな
システム全体が見えていない

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

>>874
落ちてはいけないシステムをUB地雷だらけのC++で書くことが愚か

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

>>875
Rustのスレでシステム全体って何やねん
説明してみ

**デフォルトの名無しさん** · 2025/06/18(水) 12:16:05.81

「意図したpanic」禁止したら良い
その「意図」が正しいのかコンパイラが静的分析出来ないから