Rust part33

**デフォルトの名無しさん** · 2025/08/15(金) 17:49:30.70

公式
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 part32
https://mevius.5ch.net/test/read.cgi/tech/1755057787/
Rust part31 https://mevius.5ch.net/test/read.cgi/tech/1751545806/
Rust part30 https://mevius.5ch.net/test/read.cgi/tech/1748392296/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2025/10/15(水) 18:23:05.35

所有権の複製おじさんいたやん
ああいう人にとってはRust難しかったやろな
あのクソコード見てるとなんか苦心が透けて見えて苦笑いやわ

**デフォルトの名無しさん** · 2025/10/15(水) 20:05:33.91

>>249
学習コストが高いのは、所有権ライフタイムを除けば、マルチスレッド関連だと思う
シングルスレッドの同期処理しかやらないなら、10時間以下の学習で実践投入できる……かもしれないけど(やったことないから分からない)

**デフォルトの名無しさん** · 2025/10/15(水) 20:24:15.79

fortranよりも使われtないRustをこのAIの時代に学ぶって何の意味があるんだろ

**デフォルトの名無しさん** · 2025/10/15(水) 20:45:37.79

>>253
マルチスレッド関連でRust特有はSendとSyncというマーカートレイトで区別するとは賢いなあくらいじゃないか
Mutexや条件変数など排他制御やchannelなどは他の言語で知ってれば困らない
いきなりatomicまで進む人ならメモリモデルはC++と同じ
ArcはRc理解した後なら悩むことなく

**デフォルトの名無しさん** · 2025/10/15(水) 20:50:01.63

>>254
AI時代だからこそ、AIが扱う上で表現力が高くて高速堅牢な言語には価値がある
と言いたいところだが、Rustはライブラリを全面的にコミュニティに頼らなきゃいけないし、あまりデファクトスタンダードが揃ってなくて常に乱立してるからAIと相性良くないんだよなあ
乱立に関しては比較的新しい言語だからというよりは、文化的に割とそういう傾向がある気がするんだよね

**デフォルトの名無しさん** · 2025/10/15(水) 21:03:09.05

>>255
Rust以前に触れた言語や領域の経験値と、Rustでやりたいことがそこまで被ってれば学習は早いだろうな
俺は元データサイエンティストだからC/C++とか触ってもOpenCVだったんだよね…
pythonの経験値は十年あるんだけどさあ

**デフォルトの名無しさん** · 2025/10/15(水) 21:04:31.59

あと非同期処理周りでヒープにFutureをピンさしてメモリ管理するのいまだに慣れない
辛いわ

**デフォルトの名無しさん** · 2025/10/15(水) 21:05:33.85

そういうコミュニティ依存って、今時の言語の、もっというとフロントエンドの文化なんだろうけど
それこそ10数年生きるのが普通なバックエンド向けのRustとは最高に合わないところではあるわな

**デフォルトの名無しさん** · 2025/10/15(水) 21:13:31.82

>>254
C/C++の置き換えを狙ってるならFortranとはあんまし被らないでそ。
本気で置き換えるなら512Bや256Bという、1kBも無いようなマイクロコントローラーにも書き込めるバイナリ吐くとか。
(Cとアセンブラしかない世界）

そうでなくてもAIの時代だからこそ自動運転な自動車組み込み向けはC++よりもRust。

Fortranとなら、それこそスパコンで並行並列処理は文法的にはRustの方が有利だけど、ライブラリやら最適化やらはFortranが長年資産やノウハウがあるから一朝一夕には行かんわな。
それこそ、これからの動き次第。

**デフォルトの名無しさん** · 2025/10/15(水) 22:43:58.29

>>258
何が辛い？
個別に目的と必要性と仕組みを理解しておけば組み合わさっても困らない

**デフォルトの名無しさん** · 2025/10/15(水) 23:04:23.69

>>242
そもそも何を作るかによる
あんたのような素人は黙っていた方がいい

**デフォルトの名無しさん** · 2025/10/16(木) 00:12:35.85

非同期やマルチスレッドを使わない分野もいくらでもあるため
何を作るかによるのは正しい
しかし黙れはスレ妨害

**デフォルトの名無しさん** · 2025/10/16(木) 01:46:09.80

Rustの構文って無駄の少ない洗練された感じがあるよな
関数型言語ぽい部分も多いから古めの手続き型言語ユーザーからしたら難しいのかもしれないが

**デフォルトの名無しさん** · 2025/10/16(木) 02:22:05.21

日本はともかく世界的に見れば流行りの第一言語はpythonだから
そこからRustを覚えるのは割としんどいはず

**デフォルトの名無しさん** · 2025/10/16(木) 02:22:08.52

日本はともかく世界的に見れば流行りの第一言語はpythonだから
そこからRustを覚えるのは割としんどいはず

**デフォルトの名無しさん** · 2025/10/16(木) 03:06:05.37

Pythonしか使えないような似非プログラマーは
Rustじゃなくてもいいから他の言語も使えるようになりなさい

**デフォルトの名無しさん** · 2025/10/16(木) 07:39:35.29

>>264
そうか？
C#などのモダンC系に倣って関数型由来の機能を取り入れてはいるけど、根本的に関数型じゃないからこそ複雑になってる面が大きくて、
割り切ってもっと関数型に寄せれば色々切り捨てることは可能なはずだよ
所有権や可変参照の排他性みたいなRustのユニーク機能って結局は手続きプログラミングのために必要になので

**デフォルトの名無しさん** · 2025/10/16(木) 07:49:42.75

>>264
逆ポーランドじゃない構文は、文を読む方向と制御の流れが異なるという根本的な問題があるから洗練されることは無い。UFCSぐらいはサポートしてほしいところ。

**デフォルトの名無しさん** · 2025/10/16(木) 07:52:40.33

>>268
可変参照を許さない関数型は非効率で死んでいった
C++と同等の速度を出せないなら存在意義がない
C++と同等の速度を出せた上でRustは様々な抽象化に成功している

**デフォルトの名無しさん** · 2025/10/16(木) 07:57:25.89

>>269
UFCSは最悪の機能
可能な限りフリー関数をなくして最小限にすべきであり
UFCS適用可能なものはそもそもフリー関数ではなくメンバ関数とするのが正しい解決方法
Rustもおおむねその方向

**デフォルトの名無しさん** · 2025/10/16(木) 08:15:27.91

pythonて人気てゆうよりもはやbasicみたいな感じじゃないの
python使う仕事てpython自体の知識より数学とか統計の知識がいりそうだし
てかaiてpythonみたいな遅いやつ使ってて大丈夫なんかな
rustにも機械学習ライブラリあるしそれでよくね
組込 web ai全部rustでできるせつ１

**デフォルトの名無しさん** · 2025/10/16(木) 08:18:48.99

>>271
それは洗練された構文の話じゃないね。自分でも「機能」て書いているのに気づいていないのかしらん？

**デフォルトの名無しさん** · 2025/10/16(木) 08:20:17.29

>>270
所有権や可変参照の排他性は場合によっては実行効率が犠牲になる
程度問題よ

**デフォルトの名無しさん** · 2025/10/16(木) 08:32:20.65

UFCSは有害な汚染
導入してはいけない

**デフォルトの名無しさん** · 2025/10/16(木) 08:35:08.89

>>274
所有権で実行効率が犠牲になる？？
そんな事例あるか？

**デフォルトの名無しさん** · 2025/10/16(木) 08:44:13.38

>>274
実行時にペナルティが生じうるケースなんてあるの？

**デフォルトの名無しさん** · 2025/10/16(木) 08:47:02.94

「正しい」とか「有害」とか断定してるのにその根拠は示せないのか。
科学から遠く離れた宗教の世界ですなぁ。しかも教祖ではなくタダの信者が権威を騙るのところとかは堕落した宗教みたいに見える。

**デフォルトの名無しさん** · 2025/10/16(木) 09:01:39.29

UFCSってフリー関数の第一引数が型Xならば勝手に型Xにimplしてメソッド増やしたことにみなしてしまおうという汚染のやつだろ
Rustではわざわざ混乱を避けるためや注意のため敢えてメソッドにせずにフリー関数のみを用意しているケースもあるくらい清潔さを気にしているのにそこへUFCS汚染を持ち込むのは正気の沙汰じゃない

**デフォルトの名無しさん** · 2025/10/16(木) 09:28:00.47

>>276
そりゃ現実に競合しないと分かっていてもMutexを使わざるを得ないケースとか普通にあるでしょ

**デフォルトの名無しさん** · 2025/10/16(木) 09:48:06.42

>>280
Mutexはマルチスレッドでメモリを共有する時にその排他制御のために使う
Cなど他の言語にもMutexは当然ある
「所有権で実行効率が落ちる」という聞いたこともない話の事例になっていない

**デフォルトの名無しさん** · 2025/10/16(木) 09:56:20.09

>>281
データストアを複数スレッド間で共有していても現実に絶対に競合しないと分かっている状況というのは普通にあるよ

**デフォルトの名無しさん** · 2025/10/16(木) 10:07:41.24

競合しないはず大丈夫だろうと思ってMutexを使わなかったために稀に競合する時のみバグる話はRustと関係なく大昔からあるよ
だからRustと関係なくどの言語でもMutexを使うのが正解
所有権と関係なし

**デフォルトの名無しさん** · 2025/10/16(木) 10:45:16.18

>>279
メソッドを厳密に管理したいんだったら、メソッドを表すドット表記とは別の表記を使えばいいだけの話かと。例えばアロー表記とか。
（もともとは>>264の洗練された構文の話だし）

メソッドにフリー関数とは違う特別な意味を持たせて使い分けしなくてはならないRustでそうなるのはそうなのかもね。
メソッドのユーザー側に隠蔽できていないのは洗練されていないと思うけど。

**デフォルトの名無しさん** · 2025/10/16(木) 11:10:36.20

Rustで非同期処理を実装してるけど、やっぱ魔境だと思うわ
俺はできるけど……って、謎の気持ちになる

**デフォルトの名無しさん** · 2025/10/16(木) 11:16:10.30

技術的にニッチなところ触りすぎてる時の危機感がすごい

**デフォルトの名無しさん** · 2025/10/16(木) 11:17:39.14

>>283
データ競合の検証が不十分なだけだ。
検証をサボる代わりに不必要なところまでガードするのもひとつの選択ではあるがそれを唯一の正解とすべきではない。

**デフォルトの名無しさん** · 2025/10/16(木) 11:37:34.04

排他制御はコードだけで競合しないことを保証できない時はとりあえず実装するものと思ってる

**デフォルトの名無しさん** · 2025/10/16(木) 11:44:21.55

競合による不整合は殆どの場合複数のデータストアに跨って生じるもので、競合を想定していないロジックが万一競合したなら、Mutex使ってようがまともに動く可能性は低い
そもそもそういった予期せぬ事態が発生しにくくするという点においては、競合を防ぐ解としては関数型的なイミュータブルのほうがずっと有効だ
結局どこまで効率を犠牲にして安全側に倒すかという程度問題であり、決してRustのやり方が絶対的な解というわけではない

**デフォルトの名無しさん** · 2025/10/16(木) 12:45:11.24

理屈は通ってるけど現場では通らないだろうな

**デフォルトの名無しさん** · 2025/10/16(木) 13:18:22.07

>>289
デタラメだな
その関数型的なイミュータブルでは何の解決にもなっていない
例えば最も単純な1, 2, 3, 4, 5, ...と順に抜けがなく重複しないID発行機をマルチスレッドで共有する場合を考えてみろ

**デフォルトの名無しさん** · 2025/10/16(木) 14:14:20.51

>>291
言葉通りにやるならSTMとかあるし、そもそも関数型なら実際には連番の遅延シーケンスを作ってmapするか、
もしくはIDなしで結果のシーケンスを作った上で後からIDを振るのが一般的だろうな

**デフォルトの名無しさん** · 2025/10/16(木) 14:46:26.27

>>292
話の根幹であるマルチスレッドに対応できていない
「連番の遅延シーケンスを作ってmap」「IDなしで結果のシーケンスを作った上で後からIDを振る」
しかも現実のシステムが作れない

**デフォルトの名無しさん** · 2025/10/16(木) 15:14:30.10

>>289
関数型イミュータブル手法ではマルチスレッドで競合する部分をどう解決するの？

>>292
それでは何も解決できていないですね

**デフォルトの名無しさん** · 2025/10/16(木) 15:28:40.11

>>293
mapを並列実行すりゃいいだけ
Rustでもそんなcrate山ほどあるしごく普通のテクニックよ

**デフォルトの名無しさん** · 2025/10/16(木) 15:33:47.69

>>295
色んなリクエストを処理してるマルチスレッドが動いていて各々がIDを欲しいのだからmapは無理だな

**デフォルトの名無しさん** · 2025/10/16(木) 15:38:04.63

>>296
知らんがな
WebアプリなんだったらDBかUUID使うんだからmutexがどうのという話じゃないぞ

**デフォルトの名無しさん** · 2025/10/16(木) 15:44:47.08

>>297
そんな特定の話はされてないよね
マルチスレッドで必ず起きる競合を
イミュータブルな関数型を使えば回避できて安全だ！とウソの主張をする人がいる話だよね

**デフォルトの名無しさん** · 2025/10/16(木) 15:56:59.81

>>298
だからSTMでできるでしょ
CAS命令使うからlockなんか要らん

**デフォルトの名無しさん** · 2025/10/16(木) 16:35:23.71

普通はatomic fetch-addするからソフトウェアのレベルでは競合しないわな

**デフォルトの名無しさん** · 2025/10/16(木) 16:38:08.70

>>295
mapを並行実行できるのはリソースを重ならずに分割できる狭い範囲の話のみだよ
実際に使ってみればわかるよ
共有リソースがある場合は無理

**デフォルトの名無しさん** · 2025/10/16(木) 16:50:42.80

>>299
RustもCAS命令が使えますしlock freeにできます
Rustの方法より優れた方法があると言う話の流れでそれは本末転倒でしょ
Rustが最善だと認めたことになってしまいます

**デフォルトの名無しさん** · 2025/10/16(木) 17:54:47.80

クソダサい
小学生かよｗ

**デフォルトの名無しさん** · 2025/10/16(木) 18:16:41.15

atomicモジュールはC++を模倣しただけだからRustの方法とかRustが最善とか言うのは恥ずかしいからやめて

**デフォルトの名無しさん** · 2025/10/16(木) 20:04:40.86

それを言いだしたら
RustはC++0xから分岐した言語だし

**デフォルトの名無しさん** · 2025/10/16(木) 21:06:43.72

結局Rustより秀でた方法は存在しないのかよ

**デフォルトの名無しさん** · 2025/10/16(木) 22:27:36.69

並行並列処理と言えばHaskellで初めて知ったけど、STM（ソフトウェア・トランザクショナル・メモリ）とかはRustに無いの？
OCamlでもやってたからHaskell固有のものじゃないっぽいし、イミュータブルなRustに向いてそうだからRustにもありそうなもんだけど。

**デフォルトの名無しさん** · 2025/10/16(木) 22:50:37.13

>>307
cratesで実装してるものはあるけどRustとは合わないから基本的に使われない

Rustは関数型じゃないからcomposabilityへのこだわりがなく
race conditionを静的に避ける仕組みはすでにあるわけで
実行時のオーバーヘッドが必要なSTMをわざわざ使うメリットがない

**デフォルトの名無しさん** · 2025/10/16(木) 22:58:22.11

>>308
そうなのか。
ありがとう。

**デフォルトの名無しさん** · 2025/10/16(木) 23:57:58.80

STMは基本的に競合の事後検証トランザクション方式なので様々な問題がある
1つは競合が見つかり検証失敗時にロールバックしてリトライするコスト
もう1つは競合が起きて事後に競合が見つかるまで競合した不正な状態のままプログラムが進むため
正常では起こらないループ停止条件の破綻による無限ループや
IOなど外部への副作用を伴うと不正な状態のまま正しくない書き込みが起きたりすることなど

**デフォルトの名無しさん** · 2025/10/17(金) 02:21:36.13

>>310
事後検証方式だからダメみたいな考えは間違い
compare and swapだって事後検証方式だからリトライコストも発生するし
競合が起きて事後に競合が見つかるまで競合した不正な状態のままプログラムが進む

**デフォルトの名無しさん** · 2025/10/17(金) 03:12:19.26

>>311
STMはCASよりコストがかかる
CASは不正な状態が生じない

まず競合時の復元コスト
STMはロールバックのためにトランザクション全ての記録が必要でその復元も必要
CASにはロールバックも値の復元もない
元々得た古い値がそのままあるかを確認するのみである

次に不正な状態のままプログラムが進むかどうか
STMはトランザクションの途中で競合が起きた場合にそれに気付かず進むため不正な状態になる
CASは競合が起きた場合にそれ以上進まないため不正な状態にならない
ちなみにCASで最初に得た古い値に基づき処理するのは不正ではなく正常な状態であり、競合が起きなければそれがそのまま採用される

**デフォルトの名無しさん** · 2025/10/17(金) 07:05:35.11

単純に競合と1対1対応のCASを直接使う方が粒度も細かく自由度も効率も高いのは当たり前。
現実にはCASとは戦略の異なるLL/SC利用のCPUアーキテクチャもあってCASだけで抽象化するのは効率が悪く不利なので、C++とRustでは多数の不可分関数を用意していてそれらを使い分けることで対応できる。
アーキテクチャ毎のメモリバリアも様々なので、実装するアルゴリズムに対応して必要十分なメモリオーダーも指定する。

**デフォルトの名無しさん** · 2025/10/17(金) 10:20:11.61

さすがに単純なCASで代替するとかいう言説に関してはSTMというか基本的な競合と排他制御の概念を理解してきなさいと言うしかないが、
RustでSTMがあまり採用されないのは、>>308の言ってるようにそもそも静的に競合を回避できるケースを別にすれば、リトライ自体があまり好まれないというのが大きな一因だろう
所有権システムと相性最悪だし、レイテンシの予測可能性が損なわれる点はRustの得意分野を考えると受け入れ難い
Webなんかで雑にリトライしていいケースももちろん多いけど、そういうのはSTMなんか使わなくてもレコード単位の粗粒度な楽観ロックで十分だからな

**デフォルトの名無しさん** · 2025/10/17(金) 13:56:47.42

>>312
STMのほうがCASよりコストがかかるのは当たり前
その分より高い抽象度で複数のオペレーションを1つのアトミックなオペレーションとして合成できる

CASならロールバックコストやリトライコストがかからないと思ってるのは間違い
CASの1つのメソッド呼び出しだけれ見ればそりゃロールバックもリトライもない
でも実際のアプリケーションではどちらも必要

STMの”不正な状態”というのは不正確な認識なんだけど
君の言うところの”不正な状態”というのはCASでももちろん発生する

>STMはトランザクションの途中で競合が起きた場合にそれに気付かず進むため不正な状態になる
CASだって競合が起きた場合にcompare and swap等を実行するまでは競合を検知できない
これは君が言うSTMの”不正な状態”と全く同じ

比較する粒度が根本的に間違ってるのかな

**デフォルトの名無しさん** · 2025/10/17(金) 16:48:06.46

>>315
複おじの頭で捻り出せる限界が>>293程度の例なわけだから、複数のストアが絡むトランザクショナルな排他制御なんて想像できないんだろう
とはいえ単一のストアを想定するとしたらSTMは単なるCASと事実上等価になっちゃうから
CASと比較してSTMを下げるのはちゃんちゃらおかしいのだが、それも理解していないという

**デフォルトの名無しさん** · 2025/10/17(金) 17:00:36.05

ロックフリーはそれらの諸問題が必ず発生するから使い分けが重要
大きなトランザクションや副作用を伴うものや複数のリソースを扱うものは排他制御の方が有利なことが多いだろう

そして排他制御も使い分けが重要
リーダーが多いならMutexよりも同時利用が可能なRwLockが有利
非同期の場合は性質の異なるtokio::sync::Mutexとの使い分けも重要になってくる

ロックフリーも使い分けが重要
何でもCASを使って書くのは当然愚かで別アプローチのLL/SCアーキテクチャやアトミック演算命令の存在を考慮して各関数を使い分ける必要がある
CASも用途によってcompare_exchangeと偽陽性はあるがより軽くなり得るcompare_exchange_weakとの使い分けが重要

これらの各々の使い分けは用途に応じて少しでも速くなり得る可能性があるため行なわれる
初心者あるいはそこまで速さを追い求めない用途ならば常にMutexを選択するのもあり

**デフォルトの名無しさん** · 2025/10/17(金) 17:28:34.85

RustにおけるMutex等による排他制御の強制って未定義動作(同一データストアへの書き込み競合により結果が不定となる)を生じさせないための必然的な要請でしかなくて、
それに従ってたらスレッドセーフなロジックになるわけでは全くないぞ
複おじはロックフリーやらない方がいいのは当然同意するけど、その辺理解してなそうだから多分Mutex使っててもバグってると思うよ

**デフォルトの名無しさん** · 2025/10/17(金) 17:57:19.06

そこにRust固有の問題は存在しないのに何言ってるんだこいつ

**デフォルトの名無しさん** · 2025/10/17(金) 18:35:40.01

>>318の批判対象は複おじでありRust言語ではないのだが、アイデンティティの混同が窺えるな
Rustの”Fearless Concurrency”のコンセプトがこの人のような誤解を生んでいるとしたら、それこそがRust固有の問題かもね

**デフォルトの名無しさん** · 2025/10/17(金) 18:46:02.34

ここはプログラム技術板なので批判対象が技術や言語でないなら邪魔だからプログラマ板へ行くことを勧める

**デフォルトの名無しさん** · 2025/10/17(金) 22:35:39.71

Rustのスレなんておじがいないと何日も1レスもつかないからな
実際のRustの盛り上がりっていうのはそういうもんなんだろう

**デフォルトの名無しさん** · 2025/10/17(金) 23:16:32.65

5chの過疎化が進んでる
Goスレや次世代言語スレは最後の書き込みが7月
Nimスレは内容ある書き込みが1年以上前

**デフォルトの名無しさん** · 2025/10/18(土) 00:32:16.64

Rustの評価を上げているライブラリ、トップ5候補はなんだろ
tokio、regexは入りそう

**デフォルトの名無しさん** · 2025/10/18(土) 01:16:44.66

anyhowとthiserrorは愛用してる

**デフォルトの名無しさん** · 2025/10/18(土) 01:32:21.42

serde

**デフォルトの名無しさん** · 2025/10/18(土) 05:33:11.80

Nushellいいね
PowerShellをRustで書き直したみたいな感じ

**デフォルトの名無しさん** · 2025/10/18(土) 07:21:55.57

最新研究でわかった”職場のサイコパス”が無意識にする話題
2025/06/26 9:00
「サイコパス上司は犯罪者と同じ？」研究で明らかになった驚き ...
2025/08/21 5:00
「性格が悪い人」はなぜ存在する？近年わかった、サイコパスより危険な「第五の性格」とは
2025.08.24
① ナルシスト：自分が一番でいたい人.② マキャベリスト：人を思い通りに操る人.③ サイコパス：他人の痛みに無関心な人.④ サディスト：他人を苦しめて快感を得る人.
▽凶悪度が高い者ほどの者が上記の性格のものが下記の判断を正確に行っている
サイコパスの”冷酷さ”が「他者の心を読む力」を高めている
2025.10.17 06:30:58 FRIDAY
極右と極左の脳は驚くほど似た反応をすると判明！
2025.10.13 MON
※右翼従来型の職種.左翼技術の発展とともに新しい業種なので世界中全員該当
サイコパスはサイコパスに惹かれるという研究
2018.10.29 MON
AIに「いいね」の数を競わせると盛大に嘘をつき、誤情報をまき散らすことが判明
公開： 2025-10-16 08:00
>>　研究チームは3つの仮想環境を作成。・有権者に向けたオンライン選挙キャンペーン・消費者に向けた商品の販売キャンペーン・SNSでの投稿によるエンゲージメント（反応）最大化
▽上記のAIに反社の性格を搭載させてシミレーション
「人間の心」を間違いも含め再現できるAIが開発される
2025.07.04 17:30:07 FRIDAY
★き全職種の犯罪者発見
人間を殺害した各組織追い詰めるからな！

**デフォルトの名無しさん** · 2025/10/18(土) 13:17:56.75

>>324
一位はanyhow
二位はtokio
三位はserde
四位はtoml

**デフォルトの名無しさん** · 2025/10/18(土) 13:48:14.12

世間の評価という意味ではTauriやRatatuiみたいなやつじゃね

**デフォルトの名無しさん** · 2025/10/18(土) 14:44:17.05

regexやchronoは標準ライブラリの薄さを補うためのもので、Rustの良さというと違うと思う
C++ですら普通に使えるようなものだし
clap や rayon なんかはどうだろ？

**デフォルトの名無しさん** · 2025/10/18(土) 15:02:24.67

他の言語に移植されたかラッパーが作られたライブラリこそが評価の高いライブラリと言える

**デフォルトの名無しさん** · 2025/10/18(土) 16:27:26.83

>>332
それならPolarsがあるな
RustというかPythonのライブラリだけど

**デフォルトの名無しさん** · 2025/10/18(土) 16:29:59.91

>>317
もうめちゃくちゃだなw
抽象度の異なるものをごちゃまぜにしてるだけでなく
ロックフリーや排他制御が何なのかという基本すら理解してない

さすが複おじ

**デフォルトの名無しさん** · 2025/10/18(土) 17:20:51.07

おじ使いの人はいつもデタラメに言いがかりをつけまくってるけど具体的な情報をもたらさない特徴があるね

**デフォルトの名無しさん** · 2025/10/18(土) 18:35:02.78

スレ荒らしだから無視しとけ

**デフォルトの名無しさん** · 2025/10/18(土) 21:38:19.83

anyhowとかtokioも言語標準としてあってほしい部類だよな
serdeも今時シリアライズぐらい入っててよくねえ？とは思わなくもない

**デフォルトの名無しさん** · 2025/10/18(土) 21:53:44.59

anyhowは今でこそデファクトだけど
quick-error -> error-chain -> failure -> anyhow
という変遷あっての結果だから標準ライブラリでなくて正解ではあったと思う
serde は安定してるけど結局tomlやserde_jsonは分離してるからそれだけ入っても、という感じか

**デフォルトの名無しさん** · 2025/10/18(土) 22:10:01.44

いずれもどこまでを標準に入れるか難しいから標準は現状の最小限がいいよね

**デフォルトの名無しさん** · 2025/10/18(土) 22:16:21.80

Rust crates recent downloads TOP30
1位 syn
2位 bitflags
3位 hashbrown
4位 base64
5位 regex-syntax
6位 proc-macro2
7位 indexmap
8位 regex-automata
9位 quote
10位 itertools
11位 libc
12位 heck
13位 serde
14位 memchr
15位 unicode-ident
16位 serde_derive
17位 cfg-if
18位 autocfg
19位 aho-corasick
20位 serde_json
21位 rand_core
22位 once_cell
23位 regex
24位 getrandom
25位 itoa
26位 windows_x86_64_msvc
27位 rand
28位 ryu
29位 cc
30位 strsim

**デフォルトの名無しさん** · 2025/10/18(土) 22:20:56.31

排他制御で撃沈した複オジが話題転換しようと頑張ってる感じ？

**デフォルトの名無しさん** · 2025/10/18(土) 22:29:27.69

多くのクレートが用いている基礎クレートが大量にあるから
もし標準ライブラリに入れるならそれらを優先だろうな

**デフォルトの名無しさん** · 2025/10/18(土) 22:29:58.32

itoaって独立したクレートとして存在したのか

**デフォルトの名無しさん** · 2025/10/19(日) 00:23:47.35

標準でまかなえるものが多ければ多いほど、金取って保守する業務では使いやすくなるので
標準ライブラリはちゃんと保守できる範囲なら、でかければでかいほうがいい

**デフォルトの名無しさん** · 2025/10/19(日) 00:35:19.83

金を取ってるのに標準ライブラリじゃないと保守できないってダメなとこじゃん
しかも標準ライブラリやクレートのメンテしてる人たちにお金を出す気もないんだろ

**デフォルトの名無しさん** · 2025/10/19(日) 07:59:03.97

そういうのは単純に「Rustが向かない領域の一つ」というじゃない？
できるだけリスクを減らしたい (依存を減らしたい) エンプラ分野で、OracleやMicrosoftにお金を払ってでも Java や C# を使う理由というか
自社開発なら、ライブラリが使えなくなる等のリスクも自分達の責任で済むから、話は違ってくるだろうけど

**デフォルトの名無しさん** · 2025/10/19(日) 08:11:35.49

というかC/C++の代替としてはサードパーティのライブラリは十分に吟味してちゃんと手の内で把握して使うのが当然で、
Web系のアホの「なんかよく分かんないのが色々入ってるけど動いてるからヨシ!」は想定してないんだろ

**デフォルトの名無しさん** · 2025/10/19(日) 08:12:34.65

tokioなど大手IT各社が金出すか人出すか協力するかしていて信頼性が高い
もちろん各社が実際に使ってる
標準かどうかの名目よりそういうことが重要

**デフォルトの名無しさん** · 2025/10/19(日) 08:18:08.18

>>347
RustのWeb系基盤は一番下のtokioを含めて多階層に構成されていずれも標準ライブラリではないけど皆が用いていて安心感があるよ

**デフォルトの名無しさん** · 2025/10/19(日) 09:01:48.04

コアチームの人もしばしば言っているけど
標準に入ったからといって自動的にメンテされるようになる訳ではなく
人手が足りないと単純に放置されて「このライブラリは標準だけど使わないほうがいい」とかなるだけなんだよな

**デフォルトの名無しさん** · 2025/10/19(日) 09:18:07.38

RustはWeb関連が実際に業界大手のクラウドやCDNなどで使われているのが大きいよね

**デフォルトの名無しさん** · 2025/10/19(日) 09:56:19.63

C++ での例だと文字コード変換の枠組みである codecvt は C++26 でまるごと削除になる。(C++17 の時点で非推奨)
結局のところ常に変化するし常に追従するしか仕方ない。
完成したらそれをずっと使い続けられるという訳ではない。
ウェブ界隈では常に改定し続けるという意識があるから問題か起きたらそのときに対応すればよいという将来に対して楽観的 (無頓着) な価値観が生まれたのたと思う。