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/09/20(土) 19:07:52.69

スマポがいらないのはスクリプト言語かどうかじゃなくてGCの有無の違い
パフォーマンスクリティカルな場面だと悪者にされがちだけど、GCは本来面倒なものをかなり楽に扱えるようにしてる
なので、Rustが大変に思うなら素直に他の言語にすれば良いじゃんと思う
そういう面倒さと付き合う覚悟があるならRustはとても良い言語 (C++などに比べれば)

**デフォルトの名無しさん** · 2025/09/20(土) 19:19:36.48

>>194
GCの有無とスマートポインタに関係はない
そもそもポインタを持つGC言語も多い
そこで目的毎の抽象化したポインタを持てばスマートポインタになる
例えばRustのMutex<T>のようなスマートポインタを持つ場合とバラバラにTとMutexを別個に持つ場合の利便性や安全性を比較するとわかりやすいだろう
これらはGC言語でも必要である

**デフォルトの名無しさん** · 2025/09/20(土) 20:27:30.86

Mutex<T>はスマートポインタじゃないんだが
スマポってリソースの寿命管理の仕組みだから、GCが面倒を見る言語では要らんでしょ
ポインタを持つGC言語はあるけど、スマポとGCの両方を使う言語は (少なくとも自分の知る限り) 無いと思う
ロックはまた別の話だ

**デフォルトの名無しさん** · 2025/09/20(土) 20:45:04.95

スマートポインタは「高機能なポインタ」くらいの意味で、寿命管理以外の機能を含む場合はあるよ。

**デフォルトの名無しさん** · 2025/09/20(土) 21:07:14.91

正確にはMutexのlock()で得られるMutexGuardが条件をすべて満たしている正真正銘のスマートポインタ
GCのある言語でもこのようなスマートポインタは有意義

**デフォルトの名無しさん** · 2025/09/20(土) 23:31:35.11

いずれの機能もスマートポインターに慣れてしまえばスマートポインターなっていない従来の形は使いにくくミスも生じやすくわかりにくいことに気付けるよ

**デフォルトの名無しさん** · 2025/09/20(土) 23:48:28.53

GC言語ではわざわざスマートポインタの形で実装する必要性が皆無
スコープと外部リソースの開放を結びつける仕組みは言語がそれぞれ用意してるからね

**デフォルトの名無しさん** · 2025/09/20(土) 23:59:25.70

GoはMutexと変数ばらばら
結びつける仕組みってなに

**デフォルトの名無しさん** · 2025/09/21(日) 02:43:46.06

Mutexなどロックしている間のみ変数にアクセスできるしくみを用意している言語はRustだけじゃね？

**デフォルトの名無しさん** · 2025/09/21(日) 04:07:15.57

内部通報で無理なので犯罪者通報

暗黒状態の量子もつれを生成することに成功：世界初の快挙
公開日2025.09.10 18:30:27 WEDNESDAY
https://nazology.kusuguru.co.jp/archives/184832
>>量子もつれが非常に壊れやすく、外界のノイズ（熱の揺らぎや周囲からの電磁波など）によって簡単に消えてしまうことです。
>>このノイズによる量子もつれの崩壊現象は「デコヒーレンス」と呼ばれ、量子技術が実験室の外で広く実用化されるのを妨げる最大の壁となってきました。
◇
・どうやって地上で行えるのですか？
・嵐の中や甘風が強い中での車での走行中などどうやって維持しているのかな
・UFOは重力県内でテレポートしている偽物だろう？
◇
・統合失調症から見て犯人不明で周囲の人は知っているかもしれませんが宇宙人だと名乗っているのとテレポート技術を所持している
・7人殺害した
・お前で埴鎮目だ
・殺害した人野事を晩酌で高笑いをしている
・お前「被害者＝統合失調症＝２４実感３６５日幻聴などの幻覚あり」を人質に立てこもる
・絶対に殺させる「自殺か殺人かは不明ですがさせる」
・コロな症状を引き起こせる
※など上記の事を話してきた
◇
ここにも愉快犯の犯人組織が居るだろう！

**デフォルトの名無しさん** · 2025/09/21(日) 14:55:02.19

>>182
Rustだけ

**デフォルトの名無しさん** · 2025/09/21(日) 16:00:08.03

>>204
嘘つくな
どの言語でも排他制御が必須
それがなくても動く言語は常に自動で排他制御されて重いかシングルスレッド
さらに非GC言語はshared_ptrやArcなどが必須
それがなくても動く言語はそれ相当を常に自動でされて重いかリスキーな自己管理になる

**デフォルトの名無しさん** · 2025/09/21(日) 18:04:41.94

複おじの見識の狭さを露呈してるなあ
>>182はたぶんWebだろうから、排他制御なんかアプリケーションコードの範囲ではほとんど必要無い

**デフォルトの名無しさん** · 2025/09/21(日) 18:58:11.62

>>182にウェブらしき話がないけど
ウェブでも共有データがあって排他制御されるよ

**デフォルトの名無しさん** · 2025/09/21(日) 19:30:32.11

バックエンドにしろフロントエンドにしろ、Webは並列処理って意味合いでスレッド使うだろうか
1つの処理がバカスカスレッドたてて許される場面が思い浮かばないんだが

**デフォルトの名無しさん** · 2025/09/21(日) 20:54:02.67

>>208
Webなどは非同期タスクを使う
非同期タスクはマルチスレッド上でスケジューリングされる
スレッドは間接的に自動的に使われる
用いられるスレッド数は変更できるがCPUのマルチコアスレッド総数そのままがデフォルト値

**デフォルトの名無しさん** · 2025/09/22(月) 05:34:04.05

goてポインタ使えるのにgcなのわけわからん

**デフォルトの名無しさん** · 2025/09/22(月) 12:38:06.53

ARM版のWindows上でRustを使ってる人に質問です
x64用のbinaryを吐かせたいのですが
1.x64用のRustを入れて(Prism上で動作させて)そのままx64だと思い込んでコンパイル
2.ARM用のRustを入れてx64用にクロスコンパイル
3.その他
どれがお薦めですか
皆さんはどうやってますか

**デフォルトの名無しさん** · 2025/09/22(月) 12:40:23.44

GitHub Actions上でコンパイル

**デフォルトの名無しさん** · 2025/09/22(月) 14:50:51.96

5年前ぐらいに試したときは、ARM版のWindows上で動作するリンカがなくて詰んだような覚えがあるな
（リンクとコンパイルは別だといえばそれまでになっちゃう話だけどさ）
今は変わったんだろうか？

**デフォルトの名無しさん** · 2025/09/22(月) 16:07:58.75

Rustで業務開発している人、日本にどれだけおるんだろ
そもそも求人しても集まらなくない？ tokioとかまともに扱える人、日本にどれだけおるんだろ
てか、そのレベルのコーダーならば、別の領域の技術まで収めてる可能性が高いから、
難易度の割に単価の安いRustに関わる現場に入ってくれる確率が低い気がする

**デフォルトの名無しさん** · 2025/09/22(月) 16:40:27.78

とりあえずtarget指定でクロスコンパイル

**デフォルトの名無しさん** · 2025/09/22(月) 18:24:20.41

業務で使うとしても、ニッチなところでワンポイントで使うだけなんじゃないかな

**デフォルトの名無しさん** · 2025/09/22(月) 19:04:44.83

「Rust」の平均単価が3カ月連続上昇　エン・ジャパンがフリーランス案件の分析レポートを発表
https://atmarkit.itmedia.co.jp/ait/spv/2508/21/news045.html

開発言語別では、比較的新しい言語「Rust」が3カ月連続で平均単価を伸ばし、87万4000円（2025年6月比で4.4％増）で1位となった。

言語別単価表
https://s3-ap-northeast-1.amazonaws.com/enjapanhp/wp-content/uploads/20250815095506/%E9%96%8B%E7%99%BA%E8%A8%80%E8%AA%9E%E5%88%A54.png

**デフォルトの名無しさん** · 2025/09/22(月) 22:16:09.39

>>217
エージェントの公開データを真に受けるのはちょっと…
あと、RustがGoと0.2しか離れてないわけがない。適当すぎ

**デフォルトの名無しさん** · 2025/09/22(月) 22:23:29.95

Rustの驚き屋とか自作自演しながらここに書き込むお仕事があるよ

**デフォルトの名無しさん** · 2025/09/22(月) 23:58:16.13

paypayがrust使ってjavaの10倍負荷下がったゆうてたしweb系なら求人ありそう
実際小さいベンチャーだと割とある
組込rustはさすがになさそう

**デフォルトの名無しさん** · 2025/09/23(火) 00:20:48.81

組み込みは宇宙関係は（日本含めて）そこそこある
車はボルボあたりがやる気あるけど日系はどうだろうね
家電はまぁわざわざRustじゃなくてもって感じか

**デフォルトの名無しさん** · 2025/09/23(火) 09:46:49.33

人命や数千億単位の金がかかってる機器の制御でヒープの動的アロケーションなんかやるもんなのか?
コネクティッドカー機能とか少々問題が出たところで死人が出ない上位レイヤなら、ある程度雑に作るだろうけど

**デフォルトの名無しさん** · 2025/09/23(火) 11:07:26.61

OSないような低レイヤ組み込みならno_stdでヒープとか使わないでしょ

**デフォルトの名無しさん** · 2025/09/23(火) 15:03:47.29

オナニーにも二種類あります
ムラムラしてやるのはいいオナニー、なんとなく暇だからやるのは悪いオナニーです
それでは、いいオナライフを

**デフォルトの名無しさん** · 2025/09/23(火) 18:08:05.88

>>211
Win10かWin11かで違うね
Win11ならほぼ問題無いはず

**デフォルトの名無しさん** · 2025/09/24(水) 10:08:26.98

担当者の数が少ないレイヤは絶滅して数が多いレイヤだけが生きのこる・・・という科学の理論がある
計算機科学じゃないが

**デフォルトの名無しさん** · 2025/09/24(水) 22:08:50.16

Rustコンパイラの悩みを一掃！開発者調査が示す、ビルド高速化への道
https://gamefi.co.jp/2025/09/17/rust-compiler-woes-sweep-away-developer-survey-shows-path-to-faster-builds/

2025年のRustコンパイラ性能調査の概要
この調査は、Rustの公式ブログで2025年6月にアンケートが開始され、9月9日に結果が公開されました。
調査の目的は、ユーザーがRustコンパイラの性能でどんな問題を感じているかを把握することです。
今後の改善策と関連ニュース

**デフォルトの名無しさん** · 2025/09/25(木) 23:36:25.10

コンパイルが遅いならjsを使えばいいというのがjsの存在理由なんだな
コンパイラもインタプリタもどっちも計算機科学の管轄内だし
外来種エセ科学に負けるな

**デフォルトの名無しさん** · 2025/10/04(土) 21:39:35.87

外来種エセ科学とかいう何の意味のない単語

**デフォルトの名無しさん** · 2025/10/05(日) 23:48:14.10

Case Study: How Proton uses Rust to build secure cross-platform applications for millions of people
https://kerkour.com/proton-apps-rust

**デフォルトの名無しさん** · 2025/10/06(月) 06:34:16.54

unsafeという単語がもっと無意味な単語だったら発生しなかった疑問や議論があると思う

**デフォルトの名無しさん** · 2025/10/06(月) 08:57:27.48

unsafe って outerRust 程度の意味だよなー
せいぜい鼻から悪魔召喚されるぐらいだから　ヘーキヘーキ

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

https://www.amazon.co.jp/dp/4798074926/
https://m.media-amazon.com/images/I/812GJac8n4L.jpg

**デフォルトの名無しさん** · 2025/10/07(火) 05:36:35.33

安心安全の爆速言語ｗｗｗ

**デフォルトの名無しさん** · 2025/10/07(火) 08:38:37.56

トーンポリシングのようにトーンを変えるべきと言っているのではない
unsafeを使ったら大変なことになるぞというエセ帰結主義を変えるべき

**デフォルトの名無しさん** · 2025/10/07(火) 23:34:16.46

https://blog.0xshadow.dev/series/backend-engineering-in-axum/

**デフォルトの名無しさん** · 2025/10/08(水) 06:12:45.82

驚き屋なんだからリンクと一緒に驚いた事を書けよ

**デフォルトの名無しさん** · 2025/10/08(水) 10:51:04.58

沈黙が生成されたのか
3回passしてもアウトにならないゲームに最適解はあるんだろうか

**デフォルトの名無しさん** · 2025/10/09(木) 05:47:10.57

jiff と temporal_rs
ほぼ同時期にほぼ同じ設計・機能のcrateが2つ誕生してしまった
JavaScriptのTemporal仕様をRustで実装したもの
後者はChromeのV8エンジンで使用される

**デフォルトの名無しさん** · 2025/10/09(木) 05:53:32.32

後者とは一体...

**デフォルトの名無しさん** · 2025/10/09(木) 23:29:06.13

Redis-rs 1.0.0 rc 来たね

**デフォルトの名無しさん** · 2025/10/15(水) 02:42:51.67

Rustの構文を学習するのにかかる期間は平均して100時間
この話を聞くと、大抵の奴は『俺、他の言語の構文を普通の人の○○倍の速さで取得できたから、Rustもせいぜい30時間で取得できるだろうな』と考えがち
そういうの含めて平均100時間なんだよ。罠すぎる

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

さすがに他の言語の経験があってRustの構文だけで100時間は池沼
VBAとかですら実務は厳しいだろ

**デフォルトの名無しさん** · 2025/10/15(水) 12:41:03.98

The Bookをぜんぶ読んだらどう足掻いても100時間ぐらいはかかる

**デフォルトの名無しさん** · 2025/10/15(水) 12:51:51.60

毎日1時間だけでもたった3ヶ月で習得できる
Rustを理解できない人はよっぽどの境界

**デフォルトの名無しさん** · 2025/10/15(水) 12:52:33.33

「構文」の意味を理解していないレベルならそうかもな

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

100時間もかからないだろ
Rustは抽象化が進んでいて理解しやすくコードも書きやすく読みやすい
ところが抽象化は知能レベルがある程度ないとかえって難しく理解できないのだ
一部の人々にとってRustは難しい

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

などど知能レベルが低く抽象化を全く理解していなかったおじさんが言っており

**デフォルトの名無しさん** · 2025/10/15(水) 17:01:58.19

他の言語やってたら結構わかりやすいと思うんじゃが難しいか？
ぶっちゃけ所有権ライフタイムジェネリックだけ読むだけでもええと思うけどあとはパクリみたいなもんだし

**デフォルトの名無しさん** · 2025/10/15(水) 17:27:57.11

C++
C#系言語を一つ(TypeScript, Kotlin等)
関数型言語を一つ
これくらい知ってたら楽勝だね

**デフォルトの名無しさん** · 2025/10/15(水) 17:59:28.03

Rust の型システムはだいたい Haskell そのまんまな感じ。
衛生的マクロは Scheme 風だし、手続き的マクロは Common Lisp をはじめとする伝統的な Lisp のスタイルが踏襲されてる。
Rust だけの特徴と言えるのはライフタイム注釈くらいじゃない？
まあそれがそこそこ馴染みにくいものではあるんだけど。

**デフォルトの名無しさん** · 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
それでは何も解決できていないですね