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(月) 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
それは不利だよ
自分で何もかもメンテしないといけない

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

>>487
事実になっとくしただけだぞ

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

前スレのバグのFixがリリースされてた
https://github.com/microsoft/edit/releases/tag/v1.1.0

他にもcrashするバグがあったのか
Pressing Alt followed by a non-English keyboard key will not crash Edit anymore (#244)

**デフォルトの名無しさん** · 2025/06/04(水) 00:09:54.76

>>480
unsafe依存なserde-yamlではなく
safeなyaml-rust2が今は主流

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

やっぱシリアライズ形式はjsonだな

**デフォルトの名無しさん** · 2025/06/04(水) 00:50:17.21

メンテがいなくなり
移行先もなく
自分で手を入れる必要で
ようやくローカルフォーク

**デフォルトの名無しさん** · 2025/06/04(水) 00:52:07.22

逆に最初から全てを自分で持つのはメンテが辛いだけで不利

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

GUIライブラリの話もそうだけどこうやっていろんなライブラリを調べたりアップデートに対応したりするコストがRustはバカ高いんだよね

メンテナンスが急に止まったりしない安心して使える鉄板ライブラリの塊が増えないとバカ高いコストを支払ってもお釣りが来るCloudfrare級のところ以外からは見放さされる

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

メンテ必要なければ止まっていても何も困らない
必要になってから次策を考えればいい

**デフォルトの名無しさん** · 2025/06/04(水) 02:00:11.13

>>494
鉄板ライブラリが充実してる言語は何おすすめ？

**デフォルトの名無しさん** · 2025/06/04(水) 06:07:28.58

>>496
どうせ論外論法なんだろ

**デフォルトの名無しさん** · 2025/06/04(水) 08:00:19.73

Javaがエンタープライズで世界取ったのは、どこでも動くではなく
充実の標準＆企業主体のデファクトスタンダードライブラリの存在によるところが大きいとは思う

**デフォルトの名無しさん** · 2025/06/04(水) 08:14:31.76

それを言っても卵が先か雛が先かになるから仕方がない
Javaがエンタープライズで勝った大きな根本要因の一つは、UNIXサーバーをターゲットとした開発をWindows上で問題なく行えるから
その意味では、どこでも動くからというのは極めて重要な性質

**デフォルトの名無しさん** · 2025/06/04(水) 08:30:07.30

外のパッケージに依存すれば脆弱性も共有することになるし、サプライチェーン攻撃のリスクもある
crateのようなパッケージマネージャというのは完全に性善説で成り立っていて、
潜在的にはそこらのフリーソフトなんかより遥かに危険なのだが、
それを騒ぎ立てて経営層に問題として認識させることはエンジニアの間ではタブーとなっている

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

Rustで使われてたjemallocが開発終了してしまった件