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(月) 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が開発終了してしまった件

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

広い意味では自動化に人気がないだけだな
手動のほうが良いというのがタブーになる

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

AWS社員はもっとRustライブラリの保守に尽力しろ

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

>>501
終わってない。
facebook の管轄下に移動した。
https://github.com/facebook/Jemalloc

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

「どこでも動く」の究極の形は計算機がなくてもできるカードゲームや将棋みたいなやつだ

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

>>474
「アーカイブ」という言葉の意味は、メンテナンスしなくなったから、
書庫の様な場所に保管して開発を終える、という意味？

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

>>506
GitHubにおけるアーカイブは、開発終了したリポジトリを凍結する機能
引き続き読取は可能だが書込みは不可になる

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

アーカイブされたのは2024年3月
serde_yamlを使いたい人は今後もそのまま使えて使われてる

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

ただしserde_yamlはCから移植のunsafe_ libyamlが下請け
safeなyaml_rust2をベースがいいだろうね

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

機械化（機械に責任転嫁）できないという点だけを見れば自己責任は禁忌だが

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

Rust推進者って、Linuxもそうだったが、自分は変わらず
世界の方を変えようとしているから、ウザイ。
自分が(社会的地位が)上であることは絶対的にゆるぎないと思ってる気がするよ。

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

むしろ、今までずっとそのようにしてきたことが社会を歪めておかしなことになって来た
事には気づいてない。

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

C#も押し付けがましかったが、それがRustに変わろうとしているらしい。
その前はJavaだった。Kotlinもそうされそうになったが衰退したらしいが。

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

中国人もそうなんだよ。民主主義で困ってないのに、民主主義や自由は
幻想だ。『日本や台湾は「幻想のバブルの中に」入る。
これからの時代は共産主義だ。だから、台湾の体制を中共に譲らなければ
ならない。それが人類にとって幸せだ。世界に赤い旗を立てる事が
人類の未来のためになるんだ』
などと言っている。Rustもそれに非常に似ている。

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

「xxxはRustに書き直して高速になった。バグが減った」
って、EVや空飛ぶ車に対するChinaのプロパガンダにそっくり。

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

イーロンマスクも南アメリカで17歳まで育ち、カナダから北米に渡り、
恥知らずにも中国で金儲けをし、Rustを宣伝している。

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

イーロンマスクも南アメリカで17歳まで育ち、カナダから北米に渡り、
恥知らずにも中国で金儲けをし、Rustを宣伝している。

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

南アメリカ-->南アフリカ

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

複オジの謎自演が湧いたから軌道修正

>>509
その理屈でこうなる

Cから移植の rav1d も意味ない

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

イーロン・マスク、X表示名を「Gorklon Rust」に変更
https://jp.beincrypto.com/elon-musk-gorklon-rust-meme-coin-hype/

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

アホみたいだな。