Null安全性が入れば雑なスクリプト用としては使えるんだけどな
雑なスクリプト用途ならもっとシェアあって長続きしそうな競合が色々あるからなあ
Rustも意外に雑に手軽に書けるケースが多いと分かってきた
数値以外は先にスタック上に変数を用意（＝メモリ確保）してしまえば
後はその参照を使ってアクセスするだけで所有権もライフタイムも気にせず気楽にコーディングできるんだな
lifetimeや所有権よりshared xor mutableの方が煩わしいと感じる人は多そうに思う
>>12
Cだと可変ポインタだらけだからその感覚では書けないからねぇ
考え方から矯正しなきゃならんし面倒ではある スレッド内ならばCellが使えるから可変性も自由自在だよ
Cellは安全性・高速性・利便性を両立するRustの最重要パーツの一つ
Rust2っていつぐらいになりますか？今のままだと使いづらいです。。。
Cellを使わずにshared xor mutableに囚われて不自由なプログラミングしている初心者は意外と多いね
>>18
真に受けて複オジ2世が生まれないことを願ってる Cellの利便性を知らない初心者がいるのは直感に反するからだろう
Cellは可変参照なくても非可変参照だけで書き換えられるからな
Cellを使うデメリットはないの？
ないならデフォルトがCell相当になっててもよさそう
>>23
Cellのデメリットは唯一!Syncだけ
つまりスレッド内部でしか使えない 誤解のないように言えば
スレッドを使わずにシングルスレッドの状況でももちろんCellを使える
組み込みとかだとヒープの利用が難しいので自然とスタックメインになる
>>23
コンパイル時の検査を緩めるかわりに実行時に検査が入る。
借用規則に逆らえるわけではない。 >>27
Cellは実行時検査も無くコストゼロです
スレッド内なので借用規則に逆らえます CellはCopy traitが必要なので場合によってはとんでなくパフォーマンスが劣化する場合がある
単なる数値なら問題はないが
>>31
そんなことはない
Cell<T>のTは完全に自由でありCopy要件はない
Cellで数値だけでなくVecやString等も自由に使える
例外的に一部のメソッドはCopy要件を持つがそれはOption<T>等でも同じでありそのメソッド特定のみの話 >>31
Cell::takeやCell::replaceなど追加されたのでCopyを実装してない型でも使えるよ
StringやVecなどCopyできない型を扱う場合でも
元の値をtakeして更新後replaceするなどうまく書けばそれほど非効率にもならない CellやRefCellはshared xor mutableを知った上で適切に使った方が良いと思うので
初学者へ勧めるべきかというと微妙な気はするなあ
>>34
Cellは安全性が完全に保証される型
他の型と同様に万が一に間違った使い方をしたらコンパイルエラーとなり常に安全が保証される
初心者かどうかといった区別や考慮はそこに必要ない >>33
takeってデフォルト値に置き換えて所有権をもらうやつでしょ？
うーん、なんか気持ち悪さはあるんだよな >>33
Cellの更新はset()で十分だね
もちろんreplace()してoldを捨てるのと同じ
>>37
take()はdefault値とのreplace()と同じ
これは気持ち悪いことでも何でもなくて
例えばmutableなOption<T>を維持しながら扱う時と同じ操作
その場合もSome(T)からTを取り出す時にdefault値と入れ替えるtake()を使うよね
何かが入っていないと未定義になるからその身代わり
もちろんすぐに更新する場合は概念上だけの扱いとみなせるし
実際の生成コードでもdefault値が入るコードは最適化で消えちゃう
未定義状態を避けるための自然な操作と捉えてよいかと >>38
うーむ確かにそう言われるとむしろRust Wayな気がしてきた 不必要にCellを使ってみたくなるのはRust厨二病によくみられる症状
悪影響は少ないから温かく見守っておけばそのうち治るよ
まとめると実行時に値を書き換えたいオブジェクトにはCellを使う
書き込む場合はset
読み込む場合はtakeを使う
RefCellはオワコン
>>40
内部可変性を知らないのかな？
Cellは内部可変性を与えるものであり
& mutに縛られずにコーディングの自由度を上げるだけでなく
この内部可変性を使わないと記述できない場合もあるほど重要なもの スレッド間での共有ができないからその場合は内部可変性を避けないとコンパイルエラーとなっちゃう
しかし共有しないものならばいつでも安全に使うことが出来ます
不自由なプログラミングをしてまで内部可変性の利用を避ける必要はありません
そのような場合にはむしろ使うべき時ですよ
The Bookの内容も理解してないようだから厨二病というより厨一病だねぇ
>>45
The Bookでは
CellはSyncを実装していないからマルチスレッド間では使えないことしか書かれていない >>46
!Syncが許容される場面では常にCellを使うべきだと考えていますか？ >>47
常に？
そんな極端な主張を一度もしていない
他のものと同じで有用な時に使えばよい
そして有用な時が多い
それだけだ Cellは安全なだけでなく
実行コストもかからないし
データ設計の幅も広がるし
メリットだらけだよね
Cellを嫌ってる人って何かの病気なの？
数ある型の一つに過ぎないのに
Cell使わずにshared xor mutableの制限で苦しんでいる人は単なるバカ
CellとかRefCellってRustの本にも殆ど解説がないよな
ちょろっとおまけ程度にしかない
これなしでは現実的なプログラム書けないと思うのだが本の著者らはRustを理解してないんだろうか
>>54
書籍は見たことないから知らなかったけどそうなのか
自分が使っている著名なcratesのソースを見てみるとCellを使っているcrateも多い
だから普通に皆がCellを使っていてそこにタブーは無いようだ
まあ当たり前か Cellなしでは現実的なプログラム書けないというのは言い過ぎ
ある種のプログラムではCellが必要になるくらいが適当では
Cellが必須となるプログラムと
Cellが必須でないプログラムがあるだけだよな
まあこれも当たり前かｗ
Rustで日本が変わる！世界が変わる！
などとほざいてる人は自分では使っていないと思う。
使ってたら、ウーン、こりゃ使えんなあ・・・って言ってると思う。
Rustは今までに登場したプログラミング言語の中では一番使いやすく効率がいい程度だな
世界や日本がどうなろうとどうでもいいが
理解できない人たちとの不利有利の二極化は起こるだろう
>>55
The bookにはRefCellの解説はあるけどCellの解説がないんだよね
だからCellを使ってる人が少ないのかと思う 各crateのソース調べたらtokioもasync-stdもwasm-bindgenもCell使ってるな
別方面でtauriもyewもeguiもCell使ってるな
他にもproc macro用のsynとかCLI用のclapとか様々なcrateがCell使ってるな
この状況を見るとCellは普通に使って当然っぽい
>>38
それってCellから取り出した値がdefaultだった時の処理を書かないとならないんじゃないんですか？ >>54
Cellは扱いの小さい本が多いがRefCellはだいたいどの本でもしっかり解説されてるでしょ
オライリー本はCellも解説してる Cellはスレッドローカルの共有状態を管理する時に使う
カウンタとかフラグとか
shared mutability自体多用するもんじゃないからその辺をよく考えてね
>>54
Cの入門本の8割はmallocの使い方を説明してない どうせなら不変な部分を取り出せるようにしてすればよかったのにな。
参照カウントみたいなどこでも付いて回るのは厄介だけど。
>>63
ここの議論を見るとCellの解説を最初にやるべきだと思うのになぜRefCellばかりなのだろうという謎が
歴史的経緯みたいなやつか？
日本人の書いた本もRefCellばっかだよ カジュアルにCellを使って欲しくないからだよ
よく考えて使わないとバグのもとだから
必要な人向けにはリファレンスで詳しく解説してる
>>62
マルチスレッド間共有していないから
空っぽの時に知らぬ間にアクセスされることはないよ
だから大丈夫
そしてすぐに更新することで最適化される
あとはプログラムの組み立て方の話であって言語による管轄の話ではないね interior mutabilityを持ち所有権を自分が持たないケースは特殊だから説明した方がいいかもしれないが、
interior mutabilityを持ち所有権を自分が持つケースは普通の事だからわざわざ説明するまでもない。
write lockを取るからborrow checkが実行時に遅延されるのも説明しないといけないし。
Cellの使い方教えればRustユーザーも増えると思うな
所有権そのものより副作用を簡単には許さないところにハードルがあるから
>>70
実行時borrow checkされるのはRefCellだけ
Cellはborrow checkもlockも無くてゼロコスト カジュアルに使うならマルチスレッドでも使えるMutex使っておけばよいのではという気もするが
CellはCにおけるグローバル変数と同じで真に必要な時以外は極力避けるべきもの
ましてやRustの基本的考え方に慣れてないうちから使うべきものじゃない
>>73
そこは真逆
Mutexはlockのコストがかかる
Cellはコストがかからない
>>74
Cellはグローバル変数ではなくローカルにいくつも出現可能
そしてグローバル変数のような極力避けるべきものではない >>75
ロックのオーバーヘッドを気にする必要があるのはカジュアルに含まれません immutableなのがいいと言いつつ
mutやinterior mutabilityを結局使わせるダサさなｗ
>>76
Cell<T>ならスレッド内部専用の代わりにロックがなくてTと同じコストで使えるからオススメ immutableだけで書きたければそうすれば良いのでは
そのアプローチに窮屈さを感じる人が大半だからshared xor mutableという安全に使えるサブセットが生み出されたわけで
>>78
ただしマルチスレッド対応させようとすると書き換えが必要だし性能面に大きなこだわりがないなら最初からMutexにした方が良いのでは
Cell<T>はランタイムコスト面ではTと同じかもしれないけどコード記述は結局 途中で書き込んでしまった
コードの記述の面ではTとは異なるから同じ使い心地にはならないよね
>>80
それは君が勘違いをしている
Cellはマルチスレッドであってもスレッド内で使用することができる
Mutexを使うべき時はマルチスレッドのスレッド間で共有メモリとする時
排他制御のためMutexはコストが重い
したがって両者を互いに代用することは有り得ない よくわかんないんだけどMutex<Cell<T>>は有効なの？
>>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>>と二段に重ねる必要はない >>82
ランタイムコストが無視できる場合はMutexが使えるけどCellが使えないシチュエーションはないよね
カジュアル用途なら大は小を兼ねる的な意味でCellよりMutexの方が良いのでは？
Cellにすべき理由あるの？ >>86
一文目逆だった。MutexがCellを置き換えられない場合はないよね、と言いたかった >>86
話は非常にシンプル
スレッド間でメモリを共有するならばMutex (ただし排他コストがかかる)
共有しないならばCell (コストはかからない)
適切な方を選べばよい というかRustマジで良くできてんな
考え尽くされてるわ
要するに変数は全部Cellで囲っておけばいいんでしょ
>>88
スレッド間で共有しなくてもstatic変数だったらCell使えないのでMutexは単純にマルチスレッド用とも言えないのでは
よくわからない人向けにはMutexをまずは勧めるのが良いのでは Qt使おうかと考えているけど
バインディングライブラリのritualを勧めている人がいたけど
最後のコミットが去年でサポーターが心配なんだけど
結局Cのライブラリ読み込みや既存ライブラリの利用とかどれを使えばいいの？
>>91
それは基本的な理解ができていない
static変数はスレッド間で共有が可能なためその型はSync実装を必要とする
だからCellが使えないのは当たり前
スレッド間で共有する必要がないならば
スレッドローカルに持てばSync実装を必要としないためCellを使える
例えば
thread_local! {
static FOO: Cell<Vec<i32>> = Cell::new(Vec::new());
}
これでスレッド毎に持つことができる
もちろんスレッドを使わないシングルスレッドな状況でも使える Cellって基本的に値がムーブされるから構造体分はmemcpyが起きると思うんだけどそこはどうなの
RefCellやMutexなら直接参照取れるからそっちの方が効率的だよね
>>94
memcpyは起きない
Cellに関係なく一般的にムーブはあくまでもRustの言語レベルにおける概念的なもの
したがって生成コードでは無駄なメモリ間のムーブ(コピー)は起きずに最適化される
Cellの場合でも同様に最適化される
&Cell<T>に対してtake()してTを更新してset()するコードは
& mut Tに対してTを更新するコードと同じ生成コードとなる
例えばそれらの比較コード
https://godbolt.org/z/1TY9v33YP
完全に同じ生成コードとなっていることが分かる
つまりCell<T>はTと比較して実行時ゼロコストである RustコンパイラとLLVMは凄いなあ
いつでもそうだけど生成コードではがっちり最適化してくれる
抽象的に書いても安全に書いてもCと同じ速さ
おまえも隔離スレに帰れ！ちょっと前にLLVMだから凄い坊があそこで暴れてたけど、ここはgccrsとかやる人の場だ、市ね
パターンの代替策
つまり「|」記号が
bit演算のORとしてだけでなく
パターンのORとしても使われるよってこと
>>69
なるほど
マルチスレッドで共有する場合にはどうするのが適切なんでしょうか？ Linux Kernel6.1は、Rustへ移行した最初のバージョンとなります。
Rustへ移行することにより、C言語バージョンの世代から、およそ30%の高速化を果たしました。
気分はCelltic！
「実はshared xor mutableってしっくりこないんです！」
>>105
内部可変性を得たい場合
スレッド内ではCell<T>もしくは参照を持ち出したいならRefCell<T>を使う
スレッド内部で普通の共有ならばそれらの＆を使う (＆mutでなくてもOK)
スレッド内部で所有者が別となる共有ならばそれらのRc<...>を使う
スレッド間では完全排他のMutex<T>もしくはreaders複数可のRwLock<T>を使う
(ただしTがi32やboolならばもっと軽いAtomicI32やAtomicBoolが使える)
スレッド間で共有は所有者が別となるのでそれらのArc<...>を使う >>97
最適化頑張ってるだけでムーブは概念的なものじゃないぞ。RBMMなんだから。 moveがmemcpy呼び出しになるかどうかはあくまでも実装の話で
move自体のセマンティクスはデータのコピーを要求しないということが言いたいのでは
最適化offにして構造体サイズ大きくするとmemcpy呼び出されるから、memcpy起きないというのは嘘だけど
>>110
あくまでもRustの言語レベルでの抽象的なレベルではムーブはムーブであってビットコピーの保証はそこには一切ない
そして我々は抽象的な概念に基づいてプログラミングすればよい
生成コードはムーブという抽象的な概念だけを保証して最適化される
だからこそ生成コードではムーブでビットコピーが消え得る >>111
memcpyはたまたまムーブの最適化なしのデフォルト状態で行われる可能性のあるコードにすぎないね
Rustの言語としてはmemcpyが必ず行われることなんて全く保証しない
ムーブはもっと上位の概念であってRustが保証するのはその上位の概念のみだね >>113
はいはい、>>111は誤読されかねない表現でしたね
(常に)memcpy起きないというのは嘘
と読み替えておいてください
元々の>>94のRefCellやMutexの方が効率的かという質問については、そういう場合もある、というのが答えで良いですよね
生成されるコードがどうなるかは最適化レベルや周囲のコードに依存するわけで、必ずどちらかが効率が高いと言えるようなものではない
感覚的には格納するデータサイズが大きい方がRefCell/Mutexが有利に、小さければCellが有利になりそうだけど、
ちゃんと測定したわけではないので実際のところは分からない >>114
実はRefCell構造体のメンバーにCellが使われている(現状)
使用されるメモリサイズ
Cell<T> ← Tと同じサイズ
RefCell<T> ← Tのサイズに加えてborrow管理のために内部で使用するCellサイズ分加算
動作コスト
Cell<T> ← (利用後すぐset()すれば)Tと同じコスト
RefCell<T> ← Tのコストに加えてborrow管理のために内部で使用するCellの読み書き操作コスト分加算 >>114
RefCellやMutexの方が効率的かという質問については
代用として使うならばそれらの方が遅いでしょう
RefCellはボローチェック処理が必ず入ります
Mutexは排他的ロック処理が入るのでさらに遅いです >>115
動作コストはT全体を置き換える場合だよね
TがVecで、一要素追加する場合のコストも計算してみてよ
>>117
ボローチェック処理が最適化で消えないことは保証されてるの？
ボローチェックや排他処理のコストはCellで発生するデータコピーより必ず高コストになるの？ ムーブ元の変数が使われないことがわかってるんだから
その変数の領域を使い回せばよいだけでしょ？
普通に考えてコピーとか起きないと思うんだが
RefCell使うのはアロケーションを避けたいからでしょ
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が最適化でメモリに対して直接実行する命令コードにするだろうから読み出し書き込みも消えるわけね
CopyじゃないStringやVecで&mut selfとるメソッドを試せば違いが分かるよ
Copyを実装しない適当な構造体
#[derive(Default)]
struct Foo {
inner: i32,
}
の &Cell<Foo> と &mut i32 の両方のケースで
>>122の最適化により同じ生成コードとなるから
Copyを実装してるか否かは関係ないみたい >>124
それだと簡単にインライン化出来るからね
アロケーションが必要な型という意味でCopyじゃないStringやVecと言ったんだけど
Dropと言ったほうがよかったのかな アロケーション発生しなくても(i32, i32)とかにするだけでもう生成アセンブリ同じじゃなくなるね
コンパイラが>>122の
(2) メモリ←default-value書き込み
を削除する最適化をすれば
Copy実装なかろうがヒープを使おうが
生成コードは同じになるんじゃね？ >>126
Copyにしてget/setにすれば同じになるかも macOSにおけるFirefoxのパフォーマンスを劇的に改善した方法とは？
メモリアロケーター「jemalloc」を独自にカスタマイズしたアロケーターを用いてメモリ管理を行っています。Firefoxのアロケーターでは並列処理時のロックを効率的に行うためにOSごとにネイティブなAPIを使用しているとのこと。このロックAPIとして、macOSではOSSpinLockが用いられていました。
https://gigazine.net/news/20221011-firefox-macos/
これって、Rustのメモリアロケーターがjemallocを基にしたRust実装になってるってことだよね？大昔はjemallocだったという話で >>129
現在の Rust はデフォルトではシステム標準のアロケータを使うはず。
一時期は Jemalloc (のバインディング) を使っていたけどだいぶん前にやめてる。
やりたければアロケータの差し替えは簡単に出来るので
大きなプロジェクトだと (必要な性質にあわせて) 専用のアロケータを持っていることはあるかも。 >>129
この記事はrustまったく関係ないよ
Firefoxはすべてがrustで書かれているわけではない >>132
C++とのinteropあるからrust側はC++のallocator呼び出しているだけで
独自に(オリジナルの)jemallocをリンクすることはしてないと思うよ いや動的リンクはしてないのかな？jemallocソースをリプレースして実行ファイルに組み込んでる
>>127
コンパイラはそんなに賢くないってことじゃね？ おじさんなんで最近こっちにいるの？
隔離スレが機能しなくなったのとリンクしてるのが面白い
>>140
servoを構成するコンポーネントのうちfirefoxに取り込まれたstyloしか登場してないように見えるが お前の主張は「Firefoxはservo使ってない」であって「styloしか登場してない」では無い、そもそもstyloだけじゃない
途方もなく低い技術力でマウント取りたいことが生きがいの薄汚いオッサン
servoは独立したレンダリングエンジンだからservoを使うと言えるのはgeckoを丸々置き換えた場合では
というかallocatorの話はどうなったんだ
「Firefoxはservo使ってない」定期、顔真っ赤の話しそらしオジサン、geckoを丸々置き換えた場合とか言い出したｗ
「styloしか登場してない」も消えたwww
あんたはアロケーターなんて興味ないだろwww
したけりゃしろ。自分からは詳しい技術的な話何もできない、マウントしたいだけ、業界にいる寄生虫
>>134
firefoxのレンダリングエンジンはservoじゃなくてgeckoのままだよ
servoは次世代ブラウザ向けのレンダリングエンジンの実装を模索するための実験プロジェクトで、geckoを置き換えることを意図したものではないよ
servoの一部のコンポーネントは完成度が高くgeckoに取り込まれてはいたので、
servoが発展していったらgecko全体がservoで置き換えられる未来もありえたけど、
mozillaがservoの開発者レイオフしちゃったのでその可能性もなくなっちゃったかと
動的ライブラリや静的ライブラリとして他のアプリケーションにリンクするcrateの場合、リンク先のアプリケーションバイナリに含まれる(または、動的リンクされる)allocatorを利用するのが普通なので、
geckoのservo由来のrustコードもそうなっていて独自にallocatorを定義することはしていないんじゃないかな rust関係ないけどjemallocを日本語で読む時
ジェ-マロック派？それともジェム-アロック派？
Json Evans mallocだからジェーイーマロックって呼んでる
それを言うなら malloc が (たぶん) memory allocate の略なんだから
ジェーイーエムアロックと呼ぶのが筋というものでは……。
俺はそもそも口頭で読み上げる機会がないから考えたこともなかった。
開発者本人の動画見るとジェイ・マロックに聞こえるが
ジェイ・イー・マロックが短くなってるだけかなこれ
>>146
servoじゃなくてgeckoのままは言い過ぎです、現にベクター系の2Dや、Canvasなどに使用するレンダラーはservo由来の
レンダラーが使用されます。その他はその通りでしょう >>151
geckoを構成するコンポーネントの入れ替わりはあったけど
firefoxのレンダリングエンジンは生まれたときからずっとgeckoだよ
逆にgeckoじゃなかったら何なんだ しつこくやって『Cell<T>はTと同じコスト』(真っ赤な嘘)を流したかったんでしょw
termuxのrustずっとバージョン不整合で動かないな
rustupじゃそもそもインストール出来ない
>>157 俺は普通に動いてる
一応聞きたいんだけど､TermuxはF-Droidから入れたよね?
Play Store版はもうメンテナンスされてないから色々バグると思う >>158
F-Droidから入れてる
何故かlibllvm-14.soのリンクが出来ないと怒られてしまう
で入ってるllvmのバージョンが更新で15に上がってしまってる状態
俺環かも知れんね あんまり自信がある訳じゃないんだけど、カーネルが64bitでユーザーランドが32bitみたいな環境だったりしない？
>>159
Geckoのコンポーネントを置き換える
と
Geckoを置き換える
は全然意味が違うでしょ
まあ日本語の問題で意図してるところは食い違ってないから反応するのはこれで終わりにするわ >>158,161
すまぬ色々やってる中で入れたnightlyの影響だった
お騒がせした >>163
昔「おおっ！！！あのグーグルがまた何か新しいことを始めたぞ！すごそうだ！」
今「まぁーーたはじまったよ・・・」 Googleが立ち上げては潰してきたサービス一覧｢Killed by Google｣
killedbygoogle.com
役に立つかどうかわからんものに手を出せる余裕が
個別の結果に関わらず
部分的な成果の積み上げで会社をブーストさせるんよ
IoT向けOSって言ってるし組み込みOSなんて元々百花繚乱だろ。
組み込み機器の脆弱性対応なんて大変だし、そもそもその手の脆弱性が入り込みにくい言語を採用するのは合理的だと思う。
日本ってやらない理由、出来ない理由並べる奴が多いよな
多くの日本企業よりGoogleの方が多く生み出しているし世の役に立っている
南朝鮮ってやらない理由、出来ない理由並べる奴が多いよな 多くの南朝鮮企業よりGoogleの方が多く生み出しているし世の役に立っている
Rust Foundationへの参加はNECやFUJITSUよりSamsungの方が早いんじゃないかなぁ
国内大手で積極的にRustを推していこうなんて所はなさそうに見えるし
組み込みのRenesasとかもやる気なさそうだしな
日本が後進国になってきたのは政治の責任が大きいけど
IT分野で遅れてるのは総じて教育水準が低いからだよ
>>177
利権差配と中抜きしか考えない国賊を礼讃して
統一創価売国与党に投票し続けたやつの責任だろ まったく読むに値しないクソ書き込みの羅列の中で
>>170 だけが唯一価値ある輝きをはなっている 在日だらけ。IT分野で遅れてるのは米国（英語圏）・中国の人口差だし、日本の人口減でもある。
世界中で、歴史上、移民以外で人口減を解決した国は１つもない
そういう意味では韓国などはでは優れたソフトウエアは１つもない。馬鹿な半島はAndoridのOSを
握ろうとTizenなどというゴミを掲げたが、食いついたのはNTTドコモぐらい
いま韓国で起こってるのはソフトウエアサービスの””ガラパゴス化””であり、GoogleやAmazon
Apple Payなどに対して参入障壁を作り防御するような、大昔の古臭い日本あった不公正貿易。
民主党政権時代だって３年あったわけだが、利権と中抜きしかしてない。やったことは仕分けだが
１つも役に立たないどころか、地方医療を崩壊させ、気象変動へ対処できるインフラ投資を
一時的止めた害悪しかなかった。その他にも野田政権による執拗な消費税増税もあった。
今彼らは英国が減税を匂わせただけで大混乱していることを見ずに、消費税ゼロを掲げている。
卑劣にも矛先を反らし、リベラルなのに移民反対派で、リベラルなのに「国賊、売国」などという言葉を使い、
まるで戦争前夜か、共産主義や社会主義のような物言いをするアホが出る時点で若い人の人材不足といえる。
英国が減税しただけで、支持率が7% になったw
米国の金利上昇で、韓国の金利も0.5% 上がったw
なのに、借金が1千兆円もある日本の金利が、0%w
狂った世界中の経済学者達が、日本は不正をしている。
日本国債は破綻しなければおかしいと言ってるw
外人が幾ら日本国債を売っても、金利が上がらない。
破綻しないw
いい加減、借金が1千兆円もあるという財務省の嘘に気付け！w
YouTube で勉強しろ。
【TVじゃ絶対言えない話】国の借金は嘘！？中田敦彦が解説
WEB+DB PRESS、何度目のRust入門なんだい？
pythonとrustを一通り試してみた
for文の入れ子で外側のforをbreakできるとか、数値を1_000_000と表現できるとか、
そんなところでrustのほうが行き届いている感じがした
ただpythonのリスト内包表記、添え字の-1で配列の一番最後を表すとかそんなのは便利だな
Rust入門という感じではないな
Rustを使ったWeb入門という感じ
>>185
Web+DB Press読者は簡単なWebアプリ開発はいろんな言語で経験済みで理解しやすいだろうからチュートリアルの対象に選んだだけでは？ >>186
普段読まないけどRustなので買ってみた
なかなかわかりやすかった
基本文法の解説が明らかに足りないけど
サンプルを理解するだけならこの程度で良いのか
面倒な部分が表に出ないようにうまくサンプルを調整してるし 借用がどうGCに関係するのかよくわからない
うまく説明しているサイトはないですか?
まずスタックとヒープを理解せよ
これは口を酸っぱくして言ってる
でないとRustは理解できない
両方とも初心者には辛いよなあ
わかりやすい入門書が待たれる
借用するときにデータをスタックに積む
スコープを抜けるときに一気にpopするので
GCがいらない、つまり、早い
heapだとGCのときにデータの移動が必要になる
ので遅い
この理解であってる?
heapが遅いの要因は、メモリの割り当て解放処理があるから処理量が多いとか、
割り当てた領域がバラバラになることでキャッシュ効率がさがることとかかと
ページング処理みたいなのが、ヒープだと2重に行われるんじゃないの？
>>192
Rustでのその辺のメモリの動きはオライリー本に詳しく書いてあった気がするから読むべし >>192
そんなに物事が単純なら良かったのに...
”スコープを抜けるときにGCがいらない、つまり、早い”、これは間違いでもある。インライン展開されるような高階関数なら良いが
ループ中でアロケーションしてしまうような記述をすると、その度に確保・解放されるので非効率になりかねないし、借用による
メモリーの管理ではないが、参照カウントを使用するSwiftでは、ループでボトルネックになることはある。
このためRustでは高階関数で書く事が一般的に（分かり易く）良い事とされる。あとスタックでどの言語も大体はスコープ外で
消えるのでヒープとスタックの区別は付けましょう
独立したGCスレッドが動く言語だと、スコープ外れでGCするとは限らないので、速い場合がある。一方で、高負荷な環境では
GCスレッドがありで、回収などインターラプトが入るのでRustが有利になる（＝※こちらのほうがRustが重要視される理由）
いわゆるSTOP THE WORLD（DIO様風）だ。ただ、これが無ければ良いということではなく、循環参照などを作らなければ
問題ないという話で循環参照を作ってしまうのであれば、独立したGCスレッドは便利でもある
”GCのときにデータの移動が必要”になるかどうかは、GCのアルゴリズム次第であり、厳密には”データの移動が必要”になるのは
メモリーのフラグメント解消つまりコンパクション処理によるところが大きい。これは、近代的なOSでは似たような事を行っていて
これ自体が速度に大幅に影響を及ぼすとは言い難い >>198
> ループ中でアロケーションしてしまうような記述をすると
アホなコードで議論する必要あるの？ なんかすごい早口で支離滅裂なこと言ってるけど
頭を整理した方が良いよ
スコープを抜けるときにGCがいらない、つまり、早い
これが間違っている理由を教えてください
ヒープメモリの管理はそれなりに重い処理だというのが論旨のように見える。
GC を使った場合のように不要なオブジェクトの判別をしていくコストは Rust では生じないが
それを除けば空いてる箇所と使用中の箇所を上手いこと管理する実行時コストは
GC (に付随するメモリ割り当て) でやってるのとたぶんそんなに差はないんじゃね。
>>202
＞スコープを抜けるときにGCがいらない、つまり、早い
確保したメモリはいつ解放するんだよバカ。 文法で制約したら、書き手もコンパイラも
変数の寿命を厳密に特定することができて便利だろって事で、
どこにどう確保すると速いとか、そういう話とは別では
GCがないので速い←わかる
スコープを抜けたらpopするだけなので速い←わかる
スコープを抜けるときにGCがいらない←スコープとGCは何の関係もないよね
まあGCは常に動く可能性があるからな
逆に全く動かない可能性もある
そこはGCのアルゴリズムによりけり
スタックを使っているから
pop すればそのままメモリが解放されるという意味では?
何と何を比べて何が速いと思ってるのか整理しなよ
話はそれからだ
>>208
動的データ全部スタックに積むのか。すげーな。 そんなことよりコンパイルの遅さマジでテコ入れろYO、非力なCeleronでactix-webのコンパイルしたら10分とかふざけてんのか？
コンセプトがコンパイル遅くしても賢くするだから無理
依存ライブラリまで全部自前ビルドさせられてるわけだからな
コンパイル済みcrateの配布とかやってくれればなんとかなりそうではあるが
コンパイル高速化はユーザー側でもいろいろ工夫の余地はあるが
コア数多いマシンを使うのがいちばん効果がある
分散コンパイルか、差分コンパイルか、常にバックエンドでコンパイルか
ライブラリ類も複雑化・大型化の一途をたどっているご時世だし
Androidをビルド出来ないようなマシンは開発用としては時代遅れじゃね
環境負荷を下げるためにもTier1プラットフォームはビルド済みか半分ビルド済みを配布できるようにすべき
structのフィールドにasyncのクロージャ持たせるの面倒だな
>>220
Pin<Box<dyn Future<Output = T>>> ではだめ？ >>221
Box<dyn Fn() -> Pin<Box<dyn Future<Output = T>>>>
こんな感じ >>210
全部とは言っていないローカル変数だけだ >>223
GoだってJavaだってローカル変数はスタックを利用する。 >>224
Go は知らんが Java は値型しかスタックに確保しないよ
配列使うだけでヒープ使う んなこと言ったらRustだってBox使うだけでヒープ使われるだろ
>>226
そりゃあえてBox使えばヒープ使うわな
極論バカ乙w ヒープで思いついたけどtest::benchってなんで使用したメモリ量出てこないの？Rustだってアロケーター自作できるなら出せなくないと思うんだが
c言語なんかも int a[n] とかはスタックから取ってきてる。昔はmallocしてたが。
とはいえlinuxのスタック領域はヒープとそんな変わらん。
環境によるが、Rust のスレッドごとのスタックサイズのデフォルトが2MBとかで
バカでかいローカル変数や引数を使おうとすると、
簡単に実行時エラー／スタックオーバーフローを実現できるという
ちなみに、String はヒープを使う
C 以外の言語は、すべて浅いコピー・shallow copy でしょ。
実体はコピーされずに、参照だけがコピーされる
たぶん、ローカル変数も参照だけがスタックにあって、
実体はヒープにあるのでしょ
そもそもスクリプト言語はマシンスタック使ってないから
C/C++/Rust/Goみたいなコンパイル言語とスクリプト言語(PythonとかRuby)とではメモリモデルが全く違う
JVMのJITはVMスタックをマシンスタックに引き継ぐって処理をやってるけど
Box<T>って出現頻度の割に表記が長いよな
boxキーワードに変える案はどうなったんだ？
>>230
まーた思いつきで適当なこと言ってるの？ シャローコピーもディープコピーもプログラマに意識させるような言語の方がいいと思うけどなあ
C言語は低レベルすぎるからshallow copyやdeep copyを意識する必要がそもそもないしな
ポインタをそのまま複製するのがshallow copyでポインタをデリファレンスしてからその値を複製するのがdeep copyってだけやし
cだってポインタがネストされてたら順番に見てかないといけないのは他の言語と同じでしょ。
ネストを考慮しなくて良いならjavaだってcloneで一発コピーできる
>>241
> C言語は低レベルすぎるからshallow copyやdeep copyを意識する必要がそもそもないしな
むしろ意識しまくりだろ
shallow copyとかdeep Copyとかのおしゃれな名前では呼んでないけど あえていうならCにおいては構造体のメンバをそのまま代入するのがshallow copy
構造体のメンバのポインタの領域を新しく領域を確保してコピー元の構造体を再帰的にmemcpyするのがdeep cooy
deep copy は、ネストするから難しい
Ruby などは参照のリンクを断つために、
一旦、JSON などの文字列にしてから、オブジェクトを再構築したりする
Marshal もあるけど、色々な条件がつく。
IO, Proc, 特異メソッドが使えないとか
なんか話の脈絡も流れもなく各人が単語に反応して書きたいこと垂れ流すだけのスレと化してんな
JavaScriptっていつまでバンドルとかやるん？
wasmでそれやろうとしてるけど
wasmランタイムよりJavaScriptランタイムの方がまだ速いというトホホな状態
何いってんだ
JavaScriptはRustの大口顧客だぞ
バカにするなんてとんでもない
JavaScriptの市場が大きいほどRustが儲かる仕組みなんだ
moziraとgoogle, Microsoftと主要ブラウザメーカーが推進してるからな
なんでvecの&mutに*が不必要なのか、いまいち理解してなかったけど
fn calc(n: &mut Vec<usize>) {
(*n).push(1);
}
こういうことかー。そういうことだったのかー
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の}抜ける＝プログラム終了時ようやく解放？
rust導入してもディレクトリ構造が汚くなるだけなのにどうして導入したんだろうね
正直撤回して欲しいわ
ディレクトリ構造なんかより優先すべきことがあるからだろ
rust使う意味を何も分かってないな
もうlinusがカーネル用にsafeな言語作った方がいいんじゃないの
既成言語じゃ既存の処理系と整合性をとらないといけないから
いろいろな不整合が生じる
エコシステムの充実はユーザ規模によるところがあるから
たとえ言語の設計としてベストマッチでも特化しすぎると
(使い手が増えなくて) 雑多なツールやライブラリが出揃い難いということもありうる。
Linux くらいの規模なら専用言語を作っても割に合ったりするかな？
linusがなんか言ったの？
ググってもlinux 6.1にrustが取り込まれた話しか見つけられなかった
>>263
なにそのgitな流れは。
凄まじく少ないコードで実現してしまいそうで恐ろしい。
ピーキーなのになって、普通の人は使えないのを期待しちゃう。 >>263
linusはgcc拡張のCが最高だと思ってる人だよ linuxもデフォルトcというよりもかなりカーネル用の拡張してるからrustもそうすればええわってのが
linusの主張でしょ。
一応clangでもlinuxカーネルコンパイルできるようになっているということは、
LLVMに必要な機能はそろっているということだろうから、
rustcからそれらの機能を呼び出せるようにできれば良いのかね
リーナスゴシップとかどうでもいいスレチネタを続けるなよ
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となって、タプル以外の()撲滅できないか？
>>273
()を色々使いすぎというのは同意だけどRPNだと今よりもっと使われないよ。
連鎖性言語とか好きだけど。 ()については他の言語と同じだしそこで変に独自性を出してもなぁという感じ
for &i in vec![0_usize; 5].iter() {
//iのままなんちゃら
}
for i in vec![0_usize; 5].iter() {
//*iでなんちゃら
}
参照外しはどっちをつかってる人のほうが一般的なん？
union で定義した型があり、タグビットに相当するビットで variant を区別できる場合に
enum と同じ表現でパターンマッチするというようなことは出来ませんかね？
マニュアルを見た感じでは出来なさそうなので駄目で元々な相談なんですが……。
それが欲しくなった事情としては抽象的なバイトコードマシンが定義されていて
そのバイトコードをそのまま enum にマッピングできれば楽なのになと思った次第です。
.expect("なんとかかんとかfailed.");
expectの引数はこんな文章になりがち
.expect("なんとかexpected, but かんとか found");
ならまだいいけど
コード読むときexpectというメソッド名からその引数には"期待しているものの説明"を"期待"してしまう
慣れるんだろうか…
.expect("もう少しぶっといイチモツを用意すべきです")
expectがそもそも期待するという意味より、予想するという意味合いで使われてることが多い気がする
お、Backtraceがstabilizeされたか
めでたい
むしろ政治的な要素が少しでもあると過敏反応する日本IT連中のがキモいわ
過剰反応というかツイッターでも左翼のトレンド操作がバレてしまったし
そういう必死な印象操作する奴らに全く反応しないのも正常性バイアスなだけで危険だと思うけどね
別に操作でもなんでもなく前から人が選んでるって言ってたじゃん。
だからそういうのを過剰反応って言うんだよ。
>>301
ナイーブなやっちゃなぁ
どの国でも底辺ほど極右化しちゃうのは物事が見えてないからなんやな >>302
トレンドはどのように決定されますか？
トレンドはアルゴリズムによって決定され、初期設定では、フォローしているアカウント、興味関心、位置情報をもとにカスタマイズされています。
こういうAI系にRustが使われる可能性ありそうかな？ >>305
コア部分がC++、FortranからRustに変わるとかはありそう >>304
それもまたナイーブな見方やなぁ
反自民党なら左、親自民党なら右やと思ってるんやろ？ >>306
rustのGPU周りのツールチェインは整備進んでるの？ 
