22/10/06 22:43:13.96 Re0G7B20.net
公式
URLﾘﾝｸ(www.rust-lang.org)
URLﾘﾝｸ(blog.rust-lang.org)
URLﾘﾝｸ(github.com)
Web上の実行環境
URLﾘﾝｸ(play.rust-lang.org)<)
※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
URLﾘﾝｸ(doc.rust-lang.org)
※Rustを学ぶ際に犯しがちな12の過ち
URLﾘﾝｸ(dystroy.org)
※Rustのasyncについて知りたければ「async-book」は必読
URLﾘﾝｸ(rust-lang.github.io)
※次スレは原則>>980が立てること
前スレ
Rust part16
2:デフォルトの名無しさん
22/10/06 22:43:37.18 Re0G7B20.net
Rust The Book (日本語版)
URLﾘﾝｸ(doc.rust-jp.rs)
Rust edition guide (日本語版)
URLﾘﾝｸ(doc.rust-jp.rs)
Rust by example (日本語版)
URLﾘﾝｸ(doc.rust-jp.rs)
Rust cookbook (日本語版)
URLﾘﾝｸ(uma0317.github.io)
Rust API guideline (日本語版)
URLﾘﾝｸ(sinkuu.github.io)
Rust nomicon book (日本語版)
URLﾘﾝｸ(doc.rust-jp.rs)
Rust async book (日本語版)
URLﾘﾝｸ(async-book-ja.netlify.app)
Rust WASM book (日本語版)
URLﾘﾝｸ(moshg.github.io)
Rust embeded book (日本語版)
URLﾘﾝｸ(tomoyuki-nakabayashi.github.io)
Rust enbeded discovery (日本語版)
URLﾘﾝｸ(tomoyuki-nakabayashi.github.io)
Rust Design Patterns (日本語版)
URLﾘﾝｸ(qiita.com)
URLﾘﾝｸ(qiita.com)
Rust API guideline (日本語版)
URLﾘﾝｸ(sinkuu.github.io)
3:デフォルトの名無しさん
22/10/06 22:43:46.54 Re0G7B20.net
Rust CLI (Command Line Interface) apps Book
URLﾘﾝｸ(rust-cli.github.io)
Rust macro Book
URLﾘﾝｸ(danielkeep.github.io)
Rust Future Book
URLﾘﾝｸ(cfsamson.github.io)
Rust async-std Book
URLﾘﾝｸ(book.async.rs)
Rust tokio Book
URLﾘﾝｸ(tokio.rs)
Rust rustc Book
URLﾘﾝｸ(doc.rust-lang.org)
4:/ Rust rustdoc Book https://doc.rust-lang.org/rustdoc/ Rust rustup Book https://rust-lang.github.io/rustup/ Rust Cargo Book https://doc.rust-lang.org/cargo/ Rust unstable Book https://doc.rust-lang.org/nightly/unstable-book/ Rust Reference https://doc.rust-lang.org/reference/ Rust Standard Library https://doc.rust-lang.org/std/
5:デフォルトの名無しさん
22/10/06 22:43:58.88 Re0G7B20.net
☆WebAssembly（WASM） URLﾘﾝｸ(webassembly.org) URLﾘﾝｸ(ja.m.wikipedia.org)
・Wasmer - The Universal WebAssembly Runtime URLﾘﾝｸ(wasmer.io)
-> WASI（WebAssembly System Interface）とEmscriptenに準拠したWASMを実行できるランタイム
・WAPM - WebAssembly Package Manager URLﾘﾝｸ(wapm.io)
-> WebAssembly製ツール/ライブラリのパッケージマネージャー
☆Rust
・wasm-pack - your favorite rust -> wasm workflow tool!
URLﾘﾝｸ(github.com)
-> WebAssemblyのrustcコンパイルサポート
・Yew - Rust / Wasm framework for building client web apps URLﾘﾝｸ(yew.rs)
-> WebAssembly によってマルチスレッドな Web アプリのフロントエンドを作ることができる、モダンな Rust のフレームワーク
☆最近のWebAssemblyのニュース
・Publickey － Enterprise IT × Cloud Computing × Web Technology / Blog より URLﾘﾝｸ(www.publickey1.jp)
・WebAssembly活用プロジェクト URLﾘﾝｸ(madewithwebassembly.com)
・WebAssemblyが気になるので調べてみた - Qiita URLﾘﾝｸ(qiita.com)
・WASMとRustはVue.js/React.jsを打倒するのか？ - JSへの侵略の歴史 URLﾘﾝｸ(zenn.dev)
・Typescriptの次はRustかもしれない URLﾘﾝｸ(zenn.dev)
・WebAssemblyはJVMやeBPFのリバイバルではない WasmがWeb以外でもアツい理由 - ログミーTech URLﾘﾝｸ(logmi.jp)
・Rust GUI の決定版！ Tauri を使ってクロスプラットフォームなデスクトップアプリを作ろう URLﾘﾝｸ(zenn.dev)
類似スレ
【wasm】ブラウザでC++。Emscriptenを語ろう ｽﾚﾘﾝｸ(tech板)
6:デフォルトの名無しさん
22/10/06 22:44:37.34 Re0G7B20.net
>>1
前スレのurlはれてなったよぉ…
Rust part16
ｽﾚﾘﾝｸ(tech板)
7:デフォルトの名無しさん
22/10/07 01:27:41.85 YCt9Quz7.net
>>1
おつ
8:デフォルトの名無しさん
22/10/07 11:28:42.39 d4ub3t4L.net
>>1
O2
Nim に浮気中
9:デフォルトの名無しさん
22/10/07 12:26:19.13 +0mlf9Ez.net
Null安全でないGC言語のNimに浮気する人
10:デフォルトの名無しさん
22/10/07 12:31:49.01 7pvxFIpA.net
Null安全性が入れば雑なスクリプト用としては使えるんだけどな
11:デフォルトの名無しさん
22/10/07 13:04:35.78 KVLYaA/l.net
雑なスクリプト用途ならもっとシェアあって長続きしそうな競合が色々あるからなあ
12:デフォルトの名無しさん
22/10/07 13:36:57.50 yqDZzsii.net
Rustも意外に雑に手軽に書けるケースが多いと分かってきた
数値以外は先にスタック上に変数を用意（＝メモリ確保）してしまえば
後はその参照を使ってアクセスするだけで所有権もライフタイムも気にせず気楽にコーディングできるんだな
13:デフォルトの名無しさん
22/10/07 15:04:20.94 xg0qXK5h.net
lifetimeや所有権よりshared xor mutableの方が煩わしいと感じる人は多そうに思う
14:デフォルトの名無しさん
[ここ壊れてます] .net
僕はヌルヌルおまんこは好きですね
15:デフォルトの名無しさん
[ここ壊れてます] .net
>>12
Cだと可変ポインタだらけだからその感覚では書けないからねぇ
考え方から矯正しなきゃならんし面倒ではある
16:デフォルトの名無しさん
[ここ壊れてます] .net
スレッド内ならばCellが使えるから可変性も自由自在だよ
17:デフォルトの名無しさん
[ここ壊れてます] .net
Cellを使ったら負け
18:デフォルトの名無しさん
[ここ壊れてます] .net
Cellは安全性・高速性・利便性を両立するRustの最重要パーツの一つ
19:デフォルトの名無しさん
[ここ壊れてます] .net
だんだんトンデモスレになってきてるね
20:デフォルトの名無しさん
[ここ壊れてます] .net
Rust2っていつぐらいになりますか？今のままだと使いづらいです。。。
21:デフォルトの名無しさん
[ここ壊れてます] .net
Cellを使わずにshared xor mutableに囚われて不自由なプログラミングしている初心者は意外と多いね
22:デフォルトの名無しさん
[ここ壊れてます] .net
>>18
真に受けて複オジ2世が生まれないことを願ってる
23:デフォルトの名無しさん
[ここ壊れてます] .net
Cellの利便性を知らない初心者がいるのは直感に反するからだろう
Cellは可変参照なくても非可変参照だけで書き換えられるからな
24:デフォルトの名無しさん
[ここ壊れてます] .net
Cellを使うデメリットはないの？
ないならデフォルトがCell相当になっててもよさそう
25:デフォルトの名無しさん
[ここ壊れてます] .net
>>23
Cellのデメリットは唯一!Syncだけ
つまりスレッド内部でしか使えない
26:デフォルトの名無しさん
[ここ壊れてます] .net
誤解のないように言えば
スレッドを使わずにシングルスレッドの状況でももちろんCellを使える
27:デフォルトの名無しさん
[ここ壊れてます] .net
組み込みとかだとヒープの利用が難しいので自然とスタックメインになる
28:はちみつ餃子 ◆8X2XSCHEME
[ここ壊れてます] .net
>>23
コンパイル時の検査を緩めるかわりに実行時に検査が入る。
借用規則に逆らえるわけではない。
29:デフォルトの名無しさん
[ここ壊れてます] .net
>>27
それはRefCellでは
30:デフォルトの名無しさん
[ここ壊れてます] .net
>>27
Cellは実行時検査も無くコストゼロです
スレッド内なので借用規則に逆らえます
31:はちみつ餃子
22/10/07 18:21:14.63 uxbzrjvk.net
そっかー。
32:デフォルトの名無しさん
[ここ壊れてます] .net
CellはCopy traitが必要なので場合によってはとんでなくパフォーマンスが劣化する場合がある
単なる数値なら問題はないが
33:デフォルトの名無しさん
22/10/07 19:45:02.34 Znh4X5V+.net
>>31
そんなことはない
Cell<T>のTは完全に自由でありCopy要件はない
Cellで数値だけでなくVecやString等も自由に使える
例外的に一部のメソッドはCopy要件を持つがそれはOption<T>等でも同じでありそのメソッド特定のみの話
34:デフォルトの名無しさん
22/10/07 19:48:12.01 xg0qXK5h.net
>>31
Cell::takeやCell::replaceなど追加されたのでCopyを実装してない型でも使えるよ
StringやVecなどCopyできない型を扱う場合でも
元の値をtakeして更新後replaceするなどうまく書けばそれほど非効率にもならない
35:デフォルトの名無しさん
22/10/07 19:52:07.74 xg0qXK5h.net
CellやRefCellはshared xor mutableを知った上で適切に使った方が良いと思うので
初学者へ勧めるべきかというと微妙な気はするなあ
36:デフォルトの名無しさん
22/10/07 19:58:58.94 Znh4X5V+.net
>>34
Cellは安全性が完全に保証される型
他の型と同様に万が一に間違った使い方をしたらコンパイルエラーとなり常に安全が保証される
初心者かどうかといった区別や考慮はそこに必要ない
37:デフォルトの名無しさん
22/10/07 20:08:27.14 YCt9Quz7.net
何がしたいの？
38:デフォルトの名無しさん
22/10/07 20:16:39.71 CNFz94QB.net
>>33
takeってデフォルト値に置き換えて所有権をもらうやつでしょ？
うーん、なんか気持ち悪さはあるんだよな
39:デフォルトの名無しさん
22/10/07 20:49:01.57 3/fEI9MA.net
>>33
Cellの更新はset()で十分だね
もちろんreplace()してoldを捨てるのと同じ
>>37
take()はdefault値とのreplace()と同じ
これは気持ち悪いことでも何でもなくて
例えばmutableなOption<T>を維持しながら扱う時と同じ操作
その場合もSome(T)からTを取り出す時にdefault値と入れ替えるtake()を使うよね
何かが入っていないと未定義になるからその身代わり
もちろんすぐに更新する場合は概念上だけの扱いとみなせるし
実際の生成コードでもdefault値が入るコードは最適化で消えちゃう
未定義状態を避けるための自然な操作と捉えてよいかと
40:デフォルトの名無しさん
22/10/07 21:02:50.21 CNFz94QB.net
>>38
うーむ確かにそう言われるとむしろRust Wayな気がしてきた
41:デフォルトの名無しさん
22/10/07 21:12:11.57 4RElSAp/.net
不必要にCellを使ってみたくなるのはRust厨二病によくみられる症状
悪影響は少ないから温かく見守っておけばそのうち治るよ
42:デフォルトの名無しさん
[ここ壊れてます] .net
まとめると実行時に値を書き換えたいオブジェクトにはCellを使う
書き込む場合はset
読み込む場合はtakeを使う
RefCellはオワコン
43:デフォルトの名無しさん
22/10/07 21:30:00.49 Znh4X5V+.net
>>40
内部可変性を知らないのかな？
Cellは内部可変性を与えるものであり
& mutに縛られずにコーディングの自由度を上げるだけでなく
この内部可変性を使わないと記述できない場合もあるほど重要なもの
44:デフォルトの名無しさん
22/10/07 22:49:11.13 xg0qXK5h.net
> inherited mutability is preferred, and interior mutability is something of a last resort.
内部可変性は必要な時だけつかうべき
URLﾘﾝｸ(doc.rust-lang.org)
45:デフォルトの名無しさん
22/10/07 23:05:27.46 3/fEI9MA.net
スレッド間での共有ができないからその場合は内部可変性を避けないとコンパイルエラーとなっちゃう
しかし共有しないものならばいつでも安全に使うことが出来ます
不自由なプログラミングをしてまで内部可変性の利用を避ける必要はありません
そのような場合にはむしろ使うべき時ですよ
46:デフォルトの名無しさん
22/10/07 23:15:28.30 GE9TWYxP.net
The Bookの内容も理解してないようだから厨二病というより厨一病だねぇ
47:デフォルトの名無しさん
22/10/07 23:27:40.94 Znh4X5V+.net
>>45
The Bookでは
CellはSyncを実装していないからマルチスレッド間では使えないことしか書かれていない
48:デフォルトの名無しさん
22/10/07 23:41:21.31 xg0qXK5h.net
>>46
!Syncが許容される場面では常にCellを使うべきだと考えていますか？
49:デフォルトの名無しさん
22/10/07 23:44:26.62 Znh4X5V+.net
>>47
常に？
そんな極端な主張を一度もしていない
他のものと同じで有用な時に使えばよい
そして有用な時が多い
それだけだ
50:デフォルトの名無しさん
22/10/07 23:59:28.46 v90MyUH0.net
Cellは安全なだけでなく
実行コストもかからないし
データ設計の幅も広がるし
メリットだらけだよね
51:デフォルトの名無しさん
22/10/08 00:00:53.53 74M5kg9b.net
後で読むからブログにでもまとめといて
52:デフォルトの名無しさん
22/10/08 00:05:55.63 PJN/h6/8.net
Cellを嫌ってる人って何かの病気なの？
数ある型の一つに過ぎないのに
53:デフォルトの名無しさん
22/10/08 00:09:24.75 STUNJ/8C.net
Rustレスバトル会場
ｽﾚﾘﾝｸ(tech板)
54:デフォルトの名無しさん
22/10/08 00:21:36.43 iVJbbbtq.net
Cell使わずにshared xor mutableの制限で苦しんでいる人は単なるバカ
55:デフォルトの名無しさん
22/10/08 00:35:12.49 D3DCz8sQ.net
CellとかRefCellってRustの本にも殆ど解説がないよな
ちょろっとおまけ程度にしかない
これなしでは現実的なプログラム書けないと思うのだが本の著者らはRustを理解してないんだろうか
56:デフォルトの名無しさん
22/10/08 00:52:04.60 2tIWkITu.net
>>54
書籍は見たことないから知らなかったけどそうなのか
自分が使っている著名なcratesのソースを見てみるとCellを使っているcrateも多い
だから普通に皆がCellを使っていてそこにタブーは無いようだ
まあ当たり前か
57:デフォルトの名無しさん
22/10/08 00:58:18.16 QzbKhEyQ.net
Cellなしでは現実的なプログラム書けないというのは言い過ぎ
ある種のプログラムではCellが必要になるくらいが適当では
58:デフォルトの名無しさん
22/10/08 01:04:15.77 2tIWkITu.net
Cellが必須となるプログラムと
Cellが必須でないプログラムがあるだけだよな
まあこれも当たり前かｗ
59:デフォルトの名無しさん
22/10/08 01:12:26.49 M3iYd9Ol.net
Rustで日本が変わる！世界が変わる！
などとほざいてる人は自分では使っていないと思う。
使ってたら、ウーン、こりゃ使えんなあ・・・って言ってると思う。
60:デフォルトの名無しさん
22/10/08 01:34:11.88 2tIWkITu.net
Rustは今までに登場したプログラミング言語の中では一番使いやすく効率がいい程度だな
世界や日本がどうなろうとどうでもいいが
理解できない人たちとの不利有利の二極化は起こるだろう
61:デフォルトの名無しさん
22/10/08 03:41:06.69 D3DCz8sQ.net
>>55
The bookにはRefCellの解説はあるけどCellの解説がないんだよね
だからCellを使ってる人が少ないのかと思う
62:デフォルトの名無しさん
[ここ壊れてます] .net
各crateのソース調べたらtokioもasync-stdもwasm-bindgenもCell使ってるな
別方面でtauriもyewもeguiもCell使ってるな
他にもproc macro用のsynとかCLI用のclapとか様々なcrateがCell使ってるな
この状況を見るとCellは普通に使って当然っぽい
63:デフォルトの名無しさん
22/10/08 10:23:03.05 2effy6oa.net
>>38
それってCellから取り出した値がdefaultだった時の処理を書かないとならないんじゃないんですか？
64:デフォルトの名無しさん
22/10/08 10:55:13.71 /5aPtbi3.net
>>54
Cellは扱いの小さい本が多いがRefCellはだいたいどの本でもしっかり解説されてるでしょ
オライリー本はCellも解説してる
65:デフォルトの名無しさん
22/10/08 10:59:24.30 HCP3bqwV.net
Cellはスレッドローカルの共有状態を管理する時に使う
カウンタとかフラグとか
shared mutability自体多用するもんじゃないからその辺をよく考えてね
66:デフォルトの名無しさん
22/10/08 10:59:37.80 kYZ69ulT.net
>>54
Cの入門本の8割はmallocの使い方を説明してない
67:デフォルトの名無しさん
22/10/08 13:18:33.57 HbWzH6SV.net
どうせなら不変な部分を取り出せるようにしてすればよかったのにな。
参照カウントみたいなどこでも付いて回るのは厄介だけど。
68:デフォルトの名無しさん
22/10/08 13:48:31.81 D3DCz8sQ.net
>>63
ここの議論を見るとCellの解説を最初にやるべきだと思うのになぜRefCellばかりなのだろうという謎が
歴史的経緯みたいなやつか？
日本人の書いた本もRefCellばっかだよ
69:デフォルトの名無しさん
22/10/08 14:04:15.39 cMY3Tlwa.net
カジュアルにCellを使って欲しくないからだよ
よく考えて使わないとバグのもとだから
必要な人向けにはリファレンスで詳しく解説してる
70:デフォルトの名無しさん
22/10/08 18:26:38.20 r98Hfriq.net
>>62
マルチスレッド間共有していないから
空っぽの時に知らぬ間にアクセスされることはないよ
だから大丈夫
そしてすぐに更新することで最適化される
あとはプログラムの組み立て方の話であって言語による管轄の話ではないね
71:デフォルトの名無しさん
22/10/08 19:07:57.58 vMI7I1P7.net
interior mutabilityを持ち所有権を自分が持たないケースは特殊だから説明した方がいいかもしれないが、
interior mutabilityを持ち所有権を自分が持つケースは普通の事だからわざわざ説明するまでもない。
write lockを取るからborrow checkが実行時に遅延されるのも説明しないといけないし。
72:デフォルトの名無しさん
22/10/08 19:14:27.64 N7i/LeD2.net
Cellの使い方教えればRustユーザーも増えると思うな
所有権そのものより副作用を簡単には許さないところにハードルがあるから
73:デフォルトの名無しさん
22/10/08 19:30:29.77 Xn47a3bW.net
>>70
実行時borrow checkされるのはRefCellだけ
Cellはborrow checkもlockも無くてゼロコスト
74:デフォルトの名無しさん
22/10/08 20:24:05.46 QzbKhEyQ.net
カジュアルに使うならマルチスレッドでも使えるMutex使っておけばよいのではという気もするが
75:デフォルトの名無しさん
22/10/08 21:19:30.79 BDP0djZ+.net
CellはCにおけるグローバル変数と同じで真に必要な時以外は極力避けるべきもの
ましてやRustの基本的考え方に慣れてないうちから使うべきものじゃない
76:デフォルトの名無しさん
22/10/08 22:01:30.85 LnEoG2Yz.net
>>73
そこは真逆
Mutexはlockのコストがかかる
Cellはコストがかからない
>>74
Cellはグローバル変数ではなくローカルにいくつも出現可能
そしてグローバル変数のような極力避けるべきものではない
77:デフォルトの名無しさん
22/10/08 22:04:07.45 QzbKhEyQ.net
>>75
ロックのオーバーヘッドを気にする必要があるのはカジュアルに含まれません
78:デフォルトの名無しさん
22/10/08 22:06:04.90 aSXXl0gc.net
immutableなのがいいと言いつつ
mutやinterior mutabilityを結局使わせるダサさなｗ
79:デフォルトの名無しさん
22/10/08 22:39:37.88 K1piK/7g.net
>>76
Cell<T>ならスレッド内部専用の代わりにロックがなくてTと同じコストで使えるからオススメ
80:デフォルトの名無しさん
22/10/08 22:40:45.08 QzbKhEyQ.net
immutableだけで書きたければそうすれば良いのでは
そのアプローチに窮屈さを感じる人が大半だからshared xor mutableという安全に使えるサブセットが生み出されたわけで
81:デフォルトの名無しさん
22/10/08 22:42:33.20 QzbKhEyQ.net
>>78
ただしマルチスレッド対応させようとすると書き換えが必要だし性能面に大きなこだわりがないなら最初からMutexにした方が良いのでは
Cell<T>はランタイムコスト面ではTと同じかもしれないけどコード記述は結局
82:デフォルトの名無しさん
22/10/08 22:43:05.48 QzbKhEyQ.net
途中で書き込んでしまった
コードの記述の面ではTとは異なるから同じ使い心地にはならないよね
83:デフォルトの名無しさん
22/10/08 22:53:58.00 IDy6SwOh.net
>>80
それは君が勘違いをしている
Cellはマルチスレッドであってもスレッド内で使用することができる
Mutexを使うべき時はマルチスレッドのスレッド間で共有メモリとする時
排他制御のためMutexはコストが重い
したがって両者を互いに代用することは有り得ない
84:デフォルトの名無しさん
[ここ壊れてます] .net
よくわかんないんだけどMutex<Cell<T>>は有効なの？
85:デフォルトの名無しさん
22/10/09 01:31:18.81 LqCUQ5jH.net
>>83
無効ではない
しかしMutex<T>はlockを取れたら& mut Tも得られて書き込みも可能なのでCellは不要
例えば
fn main() {
let m = Mutex::new(Vec::new());
sub(&m);
let v = m.lock().unwrap();
assert_eq!(*v, [123, 456]);
}
fn sub(m: &Mutex<Vec<i32>>) {
let mut v = m.lock().unwrap();
v.push(123);
v.push(456);
}
つまりMutexの可変参照をもっていなくても内部の可変性を得られる
ようするにCellで内部可変性を得られるのと同じ
だからMutex<Cell<T>>と二段に重ねる必要はない
86:デフォルトの名無しさん
22/10/09 01:46:07.36 NMoxe/se.net
>>84
なるほどー
めちゃくちゃ勉強になる
87:デフォルトの名無しさん
22/10/09 01:48:31.99 2Hsnp4rW.net
>>82
ランタイムコストが無視できる場合はMutexが使えるけどCellが使えないシチュエーションはないよね
カジュアル用途なら大は小を兼ねる的な意味でCellよりMutexの方が良いのでは？
Cellにすべき理由あるの？
88:デフォルトの名無しさん
22/10/09 01:49:26.64 2Hsnp4rW.net
>>86
一文目逆だった。MutexがCellを置き換えられない場合はないよね、と言いたかった
89:デフォルトの名無しさん
22/10/09 01:53:55.32 LqCUQ5jH.net
>>86
話は非常にシンプル
スレッド間でメモリを共有するならばMutex (ただし排他コストがかかる)
共有しないならばCell (コストはかからない)
適切な方を選べばよい
90:デフォルトの名無しさん
22/10/09 02:00:16.80 NMoxe/se.net
というかRustマジで良くできてんな
考え尽くされてるわ
91:デフォルトの名無しさん
22/10/09 02:01:56.84 Z8ziuvVg.net
要するに変数は全部Cellで囲っておけばいいんでしょ
92:デフォルトの名無しさん
22/10/09 02:08:28.77 2Hsnp4rW.net
>>88
スレッド間で共有しなくてもstatic変数だったらCell使えないのでMutexは単純にマルチスレッド用とも言えないのでは
よくわからない人向けにはMutexをまずは勧めるのが良いのでは
93:デフォルトの名無しさん
22/10/09 02:24:40.07 zCVUy+MP.net
Qt使おうかと考えているけど
バインディングライブラリのritualを勧めている人がいたけど
最後のコミットが去年でサポーターが心配なんだけど
結局Cのライブラリ読み込みや既存ライブラリの利用とかどれを使えばいいの？
94:デフォルトの名無しさん
22/10/09 03:05:30.55 LqCUQ5jH.net
>>91
それは基本的な理解ができていない
static変数はスレッド間で共有が可能なためその型はSync実装を必要とする
だからCellが使えないのは当たり前
スレッド間で共有する必要がないならば
スレッドローカルに持てばSync実装を必要としないためCellを使える
例えば
thread_local! {
static FOO: Cell<Vec<i32>> = Cell::new(Vec::new());
}
これでスレッド毎に持つことができる
もちろんスレッドを使わないシングルスレッドな状況でも使える
95:デフォルトの名無しさん
22/10/09 04:37:34.70 8tdOWvz3.net
Cellって基本的に値がムーブされるから構造体分はmemcpyが起きると思うんだけどそこはどうなの
RefCellやMutexなら直接参照取れるからそっちの方が効率的だよね
96:デフォルトの名無しさん
22/10/09 04:57:14.58 95mox/4o.net
複オジの嘘に騙される前には少しは頭使え
97:デフォルトの名無しさん
22/10/09 05:51:16.25 md7RXs4/.net
隔離スレに帰れ
98:デフォルトの名無しさん
22/10/09 05:51:33.43 LqCUQ5jH.net
>>94
memcpyは起きない
Cellに関係なく一般的にムーブはあくまでもRustの言語レベルにおける概念的なもの
したがって生成コードでは無駄なメモリ間のムーブ(コピー)は起きずに最適化される
Cellの場合でも同様に最適化される
&Cell<T>に対してtake()してTを更新してset()するコードは
& mut Tに対してTを更新するコードと同じ生成コードとなる
例えばそれらの比較コード
URLﾘﾝｸ(godbolt.org)
完全に同じ生成コードとなっていることが分かる
つまりCell<T>はTと比較して実行時ゼロコストである
99:デフォルトの名無しさん
22/10/09 07:01:12.90 vVo7+K5Y.net
RustコンパイラとLLVMは凄いなあ
いつでもそうだけど生成コードではがっちり最適化してくれる
抽象的に書いても安全に書いてもCと同じ速さ
100:デフォルトの名無しさん
22/10/09 11:45:38.50 kycCKtGO.net
おまえも隔離スレに帰れ！ちょっと前にLLVMだから凄い坊があそこで暴れてたけど、ここはgccrsとかやる人の場だ、市ね
101:デフォルトの名無しさん
22/10/09 13:36:44.30 1+WY+ral.net
gccrsって使えるようになったの？
102:デフォルトの名無しさん
22/10/09 20:46:00.69 yOxuO3a2.net
Linux6.1ってRustで組んだってこと？
103:デフォルトの名無しさん
[ここ壊れてます] .net
ドライバ等をRustでも書けるようになるだけ
104:デフォルトの名無しさん
22/10/09 23:29:48.75 FY4RBnfH.net
Pattern alternativesってなんですか？和訳のパターンORもよくわかりません
URLﾘﾝｸ(doc.rust-lang.org)
URLﾘﾝｸ(doc.rust-jp.rs)
105:デフォルトの名無しさん
22/10/09 23:53:45.87 vVo7+K5Y.net
パターンの代替策
つまり「|」記号が
bit演算のORとしてだけでなく
パターンのORとしても使われるよってこと
106:デフォルトの名無しさん
22/10/10 11:32:20.19 wEJNunBW.net
>>69
なるほど
マルチスレッドで共有する場合にはどうするのが適切なんでしょうか？
107:デフォルトの名無しさん
22/10/10 11:45:42.80 wEJNunBW.net
>>105
これか
URLﾘﾝｸ(qiita.com)
108:デフォルトの名無しさん
22/10/10 18:49:06.89 lNBbmc/N.net
Linux Kernel6.1は、Rustへ移行した最初のバージョンとなります。
Rustへ移行することにより、C言語バージョンの世代から、およそ30%の高速化を果たしました。
109:デフォルトの名無しさん
22/10/10 22:52:16.26 3WEeN/aN.net
気分はCelltic！
「実はshared xor mutableってしっくりこないんです！」
110:デフォルトの名無しさん
22/10/10 23:11:02.61 U+uG6kFy.net
>>105
内部可変性を得たい場合
スレッド内ではCell<T>もしくは参照を持ち出したいならRefCell<T>を使う
スレッド内部で普通の共有ならばそれらの＆を使う (＆mutでなくてもOK)
スレッド内部で所有者が別となる共有ならばそれらのRc<...>を使う
スレッド間では完全排他のMutex<T>もしくはreaders複数可のRwLock<T>を使う
(ただしTがi32やboolならばもっと軽いAtomicI32やAtomicBoolが使える)
スレッド間で共有は所有者が別となるのでそれらのArc<...>を使う
111:デフォルトの名無しさん
[ここ壊れてます] .net
>>97
最適化頑張ってるだけでムーブは概念的なものじゃないぞ。RBMMなんだから。
112:デフォルトの名無しさん
22/10/11 19:16:08.16 Bl5ahscm.net
moveがmemcpy呼び出しになるかどうかはあくまでも実装の話で
move自体のセマンティクスはデータのコピーを要求しないということが言いたいのでは
最適化offにして構造体サイズ大きくするとmemcpy呼び出されるから、memcpy起きないというのは嘘だけど
113:デフォルトの名無しさん
22/10/11 19:23:40.64 61VrJvDY.net
>>110
あくまでもRustの言語レベルでの抽象的なレベルではムーブはムーブであってビットコピーの保証はそこには一切ない
そして我々は抽象的な概念に基づいてプログラミングすればよい
生成コードはムーブという抽象的な概念だけを保証して最適化される
だからこそ生成コードではムーブでビットコピーが消え得る
114:デフォルトの名無しさん
22/10/11 19:29:43.10 61VrJvDY.net
>>111
memcpyはたまたまムーブの最適化なしのデフォルト状態で行われる可能性のあるコードにすぎないね
Rustの言語としてはmemcpyが必ず行われることなんて全く保証しない
ムーブはもっと上位の概念であってRustが保証するのはその上位の概念のみだね
115:デフォルトの名無しさん
22/10/11 19:51:08.13 Bl5ahscm.net
>>113
はいはい、>>111は誤読されかねない表現でしたね
(常に)memcpy起きないというのは嘘
と読み替えておいてください
元々の>>94のRefCellやMutexの方が効率的かという質問については、そういう場合もある、というのが答えで良いですよね
生成されるコードがどうなるかは最適化レベルや周囲のコードに依存するわけで、必ずどちらかが効率が高いと言えるようなものではない
感覚的には格納するデータサイズが大きい方がRefCell/Mutexが有利に、小さければCellが有利になりそうだけど、
ちゃんと測定したわけではないので実際のところは分からない
116:デフォルトの名無しさん
22/10/11 20:23:10.29 iRs2n6UT.net
>>114
実はRefCell構造体のメンバーにCellが使われている(現状)
使用されるメモリサイズ
Cell<T> ← Tと同じサイズ
RefCell<T> ← Tのサイズに加えてborrow管理のために内部で使用するCellサイズ分加算
動作コスト
Cell<T> ← (利用後すぐset()すれば)Tと同じコスト
RefCell<T> ← Tのコストに加えてborrow管理のために内部で使用するCellの読み書き操作コスト分加算
117:デフォルトの名無しさん
22/10/11 21:44:42.19 P/g9+OyI.net
ホント笑っちゃうくらい嘘を散りばめてくるよねw
118:デフォルトの名無しさん
22/10/11 21:58:52.19 lchMb24F.net
>>114
RefCellやMutexの方が効率的かという質問については
代用として使うならばそれらの方が遅いでしょう
RefCellはボローチェック処理が必ず入ります
Mutexは排他的ロック処理が入るのでさらに遅いです
119:デフォルトの名無しさん
22/10/11 22:06:38.86 Bl5ahscm.net
120:rget="_blank" class="reply_link">>>115 動作コストはT全体を置き換える場合だよね TがVecで、一要素追加する場合のコストも計算してみてよ >>117 ボローチェック処理が最適化で消えないことは保証されてるの？ ボローチェックや排他処理のコストはCellで発生するデータコピーより必ず高コストになるの？
121:デフォルトの名無しさん
22/10/12 14:10:22.75 IRDyECLz.net
ムーブ元の変数が使われないことがわかってるんだから
その変数の領域を使い回せばよいだけでしょ？
普通に考えてコピーとか起きないと思うんだが
122:デフォルトの名無しさん
22/10/12 18:26:20.15 R7/twQcO.net
自称分かってる人同士のケンカ
123:デフォルトの名無しさん
22/10/12 21:47:16.08 TdLmkMrU.net
RefCell使うのはアロケーションを避けたいからでしょ
124:デフォルトの名無しさん
22/10/12 23:29:45.96 MmGzrhE7.net
Cell<T>もTもメモリ領域は同じサイズで性質が異なるだけなのね
Cell<T>の更新はこうなるから
(1) メモリ→value読み出し // take()その1
(2) メモリ←default-value書き込み // take()その2
(3) valueを更新してnew-value
(4) メモリ←new-value書き込み // set()
コンパイラがまともなら(2)の部分はムダと判断して無くせそうね
さらにvalueの更新内容によっては (例えば足し算など算術の場合など)
その後にLLVMが最適化でメモリに対して直接実行する命令コードにするだろうから読み出し書き込みも消えるわけね
125:デフォルトの名無しさん
22/10/13 01:04:10.25 v9vBAx/l.net
CopyじゃないStringやVecで&mut selfとるメソッドを試せば違いが分かるよ
126:デフォルトの名無しさん
22/10/13 02:00:58.56 m/K7Pbd2.net
Copyを実装しない適当な構造体
#[derive(Default)]
struct Foo {
inner: i32,
}
の &Cell<Foo> と &mut i32 の両方のケースで
>>122の最適化により同じ生成コードとなるから
Copyを実装してるか否かは関係ないみたい
127:デフォルトの名無しさん
22/10/13 03:36:21.71 Oo+uXzBV.net
>>124
それだと簡単にインライン化出来るからね
アロケーションが必要な型という意味でCopyじゃないStringやVecと言ったんだけど
Dropと言ったほうがよかったのかな
128:デフォルトの名無しさん
22/10/13 04:02:18.88 cMF4wuqy.net
アロケーション発生しなくても(i32, i32)とかにするだけでもう生成アセンブリ同じじゃなくなるね
129:デフォルトの名無しさん
22/10/13 08:01:16.32 wSzwAK9q.net
コンパイラが>>122の
(2) メモリ←default-value書き込み
を削除する最適化をすれば
Copy実装なかろうがヒープを使おうが
生成コードは同じになるんじゃね？
130:デフォルトの名無しさん
22/10/13 15:12:31.34 FWxI+s/s.net
>>126
Copyにしてget/setにすれば同じになるかも
131:デフォルトの名無しさん
22/10/13 15:31:24.77 WZ96xtHr.net
macOSにおけるFirefoxのパフォーマンスを劇的に改善した方法とは？
メモリアロケーター「jemalloc」を独自にカスタマイズしたアロケーターを用いてメモリ管理を行っています。Firefoxのアロケーターでは並列処理時のロックを効率的に行うためにOSごとにネイティブなAPIを使用しているとのこと。このロックAPIとして、macOSではOSSpinLockが用いられていました。
URLﾘﾝｸ(gigazine.net)
これって、Rustのメモリアロケーターがjemallocを基にしたRust実装になってるってことだよね？大昔はjemallocだったという話で
132:デフォルトの名無しさん
22/10/14 21:09:01.17 iCatm8xv.net
>>136
シッタカも出来ないかまってちゃん不定期
URLﾘﾝｸ(searchfox.org)
133:デフォルトの名無しさん
22/10/15 00:38:51.20 ZRY2KlKK.net
>>130
servoを構成するコンポーネントのうちfirefoxに取り込まれたstyloしか登場してないように見えるが
134:デフォルトの名無しさん
22/10/15 10:12:30.40 kho15VFl.net
複オジにマジレスしても意味ないよ
135:デフォルトの名無しさん
22/10/15 21:19:13.19 Sue68NiD.net
お前の主張は「Firefoxはservo使ってない」であって「styloしか登場してない」では無い、そもそもstyloだけじゃない
途方もなく低い技術力でマウント取りたいことが生きがいの薄汚いオッサン
136:デフォルトの名無しさん
22/10/16 01:52:37.08 xR2EqnpB.net
servoは独立したレンダリングエンジンだからservoを使うと言えるのはgeckoを丸々置き換えた場合では
というかallocatorの話はどうなったんだ
137:デフォルトの名無しさん
22/10/16 13:06:47.08 I4ihc4bO.net
「Firefoxはservo使ってない」定期、顔真っ赤の話しそらしオジサン、geckoを丸々置き換えた場合とか言い出したｗ
「styloしか登場してない」も消えたwww
あんたはアロケーターなんて興味ないだろwww
したけりゃしろ。自分からは詳しい技術的な話何もできない、マウントしたいだけ、業界にいる寄生虫
138:デフォルトの名無しさん
22/10/16 16:22:20.12 xR2EqnpB.net
>>134
firefoxのレンダリングエンジンはservoじゃなくてgeckoのままだよ
servoは次世代ブラウザ向けのレンダリングエンジンの実装を模索するための実験プロジェクトで、geckoを置き換えることを意図したものではないよ
servoの一部のコンポーネントは完成度が高くgeckoに取り込まれてはいたので、
servoが発展していったらgecko全体がservoで置き換えられる未来もありえたけど、
mozillaがservoの開発者レイオフしちゃったのでその可能性もなくなっちゃったかと
動的ライブラリや静的ライブラリとして他のアプリケーションにリンクするcrateの場合、リンク先のアプリケーションバイナリに含まれる(または、動的リンクされる)allocatorを利用するのが普通なので、
geckoのservo由来のrustコードもそうなっていて独自にallocatorを定義することはしていないんじゃないかな
139:デフォルトの名無しさん
22/10/16 18:59:51.30 qTG+zV4j.net
rust関係ないけどjemallocを日本語で読む時
ジェ-
140:マロック派？それともジェム-アロック派？
141:デフォルトの名無しさん
22/10/16 20:24:24.45 xR2EqnpB.net
Json Evans mallocだからジェーイーマロックって呼んでる
142:はちみつ餃子
22/10/16 22:45:33.29 SvF0Fhwf.net
それを言うなら malloc が (たぶん) memory allocate の略なんだから
ジェーイーエムアロックと呼ぶのが筋というものでは……。
俺はそもそも口頭で読み上げる機会がないから考えたこともなかった。
143:デフォルトの名無しさん
22/10/16 23:11:22.79 sz/XVYMu.net
開発者本人の動画見るとジェイ・マロックに聞こえるが
ジェイ・イー・マロックが短くなってるだけかなこれ
URLﾘﾝｸ(youtu.be)
144:デフォルトの名無しさん
22/10/17 18:50:40.32 q3uOCHzu.net
>>136
servoじゃなくてgeckoのままは言い過ぎです、現にベクター系の2Dや、Canvasなどに使用するレンダラーはservo由来の
レンダラーが使用されます。その他はその通りでしょう
145:デフォルトの名無しさん
22/10/17 19:52:15.71 gBqRn20s.net
>>141
geckoを構成するコンポーネントの入れ替わりはあったけど
firefoxのレンダリングエンジンは生まれたときからずっとgeckoだよ
逆にgeckoじゃなかったら何なんだ
146:デフォルトの名無しさん
22/10/17 19:58:16.39 gBqRn20s.net
>>141
FirefoxにRustのコンポーネントを多く導入したQuantumプロジェクトの説明でも、ServoのコンポーネントをGeckoに取り込むと言っていて、
Geckoを置き換えるとは言っていない
URLﾘﾝｸ(wiki.mozilla.org)
147:デフォルトの名無しさん
22/10/17 21:29:09.32 MqsTBCMt.net
Rust関係ないからFirefoxスレでどうぞ
148:デフォルトの名無しさん
22/10/17 22:43:40.85 GuOtjDmV.net
もうその話題はいいよ
しつこいな
149:デフォルトの名無しさん
22/10/18 10:08:56.84 1nhFYrk9.net
しつこくやって『Cell<T>はTと同じコスト』(真っ赤な嘘)を流したかったんでしょw
150:デフォルトの名無しさん
22/10/18 11:26:14.64 f2tKHPpy.net
termuxのrustずっとバージョン不整合で動かないな
rustupじゃそもそもインストール出来ない
151:デフォルトの名無しさん
22/10/18 12:14:53.29 PMaXG0c3.net
>>147 俺は普通に動いてる
一応聞きたいんだけど､TermuxはF-Droidから入れたよね?
Play Store版はもうメンテナンスされてないから色々バグると思う
152:デフォルトの名無しさん
22/10/18 12:23:43.08 lAl7R2Of.net
>>143
あー、それ見てワカッタ風吹かしてんのな。「Rustのコンポーネントを多く導入」と言ってる時点で、styloだけじゃないし
2DレタリングのwebrenderもservoからのRust製だわ。”誰も”Geckoを置き換える＝Geckoが無いなんて言ってない
URLﾘﾝｸ(github.com)
153:デフォルトの名無しさん
22/10/18 14:03:11.76 f2tKHPpy.net
>>148
F-Droidから入れてる
何故かlibllvm-14.soのリンクが出来ないと怒られてしまう
で入ってるllvmのバージョンが更新で15に上がってしまってる状態
俺環かも知れんね
154:デフォルトの名無しさん
[ここ壊れてます] .net
あんまり自信がある訳じゃないんだけど、カーネルが64bitでユーザーランドが32bitみたいな環境だったりしない？
155:デフォルトの名無しさん
[ここ壊れてます] .net
>>149
Geckoのコンポーネントを置き換える
と
Geckoを置き換える
は全然意味が違うでしょ
まあ日本語の問題で意図してるところは食い違ってないから反応するのはこれで終わりにするわ
156:デフォルトの名無しさん
[ここ壊れてます] .net
グーグル、Rustで書かれたセキュアなOS「KataOS」を発表
URLﾘﾝｸ(japan.zdnet.com)
157:デフォルトの名無しさん
22/10/18 15:37:54.47 f2tKHPpy.net
>>148,151
すまぬ色々やってる中で入れたnightlyの影響だった
お騒がせした
158:デフォルトの名無しさん
22/10/19 03:30:17.24 cvhlJCwu.net
fucsia「僕はいらない子なの？」
159:デフォルトの名無しさん
22/10/19 07:05:26.07 CJepXKVA.net
>>153
昔「おおっ！！！あのグーグルがまた何か新しいことを始めたぞ！すごそうだ！」
今「まぁーーたはじまったよ・・・」
160:デフォルトの名無しさん
22/10/19 11:11:44.42 H7L8/zfi.net
Googleが立ち上げては潰してきたサービス一覧｢Killed by Google｣
killedbygoogle.com
161:デフォルトの名無しさん
22/10/19 11:23:33.38 iHEkpSLR.net
何も産まないよりは健全よね
162:デフォルトの名無しさん
22/10/19 11:35:06.09 Dqx/r4FW.net
役に立つかどうかわからんものに手を出せる余裕が
個別の結果に関わらず
部分的な成果の積み上げで会社をブーストさせるんよ
163:デフォルトの名無しさん
22/10/19 11:38:58.17 Sj+PYk/j.net
まあ堅そうな名前ではあるな
164:デフォルトの名無しさん
22/10/19 12:24:59.02 j2B3ovC/.net
IoT向けOSって言ってるし組み込みOSなんて元々百花繚乱だろ。
組み込み機器の脆弱性対応なんて大変だし、そもそもその手の脆弱性が入り込みにくい言語を採用するのは合理的だと思う。
165:デフォルトの名無しさん
22/10/19 12:46:33.84 xwPbcXKV.net
日本ってやらない理由、出来ない理由並べる奴が多いよな
多くの日本企業よりGoogleの方が多く生み出しているし世の役に立っている
166:デフォルトの名無しさん
22/10/19 12:48:40.76 aUvB23KT.net
南朝鮮ってやらない理由、出来ない理由並べる奴が多いよな 多くの南朝鮮企業よりGoogleの方が多く生み出しているし世の役に立っている
167:デフォルトの名無しさん
22/10/19 13:00:38.45 xwPbcXKV.net
Rust Foundationへの参加はNECやFUJITSUよりSamsungの方が早いんじゃないかなぁ
国内大手で積極的にRustを推していこうなんて所はなさそうに見えるし
組み込みのRenesasとかもやる気なさそうだしな
168:デフォルトの名無しさん
22/10/19 19:58:52.34 +MAum9P/.net
出来ない理由を考えるのではなく！
169:デフォルトの名無しさん
22/10/19 21:32:43.94 mHa4T+cl.net
日本が後進国になってきたのは政治の責任が大きいけど
IT分野で遅れてるのは総じて教育水準が低いからだよ
170:デフォルトの名無しさん
22/10/19 22:51:58.05 owfoFln4.net
民主主義国は政治の責任＝有権者の責任
171:デフォルトの名無しさん
22/10/19 23:03:48.16 kLmY2FYt.net
>>167
利権差配と中抜きしか考えない国賊を礼讃して
統一創価売国与党に投票し続けたやつの責任だろ
172:デフォルトの名無しさん
22/10/20 00:02:58.60 ce/AQgdF.net
まったく読むに値しないクソ書き込みの羅列の中で
>>160 だけが唯一価値ある輝きをはなっている
173:デフォルトの名無しさん
22/10/20 13:00:10.90 Px+TgmX7.net
在日だらけ。IT分野で遅れてるのは米国（英語圏）・中国の人口差だし、日本の人口減でもある。
世界中で、歴史上、移民以外で人口減を解決した国は１つもない
そういう意味では韓国などはでは優れたソフトウエアは１つもない。馬鹿な半島はAndoridのOSを
握ろうとTizenなどというゴミを掲げたが、食いついたのはNTTドコモぐらい
いま韓国で起こってるのはソフトウエアサービスの””ガラパゴス化””であり、GoogleやAmazon
Apple Payなどに対して参入障壁を作り防御するような、大昔の古臭い日本あった不公正貿易。
民主党政権時代だって３年あったわけだが、利権
174:と中抜きしかしてない。やったことは仕分けだが １つも役に立たないどころか、地方医療を崩壊させ、気象変動へ対処できるインフラ投資を 一時的止めた害悪しかなかった。その他にも野田政権による執拗な消費税増税もあった。 今彼らは英国が減税を匂わせただけで大混乱していることを見ずに、消費税ゼロを掲げている。 卑劣にも矛先を反らし、リベラルなのに移民反対派で、リベラルなのに「国賊、売国」などという言葉を使い、 まるで戦争前夜か、共産主義や社会主義のような物言いをするアホが出る時点で若い人の人材不足といえる。
175:デフォルトの名無しさん
22/10/20 16:07:13.38 zGrDbuOl.net
英国が減税しただけで、支持率が7% になったw
米国の金利上昇で、韓国の金利も0.5% 上がったw
なのに、借金が1千兆円もある日本の金利が、0%w
狂った世界中の経済学者達が、日本は不正をしている。
日本国債は破綻しなければおかしいと言ってるw
外人が幾ら日本国債を売っても、金利が上がらない。
破綻しないw
いい加減、借金が1千兆円もあるという財務省の嘘に気付け！w
YouTube で勉強しろ。
【TVじゃ絶対言えない話】国の借金は嘘！？中田敦彦が解説
176:デフォルトの名無しさん
22/10/21 19:45:15.15 xXJwtueL.net
WEB+DB PRESS、何度目のRust入門なんだい？
177:デフォルトの名無しさん
22/10/21 20:10:13.59 HoCfXQGg.net
Rust入門は初めて
178:デフォルトの名無しさん
22/10/21 21:22:06.02 2TP3mE4K.net
pythonとrustを一通り試してみた
for文の入れ子で外側のforをbreakできるとか、数値を1_000_000と表現できるとか、
そんなところでrustのほうが行き届いている感じがした
ただpythonのリスト内包表記、添え字の-1で配列の一番最後を表すとかそんなのは便利だな
179:デフォルトの名無しさん
22/10/21 21:26:14.55 gnp0h5uN.net
Rust入門という感じではないな
Rustを使ったWeb入門という感じ
180:デフォルトの名無しさん
22/10/21 22:25:35.46 YCtBy6Lb.net
>>175
Web+DB Press読者は簡単なWebアプリ開発はいろんな言語で経験済みで理解しやすいだろうからチュートリアルの対象に選んだだけでは？
181:デフォルトの名無しさん
22/10/22 13:19:56.51 OES5lhv+.net
>>176
普段読まないけどRustなので買ってみた
なかなかわかりやすかった
基本文法の解説が明らかに足りないけど
サンプルを理解するだけならこの程度で良いのか
面倒な部分が表に出ないようにうまくサンプルを調整してるし
182:デフォルトの名無しさん
22/10/22 21:03:49.60 Vp6sRBIs.net
借用がどうGCに関係するのかよくわからない
うまく説明しているサイトはないですか?
183:デフォルトの名無しさん
22/10/22 21:38:11.55 OES5lhv+.net
まずスタックとヒープを理解せよ
これは口を酸っぱくして言ってる
でないとRustは理解できない
184:デフォルトの名無しさん
22/10/22 21:39:04.07 PO/EA+oY.net
とりあえずThe Bookの4章
URLﾘﾝｸ(doc.rust-lang.org)
Rustをそれなりに習得しようと思うなら
The Bookとオライリー本を読むのが一番近道
185:デフォルトの名無しさん
22/10/22 23:56:07.88 OES5lhv+.net
両方とも初心者には辛いよなあ
わかりやすい入門書が待たれる
186:デフォルトの名無しさん
22/10/23 00:22:18.48 LnniM1YV.net
借用するときにデータをスタックに積む
スコープを抜けるときに一気にpopするので
GCがいらない、つまり、早い
heapだとGCのときにデータの移動が必要になる
ので遅い
この理解であってる?
187:デフォルトの名無しさん
22/10/23 00:29:31.67 jNoMv4k0.net
ポインタとか参照とか他の言語で扱ったことない？
188:デフォルトの名無しさん
22/10/23 00:44:57.32 h/oZflgJ.net
heapが遅いの要因は、メモリの割り当て解放処理があるから処理量が多いとか、
割り当てた領域がバラバラになることでキャッシュ効率がさがることとかかと
189:デフォルトの名無しさん
22/10/23 13:47:22.46 /F23RQvw.net
ページング処理みたいなのが、ヒープだと2重に行われるんじゃないの？
190:デフォルトの名無しさん
22/10/23 14:14:22.62 ioVOctq2.net
>>182
Rustでのその辺のメモリの動きはオライリー本に詳しく書いてあった気がするから読むべし
191:デフォルトの名無しさん
22/10/23 15:30:09.10 t4UBj2/5.net
>>182
>>185
お前ら、具体的にどうされてるからスタックだと速いかわかって無いだろ、、、
192:デフォルトの名無しさん
22/10/23 18:33:19.09 QEVtmAwk.net
>>182
そんなに物事が単純なら良かったのに...
”スコープを抜けるときにGCがいらない、つまり、早い”、これは間違いでもある。インライン展開されるような高階関数なら良いが
ループ中でアロケーションしてしまうような記述をすると、その度に確保・解放されるので非効率になりかねないし、借用による
メモリーの管理ではないが、参照カウントを使用するSwiftでは、ループでボトルネックになることはある。
このためRustでは高階関数で書く事が一般的に（分かり易く）良い事とされる。あとスタックでどの言語も大体はスコープ外で
消えるのでヒープとスタックの区別は付けましょう
独立したGCスレッドが動く言語だと、スコープ外れでGCするとは限らないので、速い場合がある。一方で、高負荷な環境では
GCスレッドがありで、回収などインターラプトが入るのでRustが有利になる（＝※こちらのほうがRustが重要視される理由）
いわゆるSTOP THE WORLD（DIO様風）だ。ただ、これが無ければ良いということではなく、循環参照などを作らなければ
問題ないという話で循環参照を作ってしまうのであれば、独立したGCスレッドは便利でもある
”GCのときにデータの移動が必要”になるかどうかは、GCのアルゴリズム次第であり、厳密には”データの移動が必要”になるのは
メモリーのフラグメント解消つまりコンパクション処理によるところが大きい。これは、近代的なOSでは似たような事を行っていて
これ自体が速度に大幅に影響を及ぼすとは言い難い
193:デフォルトの名無しさん
22/10/23 19:03:12.25 NZM9O6ur.net
>>188
> ループ中でアロケーションしてしまうような記述をすると
アホなコードで議論する必要あるの？
194:デフォルトの名無しさん
22/10/23 20:51:00.62 h/oZflgJ.net
一体何と何を比較しているのだ
195:デフォルトの名無しさん
22/10/23 22:09:39.72 HOBBKeJ+.net
なんかすごい早口で支離滅裂なこと言ってるけど
頭を整理した方が良いよ
196:デフォルトの名無しさん
22/10/24 16:50:56.92 SgELnO58.net
スコープを抜けるときにGCがいらない、つまり、早い
これが間違っている理由を教えてください
197:はちみつ餃子
22/10/24 18:09:05.87 VKX4Fsrh.net
ヒープメモリの管理はそれなりに重い処理だというのが論旨のように見える。
GC を使った場合のように不要なオブジェクトの判別をしていくコストは Rust では生じないが
それを除けば空いてる箇所と使用中の箇所を上手いこと管理する実行時コストは
GC (に付随するメモリ割り当て) でやってるのとたぶんそんなに差はないんじゃね。
198:デフォルトの名無しさん
22/10/24 18:49:41.29 8+UVFZyO.net
>>192
＞スコープを抜けるときにGCがいらない、つまり、早い
確保したメモリはいつ解放するんだよバカ。
199:デフォルトの名無しさん
22/10/24 19:05:34.14 Off49nvS.net
文法で制約したら、書き手もコンパイラも
変数の寿命を厳密に特定することができて便利だろって事で、
どこにどう確保すると速いとか、そういう話とは別では
200:デフォルトの名無しさん
22/10/24 19:14:17.25 FdEAHzhz.net
GCがないので速い←わかる
スコープを抜けたらpopするだけなので速い←わかる
スコープを抜けるときにGCがいらない←スコープとGCは何の関係もないよね
201:デフォルトの名無しさん
22/10/24 20:07:47.96 rCA25jH/.net
まあGCは常に動く可能性があるからな
逆に全く動かない可能性もある
そこはGCのアルゴリズムによりけり
202:デフォルトの名無しさん
22/10/24 21:01:10.53 SgELnO58.net
スタックを使っているから
pop すればそのままメモリが解放されるという意味では?
203:デフォルトの名無しさん
22/10/24 21:39:23.30 UxIqfb1a.net
何と何を比べて何が速いと思ってるのか整理しなよ
話はそれからだ
204:デフォルトの名無しさん
22/10/24 22:49:30.31 c7GaYtEs.net
>>198
動的データ全部スタックに積むのか。すげーな。
205:デフォルトの名無しさん
22/10/24 22:54:45.01 9jOSWWIs.net
そんなことよりコンパイルの遅さマジでテコ入れろYO、非力なCeleronでactix-webのコンパイルしたら10分とかふざけてんのか？
206:デフォルトの名無しさん
22/10/24 23:05:21.00 XsMeW9pb.net
コンセプトがコンパイル遅くしても賢くするだから無理
207:デフォルトの名無しさん
22/10/24 23:18:23.86 b0depGja.net
依存ライブラリまで全部自前ビルドさせられてるわけだからな
コンパイル済みcrateの配布とかやってくれればなんとかなりそうではあるが
208:デフォルトの名無しさん
22/10/24 23:42:51.24 cJUnO/Lg.net
コンパイル高速化はユーザー側でもいろいろ工夫の余地はあるが
コア数多いマシンを使うのがいちばん効果がある
209:デフォルトの名無しさん
22/10/25 07:14:07.04 0Y9XP165.net
分散コンパイルか、差分コンパイルか、常にバックエンドでコンパイルか
210:デフォルトの名無しさん
22/10/25 08:16:49.84 A5TY3R0Y.net
>>201
流石にもっと良いマシン買えでFA
211:デフォルトの名無しさん
22/10/25 08:49:49.17 1jHrAe9o.net
でもRustって錆だよね
212:デフォルトの名無しさん
22/10/25 11:17:17.09 5EjxpvPU.net
ライブラリ類も複雑化・大型化の一途をたどっているご時世だし
Androidをビルド出来ないようなマシンは開発用としては時代遅れじゃね
213:デフォルトの名無しさん
22/10/25 16:49:21.94 pUVcngq8.net
環境負荷を下げるためにもTier1プラットフォームはビルド済みか半分ビルド済みを配布できるようにすべき
214:デフォルトの名無しさん
22/10/25 18:21:31.05 RZIJ148t.net
structのフィールドにasyncのクロージャ持たせるの面倒だな
215:デフォルトの名無しさん
22/10/26 00:21:17.27 +/Fbza6R.net
>>210
Pin<Box<dyn Future<Output = T>>> ではだめ？
216:デフォルトの名無しさん
22/10/26 01:59:13.05 TlW6c1+d.net
>>211
Box<dyn Fn() -> Pin<Box<dyn Future<Output = T>>>>
こんな感じ
217:デフォルトの名無しさん
22/10/26 03:12:53.76 J4zGWIbj.net
>>200
全部とは言っていないローカル変数だけだ
218:デフォルトの名無しさん
22/10/26 07:48:04.37 i0Q+rT9S.net
>>213
GoだってJavaだってローカル変数はスタックを利用する。
219:デフォルトの名無しさん
22/10/26 08:03:17.30 xzd5i3vP.net
>>214
Go は知らんが Java は値型しかスタックに確保しないよ
配列使うだけでヒープ使う
220:デフォルトの名無しさん
22/10/26 10:03:48.91 8iR+QuRY.net
んなこと言ったらRustだってBox使うだけでヒープ使われるだろ
221:デフォルトの名無しさん
22/10/26 10:28:26.80 poB2zSjv.net
ピープアレルギーでも湧いたのか？
222:デフォルトの名無しさん
22/10/26 10:55:30.37 xzd5i3vP.net
>>216
そりゃあえてBox使えばヒープ使うわな
極論バカ乙w
223:デフォルトの名無しさん
22/10/26 12:39:08.43 61QnplYU.net
ヒープで思いついたけどtest::benchってなんで使用したメモリ量出てこないの？Rustだってアロケーター自作できるなら出せなくないと思うんだが
224:デフォルトの名無しさん
22/10/26 13:39:05.90 29TlHyS0.net
c言語なんかも int a[n] とかはスタックから取ってきてる。昔はmallocしてたが。
とはいえlinuxのスタック領域はヒープとそんな変わらん。
225:デフォルトの名無しさん
22/10/26 13:49:21.71 OrdcPqRc.net
環境によるが、Rust のスレッドごとのスタックサイズのデフォルトが2MBとかで
バカでかいローカル変数や引数を使おうとすると、
簡単に実行時エラー／スタックオーバーフローを実現できるという
ちなみに、String はヒープを使う
226:デフォルトの名無しさん
22/10/26 14:58:21.99 XcmPInF1.net
>>220
ん？
何が変わらんの？
227:デフォルトの名無しさん
22/10/26 16:10:38.33 +/Fbza6R.net
>>219
issueはあるが放置されてる
URLﾘﾝｸ(github.com)
こういうのは欲しい人が積極的に動かないとなかなか進まないよね
228:デフォルトの名無しさん
22/10/26 18:56:12.77 m/VlzFSs.net
C 以外の言語は、すべて浅いコピー・shallow copy でしょ。
実体はコピーされずに、参照だけがコピーされる
たぶん、ローカル変数も参照だけがスタックにあって、
実体はヒープにあるのでしょ
229:デフォルトの名無しさん
22/10/26 19:32:11.84 /Jbhrlo+.net
そもそもスクリプト言語はマシンスタック使ってないから
C/C++/Rust/Goみたいなコンパイル言語とスクリプト言語(PythonとかRuby)とではメモリモデルが全く違う
JVMのJITはVMスタックをマシンスタックに引き継ぐって処理をやってるけど
230:デフォルトの名無しさん
22/10/26 19:35:12.65 +/Fbza6R.net
>>224
Cにdeep copyの概念ある？
231:はちみつ餃子
22/10/26 19:39:57.27 UI6BPQPg.net
>>226
たぶん >>224 は Java や C# などでいう参照型のことを言ってると思う。
232:デフォルトの名無しさん
22/10/26 19:41:30.91 WAf5RIwU.net
Box<T>って出現頻度の割に表記が長いよな
boxキーワードに変える案はどうなったんだ？
233:デフォルトの名無しさん
22/10/26 20:19:12.15 SEIcgM+j.net
>>220
まーた思いつきで適当なこと言ってるの？
234:デフォルトの名無しさん
22/10/26 21:39:27.98 xibmu52f.net
シャローコピーもディープコピーもプログラマに意識させるような言語の方がいいと思うけどなあ
235:デフォルトの名無しさん
22/10/27 17:59:59.22 36nf4K/2.net
C言語は低レベルすぎるからshallow copyやdeep copyを意識する必要がそもそもないしな
ポインタをそのまま複製するのがshallow copyでポインタをデリファレンスしてからその値を複製するのがdeep copyってだけやし
236:デフォルトの名無しさん
22/10/27 18:19:49.08 mzG41rMz.net
cだってポインタがネストされてたら順番に見てかないといけないのは他の言語と同じでしょ。
ネストを考慮しなくて良いならjavaだってcloneで一発コピーできる
237:デフォルトの名無しさん
22/10/27 22:00:27.64 rMi5UTbc.net
>>231
> C言語は低レベルすぎるからshallow copyやdeep copyを意識する必要がそもそもないしな
むしろ意識しまくりだろ
shallow copyとかdeep Copyとかのおしゃれな名前では呼んでないけど
238:デフォルトの名無しさん
22/10/27 22:11:49.94 olmwGZ8d.net
複製おじさんディープコピー知らなかったもんねw
239:デフォルトの名無しさん
22/10/27 22:27:03.43 DBkkmtck.net
あえていうならCにおいては構造体のメンバをそのまま代入するのがshallow copy
構造体のメンバのポインタの領域を新しく領域を確保してコピー元の構造体を再帰的にmemcpyするのがdeep cooy
240:デフォルトの名無しさん
22/10/27 23:13:57.69 qcIge2ki.net
Cではというが大多数の言語がそうじゃね
241:デフォルトの名無しさん
22/10/28 00:02:58.28 Rl5QKwW8.net
deep copy は、ネストするから難しい
Ruby などは参照のリンクを断つために、
一旦、JSON などの文字列にしてから、オブジェクトを再構築したりする
Marshal もあるけど、色々な条件がつく。
IO, Proc, 特異メソッドが使えないとか
242:デフォルトの名無しさん
22/10/28 01:13:37.77 jXOvR4PJ.net
なんか話の脈絡も流れもなく各人が単語に反応して書きたいこと垂れ流すだけのスレと化してんな
243:デフォルトの名無しさん
22/10/28 03:43:44.96 01u53tKZ.net
高階関数はGCの性能に影響を及ぼすの?
244:デフォルトの名無しさん
22/10/28 09:27:53.24 jXOvR4PJ.net
Webpackの後継となる新バンドルツール「Turbopack」が登場。Rust製のネイティブアプリケーションでWebpackの700倍高速に。Next.js Conf 2022 － Publickey
URLﾘﾝｸ(www.publickey1.jp)
245:デフォルトの名無しさん
22/10/28 16:15:00.57 AMrJHSke.net
JavaScriptっていつまでバンドルとかやるん？
246:デフォルトの名無しさん
22/10/28 16:24:46.58 muqJ433+.net
いっそコンパイルしたら
247:デフォルトの名無しさん
22/10/28 16:28:04.57 AMrJHSke.net
wasmでそれやろうとしてるけど
wasmランタイムよりJavaScriptランタイムの方がまだ速いというトホホな状態
248:デフォルトの名無しさん
22/10/28 19:59:50.54 eNUtjibx.net
じゃあasmjsでよくね
249:デフォルトの名無しさん
22/10/30 11:39:14.94 zV+ownbZ.net
何いってんだ
JavaScriptはRustの大口顧客だぞ
バカにするなんてとんでもない
JavaScriptの市場が大きいほどRustが儲かる仕組みなんだ
250:デフォルトの名無しさん
22/10/30 13:52:59.67 Ffhte1rz.net
moziraとgoogle, Microsoftと主要ブラウザメーカーが推進してるからな
251:デフォルトの名無しさん
22/10/30 19:41:21.29 TG2fSMWC.net
なんでvecの&mutに*が不必要なのか、いまいち理解してなかったけど
fn calc(n: &mut Vec<usize>) {
(*n).push(1);
}
こういうことかー。そういうことだったのかー
252:デフォルトの名無しさん
22/10/30 23:24:15.56 tkb7REiJ.net
struct User {
name : String,
age : u32,
}
fn main() {
let mut user = User {
name : "sato".to_string(),
age : 30,
};
user.age = 40;
user.name = "aaaa".to_string();
println!("{}{}", user.name, user.age);
}
"sato".to_string()で生成したStringは
user.name = "aaaa".to_string()後はどうなるの？
mainの}抜ける＝プログラム終了時ようやく解放？
253:デフォルトの名無しさん
22/10/30 23:41:49.13 fG4j0a7a.net
Dropを自分で実装した型で試せばわかる
254:デフォルトの名無しさん
22/10/31 19:06:46.94 DHbQvQ7c.net
相変わらずLinusに怒られまくってるね
255:デフォルトの名無しさん
22/11/01 06:39:05.97 y5vMQo4Y.net
rust導入してもディレクトリ構造が汚くなるだけなのにどうして導入したんだろうね
正直撤回して欲しいわ
256:デフォルトの名無しさん
22/11/01 07:47:38.45 6ZBnCRFC.net
ディレクトリ構造なんかより優先すべきことがあるからだろ
rust使う意味を何も分かってないな
257:デフォルトの名無しさん
22/11/01 14:04:14.12 w6yg6Ajb.net
もうlinusがカーネル用にsafeな言語作った方がいいんじゃないの
既成言語じゃ既存の処理系と整合性をとらないといけないから
いろいろな不整合が生じる
258:はちみつ餃子
22/11/01 14:12:23.10 XoXOtAeK.net
エコシステムの充実はユーザ規模によるところがあるから
たとえ言語の設計としてベストマッチでも特化しすぎると
(使い手が増えなくて) 雑多なツールやライブラリが出揃い難いということもありうる。
Linux くらいの規模なら専用言語を作っても割に合ったりするかな？
259:デフォルトの名無しさん
22/11/01 14:25:52.66 smDWdngC.net
linusがなんか言ったの？
ググってもlinux 6.1にrustが取り込まれた話しか見つけられなかった
260:デフォルトの名無しさん
22/11/01 14:50:17.04 FsVxrWah.net
>>253
なにそのgitな流れは。
凄まじく少ないコードで実現してしまいそうで恐ろしい。
ピーキーなのになって、普通の人は使えないのを期待しちゃう。
261:デフォルトの名無しさん
22/11/01 14:58:39.21 O+5UiM+O.net
>>253
linusはgcc拡張のCが最高だと思ってる人だよ
262:デフォルトの名無しさん
22/11/01 18:29:34.49 cxS6KzKc.net
>>250
どれ？
263:デフォルトの名無しさん
22/11/02 15:56:44.98 ohjjd8k9.net
linuxもデフォルトcというよりもかなりカーネル用の拡張してるからrustもそうすればええわってのが
linusの主張でしょ。
264:デフォルトの名無しさん
22/11/02 16:18:07.00 qqWWqhkC.net
一応clangでもlinuxカーネルコンパイルできるようになっているということは、
LLVMに必要な機能はそろっているということだろうから、
rustcからそれらの機能を呼び出せるようにできれば良いのかね
265:デフォルトの名無しさん
22/11/02 16:35:45.00 F11hp17c.net
リーナスゴシップとかどうでもいいスレチネタを続けるなよ
266:デフォルトの名無しさん
22/11/03 02:16:08.55 atTBpfYp.net
しょーもないシンタックスの話より有意義だけどな。
267:デフォルトの名無しさん
22/11/03 05:38:58.72 CtTK5dM6.net
1要素タプルの書き方Pythonと同じなんだね
パターンマッチで参照外しと絡むとややこしいなぁ
// 要素1のタプルはカンマ必要
let (mut a, ) = (1, );
a = 100;
println!("{}", a); //=> 100
// 要素1のタプルはカンマ必要
let &(mut a, ) = &(1, );
a = 100;
println!("{}", a); //=> 100
// (式)と区別つかないからとか
let &(mut a) = &(1);
a = 100;
println!("{}", a); //=> 100
// error[E0308]: mismatched types
let &mut a = &1; // ←ココ
a = 100;
println!("{}", a);
// こっちはok
let &(mut a) = &1;
a = 100;
println!("{}", a); //=> 100
mutがどっちに付くのが優先なのか（イミュータブルなaの参照なのかaのイミュータブル参照なのか）覚えてないと適切に()付けられないね、覚えりゃいいんだけども
Rustの話に限らずもっと根本的な解決方法ってないのかな？
()をいろんな意味に酷使し過ぎでは？関数の引数部分、式の評価順変更、タプル、等々
型は後置修飾なのに&やmutはなんで前から懸かるの？
これ全部RPNにすれば解釈の曖昧さがなくなって優先順位の()が要らなくなり、関数呼び出しもf1(1, f2(2, 3), f3(4))は1 2 3 f2 4 f3 f1となって、タプル以外の()撲滅できないか？
268:デフォルトの名無しさん
22/11/03 19:40:23.88 4W4icteo.net
>>263
()を色々使いすぎというのは同意だけどRPNだと今よりもっと使われないよ。
連鎖性言語とか好きだけど。
269:デフォルトの名無しさん
22/11/03 21:14:31.73 Z+updFpk.net
()については他の言語と同じだしそこで変に独自性を出してもなぁという感じ
270:デフォルトの名無しさん
22/11/03 21:15:01.48 t6ap+kyc.net
for &i in vec![0_usize; 5].iter() {
//iのままなんちゃら
}
for i in vec![0_usize; 5].iter() {
//*iでなんちゃら
}
参照外しはどっちをつかってる人のほうが一般的なん？
271:デフォルトの名無しさん
22/11/03 21:21:15.76 0fRPRys5.net
Copy実装してる型なら別にどっちでも……
272:デフォルトの名無しさん
22/11/03 21:35:17.79 b1nVlp4p.net
union で定義した型があり、タグビットに相当するビットで variant を区別できる場合に
enum と同じ表現でパターンマッチするというようなことは出来ませんかね？
マニュアルを見た感じでは出来なさそうなので駄目で元々な相談なんですが……。
それが欲しくなった事情としては抽象的なバイトコードマシンが定義されていて
そのバイトコードをそのまま enum にマッピングできれば楽なのになと思った次第です。
273:デフォルトの名無しさん
22/11/04 04:42:50.90 QJXSkaei.net
.expect("なんとかかんとかfailed.");
expectの引数はこんな文章になりがち
.expect("なんとかexpected, but かんとか found");
ならまだいいけど
コード読むときexpectというメソッド名からその引数には"期待しているものの説明"を"期待"してしまう
慣れるんだろうか…
274:デフォルトの名無しさん
22/11/04 08:57:52.35 KcmeiRV8.net
>>269
英単語を声に出して読んでみ
275:デフォルトの名無しさん
22/11/04 09:12:11.15 NSu48ax/.net
>>269
公式のドキュメントにも
.expect("failed to parse number")
という例があるしあまり気にしない方がよさそう
URLﾘﾝｸ(doc.rust-lang.org)
276:デフォルトの名無しさん
22/11/04 09:15:25.47 yWEsFaag.net
>>271
これ英語の分からん奴が書いたんだろう
277:デフォルトの名無しさん
22/11/04 09:25:36.66 u3TD418O.net
>>269
まあ慣れるしかないわな
俺もこの名前はおかしいと思うし世の中でもおかしいと思う人はいるようだ
URLﾘﾝｸ(stackoverflow.com)
278:デフォルトの名無しさん
22/11/04 09:47:45.14 QJXSkaei.net
>>273
よかった、俺だけではなかったか
279:デフォルトの名無しさん
22/11/04 09:54:11.00 NSu48ax/.net
推奨されるメッセージのスタイルが定義されているので>>269は正しい
URLﾘﾝｸ(doc.rust-lang.org)
どうしても気になるならこれを根拠にしてメッセージを修正するpull req送ると良いと思う
280:デフォルトの名無しさん
22/11/04 11:58:42.90 hgziOenm.net
君、ぼくのおちんちんを舐めてみないかい
281:デフォルトの名無しさん
22/11/04 12:36:39.57 8jcY9XF+.net
.expect("ン拒否するゥ");
282:デフォルトの名無しさん
22/11/04 13:14:11.67 u3TD418O.net
.expect("もう少しぶっといイチモツを用意すべきです")
283:デフォルトの名無しさん
22/11/05 21:07:51.50 EPLuMYxk.net
expectがそもそも期待するという意味より、予想するという意味合いで使われてることが多い気がする
284:デフォルトの名無しさん
22/11/05 21:47:55.53 6MdwxjIj.net
ここまで1.65の話題ゼロか
285:デフォルトの名無しさん
22/11/05 21:51:57.09 4ktyBPoJ.net
GAT難しいからw
286:デフォルトの名無しさん
22/11/05 21:58:52.83 B2i8Nuif.net
Rust 1.65.0 の発表
2022 年 11 月 3 日 · Rust リリース チーム
URLﾘﾝｸ(blog.rust-lang.org)
新しい Rust リリースの詳細に入る前に、イランの宗教道徳警察によるMahsa Amini の悲劇的な死と、他の多くの人々の死と暴力的な抑圧に注意を向けたいと思います。詳細については、 URLﾘﾝｸ(en.wikipedia.org)を参照してください。私たちは、人権のために闘っているイランの人々と連帯します。
↑BLMといいウクライナといい海外ITの政治的主張入れて当然みたいなノリ苦手
質実剛健のイメージだったがRustチームも同じでちょっとガッカリ
287:デフォルトの名無しさん
22/11/05 22:23:37.34 CC30py/U.net
嫌な世の中だな
288:デフォルトの名無しさん
22/11/05 22:33:26.02 zxpwXxCd.net
そういうのが嫌なら使わなければよろしい
289:デフォルトの名無しさん
22/11/06 03:47:36.18 5A+TXyoz.net
お、Backtraceがstabilizeされたか
めでたい
290:デフォルトの名無しさん
22/11/06 23:25:31.82 tr7TV8Z+.net
>>285
うむ
291:デフォルトの名無しさん
22/11/07 14:30:18.00 5gh9UgGm.net
むしろ政治的な要素が少しでもあると過敏反応する日本IT連中のがキモいわ
292:デフォルトの名無しさん
22/11/07 14:37:07.26 3k6QMezQ.net
RustってSDGsだよね
293:デフォルトの名無しさん
22/11/07 16:35:16.97 F5fz3af4.net
みんなMSRVいくつにしてる？
294:デフォルトの名無しさん
22/11/07 21:29:16.68 oBOm8exD.net
日本人はまあ事なかれ主義だから仕方がない
295:デフォルトの名無しさん
22/11/09 08:18:29.70 JQdb1AnG.net
過剰反応というかツイッターでも左翼のトレンド操作がバレてしまったし
そういう必死な印象操作する奴らに全く反応しないのも正常性バイアスなだけで危険だと思うけどね
296:デフォルトの名無しさん
22/11/09 08:49:14.30 jv4fVWS/.net
別に操作でもなんでもなく前から人が選んでるって言ってたじゃん。
だからそういうのを過剰反応って言うんだよ。
297:デフォルトの名無しさん
22/11/09 09:39:55.00 LmGx5OMY.net
>>291
ナイーブなやっちゃなぁ
どの国でも底辺ほど極右化しちゃうのは物事が見えてないからなんやな
298:デフォルトの名無しさん
22/11/09 09:48:57.31 fSnT1d04.net
貧困老人って左傾化してるイメージある
299:デフォルトの名無しさん
22/11/09 12:28:40.18 aAawVede.net
>>292
トレンドはどのように決定されますか？
トレンドはアルゴリズムによって決定され、初期設定では、フォローしているアカウント、興味関心、位置情報をもとにカスタマイズされています。
こういうAI系にRustが使われる可能性ありそうかな？
300:デフォルトの名無しさん
22/11/09 12:56:20.73 YZQA7nNX.net
>>295
コア部分がC++、FortranからRustに変わるとかはありそう
301:デフォルトの名無しさん
22/11/09 13:03:43.26 tbXsBHme.net
>>294
それもまたナイーブな見方やなぁ
反自民党なら左、親自民党なら右やと思ってるんやろ？
302:デフォルトの名無しさん
22/11/09 14:25:41.02 bNBw/HLH.net
>>296
rustのGPU周りのツールチェインは整備進んでるの？
303:デフォルトの名無しさん
22/11/09 19:49:39.97 8uuc6jgH.net
>>298
GPGPU系は普通に使えそうな感じはしてるけどdeep learning周りはNvidiaが乗り気になるまで無理かもしれないと思えてきた
304:デフォルトの名無しさん
22/11/12 21:53:46.90 PWetNf5n.net
eguiつよそうだけどみんな興味ないの？
305:デフォルトの名無しさん
22/11/13 01:00:16.84 1Xo91Kz4.net
guiはeguiとtauriの2強になりそう
306:デフォルトの名無しさん
22/11/13 02:09:24.41 Uh0BavN1.net
eguiはエグイ
307:デフォルトの名無しさん
22/11/13 02:33:53.13 RFRBhoEy.net
言うほど2強か？
URLﾘﾝｸ(www.publickey1.jp)
308:デフォルトの名無しさん
22/11/13 21:44:40.30 S
309:eSkk5iM.net
310:デフォルトの名無しさん
22/11/13 22:06:12.87 iM/fRtPp.net
脱Electronした純Rust製コードエディタが出ないことには評価し辛いな。
311:デフォルトの名無しさん
22/11/13 22:58:55.78 T5PK/vl5
312:.net
313:デフォルトの名無しさん
22/11/15 00:12:55.17 dw7MQVYD.net
Bevyの変更量エグいな。1.0到達まで様子見するわ
URLﾘﾝｸ(bevyengine.org)
314:デフォルトの名無しさん
22/11/15 00:20:45.30 aZkMwykQ.net
米国家安全保障局、CやC＋＋からメモリー安全性の高いJavaなどへの移行を推奨
URLﾘﾝｸ(japan.zdnet.com)
ハッカーらによるリモートコード実行（RCE）をはじめとするさまざまな攻撃からコードを保護するために、C＃やGo、Java、Ruby、Swift、Rustといったメモリー安全性の高い言語に移行するよう推奨している。
315:デフォルトの名無しさん
22/11/15 00:37:48.72 91d2LP66.net
CやC++で書かれているライブラリに依存するのもやめた方が良いのかね
316:デフォルトの名無しさん
22/11/15 01:26:07.72 5Bng48RE.net
実績というのは何にも代えがたい証明だからね。
十分に広く長く使われて枯れたライブラリをすぐさま使用停止するほどではないと思う。
長期的には移行せざるを得ないと思うが。
317:デフォルトの名無しさん
22/11/15 02:05:15.69 9SlnRoJw.net
＞プログラマー側での実行に大きく依存している
言語の問題ではなくて、処理系と設計の問題だろうけど
C/C++と同程度の注意力であっても、
比較的楽に安全な実装が可能という話か
318:デフォルトの名無しさん
22/11/15 05:58:46.96 XpLYghoG.net
RubyはRustの誤植な気がする
319:デフォルトの名無しさん
22/11/15 06:20:05.09 dw7MQVYD.net
Javaもnull非安全クソ言語じゃんぬるぽ
320:デフォルトの名無しさん
22/11/15 07:20:48.25 GEd0aXfX.net
>>312
元の記事でも
The National Security Agency (NSA) is urging developers to shift to memory safe languages – such as C#, Go, Java, Ruby, Rust, and Swift
って書いてあるから誤植とかでは無いと思うがNSAのソースを示してほしいね
URLﾘﾝｸ(www.zdnet.com)
321:デフォルトの名無しさん
22/11/15 08:46:43.91 91d2LP66.net
メモリ安全という意味ではRubyは条件満たしてはいるのでは
Pythonがないのは気になるが
322:デフォルトの名無しさん
22/11/15 08:47:01.64 UduTysKC.net
ソース
URLﾘﾝｸ(media.defense.gov)
323:デフォルトの名無しさん
22/11/15 09:09:11.17 ott+UO1u.net
人工衛星イザナミ・イザナギでも、mruby を使っている
C はポインターでバグるから、
文字列処理などはポインターを使わない、安全なmrubyが良い
それで、mrubyから、Cのライブラリを呼び出せば安全
324:デフォルトの名無しさん
22/11/15 11:32:13.77 LEUpsbho.net
文字列処理でポインタを使わないってどうやんの？
325:デフォルトの名無しさん
22/11/15 11:45:11.75 Ohwd0nE1.net
陽に使わないって事だろ
326:デフォルトの名無しさん
22/11/15 12:05:46.25 91d2LP66.net
言わんとすることは分かるけど人工衛星と文字列処理はあんまり関係なさそう
327:デフォルトの名無しさん
22/11/15 12:16:51.72 REyE3AUr.net
>>316
これからメモリーセーフな言語が沢山出てきそうだな
328:デフォルトの名無しさん
22/11/15 12:57:18.27 37NRafRf.net
メモリセーフかつGC無しの言語ってRust以外に増える気配ないよな
需要あるのに
329:デフォルトの名無しさん
22/11/15 13:11:29.50 bU8+MPV6.net
C++ は安全な言語に混ぜてもらえなかったんだな。
C++はCに寄せられてしまったのかと。
330:デフォルトの名無しさん
22/11/15 13:50:50.90 eF4hIM3d.net
「生ポインタを使わずスマートポインタを使う」
「オブジェクトのコピーはすべてムーブを使う」
を徹底すればそこまで危険ではないんだけどね
331:デフォルトの名無しさん
22/11/15 13:53:08.34 Ohwd0nE1.net
>>323
まあやろうと思えばCと同じことができちゃうからね
332:デフォルトの名無しさん
22/11/15 14:25:30.22 5Bng48RE.net
>>324
知っててもクソみたいな誤りをするのが人だからな。
333:デフォルトの名無しさん
22/11/15 15:49:10.51 91d2LP66.net
Google Chromeのバグの7割がメモリ安全関連というし、
C++で安全性を保ちつつ大規模複雑なアプリケーションを作るのは難しいのでは
334:デフォルトの名無しさん
22/11/15 16:00:29.49 AMPFJlS8.net
そりゃ「〇〇するよう気をつければ良い」が通るんならそもそもバグらないよう気をつけられるはずだしな
人間が気をつけるのと機械的にチェックできることの間には大きな差がある
335:デフォルトの名無しさん
22/11/15 21:18:52.91 oaKUlL5c.net
>「オブジェクトのコピーはすべてムーブを使う」
微妙に意味が分からん
336:デフォルトの名無しさん
22/11/16 03:16:38.83 +3Ecu7Qb.net
>>329
クラスにムーブコンストラクタとムーブ代入演算子を必ず実装して
それが呼び出されように書くということね
ゼロから書く場合は可能
つまりRustっぽく書く
しかし外部ライブラリを使う場合は破綻するので無理なのだが
337:デフォルトの名無しさん
22/11/16 07:33:54.12 NR4h2Di6.net
F#をトライしていたのですが、VSは重いし、VScodeは動かすことができず
Sublimeは何とか動くが、ライブラリをうまくアクセスできず図を出力できず
コマンドラインでの実行もバージョンが古いせいかこれもライブラリにアクセスできず
で、似ているというRUSTをテストしてみました
インストールも簡単、クレートの設定も簡単
コンソールでコンパイル、実行も簡単
webにあるサンプルをテスト、５つほどwarningがでていましたが図を出力できました
F#では実行環境を作るのに四苦八苦しましたが、RUSTはあっというま
感激してここにアップしました
今から勉強します
338:デフォルトの名無しさん
22/11/16 07:35:45.01 16ZvLDN4.net
「コピーは使わないでムーブする」なら意味が通じたが
339:デフォルトの名無しさん
22/11/16 12:12:43.09 I1e3AS0A.net
>>332
そのつもりで書いてた。
推敲不足だったな。回線ケーブルで首釣るかもしれん。
340:デフォルトの名無しさん
22/11/16 18:02:22.96 +n4YDZit.net
一部のアスペ以外はそれぐらいの推論はできるからあまり気にしなくていいよ
341:デフォルトの名無しさん
22/11/16 18:02:43.41 QMFF+6Ax.net
そういうのは吊るを使う
342:デフォルトの名無しさん
22/11/16 18:29:22.77 XyYlAbZW.net
>>333
お前は誰だよw
俺を語ってんじゃねー
343:デフォルトの名無しさん
22/11/16 20:20:41.18 Lkj73ShV.net
.netでrustが使えれば無敵なのに
344:デフォルトの名無しさん
22/11/16 21:13:44.67 y4GxYc69.net
GCのランタイム環境でRUSTは意味ないんじゃ？
345:デフォルトの名無しさん
22/11/16 21:37:10.96 eOApcCVI.net
ML 系言語が Rust を高水準にした感じじゃない？
(というか ML の研究からリージョン推論が生まれて Rust に繋がっていったのだが……。)
.NET 用だと F# があるから使ってみても面白いかもね。
346:デフォルトの名無しさん
22/11/16 21:59:45.42 /cIgFYP8.net
.NETのライブラリが使いたいとかでは
347:デフォルトの名無しさん
22/11/17 00:08:08.45 Wvvh1amI.net
rust難しすぎません？
僕はまだまだ、たぶん無理だけど、そこそこできるようになったとしても、全体の底上げがなければ普及が難しいのではという自己弁護
348:デフォルトの名無しさん
22/11/17 00:34:44.66 /MItGujg.net
既存のC/C++のコードをRustに書き直すのは
頑張らなくても良いですと言われていても
世界に一人ぐらい頑張る人がいて
再実装しましたみたいなのが時々出てくるな
349:デフォルトの名無しさん
22/11/17 00:48:28.80 SzkkMxOu.net
C++ 何となく使っているけど、Rust って難しいの？
C++ より難しいなら、先に勉強しようかな
350:デフォルトの名無しさん
22/11/17 01:00:11.07 EPum3E1i.net
>>343 とりあえず動かすのはRustのが難しい
正しく動かすのはC++のが難しい
351:デフォルトの名無しさん
22/11/17 01:28:33.22 MDHZgFO+.net
C++ は未定義を踏むのがさすがに簡単すぎるのがいけない。
352:デフォルトの名無しさん
22/11/17 01:54:53.99 6uPAxih4.net
>>330
これを徹底すればC++も問題ないよ
353:デフォルトの名無しさん
22/11/17 03:15:48.27 Oh632irx.net
>>344
Rustは安全性と処理効率を保ったままさらに高みに登ろうとすると、C++では
可能だったことが不可能なことがある。
354:デフォルトの名無しさん
22/11/17 05:38:42.23 MvDxl/Xz.net
>>346
徹底するのが難しい、って話だろ
355:デフォルトの名無しさん
22/11/17 05:39:00.42 7vp/wPcJ.net
>>346
「〇〇を徹底します」みたいな精神論が再発防止にならないのは業界の常識
356:デフォルトの名無しさん
22/11/17 05:39:30.88 7vp/wPcJ.net
>>347
具体的にはどういうケース？
357:デフォルトの名無しさん
22/11/17 07:38:31.41 HsWuKvxv.net
>>350
大規模なマルチスレッドとかじゃない？
それこそ「共有メモリは排他制御を徹底すべし」ってだけの話だけど
数百万行のコードベース全体に対して常時気をつけ続けるというのは人間には無理だろう
358:デフォルトの名無しさん
22/11/17 07:44:38.30 EPum3E1i.net
>>351 マルチスレッドこそRustの得意分野だと思うんだけど
359:デフォルトの名無しさん
22/11/17 07:48:15.39 AvIWLuzY.net
rustは所有権とかライフタイムとかなければ簡単で使いやすそうって印象
360:デフォルトの名無しさん
22/11/17 07:53:43.04 HKu8SavS.net
所有権やライフタイムがいらないならrustである必要ないのでは
361:デフォルトの名無しさん
22/11/17 08:37:34.35 HsWuKvxv.net
>>352
あ、逆の話か
C++だと不可能なことがRustだと可能になるって読んでた
357のは思いつかんね
362:デフォルトの名無しさん
22/11/17 08:42:54.13 t8CddWfY.net
複雑なマルチスレッドのアプリで俺にしか直せないバグを故意に仕込むことならC++でしかできないかな
363:デフォルトの名無しさん
22/11/17 09:56:45.90 AvIWLuzY.net
>>354
プログラマが全知全能でメモリ関係のバグを踏まないって仮定したら所有権やライフタイムがなくてもrustはc++以上の優れた型システムを持ってる