Rust part38

公式
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/
（コミュニティによる日本語翻訳版もあります: https://doc.rust-jp.rs/book-ja/）

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

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

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

前スレ
Rust part37
https://mevius.5ch.io/test/read.cgi/tech/1784283151/

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

安全センサーというより緊急停止機能を無効にしてる
↓がよくあるパターン

fn do_something(...) {
assert!(...);
unsafe { do_something_unchecked(...); }
}

unsafe fn do_something_unchecked(...) {
...
}

一般的にはdo_something内のassertが無駄で省略したい時にdo_something_uncheckedを使う
assertに失敗する状況でも無理矢理do_somethingを実行するためにunsafeを使うテロリストは少数派

障害物が存在しないゾーンだから緊急停止機能を切る　→　前者
歩行者天国に突っ込むために緊急停止機能を切る　→　後者

>>162
デフォルトはunsafe禁止にすべきだと思う。

>>164
禁止にしたらswapさえも自前で実装できなくなる

>>165
safe Rust使えよ
unsafe使うなら切り離してsafeなcrateとして公開しろ

こうしてcrates.ioはunsoundなcrateだらけの無法地帯となったのであった

panicもそうだがunsafeコードを監査する道具立てが無さすぎるんだよな
いろんな実験的な取り組みは進んでるけど実用レベルのものは全然ない

安全装置を作るガイドラインは提供するが
実際に作られた安全装置が本当に安全どうかは各利用者が責任を持って検査しろ
というのが今のRust

unsafeを使ってsafeで効率のよい仕組みを作れることが判ったら、
それをクレートや標準ライブラリとして公開して、
皆がその恩恵に授かれつつ監視できるようにする
ここまでは素晴らしい

問題は穴があリそうなものも公開された場合に、
それに関心を持つ人が少なくて監視が不十分なまま据え置かれ、
盲目的に利用する人が出現すると

>>165
std::mem::swapを使うんじゃないの？

少なくともコーダーにswap実装なんてやらせたら駄目だろ。

>>168
そんなもんAIに丸投げすりゃいいだけだよ

>>171
やってから言いなよｗ
全く使い物にならんから

カニはあかんの？
全く触ったことないけど

タラバガニならいいよ

タラバガニは名前に「カニ」とはつくものの、本当はカニではなく、ヤドカリの仲間

やーどかりかりこだわり屋さん

AIに丸投げしたらunsafreだらけなんだよな
RustとＡＩの相性ってめっちゃ悪い

そういうのもういいカニよ～

>>177
ほとんどの分野はunsafe不要なのだからunsafe使うなと指示するだけだろ

kani使用者おらんの？これだけunsafe連呼して

unsafe基本使わんし

>>179
それができるんならRustなんか使わないでもっと効率のいい言語でメモリ安全にしろって指示するだけだろ

>>182
そんなことができる該当する言語はRustしかない

unsafeってメモリ弄ったりライブラリ開発する時に使う奴だべ
おらには扱えねぇだ

ハードやOSや他言語コードなどを呼び出すRustライブラリが存在しない場合、それを作る時にunsafeが必要になり得る
既にRustライブラリがあればunsafeを使わずに書ける

unsafeがあるなら、結局みんなunsafeばかり使うからC言語と何も変わらないなんて主張するレベルのプログラマーは
それこそ複おじの自演用の、極端な低能に調整された仮想敵にしかいないよ

>>186
unsafe以外の部分はRustが安全性を保証するため全てunsafeなC言語とは異なる

unsafeを勝手に使う低レベルコーダーがチームに混ざるのが危険なんだよ。

Rustは「メモリ安全」を強制する安全装置が強みなんだから、勝手に安全装置を外せなくするのをデフォルトにしておくべきだった。

借用チェッカーがチェックしてるから、コードレビューしなくていい派か？

チームでやるならオプション指定を共有すればいいだけの話なんだからデフォルトなんかどうでもいいよ。
チームで共有すべき設定にまで逆らうようなやつなら何がデフォルトでもどうせ逆らう。

実際そういう悪意あるチームメンバーは、unsafe使う云々の前に
社内の共有ファイルを嫌がらせで全消ししたり
機密情報を当然のようにSNSに上げることを警戒したほうがいい

>>188
だから unsafe なんだろ
使ったらいつでも確認できるし、言語仕様に組み込むことでCみたいにコンパイラの独自実装で機能を追加されて、言語仕様から外れた状態にならないようにしている

###エコシステム全体の傾向
​統計的な調査や研究では、パッケージやコードの規模が拡大するにつれて、コード量全体に対する unsafe の割合（コードレベルの密度）は、適切な抽象化とレビュー文化の定着によって減少傾向にあることが示されています。

​「アプリケーション開発者が unsafe を書く機会」はエコシステムの成熟とともに減っており、unsafe が使われる場所は、OSカーネル、ドライバ、高パフォーマンスなライブラリの内部といったごく一部の低レイヤー層へ厳しく局所化されていくのが、現在のRustコミュニティの目指す方向性です。

​Ralf Jung: What's the deal with unsafe Rust?

この動画では、Rustにおけるunsafeの役割や、安全性とパフォーマンスのトレードオフについて、言語開発メンバーの視点から詳しく解説されています。

事前合意なくunsafe使うやつがいたら要注意人物ブラックリスト入り
それくらいの位置付け

それで依存クレートのunsafeをどうチェックするのかな？

そいつの存在がunsafeだからな

そいつを使うって事はその使用者が安全を保証する必要があるって訳だ

You are fired !!

そりゃunsafeが不要な場所で使うのは控えめに言って無能でバカで保守性という概念がなくて後先を考えてないからだからね
ただ、unsafeが不要というのとは違うし、言語仕様に組み込まない方がいいなんて論には賛同できない

AGENTS.mdにunsafe使うなと書けばいいだけでしょ
洗濯板の議論

unsafeはunsafeを使わなければ実現できないことに使うもんなので
そんなもんをAIの指示に書くなら、最初からunsafeなんてものがないPythonとかのスクリプトで開発したほうが早い

AIにunsafeを使うなって指示を出すだけ！

そもそもAIがunsafe使うことほとんどないでしょ
まあwindowsクレート使う時くらいじゃない？

>>200
AIの時代になったから遅くてメモリを喰うPythonを使う必要がなくなった

>>202
Rustエアプなんでしょ

>>202
>>204
それ
AIがunsafe使いまくるとかどんな妄想だよって感じで、むしろAIは無能なエンジニアと比較してunsafeの適切な運用方法を知っているので、無能なエンジニアが警戒するような使い方はされない

>>205
ClaudeでBunをRustで書き換えた時にunsafeだらけだったこと知らないの？？？

zigからのマイグレーションでunsafeだらけになるのは当然では・・・？

おっしゃる通りです。「Zigで書かれていたコードをそのままRustに機械的に（あるいはAIを活用して一気に）移植した」という経緯を考えれば、unsafeだらけになるのは**完全に想定内（当然）**のことと言えます。
BunのRust移行プロジェクトにおけるunsafeを巡る実態や背景には、以下のような理由があります。

### 1. 機械的な移植（Transpile的アプローチ）の限界
Bunの初期のRust移行では、アーキテクチャやロジックを一からイディオムに沿ったRustとして書き直したのではなく、既存の膨大なZigコードの構造（ステートマシンのような生ポインターの取り回しや、親を指すバックポインターなど）をそのままRustの構文に置き換える形が取られました。
ZigにはRustのような借用チェッカーやライフタイムの概念がないため、それをRustでそのまま再現しようとすれば、*mut や unsafe に頼らざるを得なくなります。

### 2. unsafe の内訳（多くは「構造上の名残」）
その後の公式のコードベース監査（Audit）でも明かされている通り、数万件に及ぶ unsafe の多くは以下のような理由によるものです。

* **Zig時代の名残（移行コストの都合）：** ボローチェッカーを回避するための生ポインターや手動参照カウントの維持（全体の約3割）。

* **FFI境界：** JavaScriptCore（JSC）やC/C++ライブラリ（uWebSocketsやBoringSSLなど）を呼び出すためのコード（Cの関数呼び出しはRustでは定義上すべて unsafe）。

* **GC（ガベージコレクション）との相互作用：** JSのオブジェクトグラフやGC管理下のメモリと、Rustの所有権モデルが直接噛み合わない部分。

### 3. 「まず動かして、後から安全にする」という戦略
開発チームも、最初からすべてが美しい「Safe Rust」になるとはハナから考えていませんでした。
まずは既存の広大なテストスイート（99.8%以上）をパスさせ、挙動の同等性を担保することを最優先し、その上で「段階的に unsafe を剥がしてイディオムに寄せていく」という現実的なロードマップが採られています。

したがって、「Rustに書き換えたからといって、いきなり安全で美しいコードになるわけがない」というのはその通りで、あの膨大な unsafe は**「手動管理のシステム言語からRustへ一気にコードを流し込んだ歴史的経緯の現れ」**と言えます。

pythonでbunを作れというのか

>>206
あまりにもアホ発言すぎる
そもそもBunは1から書かれたのではなく、Zigで書かれた実装と全く同じように動くように書かれた
つまり、Rustの所有権システムや借用規則に全く適合しない設計であり、ここからRustの規則に適合させる気がないのであれば、書き換え自体が失敗だったと断定していい非常に問題のある状態にある

Python vs unsafe

zig 版の bun は細かに手作業でメモリの確保・解放していてその品質も疑問視されるような状況だった。
元より自動的なメモリ管理など考えない設計であったし、そこからなるべく一対一で書き替えるように指示を出してる。
問題があっても元の通りにメモリ管理管理をしろという指示だ。

まずは元の挙動を変えないことを優先して、これからまともな構造にしていくと説明している。
それがうまくいくかどうかは話が別として、 bun の書き替えで unsafe が大量にあるのは最初から意図してそう指示しているからだ。

>>206
claude.mdでunsafe使うなとか、必ず終了時にテストしろとかルール追記し続けることでリファクタ、リプレースと問題はほぼ起きないけどな
すり抜けが多々あるからルールとテスト方法、メンテナンスが一番重要になってる

>>206
AIにunsafeを使うなって指示を出すだけ！

他の言語でAIに安全にしろ！と指示しても穴が空くけど
RustでAIにunsafe使うな！と指示出せばunsafe使ってない検証も含めて100%確実にできるからな
AI向けにベストな言語だ

unsafeありで作らせてから
全部safeにしろって感じにできるかな？

>>216
何をもって同一かを含めて曖昧なのと
そんな無駄なことは非効率な遠回りすぎて価値がない
最初からsafe Rust使うのが最善

## 結論：意味はあるか？
**「大いに意味はあるが、適用する場面を選ぶべき手法」**と言えます。

* **向いているケース**：
複雑なロジックや、既存のガードレールに阻まれてAIが「できません」と逃げてしまう高度なタスク。

* **向いていないケース**：
最初から標準的なベストプラクティス（OWASP Top 10の対策など）に則ったコードを書かせるだけの通常の開発タスク（この場合は最初からセキュアなプロンプトを書いた方が早い）。

実務で活用する場合は、人間がしっかりと「Safeに成型し直す工程（コードレビューや静的解析ツールの導入）」をコントロールできることが大前提となります。

>>216
動く状態 (少なくともコンパイル可能な状態) を維持しながら発展させる開発体制の方法論は AI 以前から一応はある。
機能不足でもバグだらけでも動く状態なら問題の発見はしやすいという考え方だ。
でもそれは問題が潜んでいることが静的にはわからないのを早めに炙り出すための方法論であって、静的にわかるならそんなことをしなくて良い。

Rust の unsafe を初手で使ってから取り除くのは明らかに馬鹿馬鹿しい。
いったん unsafe にしてしまうと影響範囲が広大なので広大な範囲の検証をしながら unsafe を取り除くという大きな手間がかかる。
最初から安全なコードを積み重ねるほうがよほど楽。

>>219
影響範囲は大きいしトークンコスパ悪いってだけだからやりたいようにやって失敗して次に活かしたらいい
新人がバイブコーディングに慣れるとブラックボックス化で悲惨だけど現場でちゃんと10年やってきてるなら切り分けした後サンドボックス内でAIに丸投げして進めりゃ楽
安全なコード積み重ねた方がクオリティは良いけど重要なのは利益だしもう最近は諦めた

unsafe全部消してもRefCellの競合参照で落ちまくりそう
AI信者は「RefCellも使うな」とかやるんだろうか

RefCell地獄からAIを使って抜け出すための要点：

* **1. 構造の視覚化を頼む**
* 「どこで循環参照や二重借用が起きているか、所有権の関係を図式化して」と指示し、複雑化した依存関係を客観的に把握する。

* **2. 安全な設計への書き換えを丸投げする**
* 「RefCell を取り除き、通常の借用規則に則ったクリーンな設計に直して」や、状態を一箇所にまとめる構造（Redux風など）へのリファクタリングを依頼する。

* **3. パニックのログを壁打ちする**
* 発生した BorrowMutError のエラー文とコードをそのまま貼り、「どの行とどの行が衝突しているか特定し、最小限の修正案を出して」と指示して即席のパッチを作ってもらう。

>>221
借りっぱなしのコードなんて見たことない
すぐに返すよ

スコープ抜けたら自動返却だから
スコープ内で呼び出す子孫関数で衝突する借り方しない限り起きようがない

従来の言語だと参照したままいつの間にか値が書き換わっているスパゲッティコードになり得た
Rustの参照はsingle writer XOR multiple readersだからそのようにならないよう自然にコードが良くなる
その習慣があるためRefCell使用時でも参照違反を自然に回避しやすい

従来の言語はGC使ってるから最初から安全
memory unsafeでexception unsafeでAIとの相性最悪なRustを使う必要が全くない

>>226
GCを使ってもヌル安全やデータ競合安全などは保証されない
GCとは異なる機能が必要

>>227
ミューテックス使えば競合安全は確保できるよ。調べてみて

AIのコピペは基本スルーしてるんだが
>>218は「AIがきっぱり断るケースでunsafe無しのコード生成を依頼するのが良いでしょう」って内容？
それをコピペしてる人が心配なんだが

>>226
CやC++にメモリ安全性を付けたのがRustだよ？
そのために一度に1つのエンティティしかメモリにアクセスできないという所有権などの原則があるわけで、効率を考えてとAIで書いてコンパイラでチェックする
問題はコンパイラがCやC++よりかなり重いこと

>>229
お前頭悪そう

>>228
「気をつけてメモリを解放すれば安全だよ」
「忘れずにミューテックスを使えば競合安全だよ」
それが従来の言語

そうではなくRustは言語仕様でそれらの安全性を保証した
データ競合が起き得る状況でMutexを使い忘れるとRustはコンパイルエラーになる
これがデータ競合安全性

1. 数は多いけど最新の機材なら機械的に除去できる地雷が埋まってるのがC/C++
2. 数は少ないけど発見も除去も難しいunsafe地雷が埋まってるのがRust
3. 地雷はすべて除去済みなのがモダンなGC言語

1と2は3に比べると少し性能が良い
さてAI時代にあなたはどれを選びますか？

>>233
エアプが誤解してるな
Rustで通常のコーディングにunsafeは使われない
AIバイブコーディングでもunsafeは使われない

Rustが好きな人や組織はRustを選ぶ、モダンGC言語が好きな人や組織はモダンGC言語を選ぶ
ただそれだけのこと

>>234
自分がunsafeを直接書かなくても地雷は埋まってるんだよ
推移的依存も含めるとRustは数百以上のライブラリに依存するプロジェクトが大半
自分の埋めた地雷じゃないから余計に見つけにくいし除去しにくい

>>230
テンプレートや静的ダックタイピングの無い言語をc++とは認めん。

>>236
AIに推移的依存も含めunsafe使うなと指示するだけだろ

Cで機械的に除去できるならRustでもできるよ

kani や miri といったツールは unsafe も含めてかなり細かい検証が可能。
std や主要な (実質的に標準のような立場にある) ライブラリは検証されているし、不安なら自分でチェックすることも出来る。
かなり時間がかかるんでコンパイラに組み込むというほどにはこれからもならないだろうけど開発工程の適当なタイミングで使うくらいはしたら良いと思う。

というかなんでunsafeが人のライブラリだろうがなんだろうが「常に」悪みたいになってんだろうな
これが複おじの自演か？

actix-webのunsafe警察事件とかあったな
Rust最大の失敗はunsafeというネーミングだと思います

>>242
risky とかで良かった
あるいは warning とか
プログラマーって正しい用語使えばそれがいいことだと信じてるからダメなんだよ
特にコンパイラーとか作る系の人ら

そんなんで引っかかる奴は低レベルだからド素人避けになって都合がよい

>>243
riskyならいいけどwarningは俺がコンパイル時警告と使い分けられないから勘弁

>>242
unsafeという名前がぴったりだよ
通常時は絶対に使ってはいけないことを明確に表してる
もし使うならば理由の明記と使用の合意が求められる
さらに監視対象になる

C/C++との対比なら実行バイナリのサイズで攻めたほうがいい
rustプロジェクトのビルド中は数十GB食って
できたバイナリも数十MBってなんなん

>>247
Haskellのメモリ使用量は富豪的
Rustのストレージ使用量は富豪的
C++は何が富豪的？

>>246
自分の流儀にそぐわないものを一律にunsafeと呼ぶのはHaskellで見た

>>249
RustではRustが安全を保証しない領域のことをunsafeと定義している
最もふさわしい用語が採用されている

>>248
C++は必要知識が富豪的？

×Haskellのメモリ使用量は富豪的
○数学的に綺麗なアルゴリズムをそのまま書きやすく、結果的にメモリ使用量(GC)が富豪的になりがち

Haskellの書き味でGC無しだったら覇権だった

ハスケーはgcある時点で船降りろって感じ

Haskellの良さも一部取り入れつつC並みに速くて省メモリなRust

Rust の型システムはだいぶん Haskell の影響を受けているというかそのままだな。
個別に見ればだいたいどれも元ネタがある。
Rust に固有な言語機能はライフタイム注釈くらいだと思う。
(それも全く新しく生まれたわけではなく数十年前の研究から発展させたものだ。)

Rust
・各言語の良いと言われている仕様を寄せ集めている
・それにも関わらず重複や矛盾がなくコンパクトな言語仕様に上手くまとまっている
・そのうえでC言語並みの速さと省メモリを実現している

>>233 >>236
unsafe地雷とか言ってる時点で無知を晒してるだけ
unsafeは使ってはいけないものではなくて、コンパイラが安全を保証しないから最低限に留めるべきものに過ぎない
コンパイラは全知全能の神ではないのでプログラマが保証する領域は発生し得るし、それは何ら問題ではない

だいたいC/C++の方がunsafe Rustより安全とかいう妄想をしてる時点で、Rust知識ゼロで理解出来ないからアンチしてるだけのバカなんだよなｗ

>>257
基本的にunsafeは使ってはいけない
Rustだけで完結する通常のプログラムはunsafeを使わずとも書けるように整備されている
Rust以外との境界や低レイヤーを書く人がunsafeを使う

>>259
Rust はシステムプログラミング言語だぞ。
Rust だけで完結することが通常なはずがない。

>>260
Rustは全領域向け言語
システムプログラミングは極一部に過ぎない

とはいえ、js代わりにWebフロントエンドで使うのは今だけの流行り病な気がする