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/

でもこっそり使うんでしょう・・・？

当たり前じゃん
AI使わないとかアホの極みだからな

AIで書いて手書きで書き換える
工数ウマァ

いまどき工数なんて見ねぇよ

工数見ないでどうやって納期と金額の見積もり上げたの？

Rust Foundationは「Rust Innovation Lab（RIL）」の設立を正式に発表した。
このLabが設立された背景には「Rustの圧倒的な成功」がある。
近年Rustはそのメモリ安全性、パフォーマンス、並行処理能力の高さから、Google、Microsoft、Amazonといった巨大テック企業から、スタートアップ、さらには自動車や航空宇宙といったセーフティクリティカルな領域まで、驚異的な速さで採用を拡大してきた。
この成功は、多くのRust製ライブラリやツールが、もはや単なる「便利なオープンソース」ではなく、世界中の商用サービスや社会インフラを支える「ミッションクリティカルな構成要素」へと変貌したことを意味する。
しかし、
https://xenospectrum.com/rust-foundation-launches-rust-innovation-lab-ecosystem-maturity/

>>786
先に金額と納期を出させて
こちら側が出来るところを提示するだけ

>>787
ふーむ🤔

現実にはそんなもんだろ。
予算規模には限界があって、手間がかかるからもっと金を出せというのはどうせ無理。
交渉しても無いものは出てこない。
計画から金額を見積もるより予算から出来ることを見積もるほうが理にかなってる。

詳細な項目別工数と金額要求されるから無理

そんなもんが必要ならAIに書かせとけ

AIがこういう間違い記事を学習してしまうと
正しく「staticライフタイムなオブジェクトを作れます。」という記事がない限り正せない？

https://qiita.com/terukazu/items/efd9dc2ca334cfe90c05
Rustではプリミティブ型やリテラルだけが static 定義できます。
つまり、オブジェクトは　static ライフタイムが使えません。
Singletonパターンを使ってグローバルステートを実装することはできますが、staticライフタイムなオブジェクトは作れません。

実際に作って見せれば謝って来るさw

それはその場では謝るけど全体への学習しないパターンではないかい
ソース記事がない状況でユーザに言われるがまま訂正学習していったらヤバいじゃん

>>793
大丈夫、既にその記事の著者や我々なんかよりAIは遥かにRustを正しく理解しているから

今のフロンティアモデルは人間が>>793のような誤りを冒すに至る認知構造まで含めて余裕で理解してるでしょ
むしろこういう記事のほうがAIにとって価値がありそう

Python遅いけど、C++だと訳わからんくて完全AI任せになってしまうと思ってrustにしたら意外とc++よりはなんか分かりやすくていいね
nimも試したけどライブラリが古いのとラッパーばっかだったし程よい感じ。

バイブコーダーなのは変わらんけど、完全に置いてけぼりにはならなくなった

>>793
qiita.comやzenn.devは絶対に参照するな
とシステムプロンプトに書いておけばok

例としてstd::env::args()を&'static [&'static str]にする方法をAIたちに尋ねてみると
まずみんなleakメソッドを使いたがる
leakメソッド禁止など指示していくと正解にたどり着けるAIもいれば無理だとお手上げのAIもいる
ということは人間プログラマも正解にたどり着ける人間とお手上げの人間がいそうな気がする

所有権を理解していない初心者には難しいだろう

コンテキスト次第だろう
所有権の問題あるいは実用的な問いと考えるなら不可能だし、無意味なパズルだとするなら方法はあるわな
AIはその手の問いに対して「実用上意味がある答えを」という暗黙の前提を置きがちで、
別途staticなフィールドを外で持って値だけコピーするような方法はleak案が否定された時点で実用上無意味な方法であるとして除外されやすい
つまりお前より頭いいからそうなるんだよ

こちらのAIはstatic変数に持つのがむしろ良い方法だと言ってるよ　

＞ Box::leakのように意図しないメモリ管理の放棄や生ポインタの手動操作を伴わず、安全なカプセル化（Safeな抽象化）として実現できます。
＞ once_cell または std::sync::OnceLock（Rust 1.70以降で標準化）を使用してstatic変数にデータをグローバル保持する方法が最も一般的かつ安全です。

2023年6月安定化のOnceLockは出て来たけど
2025年7月安定化のLazyLockはないね

>>804
大切なのはleakとOnceLockのどちらが優れているかではなく、この問いにおいて一方が否定された時点でもう一方に意味があるかどうか
まともなAIであれば単なるトンチに過ぎず無意味であると判断する

>>803
Singletonパターンを知らないのか？
staticなフィールドを持ってそれを返すのはRustプログラミングの常套手段

>>801
>例としてstd::env::args()を&'static [&'static str]にする方法をAIたちに尋ねてみると
>まずみんなleakメソッドを使いたがる
尋ね方の問題だろうな

>>803
static変数に入れることは実用上意味があって便利だぜ
他のスレッドたちへ文字列を受け渡す場合
以下が可能ならばどれがいい？
①StringをCopyして渡す
②StringをArcで包んでCloneして渡す
③Stringをstatic変数に入れて&'static strを共有

constで

Rustのconstはコンパイル時に確定する値しか扱えないよ
staticは実行時に確定する値も扱えるね

複おじってOnceLock/LazyLockネタ好きだよね

プログラム実行中に決まる値だけどその後はプログラム終了後まで変わらない値はよくあるけど
それを関数呼び出しするたびに引数として渡して持ち回る方法と
static変数に入れてしまう方法
どちらが便利でコストも低いかという話だよな

起動引数程度ならどっちでもいいよ
問題はコンパイル通すためにstaticにしたがるやつ

不変staticは安全で良い方法だが、staticに親でも殺されたかのように嫌ってる人がいる

Rustって、ROM化出来るん？

できる
むしろRustができない理由が存在しない

opencode重すぎだからgooseに頑張ってほC

>>813
起動引数や設定ファイルのデータだけでなく
他のサーバから読み込んだデータなどあらゆる含む
巨大なデータまで全てが対象

・プログラム実行中に必要とするデータ
・プログラム実行中は変化しないデータ
この2点を満たすならばstatic変数に格納することで利便性が高まることが多い
コンパイルを通すために関数の引数として全てを毎回渡して引きずり回すと不利になりがち

>>808
⓪Stringを&strとして共有

これが第一選択肢

>>819
それは不可能

>>819
それはString側のスレッドが先に終わって解放されちゃったり誰にも解放されないままになったり事故多発物件で禁忌だけど
Rustはコンパイルエラーにしてくれる

しょうがないにゃあ
https://crates.io/crates/argv

>>822
こっちはちゃんとメモリリークと明記しているのが好感もてる

量が分かってるメモリリークは別に問題ないだろ

昔の、main()を抜ける前にfree()すべき論争みたい

>>823
勘違いしてるようだがそのクレイトはargvデータを利用できる環境で直接そのデータを利用することでリークなんか一切せずに&'staticを提供するクレイトだぞ
ただしunsafeだらけ

ただしとは？

ほんとだ
static mutまで使ってやがる

大した需要が無い事が判明したね
ダウンロード数からして

普通にstd::env使えばunsafe使わずに3行で書けるからなあ

Box::leakで取った参照ってBox::from_rawで戻していいのかな
&strとかスライスだと無理そうだけど&Stringなら大丈夫そうな気がする

どのAIも本質的に同じコードを出してくる
once_cell使ったり細かな違いしかない

fn args() -> &'static[&'static str] {
static ARGS_STRING: LazyLock<Vec<String>> = LazyLock::new(|| std::env::args().collect());
static ARGS_STR: LazyLock<Vec<&'static str>> = LazyLock::new(|| ARGS_STRING.iter().map(|s| &**s).collect());
return &**ARGS_STR
}

>>825
>>831だとヒープ領域にメモリ確保してリークしてるけど

メモリリークとはプログラムを動かし続けていると使っていない使用メモリが増え続けていくことだよ
増え続けないものをメモリリークとは言わない

メモリリークの定義はいろいろあります

確保したままなのに使われていないメモリ領域が増えていくとメモリリーク
これ以外に定義はない

増えていくなんて条件はプログラミング素人過ぎないか？

信仰告白みたいでかっこいいですね

https://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks

>>820>>821
草ｗ草ｗ

>>837
それは狂信的なので完全に無視していい
少なくともRustの方針とは真逆
Rustは「プログラム終了時にすべてのヒープメモリを返す」という無駄なことをしない方針をとっている
そしてIT大手各社そのRustの方針に賛同しているため現状がある

はあ？ 狂信的？ 方針？ 何の話？

>>824の話だよな
Rustは「main()を抜ける前に全てfree()すべき」というキチガイをガン無視

単にRustがメモリリークについて大した方針も用語定義も持っていないだけでは？

ところで、某「IT大手各社」が言うメモリリークも「増え続ける」なんて条件はない
https://learn.microsoft.com/en-us/cpp/c-runtime-library/find-memory-leaks-using-the-crt-library

>>842
それはダメ言語用
ちゃんと明記されてる

RustプログラムでもCRTはリンクするんじゃないの？
というか言語ごとにメモリリークの定義が違うとかないし関係ないでしょ

メモリー解放やってくれる言語でメモリーリークってあるの？

CRTってどの話
公開鍵暗号証明書のCRTか
AWSの共通ランタイムか

>>845
コンテナに詰めたまま今後使われることも無く放置されるオブジェクトというのは、言語機能も手が出せないからメモリリークということになる

>>819
他のスレッドへ渡すことができる参照は&'staticだけです

>>848
嘘おじ乙

なぜ他のスレッドへ&'static参照しか渡せないのかというと
渡した元のスレッドが先に終了したら参照が指している実体が亡くなってしまうためだよ
&'static以外の参照を渡せるようにするためには他のスレッドが動作中は元のスレッドをブロックして終了しないように制限するしかない

共有メモリでやりとりするんじゃ無くて？

お手軽な参照渡しは>>850
所有者はArcに包んで共同所有者になればcloneで共同所有者を増やすことができて他のスレッドへ渡せる

>>848
このレベルの嘘はしょぼいAIでもすぐに看破できるから
嘘つき複製おじさん注意報がなくてもみんなもう大丈夫だよね？

>>851
スレッドは全メモリ空間を共有するため全てが共有メモリ
だから共有メモリという概念は意味がなくて他から渡されたアドレス領域が参照なのか共同所有なのかという点のみ区別される

std::thread::scope

>>855
それは自分がブロックされて動作停止になることと引き換えに参照を渡す仕組み
自分が自由に動く場合は&'staticしか渡せない

相手のバッファに突っ込んでしまえばいいだけでは？

>>857
それはコピー
最もコストが高い
static変数に入れて&'static参照を共有するとコストが安い

コストより、相手のライフ状態気にしなくてし済む自由

AIともこんな調子でバトってるのかな

>>859
その通り
互いのライフを気にせず共有できる&'staticが自由でいいよ

> 問題はコンパイル通すためにstaticにしたがるやつ >>861

static変数はスレッド間で共有するために存在してるんだよ
だからこそstatic mutはunsafeでしか扱えないようにしてある
staticで可変にしたい場合は内部可変性を使うことでsafeに使えるよ

&'staticを得られるから自由に他スレッドに渡せるだけでなくシングルスレッドの利用でも利点が多い
ライフタイム気にしなくてよくなる

>>846
Cathode Ray Tube

>>862
ウケた
まさにこれだよな

関数の引数として渡すときにもstatic化は効果絶大だよ
直接もしくは連れ回す構造体に格納するとき
1. 所有型(VecやString)を使うと構造体のサイズが割り増しになる
2. 通常の参照を使うと構造体にライフタイム<'a>が付いて扱いが煩雑になる
3. 'static参照を使うと構造体がシンプルで済む
便利で効率も良いのはstatic化した時の 3. だよね

結局スレッド云々は全く関係がないんだよな
グローバル変数にして個別に受け渡しせず使いたいならstaticにする
それだけ

グローバル変数は
依存性が隠れやすい/テストしにくいなどのダウンサイドもあるので
用法用量には注意しましょうということ

複おじ節には耳をかすな
これだけでいい

static変数はグローバル変数ではありません
テストがしにくくなることもありません

>>868
基本的な違いをいくつも理解できてないな
まず指摘があるようにstatic変数はグローバル変数ではなくスコープは関数内やモジュール内に閉じて使える
次にstatic変数を直接使う話ではなくてそれが見えない場所からも使える&'static参照の話だろう

「バカは'static以外のライフタイム使わないほうがいい」はガチ

>>871
ライフタイムが難しいなんてことはないでしょ
ここでもライフタイム注釈付けたり面倒という声はあっても難しいとか見かけない

&str の lifetime に納得行かないのなら
&'static str より String 使え

>>873
参照を渡して共有したい話だから
String直接渡すならcloneになってしまうぞ
&'static strの方が何もかも良い

すべったね

しかもスレッドに渡すなら
文字列を渡したいだけなのに
&'static str vs. Arc<String>になってしまうもんな

複おじ(2022)「可変性を気にしなくてよくなるからCell使え」
複おじ(2026)「ライフタイム気にしなくてよくなるから&'static使え」

1ミリも進歩してないｗｗｗ

令和最新版staticおじさん

どんなものでも用いることでコードがシンプルになったり速くなったりするなら使うのが正解
unsafeは除く

なんでもArcにすると扱いが楽！は遅くなるからダメだけど
>>877は問題ないと思う

CPUバウンドな処理をスレッドで回したいだけなら安直にrayonで書く
プロファイラかけてボトルネックだとなったらゼロコピーで書き直す
そうそうない

これ書き味悪すぎるだろ
https://github.com/hanabi1224/Programming-Language-Benchmarks/blob/main/bench/algorithm/coro-prime-sieve/3.rs

こんな風に書けないものか
https://godbolt.org/z/dEv1EPKT9