Rust part30

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2025/05/28(水) 09:31:36.60ID:ciITeZ5D
公式
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(月) 08:51:42.98ID:h4tRZExf
いや、ウィンドウズはほぼ毎日使うよ
会社でも同じだわ
2025/06/02(月) 10:49:02.15ID:XWrf3Dm6
IDEなら編集しながらコンパイルしてるから不愉快な挙動をするのは火を見るより明らか
367デフォルトの名無しさん
垢版 |
2025/06/02(月) 11:11:49.92ID:NteO/GBi
>>293
Rustに限らずZigとかC#とか、extern cできる言語ならなんでもAndroidで使えるよ
Androidのjniやndkに全部C互換があるから
2025/06/02(月) 11:15:54.47ID:aX5lnsqr
出来るけど公式にサポートしているもののほうが楽ではある。
2025/06/02(月) 12:21:45.02ID:yqv+vYMm
Amazon Aurora DSQLは当初はJavaVM上のKotlinで開発されたものの、バグの混入を避けるためなどの理由でメモリ安全なRust言語での開発に切り替えたところ、それだけで性能が約10倍向上したとも説明されています。
https://www.publickey1.jp/blog/25/awspostgresqldbamazon_aurora_dsql.html
2025/06/02(月) 12:27:33.61ID:XWrf3Dm6
オールド公式とニュー公式どっちを選ぶかは結局自分で判断するしかない
2025/06/02(月) 13:03:04.42ID:cfmG04/d
再現方法を見てウィンドウ動かさなければ問題ないだろうと考える人は経験が浅すぎるわな
そういう感覚で物作ってると行き着くところは「複オジ品質基準」だぞ
2025/06/02(月) 13:17:30.01ID:aX5lnsqr
わかった上で重大ではない (から放置で良い) と判断することはあるだろうけど……
そういう小さなことが積み重なってよくわからん挙動を引き起こすこともそれなりにある話。
2025/06/02(月) 14:20:48.94ID:w8zlJvU9
>>369
困るとそれを貼り付けるね
374デフォルトの名無しさん
垢版 |
2025/06/02(月) 14:21:05.82ID:czhP5p30
>>369
やはりサーバー分野はRustが最強だな
375デフォルトの名無しさん
垢版 |
2025/06/02(月) 14:21:43.53ID:czhP5p30
>>373
どゆこと？
376デフォルトの名無しさん
垢版 |
2025/06/02(月) 14:31:27.48ID:czhP5p30
373がなにを否定したいのかよく分からないがRustの並列処理は非常に効率がよい
Rustで再開発することによりこの恩恵を受けて大幅に性能が向上した
今回AWSが正式リリースしたAurora DSQLは並列処理に重きをおいたものだから特に高い効果を得られたのだろう
2025/06/02(月) 14:41:07.84ID:XWrf3Dm6
カオスは初期値だけで引き起こせるんだよね
途中の小さな積み重ねは原因ではなく結果
378デフォルトの名無しさん
垢版 |
2025/06/02(月) 14:49:11.87ID:z+CFOxG+
KotlinというかJavaの並行処理はむっちゃ安全だけどその代わりにパフォーマンスが犠牲になってる。
C++のはパフォーマンスが良いけどみんなご存知のように安全性がゴミ。
Goのはパフォーマンスも安全性もいいからRustかGoのどちらを使うかでRustが選ばれたんでしょ知らんけど。
379デフォルトの名無しさん
垢版 |
2025/06/02(月) 15:15:13.25ID:z+CFOxG+
俺が考察せずともAWSの当事者の後日談的な記事あるじゃん。
KotlinのJVMのガベージコレクションのオーバーヘッドが敵だったみたいね。
もともとKotlinのスペシャリストであってRustは初心者だった開発チームが苦労の果てにコンパイル可能なコードを実行してみたらなんとKotlinで書いていたコードの10倍性能がよかった。
気分を良くした開発チームがどんどんKotlinのコードをRustに書き換えていったんだって。

Just make it scale: An Aurora DSQL story
https://www.allthingsdistributed.com/2025/05/just-make-it-scale-an-aurora-dsql-story.html
2025/06/02(月) 15:31:24.30ID:AD6qUyw7
そんでこれはオープンソースなのか?
381デフォルトの名無しさん
垢版 |
2025/06/02(月) 15:53:39.10ID:z+CFOxG+
CLI部分はオープンソースだよ
2025/06/02(月) 15:55:37.90ID:3XGAbOaK
本体をオープンソースにしろよw
2025/06/02(月) 15:58:30.64ID:bKFtipAC
>>378
単に会社の方針としてJavaかKotlinかC/C++かRustで、Goは選択肢にないんだろう
379の元記事読んだけど技術選定の際に社内実績をかなり重視してそうだし、そもそも制約がなきゃKotlinなんか選ばないでしょ
2025/06/02(月) 15:59:31.58ID:WAnrQ9FR
>>378
Goは同じくガベージコレクションのある言語だから厳しい
385デフォルトの名無しさん
垢版 |
2025/06/02(月) 16:03:48.59ID:z+CFOxG+
やはり敵はガベコレにあり。
2025/06/02(月) 16:06:35.67ID:qTYmSia5
敵はオープンソース資産を食い逃げする企業だろ
2025/06/02(月) 16:28:08.28ID:owUgTJXK
>>384
GoのGCはJVMと比較すると低遅延だから、記事の通りGCによる停止が問題になっている状況なら選択肢になりうる
2025/06/02(月) 16:40:40.26ID:k0FlxjxP
>>387
GCによる害悪2つのうちレイテンシ悪化はGoで軽減できるが全体パフォーマンスはGoも悪化する
2025/06/02(月) 16:43:17.43ID:/ossn2s1
悲報！Rust版AV1デコーダーがCより5%遅い問題が解決できず、カネで解決しようとする
https://www.memorysafety.org/blog/rav1d-perf-bounty/

Macではもっと遅かったしRustじゃなくてGoで良い領域だな
2025/06/02(月) 16:49:07.25ID:/ossn2s1
>>236 >>243
Arc削除できないと返答してるな
391デフォルトの名無しさん
垢版 |
2025/06/02(月) 16:52:44.19ID:Ca4PuVUf
シャープ、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.56ID:64YfA+90
Arcは所有者を増やすときのみカウンタ+1のオーバーヘッドがある
参照はderefによりコストゼロ
2025/06/02(月) 17:21:42.21ID:fJbPstNP
>>390
なるほど
幸先良くスタートしたけど分かっていても直せない箇所が出て来る訳ね
2025/06/02(月) 17:27:52.34ID:64YfA+90
所有者を増やしまくる愚を犯さない限りArcにデメリットはない
2025/06/02(月) 17:49:16.64ID:iSmTN9kp
>>379
Aurora DSQLは、データベース管理ソフト(DBMS)であり、データを収めているのは原則としてHDDやSSD。
だから、メインメモリーは、キャッシュのために少し使う、というのが基本のはず。
だから、データ集約に関係する高度なアルゴリズムはHDD/SSDに対して必要となるが、
メインメモリに対しては余り必要ない。だから、Rustが適す。
2025/06/02(月) 17:52:38.64ID:F42JmYRi
>>395
もうちょっと調べた方が良いよ、DB全般
2025/06/02(月) 17:59:35.62ID:iSmTN9kp
>>396
ちゃんとした言葉で反論してください。
2025/06/02(月) 18:02:50.08ID:owUgTJXK
>>397
Geminiに聞いてやったぞ

ご指摘のコメントは、データベースの仕組みとRustに関する理解に多くの誤解があるようです。
* DBのメインメモリ利用の認識違い: データベースはキャッシュだけでなく、データ処理やソート、インデックスなど、パフォーマンスのためにメインメモリを広範に活用します。「少し使う」というのは誤りです。
* Rust適用の理由が不適切: Rustはメモリを安全かつ効率的に制御できるため、DBのようなパフォーマンスが求められるシステム開発には適しますが、「メインメモリをあまり必要としないから」という理由は論理が破綻しています。
したがって、このコメントは技術的に見て多くの点で適切ではありません。
2025/06/02(月) 18:04:48.37ID:iSmTN9kp
>>398
DBMSの場合、メインメモリーに置いておく集約構造は、データの量が小さい。
だから、ある程度の速度性能が出れば、全体の速度には影響が及びにくい。
2025/06/02(月) 18:05:34.76ID:iSmTN9kp
そのGeminiの回答は、理解が浅い。
2025/06/02(月) 18:06:28.04ID:owUgTJXK
>>399
お相手の方の返信も、やはりデータベースのメモリ利用とパフォーマンスに関する誤解が続いていますね。
主な問題点
* 集約構造のデータ量は「小さい」は誤り: データベースは、高速化のために可能な限り多くの集約データや中間結果をメモリに置こうとします。データ量が多いほど、メモリを効率的に使う必要があります。
* 「ある程度の速度」で全体の速度に影響が出にくいは誤り: メモリ上の処理が非効率だと、それが全体のパフォーマンスのボトルネックになり、特に大規模データや高負荷環境では深刻な影響が出ます。少しの遅延でも、積み重なると大きな差になります。
データベースの性能は、メモリの効率的な活用に大きく依存します。

書き込む前にAIにチェックしてもらうことをお勧めする
2025/06/02(月) 18:08:30.83ID:iSmTN9kp
>>401
ただ、ネットで使うことが多い DBMSは、単位時間当たりの書き込み回数が小さい傾向がある。
そういう事まで含めて考えれば、あなたやGeminiの回答は理解が浅い。
2025/06/02(月) 18:11:00.40ID:iSmTN9kp
論理ではなく、トータルの必要時間を数式で考えないといけない。
2025/06/02(月) 18:13:55.93ID:64YfA+90
>>399
一番効果が大きいのはメモリ上のキャッシュ効果
そのキャッシュ構造管理もRustがベスト選択
2025/06/02(月) 18:16:26.41ID:iSmTN9kp
>>404
DBMSに必要な処理の特徴が、Rustとは相性がいいとは言えるかもしれないが、
DBMS以外のアプリではもっと別の特徴が必要となることが有る。
2025/06/02(月) 18:25:01.24ID:iSmTN9kp
>>404
「405」で「キャッシュ」という言葉を使ったが、CPUの中のキャッシュの事ではなく、
メインメモリー自体が HDD/SSDに対するキャッシュとみなせるという意味で使った。
混乱してはいけない。
2025/06/02(月) 18:32:11.04ID:iSmTN9kp
>>406
誤: 405
正: 395
408デフォルトの名無しさん
垢版 |
2025/06/02(月) 18:40:12.36ID:KbudeIgC
次からスレタイ「複おじ Part31」に変えようぜ
2025/06/02(月) 18:42:37.74ID:64YfA+90
>>406
DBはそのHDD/SDDに対するキャッシュ効果が最も効く
そのキャッシュ管理にもRustが最適
2025/06/02(月) 18:44:18.26ID:iSmTN9kp
>>409
もちろん、KotlinやJavaよりは効くだろう。
2025/06/02(月) 18:50:00.32ID:uLOpbVD1
>>408
別にそれでもいいよｗ
普通にRustスレ立ててもおかしな人間がやって来て自説を繰り返すだけだから
2025/06/02(月) 19:31:43.37ID:a238vP89
それやっても自分でRustスレ立てて何事もなかったかのように振る舞うだけだと思う
2025/06/02(月) 20:32:38.85ID:ddfioDeu
>>389
GCがあり不便なGoは適用範囲がほとんどないのよ
Goが使われている領域の狭さを見つめてね
2025/06/02(月) 20:44:46.47ID:+aIkiiO4
将来的にオリジナルのdav1dと乖離させない様に出来るだけ1to1で移行するには良いのでは
TypeScriptコンパイラと同じ状況かと
2025/06/02(月) 20:51:40.32ID:+aIkiiO4
書いてあるね
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.00ID:+aIkiiO4
Macの現状は7%差か
もう「significant」じゃない気がする

> Apple M3で8.8%遅かったのが7%になったとな
> 「5%遅い」はAMD Ryzenでの数字
2025/06/02(月) 20:56:39.33ID:OnNK0eHp
小さいメモリを確保したり解放したりを頻繁にやるわけではないユースケースでは GC はそんなに速度に影響しない。
するとしても回避策はある。
そんなことより Go の問題点はメモリ管理を自動化しておきながらメモリアクセス違反をあまり防げないことだな。
C/C++ から移行する分にはそんなもんだろと思えるが、メモリ安全性を期待したら失望すると思う。
2025/06/02(月) 21:00:04.05ID:+aIkiiO4
どの道テストはみっちり必要ですよ
コンパイル時のあの標語は罠かと
2025/06/02(月) 21:06:48.63ID:3VeAkVql
Goは各種安全性対策が中途半端でプログラマの自己責任だからな
Goに未来はない
2025/06/02(月) 21:18:44.47ID:3Ri7GR+v
>>396
禿同だな
>>395というか複おじはド素人なのになんで無理に変なコメントしようとするんだ？
2025/06/02(月) 21:28:48.01ID:uzsj2Y7F
>>417
>小さいメモリを確保したり解放したりを頻繁にやるわけではないユースケースでは GC はそんなに速度に影響しない。
真逆だろ
2025/06/02(月) 21:28:51.61ID:XWrf3Dm6
キリトリ記事禁止の呪いか
思いつたことはすべて公表しなければならないという
2025/06/02(月) 21:40:20.45ID:OnNK0eHp
>>421
確保しようとするメモリが大きくても小さくても一回あたりの確保・解放に必要な実行コストはあまり差がない。
大きさではなく回数が効いてくるので頻繁な確保・解放がないなら GC のコストは小さいよ。
画像処理関係は大きなデータは扱うがメモリを確保・解放する回数が大きいわけではない。
2025/06/02(月) 21:43:30.36ID:nIRomA7P
>>423
C/C++/Rustが絶対に勝つ利用法だ
425デフォルトの名無しさん
垢版 |
2025/06/02(月) 21:48:51.08ID:GgLxuemZ
>>413
Dockerとか使ったことないの？
2025/06/02(月) 21:56:07.57ID:OnNK0eHp
Go の GC もヒープメモリの確保と解放のコスト自体は C と同程度じゃないかな。
生存しているか (参照が残っているか) どうかの判定にコストがかかっているので依存関係の複雑なデータ構造だと速度的には不利になる。
どうせそのあたりを意識しながら設計するなら Go より Rust のほうがいいかなぁとは思う。
2025/06/02(月) 22:01:25.40ID:OnNK0eHp
逆にもう手に負えないほど複雑なデータ構造になってしまったときは GC の実行コストを受け入れてでも任せてしまいたいということはあるかもね。
2025/06/02(月) 22:01:47.11ID:bKFtipAC
>>426
GC自体は軽い処理で、それ自体のコストが問題になることは少ない
問題は、現在主流のGCの実装では、予測困難なタイミングでGCによる比較的長時間のアプリケーションの停止が生じること
そもそも明示的なdeleteやRAIIや参照カウントのような方法も決してゼロコストではないわけで、そのコストを払うタイミングが違うんだよ
2025/06/02(月) 22:03:46.27ID:J5nAKj7S
>>425
Docker創始者が明言「WASM+WASIがあればDockerは不要」
https://twitter.com/solomonstre/status/1111004913222324225
https://twitter.com/thejimwatkins
2025/06/02(月) 22:26:19.81ID:GjabKUPP
なお>>429 tweetから丸6年後の今
2025/06/02(月) 22:28:58.46ID:UNbfduAo
>>428
1行目から2行目で世界線が違うのか？
2025/06/02(月) 22:33:31.23ID:bKFtipAC
>>431
あなた以外には理解いただけているものと思うが、念のため補足すると、
GCの問題は処理コストの大きさではなく、そのコストを払うタイミングにある
2025/06/02(月) 22:44:13.11ID:ur17A/w2
>>432
要するにこれが良いと言う事か

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

新計測データが来てる
2025/06/02(月) 22:45:31.08ID:MPKk5iPb
>>432
GCはどの方式でも処理コストが高い
これがGC依存言語が遅い原因
2025/06/02(月) 22:48:22.30ID:MPKk5iPb
GCするなら一斉停止が最も低コスト
並行しながらGCは時間の分散ができる代わりにコストの増大を招く
2025/06/02(月) 22:59:32.23ID:ur17A/w2
Satori GC (No Gen0)は良さそうだから、さっさとGodotで試したデータを上げたら良いのに
2025/06/02(月) 23:06:29.24ID:ur17A/w2
godot使いが言っている最大レイテンシーが~5ms程度が実際に達成されるのか見て見たい
2025/06/02(月) 23:16:57.64ID:9HexqnhX
現実を無視して自己満足
2025/06/02(月) 23:35:07.57ID:e80Lnwqt
5msが本当ならゲームチェンジャー

>>434
GC言語が楽なのは分かるから
逆にGC憎くしだな
2025/06/02(月) 23:41:42.00ID:MPKk5iPb
>>439
GCを用いる以上はGCのコストを無くす方法はない
必ずペナルティが生じる
2025/06/02(月) 23:43:45.20ID:e80Lnwqt
>>440
そこはクライアント側CPUはあまっているから大丈夫

ゲームだとGPU律速
DB/IOがあればそれで律速
2025/06/02(月) 23:50:27.08ID:e80Lnwqt
というかJVMが取り入れたら世界線レベル
DSQLで1秒想定だったのが200分の1
2025/06/02(月) 23:52:03.77ID:w80jJ2EG
GCはメモリ消費量の問題もあるため論外
何をするにも不利
2025/06/02(月) 23:57:57.40ID:ab+RrVue
>>439
無学だな
GCコストを下げる魔法は存在しない
2025/06/03(火) 00:01:16.56ID:7WxgzsHE
>>420
Geminiの方が優秀だね
2025/06/03(火) 00:06:53.82ID:7WxgzsHE
見せて欲しい>>444氏の学とやらを
447デフォルトの名無しさん
垢版 |
2025/06/03(火) 01:21:41.32ID:WkxEnd7y
node.jsでサーバー構築してるけどRustにしたほうがええんかなあ
2025/06/03(火) 09:39:37.51ID:xhVN3bhy
Rustの利点が活きるAPIサーバなら普通にいいんじゃないか
フロントもある普通のWebアプリケーションだったら辞めたほうがいいと思うが
2025/06/03(火) 10:20:07.21ID:cgHky4oh
もし移行コストに見合った効果が出るのであれば相当にトラフィックの多いサーバーだろうから、
なんとなくの雰囲気や好みじゃなくて論理的に判断すべきだろう
たぶんそうではないんだろうけど、その場合モチベーションは無益な徒労を続ける上で無視できない重要な要素だから、Rustを採用することでモチベーションが上がるならやればいいんじゃないか
2025/06/03(火) 10:46:12.79ID:97yIcMrS
>>423
arena使わないとRustがGC言語に速度で負けるのはどういう場合かな？
大昔ならいざ知らず現代のGCが問題になるのはそんな単純なケースじゃないよ
2025/06/03(火) 11:29:40.94ID:g1P4UzEL
>>450
arenaを使っていないRustプログラムがほとんど
もちろんGC言語より速い
2025/06/03(火) 12:38:00.30ID:SsEYb5J+
GC言語は速さと省メモリで勝ち目は一切ないため他の理由がある時のみ用いる
2025/06/03(火) 12:47:09.85ID:rqu5SnLS
>>449
構築コストはRustもNode.jsも覚えた人には同じ
省メモリと捌けるクライアント数はRustが圧倒的
2025/06/03(火) 13:01:58.34ID:Kt5mEPBd
>>453
クライアント数が増えたらサーバーの数を増やせばいいだけだ
一般に、Node.jsのエンジニアよりもRustのエンジニアの単価の方が平均的には高いから、
Rust採用による人件費の増加とサーバーのコスト低減効果のどちらが優位か？という金の問題に帰着する
先のAurora DSQLの例では明らかに後者が優位だが、>>447含め大多数のプロダクトでは状況は異なる
いやそうではない、Rustエンジニアの単価は安い、例えば俺のように、と主張するのなら話は別だかな
2025/06/03(火) 13:04:22.23ID:rqu5SnLS
>>454
Rustが使える人にとってそんなこと関係ない
Rustで書けばサーバ数も激減できる
2025/06/03(火) 13:09:50.21ID:/7yVoUF5
>>455
Rustはコーダーに好き勝手させないためのマネジメント向け言語だよ。

unsafeの扱いは問題あるけど、そのうちコーティング規約でライブラリアン以外はunsafe使えなくするケースが増えるんじゃないんかね。
2025/06/03(火) 13:19:44.29ID:VYRLmXgA
>>456
無知がデタラメ書くのは止めなさい
Webサーバー構築でunsafeなんて出て来ない
2025/06/03(火) 13:42:18.60ID:/7yVoUF5
>>457
「コーダーがunsafeを使わない」と「コーダーはunsafeを使えない」は別物。
マネジメントサイドはコーダーを信用しないから、禁止できるなら禁止するだろ。
2025/06/03(火) 13:57:30.31ID:VYRLmXgA
>>458
ほとんどの分野でunsafeは使われない
unsafeを使うなら関係者の合意形成が必須レベル
2025/06/03(火) 14:14:20.21ID:xhVN3bhy
unsafeって、必要もないのにやったところで何かが書きやすくなるような性質のものではないと思うが
C言語上がりだとおまじないみたいに全部unsafeして生ポインタ操作とか平気でやるのか？
2025/06/03(火) 14:29:03.14ID:idwVU/iA
後知恵で、やっぱ必要かなと思ったらやる
unsafeを使わなかった敗者がunsafeで復活するかもしれない
2025/06/03(火) 14:43:50.09ID:VYRLmXgA
熟練者になるまでunsafeの存在を忘れろ
初心者がunsafeを必要と思うのは無知と勘違いだ
2025/06/03(火) 17:45:47.84ID:ZZq2n2YO
IT土方にunsafeを使わせるな
2025/06/03(火) 17:51:28.94ID:+aVViU0f
FFIやるとunsafeはすぐ出てくる
webとは関係ないが
2025/06/03(火) 18:09:13.25ID:FQzY7vd6
unsafe禁止とか言ってないで真面目にレビューしろ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。