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/02(月) 16:40:40.26

>>387
GCによる害悪2つのうちレイテンシ悪化はGoで軽減できるが全体パフォーマンスはGoも悪化する

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

悲報！Rust版AV1デコーダーがCより5%遅い問題が解決できず、カネで解決しようとする
https://www.memorysafety.org/blog/rav1d-perf-bounty/

Macではもっと遅かったしRustじゃなくてGoで良い領域だな

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

>>236 >>243
Arc削除できないと返答してるな

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

シャープ、PythonによるAIデバイス向け高位合成ツールをオープンソースで公開
https://news.mynavi.jp/techplus/article/20250602-3343055/

博報堂メディカル、生成AIを用いた審査業務効率化ソリューションを開発 [
https://news.mynavi.jp/techplus/article/20250602-3342950/

「AIをより魅力的にする戦略」がAIチャットボットに「薬物使用を促す」といった有害な考えを強化させる可能性があると研究で判明
https://gigazine.net/news/20250602-ai-chatbots-user-influence-attention/

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

Arcは所有者を増やすときのみカウンタ+1のオーバーヘッドがある
参照はderefによりコストゼロ

**デフォルトの名無しさん** · 2025/06/02(月) 17:21:42.21

>>390
なるほど
幸先良くスタートしたけど分かっていても直せない箇所が出て来る訳ね

**デフォルトの名無しさん** · 2025/06/02(月) 17:27:52.34

所有者を増やしまくる愚を犯さない限りArcにデメリットはない

**デフォルトの名無しさん** · 2025/06/02(月) 17:49:16.64

>>379
Aurora DSQLは、データベース管理ソフト(DBMS)であり、データを収めているのは原則としてHDDやSSD。
だから、メインメモリーは、キャッシュのために少し使う、というのが基本のはず。
だから、データ集約に関係する高度なアルゴリズムはHDD/SSDに対して必要となるが、
メインメモリに対しては余り必要ない。だから、Rustが適す。

**デフォルトの名無しさん** · 2025/06/02(月) 17:52:38.64

>>395
もうちょっと調べた方が良いよ、DB全般

**デフォルトの名無しさん** · 2025/06/02(月) 17:59:35.62

>>396
ちゃんとした言葉で反論してください。

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

>>397
Geminiに聞いてやったぞ

ご指摘のコメントは、データベースの仕組みとRustに関する理解に多くの誤解があるようです。
* DBのメインメモリ利用の認識違い: データベースはキャッシュだけでなく、データ処理やソート、インデックスなど、パフォーマンスのためにメインメモリを広範に活用します。「少し使う」というのは誤りです。
* Rust適用の理由が不適切: Rustはメモリを安全かつ効率的に制御できるため、DBのようなパフォーマンスが求められるシステム開発には適しますが、「メインメモリをあまり必要としないから」という理由は論理が破綻しています。
したがって、このコメントは技術的に見て多くの点で適切ではありません。

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

>>398
DBMSの場合、メインメモリーに置いておく集約構造は、データの量が小さい。
だから、ある程度の速度性能が出れば、全体の速度には影響が及びにくい。

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

そのGeminiの回答は、理解が浅い。

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

>>399
お相手の方の返信も、やはりデータベースのメモリ利用とパフォーマンスに関する誤解が続いていますね。
主な問題点
* 集約構造のデータ量は「小さい」は誤り: データベースは、高速化のために可能な限り多くの集約データや中間結果をメモリに置こうとします。データ量が多いほど、メモリを効率的に使う必要があります。
* 「ある程度の速度」で全体の速度に影響が出にくいは誤り: メモリ上の処理が非効率だと、それが全体のパフォーマンスのボトルネックになり、特に大規模データや高負荷環境では深刻な影響が出ます。少しの遅延でも、積み重なると大きな差になります。
データベースの性能は、メモリの効率的な活用に大きく依存します。

書き込む前にAIにチェックしてもらうことをお勧めする

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

>>401
ただ、ネットで使うことが多い DBMSは、単位時間当たりの書き込み回数が小さい傾向がある。
そういう事まで含めて考えれば、あなたやGeminiの回答は理解が浅い。

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

論理ではなく、トータルの必要時間を数式で考えないといけない。

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

>>399
一番効果が大きいのはメモリ上のキャッシュ効果
そのキャッシュ構造管理もRustがベスト選択

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

>>404
DBMSに必要な処理の特徴が、Rustとは相性がいいとは言えるかもしれないが、
DBMS以外のアプリではもっと別の特徴が必要となることが有る。

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

>>404
「405」で「キャッシュ」という言葉を使ったが、CPUの中のキャッシュの事ではなく、
メインメモリー自体が HDD/SSDに対するキャッシュとみなせるという意味で使った。
混乱してはいけない。

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

>>406
誤: 405
正: 395

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

次からスレタイ「複おじ Part31」に変えようぜ

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

>>406
DBはそのHDD/SDDに対するキャッシュ効果が最も効く
そのキャッシュ管理にもRustが最適

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

>>409
もちろん、KotlinやJavaよりは効くだろう。

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

>>408
別にそれでもいいよｗ
普通にRustスレ立ててもおかしな人間がやって来て自説を繰り返すだけだから

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

それやっても自分でRustスレ立てて何事もなかったかのように振る舞うだけだと思う

**デフォルトの名無しさん** · 2025/06/02(月) 20:32:38.85

>>389
GCがあり不便なGoは適用範囲がほとんどないのよ
Goが使われている領域の狭さを見つめてね

**デフォルトの名無しさん** · 2025/06/02(月) 20:44:46.47

将来的にオリジナルのdav1dと乖離させない様に出来るだけ1to1で移行するには良いのでは
TypeScriptコンパイラと同じ状況かと

**デフォルトの名無しさん** · 2025/06/02(月) 20:51:40.32

書いてあるね
https://github.com/memorysafety/rav1d/issues/1419#issuecomment-2925693567
> And we'd like to keep the Rust code similar to the C code if there's no significant advantage to changing it, as this helps backporting changes from dav1d

**デフォルトの名無しさん** · 2025/06/02(月) 20:54:08.00

Macの現状は7%差か
もう「significant」じゃない気がする

> Apple M3で8.8%遅かったのが7%になったとな
> 「5%遅い」はAMD Ryzenでの数字

**デフォルトの名無しさん** · 2025/06/02(月) 20:56:39.33

小さいメモリを確保したり解放したりを頻繁にやるわけではないユースケースでは GC はそんなに速度に影響しない。
するとしても回避策はある。
そんなことより Go の問題点はメモリ管理を自動化しておきながらメモリアクセス違反をあまり防げないことだな。
C/C++ から移行する分にはそんなもんだろと思えるが、メモリ安全性を期待したら失望すると思う。

**デフォルトの名無しさん** · 2025/06/02(月) 21:00:04.05

どの道テストはみっちり必要ですよ
コンパイル時のあの標語は罠かと

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

Goは各種安全性対策が中途半端でプログラマの自己責任だからな
Goに未来はない

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

>>396
禿同だな
>>395というか複おじはド素人なのになんで無理に変なコメントしようとするんだ？

**デフォルトの名無しさん** · 2025/06/02(月) 21:28:48.01

>>417
>小さいメモリを確保したり解放したりを頻繁にやるわけではないユースケースでは GC はそんなに速度に影響しない。
真逆だろ

**デフォルトの名無しさん** · 2025/06/02(月) 21:28:51.61

キリトリ記事禁止の呪いか
思いつたことはすべて公表しなければならないという

**デフォルトの名無しさん** · 2025/06/02(月) 21:40:20.45

>>421
確保しようとするメモリが大きくても小さくても一回あたりの確保・解放に必要な実行コストはあまり差がない。
大きさではなく回数が効いてくるので頻繁な確保・解放がないなら GC のコストは小さいよ。
画像処理関係は大きなデータは扱うがメモリを確保・解放する回数が大きいわけではない。

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

>>423
C/C++/Rustが絶対に勝つ利用法だ

**デフォルトの名無しさん** · 2025/06/02(月) 21:48:51.08

>>413
Dockerとか使ったことないの？

**デフォルトの名無しさん** · 2025/06/02(月) 21:56:07.57

Go の GC もヒープメモリの確保と解放のコスト自体は C と同程度じゃないかな。
生存しているか (参照が残っているか) どうかの判定にコストがかかっているので依存関係の複雑なデータ構造だと速度的には不利になる。
どうせそのあたりを意識しながら設計するなら Go より Rust のほうがいいかなぁとは思う。

**デフォルトの名無しさん** · 2025/06/02(月) 22:01:25.40

逆にもう手に負えないほど複雑なデータ構造になってしまったときは GC の実行コストを受け入れてでも任せてしまいたいということはあるかもね。

**デフォルトの名無しさん** · 2025/06/02(月) 22:01:47.11

>>426
GC自体は軽い処理で、それ自体のコストが問題になることは少ない
問題は、現在主流のGCの実装では、予測困難なタイミングでGCによる比較的長時間のアプリケーションの停止が生じること
そもそも明示的なdeleteやRAIIや参照カウントのような方法も決してゼロコストではないわけで、そのコストを払うタイミングが違うんだよ

**デフォルトの名無しさん** · 2025/06/02(月) 22:03:46.27

>>425
Docker創始者が明言「WASM+WASIがあればDockerは不要」
https://twitter.com/solomonstre/status/1111004913222324225
https://twitter.com/thejimwatkins

**デフォルトの名無しさん** · 2025/06/02(月) 22:26:19.81

なお>>429 tweetから丸6年後の今

**デフォルトの名無しさん** · 2025/06/02(月) 22:28:58.46

>>428
1行目から2行目で世界線が違うのか？

**デフォルトの名無しさん** · 2025/06/02(月) 22:33:31.23

>>431
あなた以外には理解いただけているものと思うが、念のため補足すると、
GCの問題は処理コストの大きさではなく、そのコストを払うタイミングにある

**デフォルトの名無しさん** · 2025/06/02(月) 22:44:13.11

>>432
要するにこれが良いと言う事か

> もうすぐGCが進化するからフリーランチ出来るね
> https://qiita.com/hez2010/items/e0a3573ecb3b14325336
> https://github.com/dotnet/runtime/discussions/115627

新計測データが来てる

**デフォルトの名無しさん** · 2025/06/02(月) 22:45:31.08

>>432
GCはどの方式でも処理コストが高い
これがGC依存言語が遅い原因

**デフォルトの名無しさん** · 2025/06/02(月) 22:48:22.30

GCするなら一斉停止が最も低コスト
並行しながらGCは時間の分散ができる代わりにコストの増大を招く

**デフォルトの名無しさん** · 2025/06/02(月) 22:59:32.23

Satori GC (No Gen0)は良さそうだから、さっさとGodotで試したデータを上げたら良いのに

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

godot使いが言っている最大レイテンシーが~5ms程度が実際に達成されるのか見て見たい

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

現実を無視して自己満足

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

5msが本当ならゲームチェンジャー

>>434
GC言語が楽なのは分かるから
逆にGC憎くしだな

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

>>439
GCを用いる以上はGCのコストを無くす方法はない
必ずペナルティが生じる

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

>>440
そこはクライアント側CPUはあまっているから大丈夫

ゲームだとGPU律速
DB/IOがあればそれで律速

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

というかJVMが取り入れたら世界線レベル
DSQLで1秒想定だったのが200分の1

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

GCはメモリ消費量の問題もあるため論外
何をするにも不利

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

>>439
無学だな
GCコストを下げる魔法は存在しない

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

>>420
Geminiの方が優秀だね

**デフォルトの名無しさん** · 2025/06/03(火) 00:06:53.82

見せて欲しい>>444氏の学とやらを

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

node.jsでサーバー構築してるけどRustにしたほうがええんかなあ

**デフォルトの名無しさん** · 2025/06/03(火) 09:39:37.51

Rustの利点が活きるAPIサーバなら普通にいいんじゃないか
フロントもある普通のWebアプリケーションだったら辞めたほうがいいと思うが

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

もし移行コストに見合った効果が出るのであれば相当にトラフィックの多いサーバーだろうから、
なんとなくの雰囲気や好みじゃなくて論理的に判断すべきだろう
たぶんそうではないんだろうけど、その場合モチベーションは無益な徒労を続ける上で無視できない重要な要素だから、Rustを採用することでモチベーションが上がるならやればいいんじゃないか

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

>>423
arena使わないとRustがGC言語に速度で負けるのはどういう場合かな？
大昔ならいざ知らず現代のGCが問題になるのはそんな単純なケースじゃないよ

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

>>450
arenaを使っていないRustプログラムがほとんど
もちろんGC言語より速い

**デフォルトの名無しさん** · 2025/06/03(火) 12:38:00.30

GC言語は速さと省メモリで勝ち目は一切ないため他の理由がある時のみ用いる

**デフォルトの名無しさん** · 2025/06/03(火) 12:47:09.85

>>449
構築コストはRustもNode.jsも覚えた人には同じ
省メモリと捌けるクライアント数はRustが圧倒的

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

>>453
クライアント数が増えたらサーバーの数を増やせばいいだけだ
一般に、Node.jsのエンジニアよりもRustのエンジニアの単価の方が平均的には高いから、
Rust採用による人件費の増加とサーバーのコスト低減効果のどちらが優位か？という金の問題に帰着する
先のAurora DSQLの例では明らかに後者が優位だが、>>447含め大多数のプロダクトでは状況は異なる
いやそうではない、Rustエンジニアの単価は安い、例えば俺のように、と主張するのなら話は別だかな

**デフォルトの名無しさん** · 2025/06/03(火) 13:04:22.23

>>454
Rustが使える人にとってそんなこと関係ない
Rustで書けばサーバ数も激減できる

**デフォルトの名無しさん** · 2025/06/03(火) 13:09:50.21

>>455
Rustはコーダーに好き勝手させないためのマネジメント向け言語だよ。

unsafeの扱いは問題あるけど、そのうちコーティング規約でライブラリアン以外はunsafe使えなくするケースが増えるんじゃないんかね。

**デフォルトの名無しさん** · 2025/06/03(火) 13:19:44.29

>>456
無知がデタラメ書くのは止めなさい
Webサーバー構築でunsafeなんて出て来ない

**デフォルトの名無しさん** · 2025/06/03(火) 13:42:18.60

>>457
「コーダーがunsafeを使わない」と「コーダーはunsafeを使えない」は別物。
マネジメントサイドはコーダーを信用しないから、禁止できるなら禁止するだろ。

**デフォルトの名無しさん** · 2025/06/03(火) 13:57:30.31

>>458
ほとんどの分野でunsafeは使われない
unsafeを使うなら関係者の合意形成が必須レベル

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

unsafeって、必要もないのにやったところで何かが書きやすくなるような性質のものではないと思うが
C言語上がりだとおまじないみたいに全部unsafeして生ポインタ操作とか平気でやるのか？

**デフォルトの名無しさん** · 2025/06/03(火) 14:29:03.14

後知恵で、やっぱ必要かなと思ったらやる
unsafeを使わなかった敗者がunsafeで復活するかもしれない

**デフォルトの名無しさん** · 2025/06/03(火) 14:43:50.09

熟練者になるまでunsafeの存在を忘れろ
初心者がunsafeを必要と思うのは無知と勘違いだ

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

IT土方にunsafeを使わせるな

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

FFIやるとunsafeはすぐ出てくる
webとは関係ないが

**デフォルトの名無しさん** · 2025/06/03(火) 18:09:13.25

unsafe禁止とか言ってないで真面目にレビューしろ

**デフォルトの名無しさん** · 2025/06/03(火) 19:07:45.18

処刑されないこともあるが裁判にかけられる

**デフォルトの名無しさん** · 2025/06/03(火) 20:15:54.93

>>464
FFIでも整備されていてunsafe不要な分野も多いね
未整備なら素人は手を出さない方が

**デフォルトの名無しさん** · 2025/06/03(火) 20:26:02.65

ほとんどの分野で使われないなら、なおさらunsafe禁止すべき。

膝を撃ち抜く自由を無くしたのがRustの利点なのだから、unsafeを使えないSafeRustのみのコーダーモードを用意すべきかと。
#![forbid(unsafe_code)]とかがデフォルトにならんかね。

**デフォルトの名無しさん** · 2025/06/03(火) 20:50:43.22

正確な判断はunsafeが使われた後でしかできないよ
後で訂正や追加されるようなルールは守りたくないと思ってる者ほど事前にルールを確定しようとする

**デフォルトの名無しさん** · 2025/06/03(火) 20:56:07.12

そう
ソースを確かめず、アプリやサービスで判断する場合
今の Rust は SafeRust との明示がない限り
デフォルトは unsafe Rust だと言う事

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

safe ＝ Rustコンパイラが安全性を保証する
unsafe ＝他の言語と同じくプログラマ自己責任

**デフォルトの名無しさん** · 2025/06/03(火) 21:09:34.02

Cコードを呼び出すときはunsafeを使わざるを得ないけどな

**デフォルトの名無しさん** · 2025/06/03(火) 21:19:12.46

> Cコードを呼び出すときはunsafeを使わざるを得ないけどな

△ Cコードを呼び出すとき
○ dll関数を呼び出すとき (その関数がRustで書かれていても)

ABI策定はどうなっているのか

**デフォルトの名無しさん** · 2025/06/03(火) 21:33:34.20

いつの間にか serde_yaml のリポジトリがアーカイブされてる…

**デフォルトの名無しさん** · 2025/06/03(火) 21:59:05.52

>>474
https://doc.serdeyml.com/serde_yml/

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

>>475
0.0.12

Build Status FAILING

**デフォルトの名無しさん** · 2025/06/03(火) 22:19:03.78

Node.jsのNestJS使ってる
使いやすくてすばらしい
Rustでもこういうフレームワーク使いたい

**デフォルトの名無しさん** · 2025/06/03(火) 22:42:41.40

>>473
Rust ABIはUndefined

**デフォルトの名無しさん** · 2025/06/03(火) 22:50:13.08

>>474
Rustのライブラリモデルの宿命だな

**デフォルトの名無しさん** · 2025/06/03(火) 23:00:49.81

>>474
これunsafe使いまくり
なのに今後何があっても直さないのか

**デフォルトの名無しさん** · 2025/06/03(火) 23:24:47.93

>>474
serde-yamlの管理人はsyn/proc-macro2やthiserror/anyhowなど幅広くやってるdtolnayだね

**デフォルトの名無しさん** · 2025/06/03(火) 23:28:35.41

それらも用心が必要という事態か？

**デフォルトの名無しさん** · 2025/06/03(火) 23:29:41.66

>>479
こんなに簡単にはしご外されるモデルなんだね

**デフォルトの名無しさん** · 2025/06/03(火) 23:30:11.84

yamlの仕様は闇が深いので関わらない方がいい

**デフォルトの名無しさん** · 2025/06/03(火) 23:39:58.59

>>481
C++⇔Rust FFIのcxxも

**デフォルトの名無しさん** · 2025/06/03(火) 23:47:22.51

MS/editが外部crate依存が少ないのは納得した

**デフォルトの名無しさん** · 2025/06/03(火) 23:49:19.18

>>486
それは不利だよ
自分で何もかもメンテしないといけない