2ちゃんねる ■掲示板に戻る■ 全部 1- 最新50    

■ このスレッドは過去ログ倉庫に格納されています

Rust part17

1 :デフォルトの名無しさん:2022/10/06(木) 22:43:13.96 ID:Re0G7B20.net
公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※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 part16

2 :デフォルトの名無しさん:2022/10/06(木) 22:43:37.18 ID:Re0G7B20.net
Rust The Book (日本語版)
https://doc.rust-jp.rs/book-ja/
Rust edition guide (日本語版)
https://doc.rust-jp.rs/edition-guide/
Rust by example (日本語版)
https://doc.rust-jp.rs/rust-by-example-ja/
Rust cookbook (日本語版)
https://uma0317.github.io/rust-cookbook-ja/
Rust API guideline (日本語版)
https://sinkuu.github.io/api-guidelines/
Rust nomicon book (日本語版)
https://doc.rust-jp.rs/rust-nomicon-ja/
Rust async book (日本語版)
https://async-book-ja.netlify.app/
Rust WASM book (日本語版)
https://moshg.github.io/rustwasm-book-ja/
Rust embeded book (日本語版)
https://tomoyuki-nakabayashi.github.io/book/
Rust enbeded discovery (日本語版)
https://tomoyuki-nakabayashi.github.io/discovery/
Rust Design Patterns (日本語版)
https://qiita.com/Yappii_111/items/4ccc3a8461cdd4035651
https://qiita.com/Yappii_111/items/654717e6a6a980722189
Rust API guideline (日本語版)
https://sinkuu.github.io/api-guidelines/

3 :デフォルトの名無しさん:2022/10/06(木) 22:43:46.54 ID:Re0G7B20.net
Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/book/
Rust macro Book
https://danielkeep.github.io/tlborm/book/
Rust Future Book
https://cfsamson.github.io/books-futures-explained/
Rust async-std Book
https://book.async.rs/
Rust tokio Book
https://tokio.rs/tokio/tutorial
Rust rustc Book
https://doc.rust-lang.org/rustc/
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/

4 :デフォルトの名無しさん:2022/10/06(木) 22:43:58.88 ID:Re0G7B20.net
☆WebAssembly(WASM) https://webassembly.org/ https://ja.m.wikipedia.org/wiki/WebAssembly
・Wasmer - The Universal WebAssembly Runtime https://wasmer.io/
-> WASI(WebAssembly System Interface)とEmscriptenに準拠したWASMを実行できるランタイム
・WAPM - WebAssembly Package Manager https://wapm.io/
-> WebAssembly製ツール/ライブラリのパッケージマネージャー
☆Rust
・wasm-pack - your favorite rust -> wasm workflow tool!
https://github.com/rustwasm/wasm-pack
-> WebAssemblyのrustcコンパイルサポート
・Yew - Rust / Wasm framework for building client web apps https://yew.rs/ja/
-> WebAssembly によってマルチスレッドな Web アプリのフロントエンドを作ることができる、モダンな Rust のフレームワーク
☆最近のWebAssemblyのニュース
・Publickey - Enterprise IT × Cloud Computing × Web Technology / Blog より https://www.publickey1.jp/programming-lang/webassembly/
・WebAssembly活用プロジェクト https://madewithwebassembly.com/
・WebAssemblyが気になるので調べてみた - Qiita https://qiita.com/t_katsumura/items/ff379aaaba6931aad1c4
・WASMとRustはVue.js/React.jsを打倒するのか? - JSへの侵略の歴史 https://zenn.dev/koduki/articles/c07db4179bb7b86086a1
・Typescriptの次はRustかもしれない https://zenn.dev/akfm/articles/81713d4c1275ac64a75c
・WebAssemblyはJVMやeBPFのリバイバルではない WasmがWeb以外でもアツい理由 - ログミーTech https://logmi.jp/tech/articles/324956
・Rust GUI の決定版! Tauri を使ってクロスプラットフォームなデスクトップアプリを作ろう https://zenn.dev/kumassy/books/6e518fe09a86b2
類似スレ
【wasm】ブラウザでC++。Emscriptenを語ろう https://mevius.5ch.net/test/read.cgi/tech/1547549448/

5 :デフォルトの名無しさん:2022/10/06(木) 22:44:37.34 ID:Re0G7B20.net
>>1
前スレのurlはれてなったよぉ…
Rust part16
http://mevius.5ch.net/test/read.cgi/tech/1656285423/

6 :デフォルトの名無しさん:2022/10/07(金) 01:27:41.85 ID:YCt9Quz7.net
>>1
おつ

7 :デフォルトの名無しさん:2022/10/07(金) 11:28:42.39 ID:d4ub3t4L.net
>>1
O2

Nim に浮気中

8 :デフォルトの名無しさん:2022/10/07(金) 12:26:19.13 ID:+0mlf9Ez.net
Null安全でないGC言語のNimに浮気する人

9 :デフォルトの名無しさん:2022/10/07(金) 12:31:49.01 ID:7pvxFIpA.net
Null安全性が入れば雑なスクリプト用としては使えるんだけどな

10 :デフォルトの名無しさん:2022/10/07(金) 13:04:35.78 ID:KVLYaA/l.net
雑なスクリプト用途ならもっとシェアあって長続きしそうな競合が色々あるからなあ

11 :デフォルトの名無しさん:2022/10/07(金) 13:36:57.50 ID:yqDZzsii.net
Rustも意外に雑に手軽に書けるケースが多いと分かってきた
数値以外は先にスタック上に変数を用意(=メモリ確保)してしまえば
後はその参照を使ってアクセスするだけで所有権もライフタイムも気にせず気楽にコーディングできるんだな

12 :デフォルトの名無しさん:2022/10/07(金) 15:04:20.94 ID:xg0qXK5h.net
lifetimeや所有権よりshared xor mutableの方が煩わしいと感じる人は多そうに思う

13 :デフォルトの名無しさん:[ここ壊れてます] .net
僕はヌルヌルおまんこは好きですね

14 :デフォルトの名無しさん:[ここ壊れてます] .net
>>12
Cだと可変ポインタだらけだからその感覚では書けないからねぇ
考え方から矯正しなきゃならんし面倒ではある

15 :デフォルトの名無しさん:[ここ壊れてます] .net
スレッド内ならばCellが使えるから可変性も自由自在だよ

16 :デフォルトの名無しさん:[ここ壊れてます] .net
Cellを使ったら負け

17 :デフォルトの名無しさん:[ここ壊れてます] .net
Cellは安全性・高速性・利便性を両立するRustの最重要パーツの一つ

18 :デフォルトの名無しさん:[ここ壊れてます] .net
だんだんトンデモスレになってきてるね

19 :デフォルトの名無しさん:[ここ壊れてます] .net
Rust2っていつぐらいになりますか?今のままだと使いづらいです。。。

20 :デフォルトの名無しさん:[ここ壊れてます] .net
Cellを使わずにshared xor mutableに囚われて不自由なプログラミングしている初心者は意外と多いね

21 :デフォルトの名無しさん:[ここ壊れてます] .net
>>18
真に受けて複オジ2世が生まれないことを願ってる

22 :デフォルトの名無しさん:[ここ壊れてます] .net
Cellの利便性を知らない初心者がいるのは直感に反するからだろう
Cellは可変参照なくても非可変参照だけで書き換えられるからな

23 :デフォルトの名無しさん:[ここ壊れてます] .net
Cellを使うデメリットはないの?
ないならデフォルトがCell相当になっててもよさそう

24 :デフォルトの名無しさん:[ここ壊れてます] .net
>>23
Cellのデメリットは唯一!Syncだけ
つまりスレッド内部でしか使えない

25 :デフォルトの名無しさん:[ここ壊れてます] .net
誤解のないように言えば
スレッドを使わずにシングルスレッドの状況でももちろんCellを使える

26 :デフォルトの名無しさん:[ここ壊れてます] .net
組み込みとかだとヒープの利用が難しいので自然とスタックメインになる

27 :はちみつ餃子 ◆8X2XSCHEME :[ここ壊れてます] .net
>>23
コンパイル時の検査を緩めるかわりに実行時に検査が入る。
借用規則に逆らえるわけではない。

28 :デフォルトの名無しさん:[ここ壊れてます] .net
>>27
それはRefCellでは

29 :デフォルトの名無しさん:[ここ壊れてます] .net
>>27
Cellは実行時検査も無くコストゼロです
スレッド内なので借用規則に逆らえます

30 :はちみつ餃子 :2022/10/07(金) 18:21:14.63 ID:uxbzrjvk.net
そっかー。

31 :デフォルトの名無しさん:[ここ壊れてます] .net
CellはCopy traitが必要なので場合によってはとんでなくパフォーマンスが劣化する場合がある

単なる数値なら問題はないが

32 :デフォルトの名無しさん:2022/10/07(金) 19:45:02.34 ID:Znh4X5V+.net
>>31
そんなことはない
Cell<T>のTは完全に自由でありCopy要件はない
Cellで数値だけでなくVecやString等も自由に使える
例外的に一部のメソッドはCopy要件を持つがそれはOption<T>等でも同じでありそのメソッド特定のみの話

33 :デフォルトの名無しさん:2022/10/07(金) 19:48:12.01 ID:xg0qXK5h.net
>>31
Cell::takeやCell::replaceなど追加されたのでCopyを実装してない型でも使えるよ
StringやVecなどCopyできない型を扱う場合でも
元の値をtakeして更新後replaceするなどうまく書けばそれほど非効率にもならない

34 :デフォルトの名無しさん:2022/10/07(金) 19:52:07.74 ID:xg0qXK5h.net
CellやRefCellはshared xor mutableを知った上で適切に使った方が良いと思うので
初学者へ勧めるべきかというと微妙な気はするなあ

35 :デフォルトの名無しさん:2022/10/07(金) 19:58:58.94 ID:Znh4X5V+.net
>>34
Cellは安全性が完全に保証される型
他の型と同様に万が一に間違った使い方をしたらコンパイルエラーとなり常に安全が保証される
初心者かどうかといった区別や考慮はそこに必要ない

36 :デフォルトの名無しさん:2022/10/07(金) 20:08:27.14 ID:YCt9Quz7.net
何がしたいの?

37 :デフォルトの名無しさん:2022/10/07(金) 20:16:39.71 ID:CNFz94QB.net
>>33
takeってデフォルト値に置き換えて所有権をもらうやつでしょ?
うーん、なんか気持ち悪さはあるんだよな

38 :デフォルトの名無しさん:2022/10/07(金) 20:49:01.57 ID:3/fEI9MA.net
>>33
Cellの更新はset()で十分だね
もちろんreplace()してoldを捨てるのと同じ

>>37
take()はdefault値とのreplace()と同じ
これは気持ち悪いことでも何でもなくて
例えばmutableなOption<T>を維持しながら扱う時と同じ操作
その場合もSome(T)からTを取り出す時にdefault値と入れ替えるtake()を使うよね
何かが入っていないと未定義になるからその身代わり
もちろんすぐに更新する場合は概念上だけの扱いとみなせるし
実際の生成コードでもdefault値が入るコードは最適化で消えちゃう
未定義状態を避けるための自然な操作と捉えてよいかと

39 :デフォルトの名無しさん:2022/10/07(金) 21:02:50.21 ID:CNFz94QB.net
>>38
うーむ確かにそう言われるとむしろRust Wayな気がしてきた

40 :デフォルトの名無しさん:2022/10/07(金) 21:12:11.57 ID:4RElSAp/.net
不必要にCellを使ってみたくなるのはRust厨二病によくみられる症状
悪影響は少ないから温かく見守っておけばそのうち治るよ

41 :デフォルトの名無しさん:[ここ壊れてます] .net
まとめると実行時に値を書き換えたいオブジェクトにはCellを使う
書き込む場合はset
読み込む場合はtakeを使う

RefCellはオワコン

42 :デフォルトの名無しさん:2022/10/07(金) 21:30:00.49 ID:Znh4X5V+.net
>>40
内部可変性を知らないのかな?
Cellは内部可変性を与えるものであり
& mutに縛られずにコーディングの自由度を上げるだけでなく
この内部可変性を使わないと記述できない場合もあるほど重要なもの

43 :デフォルトの名無しさん:2022/10/07(金) 22:49:11.13 ID:xg0qXK5h.net
> inherited mutability is preferred, and interior mutability is something of a last resort.
内部可変性は必要な時だけつかうべき
https://doc.rust-lang.org/std/cell/

44 :デフォルトの名無しさん:2022/10/07(金) 23:05:27.46 ID:3/fEI9MA.net
スレッド間での共有ができないからその場合は内部可変性を避けないとコンパイルエラーとなっちゃう
しかし共有しないものならばいつでも安全に使うことが出来ます
不自由なプログラミングをしてまで内部可変性の利用を避ける必要はありません
そのような場合にはむしろ使うべき時ですよ

45 :デフォルトの名無しさん:2022/10/07(金) 23:15:28.30 ID:GE9TWYxP.net
The Bookの内容も理解してないようだから厨二病というより厨一病だねぇ

46 :デフォルトの名無しさん:2022/10/07(金) 23:27:40.94 ID:Znh4X5V+.net
>>45
The Bookでは
CellはSyncを実装していないからマルチスレッド間では使えないことしか書かれていない

47 :デフォルトの名無しさん:2022/10/07(金) 23:41:21.31 ID:xg0qXK5h.net
>>46
!Syncが許容される場面では常にCellを使うべきだと考えていますか?

48 :デフォルトの名無しさん:2022/10/07(金) 23:44:26.62 ID:Znh4X5V+.net
>>47
常に?
そんな極端な主張を一度もしていない
他のものと同じで有用な時に使えばよい
そして有用な時が多い
それだけだ

49 :デフォルトの名無しさん:2022/10/07(金) 23:59:28.46 ID:v90MyUH0.net
Cellは安全なだけでなく
実行コストもかからないし
データ設計の幅も広がるし
メリットだらけだよね

50 :デフォルトの名無しさん:2022/10/08(土) 00:00:53.53 ID:74M5kg9b.net
後で読むからブログにでもまとめといて

51 :デフォルトの名無しさん:2022/10/08(土) 00:05:55.63 ID:PJN/h6/8.net
Cellを嫌ってる人って何かの病気なの?
数ある型の一つに過ぎないのに

52 :デフォルトの名無しさん:2022/10/08(土) 00:09:24.75 ID:STUNJ/8C.net
Rustレスバトル会場
https://mevius.5ch.net/test/read.cgi/tech/1657382429/

53 :デフォルトの名無しさん:2022/10/08(土) 00:21:36.43 ID:iVJbbbtq.net
Cell使わずにshared xor mutableの制限で苦しんでいる人は単なるバカ

54 :デフォルトの名無しさん:2022/10/08(土) 00:35:12.49 ID:D3DCz8sQ.net
CellとかRefCellってRustの本にも殆ど解説がないよな
ちょろっとおまけ程度にしかない
これなしでは現実的なプログラム書けないと思うのだが本の著者らはRustを理解してないんだろうか

55 :デフォルトの名無しさん:2022/10/08(土) 00:52:04.60 ID:2tIWkITu.net
>>54
書籍は見たことないから知らなかったけどそうなのか
自分が使っている著名なcratesのソースを見てみるとCellを使っているcrateも多い
だから普通に皆がCellを使っていてそこにタブーは無いようだ
まあ当たり前か

56 :デフォルトの名無しさん:2022/10/08(土) 00:58:18.16 ID:QzbKhEyQ.net
Cellなしでは現実的なプログラム書けないというのは言い過ぎ
ある種のプログラムではCellが必要になるくらいが適当では

57 :デフォルトの名無しさん:2022/10/08(土) 01:04:15.77 ID:2tIWkITu.net
Cellが必須となるプログラムと
Cellが必須でないプログラムがあるだけだよな
まあこれも当たり前かw

58 :デフォルトの名無しさん:2022/10/08(土) 01:12:26.49 ID:M3iYd9Ol.net
Rustで日本が変わる!世界が変わる!
などとほざいてる人は自分では使っていないと思う。
使ってたら、ウーン、こりゃ使えんなあ・・・って言ってると思う。

59 :デフォルトの名無しさん:2022/10/08(土) 01:34:11.88 ID:2tIWkITu.net
Rustは今までに登場したプログラミング言語の中では一番使いやすく効率がいい程度だな
世界や日本がどうなろうとどうでもいいが
理解できない人たちとの不利有利の二極化は起こるだろう

60 :デフォルトの名無しさん:2022/10/08(土) 03:41:06.69 ID:D3DCz8sQ.net
>>55
The bookにはRefCellの解説はあるけどCellの解説がないんだよね
だからCellを使ってる人が少ないのかと思う

61 :デフォルトの名無しさん:[ここ壊れてます] .net
各crateのソース調べたらtokioもasync-stdもwasm-bindgenもCell使ってるな
別方面でtauriもyewもeguiもCell使ってるな
他にもproc macro用のsynとかCLI用のclapとか様々なcrateがCell使ってるな
この状況を見るとCellは普通に使って当然っぽい

62 :デフォルトの名無しさん:2022/10/08(土) 10:23:03.05 ID:2effy6oa.net
>>38
それってCellから取り出した値がdefaultだった時の処理を書かないとならないんじゃないんですか?

63 :デフォルトの名無しさん:2022/10/08(土) 10:55:13.71 ID:/5aPtbi3.net
>>54
Cellは扱いの小さい本が多いがRefCellはだいたいどの本でもしっかり解説されてるでしょ

オライリー本はCellも解説してる

64 :デフォルトの名無しさん:2022/10/08(土) 10:59:24.30 ID:HCP3bqwV.net
Cellはスレッドローカルの共有状態を管理する時に使う
カウンタとかフラグとか

shared mutability自体多用するもんじゃないからその辺をよく考えてね

65 :デフォルトの名無しさん:2022/10/08(土) 10:59:37.80 ID:kYZ69ulT.net
>>54
Cの入門本の8割はmallocの使い方を説明してない

66 :デフォルトの名無しさん:2022/10/08(土) 13:18:33.57 ID:HbWzH6SV.net
どうせなら不変な部分を取り出せるようにしてすればよかったのにな。
参照カウントみたいなどこでも付いて回るのは厄介だけど。

67 :デフォルトの名無しさん:2022/10/08(土) 13:48:31.81 ID:D3DCz8sQ.net
>>63
ここの議論を見るとCellの解説を最初にやるべきだと思うのになぜRefCellばかりなのだろうという謎が
歴史的経緯みたいなやつか?
日本人の書いた本もRefCellばっかだよ

68 :デフォルトの名無しさん:2022/10/08(土) 14:04:15.39 ID:cMY3Tlwa.net
カジュアルにCellを使って欲しくないからだよ
よく考えて使わないとバグのもとだから
必要な人向けにはリファレンスで詳しく解説してる

69 :デフォルトの名無しさん:2022/10/08(土) 18:26:38.20 ID:r98Hfriq.net
>>62
マルチスレッド間共有していないから
空っぽの時に知らぬ間にアクセスされることはないよ
だから大丈夫
そしてすぐに更新することで最適化される
あとはプログラムの組み立て方の話であって言語による管轄の話ではないね

70 :デフォルトの名無しさん:2022/10/08(土) 19:07:57.58 ID:vMI7I1P7.net
interior mutabilityを持ち所有権を自分が持たないケースは特殊だから説明した方がいいかもしれないが、
interior mutabilityを持ち所有権を自分が持つケースは普通の事だからわざわざ説明するまでもない。

write lockを取るからborrow checkが実行時に遅延されるのも説明しないといけないし。

71 :デフォルトの名無しさん:2022/10/08(土) 19:14:27.64 ID:N7i/LeD2.net
Cellの使い方教えればRustユーザーも増えると思うな
所有権そのものより副作用を簡単には許さないところにハードルがあるから

72 :デフォルトの名無しさん:2022/10/08(土) 19:30:29.77 ID:Xn47a3bW.net
>>70
実行時borrow checkされるのはRefCellだけ
Cellはborrow checkもlockも無くてゼロコスト

73 :デフォルトの名無しさん:2022/10/08(土) 20:24:05.46 ID:QzbKhEyQ.net
カジュアルに使うならマルチスレッドでも使えるMutex使っておけばよいのではという気もするが

74 :デフォルトの名無しさん:2022/10/08(土) 21:19:30.79 ID:BDP0djZ+.net
CellはCにおけるグローバル変数と同じで真に必要な時以外は極力避けるべきもの
ましてやRustの基本的考え方に慣れてないうちから使うべきものじゃない

75 :デフォルトの名無しさん:2022/10/08(土) 22:01:30.85 ID:LnEoG2Yz.net
>>73
そこは真逆
Mutexはlockのコストがかかる
Cellはコストがかからない

>>74
Cellはグローバル変数ではなくローカルにいくつも出現可能
そしてグローバル変数のような極力避けるべきものではない

76 :デフォルトの名無しさん:2022/10/08(土) 22:04:07.45 ID:QzbKhEyQ.net
>>75
ロックのオーバーヘッドを気にする必要があるのはカジュアルに含まれません

77 :デフォルトの名無しさん:2022/10/08(土) 22:06:04.90 ID:aSXXl0gc.net
immutableなのがいいと言いつつ
mutやinterior mutabilityを結局使わせるダサさなw

78 :デフォルトの名無しさん:2022/10/08(土) 22:39:37.88 ID:K1piK/7g.net
>>76
Cell<T>ならスレッド内部専用の代わりにロックがなくてTと同じコストで使えるからオススメ

79 :デフォルトの名無しさん:2022/10/08(土) 22:40:45.08 ID:QzbKhEyQ.net
immutableだけで書きたければそうすれば良いのでは
そのアプローチに窮屈さを感じる人が大半だからshared xor mutableという安全に使えるサブセットが生み出されたわけで

80 :デフォルトの名無しさん:2022/10/08(土) 22:42:33.20 ID:QzbKhEyQ.net
>>78
ただしマルチスレッド対応させようとすると書き換えが必要だし性能面に大きなこだわりがないなら最初からMutexにした方が良いのでは
Cell<T>はランタイムコスト面ではTと同じかもしれないけどコード記述は結局

81 :デフォルトの名無しさん:2022/10/08(土) 22:43:05.48 ID:QzbKhEyQ.net
途中で書き込んでしまった

コードの記述の面ではTとは異なるから同じ使い心地にはならないよね

82 :デフォルトの名無しさん:2022/10/08(土) 22:53:58.00 ID:IDy6SwOh.net
>>80
それは君が勘違いをしている
Cellはマルチスレッドであってもスレッド内で使用することができる
Mutexを使うべき時はマルチスレッドのスレッド間で共有メモリとする時
排他制御のためMutexはコストが重い
したがって両者を互いに代用することは有り得ない

83 :デフォルトの名無しさん:[ここ壊れてます] .net
よくわかんないんだけどMutex<Cell<T>>は有効なの?

84 :デフォルトの名無しさん:2022/10/09(日) 01:31:18.81 ID: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>>と二段に重ねる必要はない

85 :デフォルトの名無しさん:2022/10/09(日) 01:46:07.36 ID:NMoxe/se.net
>>84
なるほどー
めちゃくちゃ勉強になる

86 :デフォルトの名無しさん:2022/10/09(日) 01:48:31.99 ID:2Hsnp4rW.net
>>82
ランタイムコストが無視できる場合はMutexが使えるけどCellが使えないシチュエーションはないよね
カジュアル用途なら大は小を兼ねる的な意味でCellよりMutexの方が良いのでは?
Cellにすべき理由あるの?

87 :デフォルトの名無しさん:2022/10/09(日) 01:49:26.64 ID:2Hsnp4rW.net
>>86
一文目逆だった。MutexがCellを置き換えられない場合はないよね、と言いたかった

88 :デフォルトの名無しさん:2022/10/09(日) 01:53:55.32 ID:LqCUQ5jH.net
>>86
話は非常にシンプル
スレッド間でメモリを共有するならばMutex (ただし排他コストがかかる)
共有しないならばCell (コストはかからない)
適切な方を選べばよい

89 :デフォルトの名無しさん:2022/10/09(日) 02:00:16.80 ID:NMoxe/se.net
というかRustマジで良くできてんな
考え尽くされてるわ

90 :デフォルトの名無しさん:2022/10/09(日) 02:01:56.84 ID:Z8ziuvVg.net
要するに変数は全部Cellで囲っておけばいいんでしょ

91 :デフォルトの名無しさん:2022/10/09(日) 02:08:28.77 ID:2Hsnp4rW.net
>>88
スレッド間で共有しなくてもstatic変数だったらCell使えないのでMutexは単純にマルチスレッド用とも言えないのでは
よくわからない人向けにはMutexをまずは勧めるのが良いのでは

92 :デフォルトの名無しさん:2022/10/09(日) 02:24:40.07 ID:zCVUy+MP.net
Qt使おうかと考えているけど
バインディングライブラリのritualを勧めている人がいたけど
最後のコミットが去年でサポーターが心配なんだけど
結局Cのライブラリ読み込みや既存ライブラリの利用とかどれを使えばいいの?

93 :デフォルトの名無しさん:2022/10/09(日) 03:05:30.55 ID:LqCUQ5jH.net
>>91
それは基本的な理解ができていない
static変数はスレッド間で共有が可能なためその型はSync実装を必要とする
だからCellが使えないのは当たり前

スレッド間で共有する必要がないならば
スレッドローカルに持てばSync実装を必要としないためCellを使える
例えば
thread_local! {
 static FOO: Cell<Vec<i32>> = Cell::new(Vec::new());
}
これでスレッド毎に持つことができる
もちろんスレッドを使わないシングルスレッドな状況でも使える

94 :デフォルトの名無しさん:2022/10/09(日) 04:37:34.70 ID:8tdOWvz3.net
Cellって基本的に値がムーブされるから構造体分はmemcpyが起きると思うんだけどそこはどうなの
RefCellやMutexなら直接参照取れるからそっちの方が効率的だよね

95 :デフォルトの名無しさん:2022/10/09(日) 04:57:14.58 ID:95mox/4o.net
複オジの嘘に騙される前には少しは頭使え

96 :デフォルトの名無しさん:2022/10/09(日) 05:51:16.25 ID:md7RXs4/.net
隔離スレに帰れ

97 :デフォルトの名無しさん:2022/10/09(日) 05:51:33.43 ID:LqCUQ5jH.net
>>94
memcpyは起きない
Cellに関係なく一般的にムーブはあくまでもRustの言語レベルにおける概念的なもの
したがって生成コードでは無駄なメモリ間のムーブ(コピー)は起きずに最適化される

Cellの場合でも同様に最適化される
&Cell<T>に対してtake()してTを更新してset()するコードは
& mut Tに対してTを更新するコードと同じ生成コードとなる

例えばそれらの比較コード
https://godbolt.org/z/1TY9v33YP
完全に同じ生成コードとなっていることが分かる
つまりCell<T>はTと比較して実行時ゼロコストである

98 :デフォルトの名無しさん:2022/10/09(日) 07:01:12.90 ID:vVo7+K5Y.net
RustコンパイラとLLVMは凄いなあ
いつでもそうだけど生成コードではがっちり最適化してくれる
抽象的に書いても安全に書いてもCと同じ速さ

99 :デフォルトの名無しさん:2022/10/09(日) 11:45:38.50 ID:kycCKtGO.net
おまえも隔離スレに帰れ!ちょっと前にLLVMだから凄い坊があそこで暴れてたけど、ここはgccrsとかやる人の場だ、市ね

100 :デフォルトの名無しさん:2022/10/09(日) 13:36:44.30 ID:1+WY+ral.net
gccrsって使えるようになったの?

101 :デフォルトの名無しさん:2022/10/09(日) 20:46:00.69 ID:yOxuO3a2.net
Linux6.1ってRustで組んだってこと?

102 :デフォルトの名無しさん:[ここ壊れてます] .net
ドライバ等をRustでも書けるようになるだけ

103 :デフォルトの名無しさん:2022/10/09(日) 23:29:48.75 ID:FY4RBnfH.net
Pattern alternativesってなんですか?和訳のパターンORもよくわかりません
https://doc.rust-lang.org/book/appendix-02-operators.html
https://doc.rust-jp.rs/book-ja/appendix-02-operators.html

104 :デフォルトの名無しさん:2022/10/09(日) 23:53:45.87 ID:vVo7+K5Y.net
パターンの代替策
つまり「|」記号が
bit演算のORとしてだけでなく
パターンのORとしても使われるよってこと

105 :デフォルトの名無しさん:2022/10/10(月) 11:32:20.19 ID:wEJNunBW.net
>>69
なるほど
マルチスレッドで共有する場合にはどうするのが適切なんでしょうか?

106 :デフォルトの名無しさん:2022/10/10(月) 11:45:42.80 ID:wEJNunBW.net
>>105
これか

https://qiita.com/muumu/items/f264ad781486d3dd037b

107 :デフォルトの名無しさん:2022/10/10(月) 18:49:06.89 ID:lNBbmc/N.net
Linux Kernel6.1は、Rustへ移行した最初のバージョンとなります。
Rustへ移行することにより、C言語バージョンの世代から、およそ30%の高速化を果たしました。

108 :デフォルトの名無しさん:2022/10/10(月) 22:52:16.26 ID:3WEeN/aN.net
気分はCelltic!
「実はshared xor mutableってしっくりこないんです!」

109 :デフォルトの名無しさん:2022/10/10(月) 23:11:02.61 ID:U+uG6kFy.net
>>105
内部可変性を得たい場合
スレッド内ではCell<T>もしくは参照を持ち出したいならRefCell<T>を使う
スレッド内部で普通の共有ならばそれらの&を使う (&mutでなくてもOK)
スレッド内部で所有者が別となる共有ならばそれらのRc<...>を使う

スレッド間では完全排他のMutex<T>もしくはreaders複数可のRwLock<T>を使う
(ただしTがi32やboolならばもっと軽いAtomicI32やAtomicBoolが使える)
スレッド間で共有は所有者が別となるのでそれらのArc<...>を使う

110 :デフォルトの名無しさん:[ここ壊れてます] .net
>>97
最適化頑張ってるだけでムーブは概念的なものじゃないぞ。RBMMなんだから。

111 :デフォルトの名無しさん:2022/10/11(火) 19:16:08.16 ID:Bl5ahscm.net
moveがmemcpy呼び出しになるかどうかはあくまでも実装の話で
move自体のセマンティクスはデータのコピーを要求しないということが言いたいのでは

最適化offにして構造体サイズ大きくするとmemcpy呼び出されるから、memcpy起きないというのは嘘だけど

112 :デフォルトの名無しさん:2022/10/11(火) 19:23:40.64 ID:61VrJvDY.net
>>110
あくまでもRustの言語レベルでの抽象的なレベルではムーブはムーブであってビットコピーの保証はそこには一切ない
そして我々は抽象的な概念に基づいてプログラミングすればよい
生成コードはムーブという抽象的な概念だけを保証して最適化される
だからこそ生成コードではムーブでビットコピーが消え得る

113 :デフォルトの名無しさん:2022/10/11(火) 19:29:43.10 ID:61VrJvDY.net
>>111
memcpyはたまたまムーブの最適化なしのデフォルト状態で行われる可能性のあるコードにすぎないね
Rustの言語としてはmemcpyが必ず行われることなんて全く保証しない
ムーブはもっと上位の概念であってRustが保証するのはその上位の概念のみだね

114 :デフォルトの名無しさん:2022/10/11(火) 19:51:08.13 ID:Bl5ahscm.net
>>113
はいはい、>>111は誤読されかねない表現でしたね
(常に)memcpy起きないというのは嘘
と読み替えておいてください

元々の>>94のRefCellやMutexの方が効率的かという質問については、そういう場合もある、というのが答えで良いですよね

生成されるコードがどうなるかは最適化レベルや周囲のコードに依存するわけで、必ずどちらかが効率が高いと言えるようなものではない
感覚的には格納するデータサイズが大きい方がRefCell/Mutexが有利に、小さければCellが有利になりそうだけど、
ちゃんと測定したわけではないので実際のところは分からない

115 :デフォルトの名無しさん:2022/10/11(火) 20:23:10.29 ID:iRs2n6UT.net
>>114
実はRefCell構造体のメンバーにCellが使われている(現状)

使用されるメモリサイズ
Cell<T> ← Tと同じサイズ
RefCell<T> ← Tのサイズに加えてborrow管理のために内部で使用するCellサイズ分加算

動作コスト
Cell<T> ← (利用後すぐset()すれば)Tと同じコスト
RefCell<T> ← Tのコストに加えてborrow管理のために内部で使用するCellの読み書き操作コスト分加算

116 :デフォルトの名無しさん:2022/10/11(火) 21:44:42.19 ID:P/g9+OyI.net
ホント笑っちゃうくらい嘘を散りばめてくるよねw

117 :デフォルトの名無しさん:2022/10/11(火) 21:58:52.19 ID:lchMb24F.net
>>114
RefCellやMutexの方が効率的かという質問については
代用として使うならばそれらの方が遅いでしょう
RefCellはボローチェック処理が必ず入ります
Mutexは排他的ロック処理が入るのでさらに遅いです

118 :デフォルトの名無しさん:2022/10/11(火) 22:06:38.86 ID:Bl5ahscm.net
>>115
動作コストはT全体を置き換える場合だよね
TがVecで、一要素追加する場合のコストも計算してみてよ

>>117
ボローチェック処理が最適化で消えないことは保証されてるの?
ボローチェックや排他処理のコストはCellで発生するデータコピーより必ず高コストになるの?

119 :デフォルトの名無しさん:2022/10/12(水) 14:10:22.75 ID:IRDyECLz.net
ムーブ元の変数が使われないことがわかってるんだから
その変数の領域を使い回せばよいだけでしょ?
普通に考えてコピーとか起きないと思うんだが

120 :デフォルトの名無しさん:2022/10/12(水) 18:26:20.15 ID:R7/twQcO.net
自称分かってる人同士のケンカ

121 :デフォルトの名無しさん:2022/10/12(水) 21:47:16.08 ID:TdLmkMrU.net
RefCell使うのはアロケーションを避けたいからでしょ

122 :デフォルトの名無しさん:2022/10/12(水) 23:29:45.96 ID: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が最適化でメモリに対して直接実行する命令コードにするだろうから読み出し書き込みも消えるわけね

123 :デフォルトの名無しさん:2022/10/13(木) 01:04:10.25 ID:v9vBAx/l.net
CopyじゃないStringやVecで&mut selfとるメソッドを試せば違いが分かるよ

124 :デフォルトの名無しさん:2022/10/13(木) 02:00:58.56 ID:m/K7Pbd2.net
Copyを実装しない適当な構造体
#[derive(Default)]
struct Foo {
 inner: i32,
}
の &Cell<Foo> と &mut i32 の両方のケースで
>>122の最適化により同じ生成コードとなるから
Copyを実装してるか否かは関係ないみたい

125 :デフォルトの名無しさん:2022/10/13(木) 03:36:21.71 ID:Oo+uXzBV.net
>>124
それだと簡単にインライン化出来るからね
アロケーションが必要な型という意味でCopyじゃないStringやVecと言ったんだけど
Dropと言ったほうがよかったのかな

126 :デフォルトの名無しさん:2022/10/13(木) 04:02:18.88 ID:cMF4wuqy.net
アロケーション発生しなくても(i32, i32)とかにするだけでもう生成アセンブリ同じじゃなくなるね

127 :デフォルトの名無しさん:2022/10/13(木) 08:01:16.32 ID:wSzwAK9q.net
コンパイラが>>122
(2) メモリ←default-value書き込み
を削除する最適化をすれば
Copy実装なかろうがヒープを使おうが
生成コードは同じになるんじゃね?

128 :デフォルトの名無しさん:2022/10/13(木) 15:12:31.34 ID:FWxI+s/s.net
>>126
Copyにしてget/setにすれば同じになるかも

129 :デフォルトの名無しさん:2022/10/13(木) 15:31:24.77 ID:WZ96xtHr.net
macOSにおけるFirefoxのパフォーマンスを劇的に改善した方法とは?
メモリアロケーター「jemalloc」を独自にカスタマイズしたアロケーターを用いてメモリ管理を行っています。Firefoxのアロケーターでは並列処理時のロックを効率的に行うためにOSごとにネイティブなAPIを使用しているとのこと。このロックAPIとして、macOSではOSSpinLockが用いられていました。
https://gigazine.net/news/20221011-firefox-macos/

これって、Rustのメモリアロケーターがjemallocを基にしたRust実装になってるってことだよね?大昔はjemallocだったという話で

130 :デフォルトの名無しさん:2022/10/14(金) 21:09:01.17 ID:iCatm8xv.net
>>136
シッタカも出来ないかまってちゃん不定期
https://searchfox.org/mozilla-central/search?q=servo%2F&path=&case=false®exp=false

131 :デフォルトの名無しさん:2022/10/15(土) 00:38:51.20 ID:ZRY2KlKK.net
>>130
servoを構成するコンポーネントのうちfirefoxに取り込まれたstyloしか登場してないように見えるが

132 :デフォルトの名無しさん:2022/10/15(土) 10:12:30.40 ID:kho15VFl.net
複オジにマジレスしても意味ないよ

133 :デフォルトの名無しさん:2022/10/15(土) 21:19:13.19 ID:Sue68NiD.net
お前の主張は「Firefoxはservo使ってない」であって「styloしか登場してない」では無い、そもそもstyloだけじゃない
途方もなく低い技術力でマウント取りたいことが生きがいの薄汚いオッサン

134 :デフォルトの名無しさん:2022/10/16(日) 01:52:37.08 ID:xR2EqnpB.net
servoは独立したレンダリングエンジンだからservoを使うと言えるのはgeckoを丸々置き換えた場合では
というかallocatorの話はどうなったんだ

135 :デフォルトの名無しさん:2022/10/16(日) 13:06:47.08 ID:I4ihc4bO.net
「Firefoxはservo使ってない」定期、顔真っ赤の話しそらしオジサン、geckoを丸々置き換えた場合とか言い出したw
「styloしか登場してない」も消えたwww
あんたはアロケーターなんて興味ないだろwww
したけりゃしろ。自分からは詳しい技術的な話何もできない、マウントしたいだけ、業界にいる寄生虫

136 :デフォルトの名無しさん:2022/10/16(日) 16:22:20.12 ID:xR2EqnpB.net
>>134
firefoxのレンダリングエンジンはservoじゃなくてgeckoのままだよ
servoは次世代ブラウザ向けのレンダリングエンジンの実装を模索するための実験プロジェクトで、geckoを置き換えることを意図したものではないよ
servoの一部のコンポーネントは完成度が高くgeckoに取り込まれてはいたので、
servoが発展していったらgecko全体がservoで置き換えられる未来もありえたけど、
mozillaがservoの開発者レイオフしちゃったのでその可能性もなくなっちゃったかと

動的ライブラリや静的ライブラリとして他のアプリケーションにリンクするcrateの場合、リンク先のアプリケーションバイナリに含まれる(または、動的リンクされる)allocatorを利用するのが普通なので、
geckoのservo由来のrustコードもそうなっていて独自にallocatorを定義することはしていないんじゃないかな

137 :デフォルトの名無しさん:2022/10/16(日) 18:59:51.30 ID:qTG+zV4j.net
rust関係ないけどjemallocを日本語で読む時
ジェ-マロック派?それともジェム-アロック派?

138 :デフォルトの名無しさん:2022/10/16(日) 20:24:24.45 ID:xR2EqnpB.net
Json Evans mallocだからジェーイーマロックって呼んでる

139 :はちみつ餃子 :2022/10/16(日) 22:45:33.29 ID:SvF0Fhwf.net
それを言うなら malloc が (たぶん) memory allocate の略なんだから
ジェーイーエムアロックと呼ぶのが筋というものでは……。

俺はそもそも口頭で読み上げる機会がないから考えたこともなかった。

140 :デフォルトの名無しさん:2022/10/16(日) 23:11:22.79 ID:sz/XVYMu.net
開発者本人の動画見るとジェイ・マロックに聞こえるが
ジェイ・イー・マロックが短くなってるだけかなこれ
https://youtu.be/RcWp5vwGlYU?t=79

141 :デフォルトの名無しさん:2022/10/17(月) 18:50:40.32 ID:q3uOCHzu.net
>>136
servoじゃなくてgeckoのままは言い過ぎです、現にベクター系の2Dや、Canvasなどに使用するレンダラーはservo由来の
レンダラーが使用されます。その他はその通りでしょう

142 :デフォルトの名無しさん:2022/10/17(月) 19:52:15.71 ID:gBqRn20s.net
>>141
geckoを構成するコンポーネントの入れ替わりはあったけど
firefoxのレンダリングエンジンは生まれたときからずっとgeckoだよ
逆にgeckoじゃなかったら何なんだ

143 :デフォルトの名無しさん:2022/10/17(月) 19:58:16.39 ID:gBqRn20s.net
>>141
FirefoxにRustのコンポーネントを多く導入したQuantumプロジェクトの説明でも、ServoのコンポーネントをGeckoに取り込むと言っていて、
Geckoを置き換えるとは言っていない
https://wiki.mozilla.org/Quantum

144 :デフォルトの名無しさん:2022/10/17(月) 21:29:09.32 ID:MqsTBCMt.net
Rust関係ないからFirefoxスレでどうぞ

145 :デフォルトの名無しさん:2022/10/17(月) 22:43:40.85 ID:GuOtjDmV.net
もうその話題はいいよ
しつこいな

146 :デフォルトの名無しさん:2022/10/18(火) 10:08:56.84 ID:1nhFYrk9.net
しつこくやって『Cell<T>はTと同じコスト』(真っ赤な嘘)を流したかったんでしょw

147 :デフォルトの名無しさん:2022/10/18(火) 11:26:14.64 ID:f2tKHPpy.net
termuxのrustずっとバージョン不整合で動かないな
rustupじゃそもそもインストール出来ない

148 :デフォルトの名無しさん:2022/10/18(火) 12:14:53.29 ID:PMaXG0c3.net
>>147 俺は普通に動いてる
一応聞きたいんだけど、TermuxはF-Droidから入れたよね?
Play Store版はもうメンテナンスされてないから色々バグると思う

149 :デフォルトの名無しさん:2022/10/18(火) 12:23:43.08 ID:lAl7R2Of.net
>>143
あー、それ見てワカッタ風吹かしてんのな。「Rustのコンポーネントを多く導入」と言ってる時点で、styloだけじゃないし
2DレタリングのwebrenderもservoからのRust製だわ。”誰も”Geckoを置き換える=Geckoが無いなんて言ってない
https://github.com/servo/webrender

150 :デフォルトの名無しさん:2022/10/18(火) 14:03:11.76 ID:f2tKHPpy.net
>>148
F-Droidから入れてる
何故かlibllvm-14.soのリンクが出来ないと怒られてしまう
で入ってるllvmのバージョンが更新で15に上がってしまってる状態
俺環かも知れんね

151 :デフォルトの名無しさん:[ここ壊れてます] .net
あんまり自信がある訳じゃないんだけど、カーネルが64bitでユーザーランドが32bitみたいな環境だったりしない?

152 :デフォルトの名無しさん:[ここ壊れてます] .net
>>149
Geckoのコンポーネントを置き換える

Geckoを置き換える
は全然意味が違うでしょ

まあ日本語の問題で意図してるところは食い違ってないから反応するのはこれで終わりにするわ

153 :デフォルトの名無しさん:[ここ壊れてます] .net
グーグル、Rustで書かれたセキュアなOS「KataOS」を発表
https://japan.zdnet.com/article/35194751/

154 :デフォルトの名無しさん:2022/10/18(火) 15:37:54.47 ID:f2tKHPpy.net
>>148,151
すまぬ色々やってる中で入れたnightlyの影響だった
お騒がせした

155 :デフォルトの名無しさん:2022/10/19(水) 03:30:17.24 ID:cvhlJCwu.net
fucsia「僕はいらない子なの?」

156 :デフォルトの名無しさん:2022/10/19(水) 07:05:26.07 ID:CJepXKVA.net
>>153
昔「おおっ!!!あのグーグルがまた何か新しいことを始めたぞ!すごそうだ!」
今「まぁーーたはじまったよ・・・」

157 :デフォルトの名無しさん:2022/10/19(水) 11:11:44.42 ID:H7L8/zfi.net
Googleが立ち上げては潰してきたサービス一覧「Killed by Google」
killedbygoogle.com

158 :デフォルトの名無しさん:2022/10/19(水) 11:23:33.38 ID:iHEkpSLR.net
何も産まないよりは健全よね

159 :デフォルトの名無しさん:2022/10/19(水) 11:35:06.09 ID:Dqx/r4FW.net
役に立つかどうかわからんものに手を出せる余裕が
個別の結果に関わらず
部分的な成果の積み上げで会社をブーストさせるんよ

160 :デフォルトの名無しさん:2022/10/19(水) 11:38:58.17 ID:Sj+PYk/j.net
まあ堅そうな名前ではあるな

161 :デフォルトの名無しさん:2022/10/19(水) 12:24:59.02 ID:j2B3ovC/.net
IoT向けOSって言ってるし組み込みOSなんて元々百花繚乱だろ。
組み込み機器の脆弱性対応なんて大変だし、そもそもその手の脆弱性が入り込みにくい言語を採用するのは合理的だと思う。

162 :デフォルトの名無しさん:2022/10/19(水) 12:46:33.84 ID:xwPbcXKV.net
日本ってやらない理由、出来ない理由並べる奴が多いよな
多くの日本企業よりGoogleの方が多く生み出しているし世の役に立っている

163 :デフォルトの名無しさん:2022/10/19(水) 12:48:40.76 ID:aUvB23KT.net
南朝鮮ってやらない理由、出来ない理由並べる奴が多いよな 多くの南朝鮮企業よりGoogleの方が多く生み出しているし世の役に立っている

164 :デフォルトの名無しさん:2022/10/19(水) 13:00:38.45 ID:xwPbcXKV.net
Rust Foundationへの参加はNECやFUJITSUよりSamsungの方が早いんじゃないかなぁ
国内大手で積極的にRustを推していこうなんて所はなさそうに見えるし
組み込みのRenesasとかもやる気なさそうだしな

165 :デフォルトの名無しさん:2022/10/19(水) 19:58:52.34 ID:+MAum9P/.net
出来ない理由を考えるのではなく!

166 :デフォルトの名無しさん:2022/10/19(水) 21:32:43.94 ID:mHa4T+cl.net
日本が後進国になってきたのは政治の責任が大きいけど
IT分野で遅れてるのは総じて教育水準が低いからだよ

167 :デフォルトの名無しさん:2022/10/19(水) 22:51:58.05 ID:owfoFln4.net
民主主義国は政治の責任=有権者の責任

168 :デフォルトの名無しさん:2022/10/19(水) 23:03:48.16 ID:kLmY2FYt.net
>>167
利権差配と中抜きしか考えない国賊を礼讃して
統一創価売国与党に投票し続けたやつの責任だろ

169 :デフォルトの名無しさん:2022/10/20(木) 00:02:58.60 ID:ce/AQgdF.net
まったく読むに値しないクソ書き込みの羅列の中で
>>160 だけが唯一価値ある輝きをはなっている

170 :デフォルトの名無しさん:2022/10/20(木) 13:00:10.90 ID:Px+TgmX7.net
在日だらけ。IT分野で遅れてるのは米国(英語圏)・中国の人口差だし、日本の人口減でもある。
世界中で、歴史上、移民以外で人口減を解決した国は1つもない
そういう意味では韓国などはでは優れたソフトウエアは1つもない。馬鹿な半島はAndoridのOSを
握ろうとTizenなどというゴミを掲げたが、食いついたのはNTTドコモぐらい
いま韓国で起こってるのはソフトウエアサービスの””ガラパゴス化””であり、GoogleやAmazon
Apple Payなどに対して参入障壁を作り防御するような、大昔の古臭い日本あった不公正貿易。
民主党政権時代だって3年あったわけだが、利権と中抜きしかしてない。やったことは仕分けだが
1つも役に立たないどころか、地方医療を崩壊させ、気象変動へ対処できるインフラ投資を
一時的止めた害悪しかなかった。その他にも野田政権による執拗な消費税増税もあった。
今彼らは英国が減税を匂わせただけで大混乱していることを見ずに、消費税ゼロを掲げている。

卑劣にも矛先を反らし、リベラルなのに移民反対派で、リベラルなのに「国賊、売国」などという言葉を使い、
まるで戦争前夜か、共産主義や社会主義のような物言いをするアホが出る時点で若い人の人材不足といえる。

171 :デフォルトの名無しさん:2022/10/20(木) 16:07:13.38 ID:zGrDbuOl.net
英国が減税しただけで、支持率が7% になったw
米国の金利上昇で、韓国の金利も0.5% 上がったw

なのに、借金が1千兆円もある日本の金利が、0%w

狂った世界中の経済学者達が、日本は不正をしている。
日本国債は破綻しなければおかしいと言ってるw

外人が幾ら日本国債を売っても、金利が上がらない。
破綻しないw

いい加減、借金が1千兆円もあるという財務省の嘘に気付け!w

YouTube で勉強しろ。
【TVじゃ絶対言えない話】国の借金は嘘!?中田敦彦が解説

172 :デフォルトの名無しさん:2022/10/21(金) 19:45:15.15 ID:xXJwtueL.net
WEB+DB PRESS、何度目のRust入門なんだい?

173 :デフォルトの名無しさん:2022/10/21(金) 20:10:13.59 ID:HoCfXQGg.net
Rust入門は初めて

174 :デフォルトの名無しさん:2022/10/21(金) 21:22:06.02 ID:2TP3mE4K.net
pythonとrustを一通り試してみた
for文の入れ子で外側のforをbreakできるとか、数値を1_000_000と表現できるとか、
そんなところでrustのほうが行き届いている感じがした

ただpythonのリスト内包表記、添え字の-1で配列の一番最後を表すとかそんなのは便利だな

175 :デフォルトの名無しさん:2022/10/21(金) 21:26:14.55 ID:gnp0h5uN.net
Rust入門という感じではないな
Rustを使ったWeb入門という感じ

176 :デフォルトの名無しさん:2022/10/21(金) 22:25:35.46 ID:YCtBy6Lb.net
>>175
Web+DB Press読者は簡単なWebアプリ開発はいろんな言語で経験済みで理解しやすいだろうからチュートリアルの対象に選んだだけでは?

177 :デフォルトの名無しさん:2022/10/22(土) 13:19:56.51 ID:OES5lhv+.net
>>176
普段読まないけどRustなので買ってみた
なかなかわかりやすかった
基本文法の解説が明らかに足りないけど
サンプルを理解するだけならこの程度で良いのか
面倒な部分が表に出ないようにうまくサンプルを調整してるし

178 :デフォルトの名無しさん:2022/10/22(土) 21:03:49.60 ID:Vp6sRBIs.net
借用がどうGCに関係するのかよくわからない
うまく説明しているサイトはないですか?

179 :デフォルトの名無しさん:2022/10/22(土) 21:38:11.55 ID:OES5lhv+.net
まずスタックとヒープを理解せよ
これは口を酸っぱくして言ってる
でないとRustは理解できない

180 :デフォルトの名無しさん:2022/10/22(土) 21:39:04.07 ID:PO/EA+oY.net
とりあえずThe Bookの4章
https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html

Rustをそれなりに習得しようと思うなら
The Bookとオライリー本を読むのが一番近道

181 :デフォルトの名無しさん:2022/10/22(土) 23:56:07.88 ID:OES5lhv+.net
両方とも初心者には辛いよなあ
わかりやすい入門書が待たれる

182 :デフォルトの名無しさん:2022/10/23(日) 00:22:18.48 ID:LnniM1YV.net
借用するときにデータをスタックに積む
スコープを抜けるときに一気にpopするので
GCがいらない、つまり、早い
heapだとGCのときにデータの移動が必要になる
ので遅い
この理解であってる?

183 :デフォルトの名無しさん:2022/10/23(日) 00:29:31.67 ID:jNoMv4k0.net
ポインタとか参照とか他の言語で扱ったことない?

184 :デフォルトの名無しさん:2022/10/23(日) 00:44:57.32 ID:h/oZflgJ.net
heapが遅いの要因は、メモリの割り当て解放処理があるから処理量が多いとか、
割り当てた領域がバラバラになることでキャッシュ効率がさがることとかかと

185 :デフォルトの名無しさん:2022/10/23(日) 13:47:22.46 ID:/F23RQvw.net
ページング処理みたいなのが、ヒープだと2重に行われるんじゃないの?

186 :デフォルトの名無しさん:2022/10/23(日) 14:14:22.62 ID:ioVOctq2.net
>>182
Rustでのその辺のメモリの動きはオライリー本に詳しく書いてあった気がするから読むべし

187 :デフォルトの名無しさん:2022/10/23(日) 15:30:09.10 ID:t4UBj2/5.net
>>182
>>185
お前ら、具体的にどうされてるからスタックだと速いかわかって無いだろ、、、

188 :デフォルトの名無しさん:2022/10/23(日) 18:33:19.09 ID:QEVtmAwk.net
>>182
そんなに物事が単純なら良かったのに...
”スコープを抜けるときにGCがいらない、つまり、早い”、これは間違いでもある。インライン展開されるような高階関数なら良いが
ループ中でアロケーションしてしまうような記述をすると、その度に確保・解放されるので非効率になりかねないし、借用による
メモリーの管理ではないが、参照カウントを使用するSwiftでは、ループでボトルネックになることはある。
このためRustでは高階関数で書く事が一般的に(分かり易く)良い事とされる。あとスタックでどの言語も大体はスコープ外で
消えるのでヒープとスタックの区別は付けましょう

独立したGCスレッドが動く言語だと、スコープ外れでGCするとは限らないので、速い場合がある。一方で、高負荷な環境では
GCスレッドがありで、回収などインターラプトが入るのでRustが有利になる(=※こちらのほうがRustが重要視される理由)
いわゆるSTOP THE WORLD(DIO様風)だ。ただ、これが無ければ良いということではなく、循環参照などを作らなければ
問題ないという話で循環参照を作ってしまうのであれば、独立したGCスレッドは便利でもある

”GCのときにデータの移動が必要”になるかどうかは、GCのアルゴリズム次第であり、厳密には”データの移動が必要”になるのは
メモリーのフラグメント解消つまりコンパクション処理によるところが大きい。これは、近代的なOSでは似たような事を行っていて
これ自体が速度に大幅に影響を及ぼすとは言い難い

189 :デフォルトの名無しさん:2022/10/23(日) 19:03:12.25 ID:NZM9O6ur.net
>>188
> ループ中でアロケーションしてしまうような記述をすると
アホなコードで議論する必要あるの?

190 :デフォルトの名無しさん:2022/10/23(日) 20:51:00.62 ID:h/oZflgJ.net
一体何と何を比較しているのだ

191 :デフォルトの名無しさん:2022/10/23(日) 22:09:39.72 ID:HOBBKeJ+.net
なんかすごい早口で支離滅裂なこと言ってるけど
頭を整理した方が良いよ

192 :デフォルトの名無しさん:2022/10/24(月) 16:50:56.92 ID:SgELnO58.net
スコープを抜けるときにGCがいらない、つまり、早い

これが間違っている理由を教えてください

193 :はちみつ餃子 :2022/10/24(月) 18:09:05.87 ID:VKX4Fsrh.net
ヒープメモリの管理はそれなりに重い処理だというのが論旨のように見える。

GC を使った場合のように不要なオブジェクトの判別をしていくコストは Rust では生じないが
それを除けば空いてる箇所と使用中の箇所を上手いこと管理する実行時コストは
GC (に付随するメモリ割り当て) でやってるのとたぶんそんなに差はないんじゃね。

194 :デフォルトの名無しさん:2022/10/24(月) 18:49:41.29 ID:8+UVFZyO.net
>>192
>スコープを抜けるときにGCがいらない、つまり、早い

確保したメモリはいつ解放するんだよバカ。

195 :デフォルトの名無しさん:2022/10/24(月) 19:05:34.14 ID:Off49nvS.net
文法で制約したら、書き手もコンパイラも
変数の寿命を厳密に特定することができて便利だろって事で、
どこにどう確保すると速いとか、そういう話とは別では

196 :デフォルトの名無しさん:2022/10/24(月) 19:14:17.25 ID:FdEAHzhz.net
GCがないので速い←わかる
スコープを抜けたらpopするだけなので速い←わかる
スコープを抜けるときにGCがいらない←スコープとGCは何の関係もないよね

197 :デフォルトの名無しさん:2022/10/24(月) 20:07:47.96 ID:rCA25jH/.net
まあGCは常に動く可能性があるからな
逆に全く動かない可能性もある
そこはGCのアルゴリズムによりけり

198 :デフォルトの名無しさん:2022/10/24(月) 21:01:10.53 ID:SgELnO58.net
スタックを使っているから
pop すればそのままメモリが解放されるという意味では?

199 :デフォルトの名無しさん:2022/10/24(月) 21:39:23.30 ID:UxIqfb1a.net
何と何を比べて何が速いと思ってるのか整理しなよ
話はそれからだ

200 :デフォルトの名無しさん:2022/10/24(月) 22:49:30.31 ID:c7GaYtEs.net
>>198
動的データ全部スタックに積むのか。すげーな。

201 :デフォルトの名無しさん:2022/10/24(月) 22:54:45.01 ID:9jOSWWIs.net
そんなことよりコンパイルの遅さマジでテコ入れろYO、非力なCeleronでactix-webのコンパイルしたら10分とかふざけてんのか?

202 :デフォルトの名無しさん:2022/10/24(月) 23:05:21.00 ID:XsMeW9pb.net
コンセプトがコンパイル遅くしても賢くするだから無理

203 :デフォルトの名無しさん:2022/10/24(月) 23:18:23.86 ID:b0depGja.net
依存ライブラリまで全部自前ビルドさせられてるわけだからな
コンパイル済みcrateの配布とかやってくれればなんとかなりそうではあるが

204 :デフォルトの名無しさん:2022/10/24(月) 23:42:51.24 ID:cJUnO/Lg.net
コンパイル高速化はユーザー側でもいろいろ工夫の余地はあるが
コア数多いマシンを使うのがいちばん効果がある

205 :デフォルトの名無しさん:2022/10/25(火) 07:14:07.04 ID:0Y9XP165.net
分散コンパイルか、差分コンパイルか、常にバックエンドでコンパイルか

206 :デフォルトの名無しさん:2022/10/25(火) 08:16:49.84 ID:A5TY3R0Y.net
>>201
流石にもっと良いマシン買えでFA

207 :デフォルトの名無しさん:2022/10/25(火) 08:49:49.17 ID:1jHrAe9o.net
でもRustって錆だよね

208 :デフォルトの名無しさん:2022/10/25(火) 11:17:17.09 ID:5EjxpvPU.net
ライブラリ類も複雑化・大型化の一途をたどっているご時世だし
Androidをビルド出来ないようなマシンは開発用としては時代遅れじゃね

209 :デフォルトの名無しさん:2022/10/25(火) 16:49:21.94 ID:pUVcngq8.net
環境負荷を下げるためにもTier1プラットフォームはビルド済みか半分ビルド済みを配布できるようにすべき

210 :デフォルトの名無しさん:2022/10/25(火) 18:21:31.05 ID:RZIJ148t.net
structのフィールドにasyncのクロージャ持たせるの面倒だな

211 :デフォルトの名無しさん:2022/10/26(水) 00:21:17.27 ID:+/Fbza6R.net
>>210
Pin<Box<dyn Future<Output = T>>> ではだめ?

212 :デフォルトの名無しさん:2022/10/26(水) 01:59:13.05 ID:TlW6c1+d.net
>>211
Box<dyn Fn() -> Pin<Box<dyn Future<Output = T>>>>
こんな感じ

213 :デフォルトの名無しさん:2022/10/26(水) 03:12:53.76 ID:J4zGWIbj.net
>>200
全部とは言っていないローカル変数だけだ

214 :デフォルトの名無しさん:2022/10/26(水) 07:48:04.37 ID:i0Q+rT9S.net
>>213
GoだってJavaだってローカル変数はスタックを利用する。

215 :デフォルトの名無しさん:2022/10/26(水) 08:03:17.30 ID:xzd5i3vP.net
>>214
Go は知らんが Java は値型しかスタックに確保しないよ
配列使うだけでヒープ使う

216 :デフォルトの名無しさん:2022/10/26(水) 10:03:48.91 ID:8iR+QuRY.net
んなこと言ったらRustだってBox使うだけでヒープ使われるだろ

217 :デフォルトの名無しさん:2022/10/26(水) 10:28:26.80 ID:poB2zSjv.net
ピープアレルギーでも湧いたのか?

218 :デフォルトの名無しさん:2022/10/26(水) 10:55:30.37 ID:xzd5i3vP.net
>>216
そりゃあえてBox使えばヒープ使うわな
極論バカ乙w

219 :デフォルトの名無しさん:2022/10/26(水) 12:39:08.43 ID:61QnplYU.net
ヒープで思いついたけどtest::benchってなんで使用したメモリ量出てこないの?Rustだってアロケーター自作できるなら出せなくないと思うんだが

220 :デフォルトの名無しさん:2022/10/26(水) 13:39:05.90 ID:29TlHyS0.net
c言語なんかも int a[n] とかはスタックから取ってきてる。昔はmallocしてたが。
とはいえlinuxのスタック領域はヒープとそんな変わらん。

221 :デフォルトの名無しさん:2022/10/26(水) 13:49:21.71 ID:OrdcPqRc.net
環境によるが、Rust のスレッドごとのスタックサイズのデフォルトが2MBとかで
バカでかいローカル変数や引数を使おうとすると、
簡単に実行時エラー/スタックオーバーフローを実現できるという
ちなみに、String はヒープを使う

222 :デフォルトの名無しさん:2022/10/26(水) 14:58:21.99 ID:XcmPInF1.net
>>220
ん?
何が変わらんの?

223 :デフォルトの名無しさん:2022/10/26(水) 16:10:38.33 ID:+/Fbza6R.net
>>219
issueはあるが放置されてる
https://github.com/rust-lang/rust/issues/22666
こういうのは欲しい人が積極的に動かないとなかなか進まないよね

224 :デフォルトの名無しさん:2022/10/26(水) 18:56:12.77 ID:m/VlzFSs.net
C 以外の言語は、すべて浅いコピー・shallow copy でしょ。
実体はコピーされずに、参照だけがコピーされる

たぶん、ローカル変数も参照だけがスタックにあって、
実体はヒープにあるのでしょ

225 :デフォルトの名無しさん:2022/10/26(水) 19:32:11.84 ID:/Jbhrlo+.net
そもそもスクリプト言語はマシンスタック使ってないから
C/C++/Rust/Goみたいなコンパイル言語とスクリプト言語(PythonとかRuby)とではメモリモデルが全く違う

JVMのJITはVMスタックをマシンスタックに引き継ぐって処理をやってるけど

226 :デフォルトの名無しさん:2022/10/26(水) 19:35:12.65 ID:+/Fbza6R.net
>>224
Cにdeep copyの概念ある?

227 :はちみつ餃子 :2022/10/26(水) 19:39:57.27 ID:UI6BPQPg.net
>>226
たぶん >>224 は Java や C# などでいう参照型のことを言ってると思う。

228 :デフォルトの名無しさん:2022/10/26(水) 19:41:30.91 ID:WAf5RIwU.net
Box<T>って出現頻度の割に表記が長いよな
boxキーワードに変える案はどうなったんだ?

229 :デフォルトの名無しさん:2022/10/26(水) 20:19:12.15 ID:SEIcgM+j.net
>>220
まーた思いつきで適当なこと言ってるの?

230 :デフォルトの名無しさん:2022/10/26(水) 21:39:27.98 ID:xibmu52f.net
シャローコピーもディープコピーもプログラマに意識させるような言語の方がいいと思うけどなあ

231 :デフォルトの名無しさん:2022/10/27(木) 17:59:59.22 ID:36nf4K/2.net
C言語は低レベルすぎるからshallow copyやdeep copyを意識する必要がそもそもないしな
ポインタをそのまま複製するのがshallow copyでポインタをデリファレンスしてからその値を複製するのがdeep copyってだけやし

232 :デフォルトの名無しさん:2022/10/27(木) 18:19:49.08 ID:mzG41rMz.net
cだってポインタがネストされてたら順番に見てかないといけないのは他の言語と同じでしょ。
ネストを考慮しなくて良いならjavaだってcloneで一発コピーできる

233 :デフォルトの名無しさん:2022/10/27(木) 22:00:27.64 ID:rMi5UTbc.net
>>231
> C言語は低レベルすぎるからshallow copyやdeep copyを意識する必要がそもそもないしな
むしろ意識しまくりだろ
shallow copyとかdeep Copyとかのおしゃれな名前では呼んでないけど

234 :デフォルトの名無しさん:2022/10/27(木) 22:11:49.94 ID:olmwGZ8d.net
複製おじさんディープコピー知らなかったもんねw

235 :デフォルトの名無しさん:2022/10/27(木) 22:27:03.43 ID:DBkkmtck.net
あえていうならCにおいては構造体のメンバをそのまま代入するのがshallow copy
構造体のメンバのポインタの領域を新しく領域を確保してコピー元の構造体を再帰的にmemcpyするのがdeep cooy

236 :デフォルトの名無しさん:2022/10/27(木) 23:13:57.69 ID:qcIge2ki.net
Cではというが大多数の言語がそうじゃね

237 :デフォルトの名無しさん:2022/10/28(金) 00:02:58.28 ID:Rl5QKwW8.net
deep copy は、ネストするから難しい

Ruby などは参照のリンクを断つために、
一旦、JSON などの文字列にしてから、オブジェクトを再構築したりする

Marshal もあるけど、色々な条件がつく。
IO, Proc, 特異メソッドが使えないとか

238 :デフォルトの名無しさん:2022/10/28(金) 01:13:37.77 ID:jXOvR4PJ.net
なんか話の脈絡も流れもなく各人が単語に反応して書きたいこと垂れ流すだけのスレと化してんな

239 :デフォルトの名無しさん:2022/10/28(金) 03:43:44.96 ID:01u53tKZ.net
高階関数はGCの性能に影響を及ぼすの?

240 :デフォルトの名無しさん:2022/10/28(金) 09:27:53.24 ID:jXOvR4PJ.net
Webpackの後継となる新バンドルツール「Turbopack」が登場。Rust製のネイティブアプリケーションでWebpackの700倍高速に。Next.js Conf 2022 - Publickey
https://www.publickey1.jp/blog/22/webpackturbopackrustwebpack700nextjs_conf_2022.html

241 :デフォルトの名無しさん:2022/10/28(金) 16:15:00.57 ID:AMrJHSke.net
JavaScriptっていつまでバンドルとかやるん?

242 :デフォルトの名無しさん:2022/10/28(金) 16:24:46.58 ID:muqJ433+.net
いっそコンパイルしたら

243 :デフォルトの名無しさん:2022/10/28(金) 16:28:04.57 ID:AMrJHSke.net
wasmでそれやろうとしてるけど
wasmランタイムよりJavaScriptランタイムの方がまだ速いというトホホな状態

244 :デフォルトの名無しさん:2022/10/28(金) 19:59:50.54 ID:eNUtjibx.net
じゃあasmjsでよくね

245 :デフォルトの名無しさん:2022/10/30(日) 11:39:14.94 ID:zV+ownbZ.net
何いってんだ
JavaScriptはRustの大口顧客だぞ
バカにするなんてとんでもない
JavaScriptの市場が大きいほどRustが儲かる仕組みなんだ

246 :デフォルトの名無しさん:2022/10/30(日) 13:52:59.67 ID:Ffhte1rz.net
moziraとgoogle, Microsoftと主要ブラウザメーカーが推進してるからな

247 :デフォルトの名無しさん:2022/10/30(日) 19:41:21.29 ID:TG2fSMWC.net
なんでvecの&mutに*が不必要なのか、いまいち理解してなかったけど

fn calc(n: &mut Vec<usize>) {
 (*n).push(1);
}

こういうことかー。そういうことだったのかー

248 :デフォルトの名無しさん:2022/10/30(日) 23:24:15.56 ID: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の}抜ける=プログラム終了時ようやく解放?

249 :デフォルトの名無しさん:2022/10/30(日) 23:41:49.13 ID:fG4j0a7a.net
Dropを自分で実装した型で試せばわかる

250 :デフォルトの名無しさん:2022/10/31(月) 19:06:46.94 ID:DHbQvQ7c.net
相変わらずLinusに怒られまくってるね

251 :デフォルトの名無しさん:2022/11/01(火) 06:39:05.97 ID:y5vMQo4Y.net
rust導入してもディレクトリ構造が汚くなるだけなのにどうして導入したんだろうね
正直撤回して欲しいわ

252 :デフォルトの名無しさん:2022/11/01(火) 07:47:38.45 ID:6ZBnCRFC.net
ディレクトリ構造なんかより優先すべきことがあるからだろ
rust使う意味を何も分かってないな

253 :デフォルトの名無しさん:2022/11/01(火) 14:04:14.12 ID:w6yg6Ajb.net
もうlinusがカーネル用にsafeな言語作った方がいいんじゃないの
既成言語じゃ既存の処理系と整合性をとらないといけないから
いろいろな不整合が生じる

254 :はちみつ餃子 :2022/11/01(火) 14:12:23.10 ID:XoXOtAeK.net
エコシステムの充実はユーザ規模によるところがあるから
たとえ言語の設計としてベストマッチでも特化しすぎると
(使い手が増えなくて) 雑多なツールやライブラリが出揃い難いということもありうる。

Linux くらいの規模なら専用言語を作っても割に合ったりするかな?

255 :デフォルトの名無しさん:2022/11/01(火) 14:25:52.66 ID:smDWdngC.net
linusがなんか言ったの?
ググってもlinux 6.1にrustが取り込まれた話しか見つけられなかった

256 :デフォルトの名無しさん:2022/11/01(火) 14:50:17.04 ID:FsVxrWah.net
>>253
なにそのgitな流れは。
凄まじく少ないコードで実現してしまいそうで恐ろしい。
ピーキーなのになって、普通の人は使えないのを期待しちゃう。

257 :デフォルトの名無しさん:2022/11/01(火) 14:58:39.21 ID:O+5UiM+O.net
>>253
linusはgcc拡張のCが最高だと思ってる人だよ

258 :デフォルトの名無しさん:2022/11/01(火) 18:29:34.49 ID:cxS6KzKc.net
>>250
どれ?

259 :デフォルトの名無しさん:2022/11/02(水) 15:56:44.98 ID:ohjjd8k9.net
linuxもデフォルトcというよりもかなりカーネル用の拡張してるからrustもそうすればええわってのが
linusの主張でしょ。

260 :デフォルトの名無しさん:2022/11/02(水) 16:18:07.00 ID:qqWWqhkC.net
一応clangでもlinuxカーネルコンパイルできるようになっているということは、
LLVMに必要な機能はそろっているということだろうから、
rustcからそれらの機能を呼び出せるようにできれば良いのかね

261 :デフォルトの名無しさん:2022/11/02(水) 16:35:45.00 ID:F11hp17c.net
リーナスゴシップとかどうでもいいスレチネタを続けるなよ

262 :デフォルトの名無しさん:2022/11/03(木) 02:16:08.55 ID:atTBpfYp.net
しょーもないシンタックスの話より有意義だけどな。

263 :デフォルトの名無しさん:2022/11/03(木) 05:38:58.72 ID: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となって、タプル以外の()撲滅できないか?

264 :デフォルトの名無しさん:2022/11/03(木) 19:40:23.88 ID:4W4icteo.net
>>263
()を色々使いすぎというのは同意だけどRPNだと今よりもっと使われないよ。
連鎖性言語とか好きだけど。

265 :デフォルトの名無しさん:2022/11/03(木) 21:14:31.73 ID:Z+updFpk.net
()については他の言語と同じだしそこで変に独自性を出してもなぁという感じ

266 :デフォルトの名無しさん:2022/11/03(木) 21:15:01.48 ID:t6ap+kyc.net
for &i in vec![0_usize; 5].iter() {
 //iのままなんちゃら
}

for i in vec![0_usize; 5].iter() {
 //*iでなんちゃら
}

参照外しはどっちをつかってる人のほうが一般的なん?

267 :デフォルトの名無しさん:2022/11/03(木) 21:21:15.76 ID:0fRPRys5.net
Copy実装してる型なら別にどっちでも……

268 :デフォルトの名無しさん:2022/11/03(木) 21:35:17.79 ID:b1nVlp4p.net
union で定義した型があり、タグビットに相当するビットで variant を区別できる場合に
enum と同じ表現でパターンマッチするというようなことは出来ませんかね?
マニュアルを見た感じでは出来なさそうなので駄目で元々な相談なんですが……。

それが欲しくなった事情としては抽象的なバイトコードマシンが定義されていて
そのバイトコードをそのまま enum にマッピングできれば楽なのになと思った次第です。

269 :デフォルトの名無しさん:2022/11/04(金) 04:42:50.90 ID:QJXSkaei.net
.expect("なんとかかんとかfailed.");
expectの引数はこんな文章になりがち
.expect("なんとかexpected, but かんとか found");
ならまだいいけど
コード読むときexpectというメソッド名からその引数には"期待しているものの説明"を"期待"してしまう
慣れるんだろうか…

270 :デフォルトの名無しさん:2022/11/04(金) 08:57:52.35 ID:KcmeiRV8.net
>>269
英単語を声に出して読んでみ

271 :デフォルトの名無しさん:2022/11/04(金) 09:12:11.15 ID:NSu48ax/.net
>>269
公式のドキュメントにも
.expect("failed to parse number")
という例があるしあまり気にしない方がよさそう
https://doc.rust-lang.org/std/result/enum.Result.html#method.inspect

272 :デフォルトの名無しさん:2022/11/04(金) 09:15:25.47 ID:yWEsFaag.net
>>271
これ英語の分からん奴が書いたんだろう

273 :デフォルトの名無しさん:2022/11/04(金) 09:25:36.66 ID:u3TD418O.net
>>269
まあ慣れるしかないわな
俺もこの名前はおかしいと思うし世の中でもおかしいと思う人はいるようだ
https://stackoverflow.com/questions/66362625/why-is-rusts-expect-called-expect

274 :デフォルトの名無しさん:2022/11/04(金) 09:47:45.14 ID:QJXSkaei.net
>>273
よかった、俺だけではなかったか

275 :デフォルトの名無しさん:2022/11/04(金) 09:54:11.00 ID:NSu48ax/.net
推奨されるメッセージのスタイルが定義されているので>>269は正しい
https://doc.rust-lang.org/std/result/enum.Result.html#recommended-message-style
どうしても気になるならこれを根拠にしてメッセージを修正するpull req送ると良いと思う

276 :デフォルトの名無しさん:2022/11/04(金) 11:58:42.90 ID:hgziOenm.net
君、ぼくのおちんちんを舐めてみないかい

277 :デフォルトの名無しさん:2022/11/04(金) 12:36:39.57 ID:8jcY9XF+.net
.expect("ン拒否するゥ");

278 :デフォルトの名無しさん:2022/11/04(金) 13:14:11.67 ID:u3TD418O.net
.expect("もう少しぶっといイチモツを用意すべきです")

279 :デフォルトの名無しさん:2022/11/05(土) 21:07:51.50 ID:EPLuMYxk.net
expectがそもそも期待するという意味より、予想するという意味合いで使われてることが多い気がする

280 :デフォルトの名無しさん:2022/11/05(土) 21:47:55.53 ID:6MdwxjIj.net
ここまで1.65の話題ゼロか

281 :デフォルトの名無しさん:2022/11/05(土) 21:51:57.09 ID:4ktyBPoJ.net
GAT難しいからw

282 :デフォルトの名無しさん:2022/11/05(土) 21:58:52.83 ID:B2i8Nuif.net
Rust 1.65.0 の発表
2022 年 11 月 3 日 · Rust リリース チーム
https://blog.rust-lang.org/2022/11/03/Rust-1.65.0.html
新しい Rust リリースの詳細に入る前に、イランの宗教道徳警察によるMahsa Amini の悲劇的な死と、他の多くの人々の死と暴力的な抑圧に注意を向けたいと思います。詳細については、 https://en.wikipedia.org/wiki/Mahsa_Amini_protestsを参照してください。私たちは、人権のために闘っているイランの人々と連帯します。

↑BLMといいウクライナといい海外ITの政治的主張入れて当然みたいなノリ苦手
質実剛健のイメージだったがRustチームも同じでちょっとガッカリ

283 :デフォルトの名無しさん:2022/11/05(土) 22:23:37.34 ID:CC30py/U.net
嫌な世の中だな

284 :デフォルトの名無しさん:2022/11/05(土) 22:33:26.02 ID:zxpwXxCd.net
そういうのが嫌なら使わなければよろしい

285 :デフォルトの名無しさん:2022/11/06(日) 03:47:36.18 ID:5A+TXyoz.net
お、Backtraceがstabilizeされたか
めでたい

286 :デフォルトの名無しさん:2022/11/06(日) 23:25:31.82 ID:tr7TV8Z+.net
>>285
うむ

287 :デフォルトの名無しさん:2022/11/07(月) 14:30:18.00 ID:5gh9UgGm.net
むしろ政治的な要素が少しでもあると過敏反応する日本IT連中のがキモいわ

288 :デフォルトの名無しさん:2022/11/07(月) 14:37:07.26 ID:3k6QMezQ.net
RustってSDGsだよね

289 :デフォルトの名無しさん:2022/11/07(月) 16:35:16.97 ID:F5fz3af4.net
みんなMSRVいくつにしてる?

290 :デフォルトの名無しさん:2022/11/07(月) 21:29:16.68 ID:oBOm8exD.net
日本人はまあ事なかれ主義だから仕方がない

291 :デフォルトの名無しさん:2022/11/09(水) 08:18:29.70 ID:JQdb1AnG.net
過剰反応というかツイッターでも左翼のトレンド操作がバレてしまったし
そういう必死な印象操作する奴らに全く反応しないのも正常性バイアスなだけで危険だと思うけどね

292 :デフォルトの名無しさん:2022/11/09(水) 08:49:14.30 ID:jv4fVWS/.net
別に操作でもなんでもなく前から人が選んでるって言ってたじゃん。
だからそういうのを過剰反応って言うんだよ。

293 :デフォルトの名無しさん:2022/11/09(水) 09:39:55.00 ID:LmGx5OMY.net
>>291
ナイーブなやっちゃなぁ
どの国でも底辺ほど極右化しちゃうのは物事が見えてないからなんやな

294 :デフォルトの名無しさん:2022/11/09(水) 09:48:57.31 ID:fSnT1d04.net
貧困老人って左傾化してるイメージある

295 :デフォルトの名無しさん:2022/11/09(水) 12:28:40.18 ID:aAawVede.net
>>292
トレンドはどのように決定されますか?
トレンドはアルゴリズムによって決定され、初期設定では、フォローしているアカウント、興味関心、位置情報をもとにカスタマイズされています。

こういうAI系にRustが使われる可能性ありそうかな?

296 :デフォルトの名無しさん:2022/11/09(水) 12:56:20.73 ID:YZQA7nNX.net
>>295
コア部分がC++、FortranからRustに変わるとかはありそう

297 :デフォルトの名無しさん:2022/11/09(水) 13:03:43.26 ID:tbXsBHme.net
>>294
それもまたナイーブな見方やなぁ
反自民党なら左、親自民党なら右やと思ってるんやろ?

298 :デフォルトの名無しさん:2022/11/09(水) 14:25:41.02 ID:bNBw/HLH.net
>>296
rustのGPU周りのツールチェインは整備進んでるの?

299 :デフォルトの名無しさん:2022/11/09(水) 19:49:39.97 ID:8uuc6jgH.net
>>298
GPGPU系は普通に使えそうな感じはしてるけどdeep learning周りはNvidiaが乗り気になるまで無理かもしれないと思えてきた

300 :デフォルトの名無しさん:2022/11/12(土) 21:53:46.90 ID:PWetNf5n.net
eguiつよそうだけどみんな興味ないの?

301 :デフォルトの名無しさん:2022/11/13(日) 01:00:16.84 ID:1Xo91Kz4.net
guiはeguiとtauriの2強になりそう

302 :デフォルトの名無しさん:2022/11/13(日) 02:09:24.41 ID:Uh0BavN1.net
eguiはエグイ

303 :デフォルトの名無しさん:2022/11/13(日) 02:33:53.13 ID:RFRBhoEy.net
言うほど2強か?
https://www.publickey1.jp/blog/22/electrontauriguitauri-egui_010.html

304 :デフォルトの名無しさん:2022/11/13(日) 21:44:40.30 ID:SeSkk5iM.net
丸の内線ってマジでいらんよな

305 :デフォルトの名無しさん:2022/11/13(日) 22:06:12.87 ID:iM/fRtPp.net
脱Electronした純Rust製コードエディタが出ないことには評価し辛いな。

306 :デフォルトの名無しさん:2022/11/13(日) 22:58:55.78 ID:T5PK/vl5.net
そんなんLapceがあるだろ

307 :デフォルトの名無しさん:2022/11/15(火) 00:12:55.17 ID:dw7MQVYD.net
Bevyの変更量エグいな。1.0到達まで様子見するわ
https://bevyengine.org/news/bevy-0-9/

308 :デフォルトの名無しさん:2022/11/15(火) 00:20:45.30 ID:aZkMwykQ.net
米国家安全保障局、CやC++からメモリー安全性の高いJavaなどへの移行を推奨
https://japan.zdnet.com/article/35195997/

ハッカーらによるリモートコード実行(RCE)をはじめとするさまざまな攻撃からコードを保護するために、C#やGo、Java、Ruby、Swift、Rustといったメモリー安全性の高い言語に移行するよう推奨している。

309 :デフォルトの名無しさん:2022/11/15(火) 00:37:48.72 ID:91d2LP66.net
CやC++で書かれているライブラリに依存するのもやめた方が良いのかね

310 :デフォルトの名無しさん:2022/11/15(火) 01:26:07.72 ID:5Bng48RE.net
実績というのは何にも代えがたい証明だからね。
十分に広く長く使われて枯れたライブラリをすぐさま使用停止するほどではないと思う。
長期的には移行せざるを得ないと思うが。

311 :デフォルトの名無しさん:2022/11/15(火) 02:05:15.69 ID:9SlnRoJw.net
>プログラマー側での実行に大きく依存している
言語の問題ではなくて、処理系と設計の問題だろうけど
C/C++と同程度の注意力であっても、
比較的楽に安全な実装が可能という話か

312 :デフォルトの名無しさん:2022/11/15(火) 05:58:46.96 ID:XpLYghoG.net
RubyはRustの誤植な気がする

313 :デフォルトの名無しさん:2022/11/15(火) 06:20:05.09 ID:dw7MQVYD.net
Javaもnull非安全クソ言語じゃんぬるぽ

314 :デフォルトの名無しさん:2022/11/15(火) 07:20:48.25 ID: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のソースを示してほしいね
https://www.zdnet.com/article/programming-languages-these-top-four-rule-and-developers-are-happy-for-now/

315 :デフォルトの名無しさん:2022/11/15(火) 08:46:43.91 ID:91d2LP66.net
メモリ安全という意味ではRubyは条件満たしてはいるのでは
Pythonがないのは気になるが

316 :デフォルトの名無しさん:2022/11/15(火) 08:47:01.64 ID:UduTysKC.net
ソース
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF

317 :デフォルトの名無しさん:2022/11/15(火) 09:09:11.17 ID:ott+UO1u.net
人工衛星イザナミ・イザナギでも、mruby を使っている

C はポインターでバグるから、
文字列処理などはポインターを使わない、安全なmrubyが良い

それで、mrubyから、Cのライブラリを呼び出せば安全

318 :デフォルトの名無しさん:2022/11/15(火) 11:32:13.77 ID:LEUpsbho.net
文字列処理でポインタを使わないってどうやんの?

319 :デフォルトの名無しさん:2022/11/15(火) 11:45:11.75 ID:Ohwd0nE1.net
陽に使わないって事だろ

320 :デフォルトの名無しさん:2022/11/15(火) 12:05:46.25 ID:91d2LP66.net
言わんとすることは分かるけど人工衛星と文字列処理はあんまり関係なさそう

321 :デフォルトの名無しさん:2022/11/15(火) 12:16:51.72 ID:REyE3AUr.net
>>316
これからメモリーセーフな言語が沢山出てきそうだな

322 :デフォルトの名無しさん:2022/11/15(火) 12:57:18.27 ID:37NRafRf.net
メモリセーフかつGC無しの言語ってRust以外に増える気配ないよな
需要あるのに

323 :デフォルトの名無しさん:2022/11/15(火) 13:11:29.50 ID:bU8+MPV6.net
C++ は安全な言語に混ぜてもらえなかったんだな。
C++はCに寄せられてしまったのかと。

324 :デフォルトの名無しさん:2022/11/15(火) 13:50:50.90 ID:eF4hIM3d.net
「生ポインタを使わずスマートポインタを使う」
「オブジェクトのコピーはすべてムーブを使う」
を徹底すればそこまで危険ではないんだけどね

325 :デフォルトの名無しさん:2022/11/15(火) 13:53:08.34 ID:Ohwd0nE1.net
>>323
まあやろうと思えばCと同じことができちゃうからね

326 :デフォルトの名無しさん:2022/11/15(火) 14:25:30.22 ID:5Bng48RE.net
>>324
知っててもクソみたいな誤りをするのが人だからな。

327 :デフォルトの名無しさん:2022/11/15(火) 15:49:10.51 ID:91d2LP66.net
Google Chromeのバグの7割がメモリ安全関連というし、
C++で安全性を保ちつつ大規模複雑なアプリケーションを作るのは難しいのでは

328 :デフォルトの名無しさん:2022/11/15(火) 16:00:29.49 ID:AMPFJlS8.net
そりゃ「〇〇するよう気をつければ良い」が通るんならそもそもバグらないよう気をつけられるはずだしな
人間が気をつけるのと機械的にチェックできることの間には大きな差がある

329 :デフォルトの名無しさん:2022/11/15(火) 21:18:52.91 ID:oaKUlL5c.net
>「オブジェクトのコピーはすべてムーブを使う」

微妙に意味が分からん

330 :デフォルトの名無しさん:2022/11/16(水) 03:16:38.83 ID:+3Ecu7Qb.net
>>329
クラスにムーブコンストラクタとムーブ代入演算子を必ず実装して
それが呼び出されように書くということね
ゼロから書く場合は可能
つまりRustっぽく書く
しかし外部ライブラリを使う場合は破綻するので無理なのだが

331 :デフォルトの名無しさん:2022/11/16(水) 07:33:54.12 ID:NR4h2Di6.net
F#をトライしていたのですが、VSは重いし、VScodeは動かすことができず
Sublimeは何とか動くが、ライブラリをうまくアクセスできず図を出力できず
コマンドラインでの実行もバージョンが古いせいかこれもライブラリにアクセスできず
で、似ているというRUSTをテストしてみました

インストールも簡単、クレートの設定も簡単
コンソールでコンパイル、実行も簡単
webにあるサンプルをテスト、5つほどwarningがでていましたが図を出力できました
F#では実行環境を作るのに四苦八苦しましたが、RUSTはあっというま
感激してここにアップしました
今から勉強します

332 :デフォルトの名無しさん:2022/11/16(水) 07:35:45.01 ID:16ZvLDN4.net
「コピーは使わないでムーブする」なら意味が通じたが

333 :デフォルトの名無しさん:2022/11/16(水) 12:12:43.09 ID:I1e3AS0A.net
>>332
そのつもりで書いてた。
推敲不足だったな。回線ケーブルで首釣るかもしれん。

334 :デフォルトの名無しさん:2022/11/16(水) 18:02:22.96 ID:+n4YDZit.net
一部のアスペ以外はそれぐらいの推論はできるからあまり気にしなくていいよ

335 :デフォルトの名無しさん:2022/11/16(水) 18:02:43.41 ID:QMFF+6Ax.net
そういうのは吊るを使う

336 :デフォルトの名無しさん:2022/11/16(水) 18:29:22.77 ID:XyYlAbZW.net
>>333
お前は誰だよw
俺を語ってんじゃねー

337 :デフォルトの名無しさん:2022/11/16(水) 20:20:41.18 ID:Lkj73ShV.net
.netでrustが使えれば無敵なのに

338 :デフォルトの名無しさん:2022/11/16(水) 21:13:44.67 ID:y4GxYc69.net
GCのランタイム環境でRUSTは意味ないんじゃ?

339 :デフォルトの名無しさん:2022/11/16(水) 21:37:10.96 ID:eOApcCVI.net
ML 系言語が Rust を高水準にした感じじゃない?
(というか ML の研究からリージョン推論が生まれて Rust に繋がっていったのだが……。)
.NET 用だと F# があるから使ってみても面白いかもね。

340 :デフォルトの名無しさん:2022/11/16(水) 21:59:45.42 ID:/cIgFYP8.net
.NETのライブラリが使いたいとかでは

341 :デフォルトの名無しさん:2022/11/17(木) 00:08:08.45 ID:Wvvh1amI.net
rust難しすぎません?
僕はまだまだ、たぶん無理だけど、そこそこできるようになったとしても、全体の底上げがなければ普及が難しいのではという自己弁護

342 :デフォルトの名無しさん:2022/11/17(木) 00:34:44.66 ID:/MItGujg.net
既存のC/C++のコードをRustに書き直すのは
頑張らなくても良いですと言われていても
世界に一人ぐらい頑張る人がいて
再実装しましたみたいなのが時々出てくるな

343 :デフォルトの名無しさん:2022/11/17(木) 00:48:28.80 ID:SzkkMxOu.net
C++ 何となく使っているけど、Rust って難しいの?
C++ より難しいなら、先に勉強しようかな

344 :デフォルトの名無しさん:2022/11/17(木) 01:00:11.07 ID:EPum3E1i.net
>>343 とりあえず動かすのはRustのが難しい
正しく動かすのはC++のが難しい

345 :デフォルトの名無しさん:2022/11/17(木) 01:28:33.22 ID:MDHZgFO+.net
C++ は未定義を踏むのがさすがに簡単すぎるのがいけない。

346 :デフォルトの名無しさん:2022/11/17(木) 01:54:53.99 ID:6uPAxih4.net
>>330
これを徹底すればC++も問題ないよ

347 :デフォルトの名無しさん:2022/11/17(木) 03:15:48.27 ID:Oh632irx.net
>>344
Rustは安全性と処理効率を保ったままさらに高みに登ろうとすると、C++では
可能だったことが不可能なことがある。

348 :デフォルトの名無しさん:2022/11/17(木) 05:38:42.23 ID:MvDxl/Xz.net
>>346
徹底するのが難しい、って話だろ

349 :デフォルトの名無しさん:2022/11/17(木) 05:39:00.42 ID:7vp/wPcJ.net
>>346
「〇〇を徹底します」みたいな精神論が再発防止にならないのは業界の常識

350 :デフォルトの名無しさん:2022/11/17(木) 05:39:30.88 ID:7vp/wPcJ.net
>>347
具体的にはどういうケース?

351 :デフォルトの名無しさん:2022/11/17(木) 07:38:31.41 ID:HsWuKvxv.net
>>350
大規模なマルチスレッドとかじゃない?
それこそ「共有メモリは排他制御を徹底すべし」ってだけの話だけど
数百万行のコードベース全体に対して常時気をつけ続けるというのは人間には無理だろう

352 :デフォルトの名無しさん:2022/11/17(木) 07:44:38.30 ID:EPum3E1i.net
>>351 マルチスレッドこそRustの得意分野だと思うんだけど

353 :デフォルトの名無しさん:2022/11/17(木) 07:48:15.39 ID:AvIWLuzY.net
rustは所有権とかライフタイムとかなければ簡単で使いやすそうって印象

354 :デフォルトの名無しさん:2022/11/17(木) 07:53:43.04 ID:HKu8SavS.net
所有権やライフタイムがいらないならrustである必要ないのでは

355 :デフォルトの名無しさん:2022/11/17(木) 08:37:34.35 ID:HsWuKvxv.net
>>352
あ、逆の話か
C++だと不可能なことがRustだと可能になるって読んでた
357のは思いつかんね

356 :デフォルトの名無しさん:2022/11/17(木) 08:42:54.13 ID:t8CddWfY.net
複雑なマルチスレッドのアプリで俺にしか直せないバグを故意に仕込むことならC++でしかできないかな

357 :デフォルトの名無しさん:2022/11/17(木) 09:56:45.90 ID:AvIWLuzY.net
>>354
プログラマが全知全能でメモリ関係のバグを踏まないって仮定したら所有権やライフタイムがなくてもrustはc++以上の優れた型システムを持ってる

358 :デフォルトの名無しさん:2022/11/17(木) 10:21:30.69 ID:oUYdn6MU.net
>>357
Haskellの方が優れてるよ

359 :デフォルトの名無しさん:2022/11/18(金) 17:50:50.73 ID:nTmfkfcZ.net
米GitHubは11月18日までに、2022年にGitHub上で多く使用されたプログラミング言語ランキングを発表した。

その結果、1位は「JavaScript」だった。以降、2位「Python」、3位「Java」、4位「Typescript」、5位「C#」、
6位「C++」、7位「PHP」、8位「Shell」、9位「C」、10位「Ruby」と続いた。

Rubyに負けたらいけないだろw

360 :デフォルトの名無しさん:2022/11/18(金) 17:57:22.15 ID:G2UZSnwT.net
企業の人ってGitHub使えるのかな?
企業が使い始めたら増えると思うけど。

361 :デフォルトの名無しさん:2022/11/18(金) 18:25:40.22 ID:nTmfkfcZ.net
真の意味でホビーユーザーに支持されなきゃだめだよ

362 :デフォルトの名無しさん:2022/11/18(金) 18:31:52.75 ID:UFs4jVzI.net
ゆきひろにより開発されたオブジェクト指向スクリプト言語か

363 :デフォルトの名無しさん:2022/11/18(金) 18:55:51.18 ID:fYiWUan7.net
このグラフ、Typescriptの躍進とRubyの凋落が対照的で興味深かった。

364 :デフォルトの名無しさん:2022/11/18(金) 19:00:57.54 ID:WkS6x7hj.net
これか
https://i.imgur.com/QE0WMb7.jpg

365 :デフォルトの名無しさん:2022/11/18(金) 21:08:51.27 ID:8iIh2nXZ.net
C/C++の減少分がRustじゃね

366 :デフォルトの名無しさん:2022/11/18(金) 21:48:16.28 ID:G2UZSnwT.net
その説が正しい使い方気がした

367 :デフォルトの名無しさん:2022/11/19(土) 00:42:59.64 ID:h9f1WTcb.net
>>350
効率よくリンクリストやグラフ構造を使うこと。
この(前?)スレで散々議論されていた。

368 :デフォルトの名無しさん:2022/11/19(土) 00:49:11.67 ID:UL/detO7.net
いい加減スレ違いはやめろって

369 :デフォルトの名無しさん:2022/11/19(土) 04:53:18.01 ID:c1VeRjNF.net
>>367
全然具体的でなくて草
そりゃ散々議論(のつもりw)になるわ
コードで示すとか出来ないの?

370 :デフォルトの名無しさん:2022/11/19(土) 09:49:20.36 ID:RDqVxLmi.net
tscがRustだと書き直すのが難しいとか聞いたが

371 :デフォルトの名無しさん:2022/11/19(土) 10:48:30.65 ID:AeJpea+k.net
>>370
tscをRustに一部移植
元のコードがGC前提だから全体の移植は大変なのでGoに変更
GoはGoで無駄な作業が多くて大変。やっぱりRustのほうが良かったのでRustに戻す

というのが今の状況
来年あたりまたGoに戻ってる可能性はあるが

372 :デフォルトの名無しさん:2022/11/19(土) 14:18:44.14 ID:UL/detO7.net
>>371
移植とか考えずに仕様だけ洗い出してからRustで実装するのがベストでしょうね
仕様解析チーム(tscを読み込んでドキュメント化する)
とRust実装チーム(Rustのエキスパートたち)
この2チームがいれば十分だし

373 :デフォルトの名無しさん:2022/11/19(土) 20:51:33.06 ID:W8eLHJQE.net
Rustで実装が難しいようなアルゴリズムは不安全で時代遅れだ説

374 :デフォルトの名無しさん:2022/11/19(土) 20:55:58.15 ID:LAn7MDSu.net
解析してる間にどんどんtscの仕様は変わっていくよ

375 :デフォルトの名無しさん:2022/11/19(土) 21:07:54.54 ID:2PIO0unP.net
Rustってお互いに参照し合うようなグラフ構造を表現しにくいイメージある

376 :デフォルトの名無しさん:2022/11/19(土) 22:17:39.01 ID:ibRUDL6T.net
し難いのか不可能なのかどっちよ

377 :デフォルトの名無しさん:2022/11/19(土) 22:23:36.77 ID:yb7KRrg5.net
rustcでグラフ構造扱ってるよ
ポインタではなくインデックスでアクセする実装

378 :デフォルトの名無しさん:2022/11/19(土) 22:41:12.16 ID:yWSzX/NN.net
>>377
なるほどなあ

379 :デフォルトの名無しさん:2022/11/19(土) 23:28:51.73 ID:PCVv4O5z.net
>>377
前スレ読んでもわかるが、それでやれば出来るのは分かってるんだけど、
効率が落ちるから「ゼロコスト安全性」ではない。

380 :デフォルトの名無しさん:2022/11/19(土) 23:29:54.28 ID:PCVv4O5z.net
>>373
リンク構造を持つデータ構造は今も発展途上中で今後も開発されていくが、
Rustでは取り扱いにくく、むしろRustこそ時代遅れ。

381 :デフォルトの名無しさん:2022/11/19(土) 23:31:24.06 ID:PCVv4O5z.net
ポインタが理解できない人は、ポインタが中心に居るところのリンク構造を全て
無視するから、Rustの欠点が理解できないだけ。

382 :デフォルトの名無しさん:2022/11/19(土) 23:32:17.52 ID:Bzioz9F5.net
>>376
しにくいだけ
>>1のHow to not learn RustとかオライリーのProgramming Rustでも指摘されてたはず

383 :デフォルトの名無しさん:2022/11/19(土) 23:44:21.19 ID:PCVv4O5z.net
>>376
不可能ではないが、C言語のように参照やポインタでダイレクトに取り扱うのが
不可能なので、インデックスを介してアクセスした、非常に複雑な仕組みで
アクセスしたりする必要があり、効率が落ちる。
マシン語レベルで見ると、アクセスすすために必要なコードが増えるから。

384 :デフォルトの名無しさん:2022/11/19(土) 23:44:57.71 ID:PCVv4O5z.net
誤:インデックスを介してアクセスした、非常に複雑な仕組みで
正:インデックスを介してアクセスしたり、あるいは、非常に複雑な仕組みで

385 :デフォルトの名無しさん:2022/11/20(日) 00:54:20.94 ID:uh6X/Buy.net
窮屈だからとか言って車に乗るときにシートベルトを付けないタイプの人かな

386 :デフォルトの名無しさん:2022/11/20(日) 01:12:16.21 ID:RgPem6BD.net
見かけ上はインデックスアクセスでも最適化がかかると途中のアドレス計算はほとんど消滅してポインタでやるのとそんなに差はなくなるよ。
ポインタを露骨に使うのはコンパイラ技術の未熟さをプログラマに補わせてただけ。
十分に高い能力のコンパイラにとってはプログラマが細々とした効率のための指示をするのはむしろ最適化の邪魔になる。

全体の構成やアルゴリズムの話ならともかく、細々とした部分はコンパイラのほうが人間よりよっぽど賢いんやぞ。

387 :デフォルトの名無しさん:2022/11/20(日) 01:28:00.24 ID:8zb5D3SN.net
ahoの「アルゴリズムの設計と解析」という古い本で木構造をインデックスアクセスで実装していたけど
rustにふさわしい実装だったんだな
この本はポインタがない言語を想定していたのだろうけど

388 :デフォルトの名無しさん:2022/11/20(日) 01:29:41.16 ID:mdre8ZhB.net
ポインタで書いた方が速いじゃんて事は現にあったし
昔だと、それでも遅いからってアセンブリ言語で関数書いて呼んだりしたが
今なら、そこまでやらなくてもいいだろう
これは、コンパイラの進化もあるだろうが、CPUの進化の恩恵が大きい

389 :デフォルトの名無しさん:2022/11/20(日) 01:32:00.55 ID:8zb5D3SN.net
脱ポインタの流れは変わらないと思うけどね
安全性とは程遠いからこれを無くさない限り絶対にメモリ安全性は守られない

390 :デフォルトの名無しさん:2022/11/20(日) 09:27:21.62 ID:feChXjeV.net
unsafeつかえばいいじゃん

391 :デフォルトの名無しさん:2022/11/20(日) 13:59:12.71 ID:9/YCbfcZ.net
>>386
インデックスを使おうとすると、1つのオブジェクトを作成する際にヒープから確保できず、
同じ集約(コンテナ)に属する全オブジェクトが入っている配列をreallocするような
動作が必要となり、スプリアス的に「停止時間」が入る。
また、その際キャッシュが大規模クリアされてしまう。

392 :デフォルトの名無しさん:2022/11/20(日) 14:00:19.95 ID:9/YCbfcZ.net
>>390
前スレ(?)で、それでは済まないことが指摘済み。

393 :デフォルトの名無しさん:2022/11/20(日) 14:05:25.97 ID:9/YCbfcZ.net
>>389
自分が理解できないことは「ダメ」なこととしたり、排除しようとしてしまう。
典型例としては:
・数学が苦手な人 --> 数学不要論に走り、学校で教えることすら禁止させようとする。
・オブジェクト指向のメリットが理解できない人 -->オブジェクト不要論に走る。
・ポインタが苦手な人 --> ポインタを排除しようとする。
Rustはポインタを使うデータ構造を上手く使えなくなるようになっているので、
ポインタが理解できない人は、他の人も使えなくなって安堵の境地に浸れる。
オブジェクト指向で最も大事なclassの概念も使えなくなっているので、
オブジェクト指向が使えこなせなかった人は、他の人も使えなくなって、
競走上の劣等性を感じなくてすむ様になって得した気分になる。
しかし、現実は、そう甘くは無い。

394 :デフォルトの名無しさん:2022/11/20(日) 14:06:00.71 ID:RgPem6BD.net
>>391
> 必要となり

ならない。

395 :デフォルトの名無しさん:2022/11/20(日) 14:09:39.17 ID:9/YCbfcZ.net
>>394
インデックスは「連番」なので、その集約に属する全てのノードが、
1つの配列に入ってなければならない。
だから、ノードを追加した時に配列の容量が足りなくなると、
全ノードを入れるための配列の再確保が必要となる。
(全ノードが十分入る容量の配列を一気に確保して、move 動作が必要となる。
この際にキャッシュがほぼ全クリア状態になる。)

396 :デフォルトの名無しさん:2022/11/20(日) 14:14:51.22 ID:9/YCbfcZ.net
>>391
[追加]
さらに、それに加えて、インデックスからオブジェクトにアクセスする際には、
オブジェクトのアドレス計算が必要となる。
それに、次のような掛け算が必要となる:
size = sizeof(OBJECT);
address = base + index * size; // 掛け算。
掛け算は計算科学上遅い処理であり、避けるべき処理である事が知られている。

397 :デフォルトの名無しさん:2022/11/20(日) 14:16:00.87 ID:YFSLlDHr.net
Rustで複雑なことをさせなければいい

398 :デフォルトの名無しさん:2022/11/20(日) 14:19:02.05 ID:RgPem6BD.net
>>396
> 遅い処理

遅くない。

399 :デフォルトの名無しさん:2022/11/20(日) 14:19:28.58 ID:9/YCbfcZ.net
>>396
[補足]
ただし、index * size の値を、「offset 値」として予め計算しておいて、
index値ではなく、offset値をindex値の代わりにすると、この掛け算は
除去できる。
このoffset値は、「相対アドレス」や「相対ポインタ」に相当する。

400 :デフォルトの名無しさん:2022/11/20(日) 14:20:12.92 ID:9/YCbfcZ.net
>>398
ポインタよりは遅い。
32BIT値の掛け算は、16クロックほど掛かる。

401 :デフォルトの名無しさん:2022/11/20(日) 14:20:23.64 ID:8zb5D3SN.net
>>395
Vec使えばそんな不効率なことはせんよ

402 :デフォルトの名無しさん:2022/11/20(日) 14:23:27.03 ID:RgPem6BD.net
>>400
かからない。
原理的には掛け算が高コストなのはわかるが現代の CPU は
その差を埋めるために高度なアドレシングモードを用意した。

403 :デフォルトの名無しさん:2022/11/20(日) 14:26:55.83 ID:9/YCbfcZ.net
>>401
不可能。

404 :デフォルトの名無しさん:2022/11/20(日) 14:27:54.72 ID:9/YCbfcZ.net
>>402
>その差を埋めるために高度なアドレシングモードを用意した。
全く関係無い。
imul命令のlatencyはどんどん速くなって、いて、いまや 3 クロックほどに
なっているらしいが、アドレッシングモードは関係無い。

405 :デフォルトの名無しさん:2022/11/20(日) 14:31:49.56 ID:RgPem6BD.net
>>404
imul は使われない。
関係ないものを持ち出しているのはそっち。

406 :デフォルトの名無しさん:2022/11/20(日) 14:34:23.52 ID:8zb5D3SN.net
この人大丈夫か?
なんか支離滅裂になってきてるが

407 :デフォルトの名無しさん:2022/11/20(日) 14:43:00.42 ID:AxU0uBeT.net
速度求めるならsizeは2のべき乗にするだろうしそれならバレルシフタで相当昔から1クロックで済むだろ
それほど大きくないサイズならアドレッシングモードでサポートしてるプロセッサーもあるし
ID:9/YCbfcZ はもう少しちゃんと勉強した方がいいと思うよ

408 :デフォルトの名無しさん:2022/11/20(日) 14:48:48.34 ID:YFSLlDHr.net
Rustで作ったdenoはなぜか遅いんだよな

https://dev.to/codesphere/bun-the-new-javascript-runtime-competing-with-deno-and-node-115d

409 :デフォルトの名無しさん:2022/11/20(日) 14:49:57.69 ID:9/YCbfcZ.net
>>407
メモリの無駄になるので、一般にはObjectのサイズは2のべき乗には出来ない。

410 :デフォルトの名無しさん:2022/11/20(日) 14:53:40.99 ID:RgPem6BD.net
>>408
元が根本的にダメだったら単に作り直すだけでも速くなったりするが、
大きなプロジェクトの成果物の性能が良いのは細々としたチューニングを続けてきたという蓄積の賜物。
すぐには越えられないのはごく普通のこと。

411 :デフォルトの名無しさん:2022/11/20(日) 15:06:31.98 ID:9/YCbfcZ.net
>>405
配列
T a[N];
に対して、
a[index]
のアドレスを計算する時、
address = ((BYTE *)&a) + sizeof(T) * index;
の計算が行なわれ、マシン語レベルでは :
mov rax,(Tのサイズ)
imul rax,(index)
add rax,(aのアドレス)
と計算される。
Tのサイズが、1,2,4,8 の場合に限っては、
lea rax,[(aのアドレス) + (Tのサイズ) * index]
と書けるが、一般の場合には無理。

412 :デフォルトの名無しさん:2022/11/20(日) 15:15:31.54 ID:feChXjeV.net
>>408
bunが速いのは、denoやnodejsではJSで書かれている部分がbunではzigで書かれていることや
JSエンジンのJITの段数の違いによるもので
rust関係ないという理解なんだけど

413 :デフォルトの名無しさん:2022/11/20(日) 15:17:09.91 ID:9/YCbfcZ.net
>>412
Bunはおいておいて、node(C++製JSエンジン?)とdeno(Rust製JSエンジン?)
では、denoの方がnodeより遅いと読み取れる。

414 :デフォルトの名無しさん:2022/11/20(日) 15:17:10.42 ID:feChXjeV.net
>>392
どのレス?もっかい書いてよ

415 :デフォルトの名無しさん:2022/11/20(日) 15:17:44.33 ID:9/YCbfcZ.net
>>414
レスではなくスレ。
何度も書かない。

416 :デフォルトの名無しさん:2022/11/20(日) 15:24:09.33 ID:feChXjeV.net
>>413
Rust製JSエンジンとか書いてる時点でよくわかってないのが読み取れる

417 :デフォルトの名無しさん:2022/11/20(日) 15:26:15.43 ID:feChXjeV.net
>>415
スレのどのレスか教えてよ

418 :デフォルトの名無しさん:2022/11/20(日) 15:26:41.67 ID:YFSLlDHr.net
>>410
そっか、チューニング大事なんだな

419 :デフォルトの名無しさん:2022/11/20(日) 15:30:49.96 ID:9/YCbfcZ.net
>>417
検索してくれ。

420 :デフォルトの名無しさん:2022/11/20(日) 15:34:04.94 ID:9/YCbfcZ.net
>>416
nodeやdenoは余り知らないから。

421 :デフォルトの名無しさん:2022/11/20(日) 15:39:36.41 ID:feChXjeV.net
>>419
これのこと?
https://mevius.5ch.net/test/read.cgi/tech/1656285423/151

422 :デフォルトの名無しさん:2022/11/20(日) 15:43:51.99 ID:9/YCbfcZ.net
>>421
まあ、そうだ。ただし、それは議論の一部。
ただ、反論する前に、頭がいいことが資格だぞ。
この板は頭の良さに対して全くフィルターが掛かってないから議論が混沌とする。
文字だけで理解するのではなく、イマジネーションと脳内のワーキングメモリー
を働かせて図形的に考えないとダメだぞ。

423 :デフォルトの名無しさん:2022/11/20(日) 15:45:48.15 ID:feChXjeV.net
>>421のレスはすべてをunsafeにすれば可能と暗に言ってるから、
>>392の言うunsafeを使っても済まない場合には該当しないか

424 :デフォルトの名無しさん:2022/11/20(日) 15:47:47.99 ID:feChXjeV.net
>>422
そうだね、文章だけではあなたの脳内の意図をちゃんと読み取れないから想像力が重要だね

425 :デフォルトの名無しさん:2022/11/20(日) 15:56:42.10 ID:9/YCbfcZ.net
>>423
しかし、「すべてをunsafe」にするなら、Rustの意味が全く無いから、
「それでは済まない」。

426 :デフォルトの名無しさん:2022/11/20(日) 15:57:37.84 ID:9/YCbfcZ.net
>>424
ちゃんと書くには長く書く必要があるが、理解できない人が多いから書けない。
そもそも、5chでは文章が途切れて書ききれない。

427 :デフォルトの名無しさん:2022/11/20(日) 16:13:12.85 ID:RgPem6BD.net
>>418
チューニングの蓄積は大事だが、チューニングは実行環境 (など) の特性に合わせるということだから
前提となる特性が変われば今までの蓄積が今度は足を引っ張ることもある。
だからたまにはリセット (別プロジェクトとして始動) をするのも必要なことなんだよ。
少しづつ違う方針のものが併存しているのが健全な状態で、
真似したり反発したりしながら新陳代謝をしていくもんだ。

428 :デフォルトの名無しさん:2022/11/20(日) 19:14:36.78 ID:0EAflA1G.net
グラフとかリンクトリストとかにはarena使えないの?
bumpaloとかtyped-arenaとかid_arenaとかgenerational-arenaとか色々出てるけど

429 :デフォルトの名無しさん:2022/11/20(日) 19:36:54.78 ID:feChXjeV.net
>>426
じゃあなんでこのスレに書いてるの?

430 :デフォルトの名無しさん:2022/11/20(日) 19:37:03.39 ID:feChXjeV.net
>>428
普通に使えるよ

431 :デフォルトの名無しさん:2022/11/20(日) 19:39:01.04 ID:feChXjeV.net
>>425
そもそもすべてをunsafeにする必要があるという前提が偽だよね
特定のデータ構造の操作がプラグラムのすべてなの?

432 :デフォルトの名無しさん:2022/11/20(日) 20:33:05.68 ID:Y0E2xhem.net
単純なLinkedListのdropでstackoverflow
https://matklad.github.io/2022/11/18/if-a-tree-falls-in-a-forest-does-it-overflow-the-stack.html

dropが再帰的に呼ばれそうなところでwarning出してくれたら嬉しいんだけどな


433 :デフォルトの名無しさん:2022/11/21(月) 16:56:19.41 ID:qlbniNQc.net
試しにいろいろやってみたけど
引数を含めて参照渡しなのか値渡しなのか完全に区別されてるのがいいね

434 :デフォルトの名無しさん:2022/11/21(月) 17:12:12.72 ID:VM/mtrCu.net
unsafeは甘え

435 :デフォルトの名無しさん:2022/11/21(月) 17:26:26.15 ID:EfM99hS7.net
超エキスパートの皆さんが unsafe で
システムプログラミングしてくださるんだろうが

436 :デフォルトの名無しさん:2022/11/21(月) 21:30:40.94 ID:rgJVysd6.net
https://qiita.com/ohakutsu/items/5d29001f79d42d63e886
本筋と関係ない部分での強めの態度での批判(というかいちゃもん)、いかにも日本的な陰湿なマウント文化が凝縮されていて笑えない

437 :デフォルトの名無しさん:2022/11/21(月) 21:46:20.48 ID:bYPD5c9s.net
テスト

438 :デフォルトの名無しさん:2022/11/21(月) 21:47:48.09 ID:bYPD5c9s.net
お、書けたか

今日から勉強始めて Tour of Rust やってるんだけどなんか分かりづらいような...?
The Book からやったほうがいいのかな

439 :デフォルトの名無しさん:2022/11/21(月) 21:54:54.43 ID:sdhkglZS.net
Haskellからやった方がいいかも

440 :デフォルトの名無しさん:2022/11/21(月) 22:00:50.98 ID:bYPD5c9s.net
Haskell... モナド... うっ、頭が

441 :デフォルトの名無しさん:2022/11/21(月) 23:01:50.99 ID:gRBDBkQB.net
>>436
本当にこれ
ワイもその記事のコメント欄読んでいたけど
@Akira-T-Hatakeyamaが的外れの癖に高圧的に書いていて見ていて気分が悪くなったわ
サンプルコードもそんなおかしいものではないし事実Cではするメモリリークも防げている
まったく害のない記事を上げたがために揚げ足取りを取られていて不憫や

442 :デフォルトの名無しさん:2022/11/21(月) 23:15:45.42 ID:SGMQ7SqF.net
> Cをきちんと理解していない人が RUST が安全ですと言っても、説得力皆無ですね。

ここに完全同意できてしまうから
この話はもうそこで終わってしまう

批判された側は改善するか記事消すかして
態度で反省を示してほしいわ
ゴミ記事量産すなって話

443 :デフォルトの名無しさん:2022/11/21(月) 23:45:49.72 ID:/NggQuuk.net
callocの代わりにalloca使えとか揚げ足取りがすぎる
普通のOSならメモリリーク起きないというのも意味不明

444 :デフォルトの名無しさん:2022/11/21(月) 23:50:01.01 ID:/NggQuuk.net
とはいえ元記事も微妙でメモリ安全の話をするならuse-after-free等の話をして欲しかった

445 :デフォルトの名無しさん:2022/11/22(火) 06:46:59.40 ID:5norvibI.net
ありがちな不具合を示すサンプルにこうすりゃいいとか言われてもねぇ...
そもそもstr_new()でalloca()使ったらstr_new()から抜けた時に解放されちゃうからもっと酷いことになるのわかってないだろw

446 :デフォルトの名無しさん:2022/11/22(火) 09:08:14.28 ID:XE2I6odc.net
>>441
コメントしてるやつほどではないにしても
記事もそれなりに害のある記事やろ

447 :デフォルトの名無しさん:2022/11/22(火) 10:53:06.52 ID:iGHsIGH/.net
コンパイル時評価の欠点
https://c3.handmade.network/blog/p/8590-the_downsides_of_compile_time_evaluation

Rustが攻撃されてる!許せねぇ!

448 :デフォルトの名無しさん:2022/11/22(火) 11:53:04.77 ID:7hOwVVcX.net
const fnと思ったらmacroの話か
書かれてることはもっともだと思うしrust-analyzerの作者も似たようなことを言っていたような

449 :デフォルトの名無しさん:2022/11/22(火) 12:05:47.11 ID:5norvibI.net
コンパイル時評価の欠点と言うかマクロは混乱しやすいって話だろ
まあ良薬も使いすぎると毒になるしほどほどに使うのは難しいし、処理系のサポートが難しくてエラーメッセージがイミフになるとかあるから半分ぐらいは同意する

450 :デフォルトの名無しさん:2022/11/22(火) 13:20:21.25 ID:8XCnEjtt.net
>>447
この文脈でdownsidesを欠点と訳すのは微妙
「コンパイル時評価のマイナス面」みたいにプラス面の存在が当然の前提となる日本語にしないと与える意味が変わる

451 :デフォルトの名無しさん:2022/11/22(火) 16:03:09.05 ID:gDAAjuMT.net
0..10 で生成されるオブジェクトってイテレータですか?

452 :デフォルトの名無しさん:2022/11/22(火) 16:12:53.87 ID:7RPBFD0W.net
>>451
はい

0..10はRange<i32>
impl<A> Iterator for Range<A> where A: Step
impl Step for i32

453 :デフォルトの名無しさん:2022/11/22(火) 17:02:18.19 ID:gDAAjuMT.net
>>452
ありがとうございました

454 :デフォルトの名無しさん:2022/11/23(水) 08:39:00.67 ID:wkDaFc7P.net
>>453
どういたしまして

455 :デフォルトの名無しさん:2022/11/23(水) 22:54:55.70 ID:/vguy0QL.net
The Bookの日本語版がRust 1.58で英語版がRust 1.62っぽいんですけど、この差が問題になることありますか?

456 :デフォルトの名無しさん:2022/11/23(水) 23:36:05.63 ID:Z55i7UcV.net
>>455 ほぼない
強いて言えば新しい書き方が載ってないぐらい
古い書き方でも問題なく動く

457 :デフォルトの名無しさん:2022/11/24(木) 01:19:12.75 ID:4Rr7WzTC.net
>>455
バージョンの差は問題にならないが日本語版と原文の差は大きい

英語が苦手で原文だと読むのに3倍時間かかるような人でも原文読む方がRustを理解するには圧倒的な近道

458 :デフォルトの名無しさん:2022/11/24(木) 02:03:20.81 ID:7DmT43os.net
英語が駄目って人は百倍かけても読めない。

459 :デフォルトの名無しさん:2022/11/24(木) 02:06:19.42 ID:L4U2ehwP.net
The Book自体がそんな一生懸命読むべきもんじゃない
別のそのへんの本屋で売ってるRust本でもいい

460 :デフォルトの名無しさん:2022/11/24(木) 02:06:45.58 ID:01gKjbzi.net
機械翻訳も良くなったとは言え普通に間違えるし英語読めない人なら日本語版の方がいいでしょ

461 :デフォルトの名無しさん:2022/11/24(木) 03:11:31.83 ID:7Kcsa8Zb.net
あの日本語版はないわな
Rust習得の弊害でしかない

462 :465:2022/11/24(木) 09:13:21.63 ID:/ycVFx5q.net
様々な意見、ありがとうございます!
両方を見比べて大きな差がありそうなところは英語版を翻訳して読んでみようと思います

463 :デフォルトの名無しさん:2022/11/24(木) 09:14:00.12 ID:ZOGzuV/a.net
日本語版の一番の欠点は、基礎や概念を説明している項目が所々抜けてることだろうな
なんもわからないまま結論を覚えるだけになってしまう

464 :デフォルトの名無しさん:2022/11/24(木) 10:04:24.95 ID:wZ9/qcyF.net
Rustって難しくね?
できればライフタイムあたり意識しないでプログラミングしたいんだけど

465 :デフォルトの名無しさん:2022/11/24(木) 11:37:21.52 ID:rSYd8nrB.net
そういう難しいところに直に向かい合うための言語なので...

466 :デフォルトの名無しさん:2022/11/24(木) 12:37:17.60 ID:5MNsXfkj.net
Typeshareが1.0になったけどどない?
https://github.com/1Password/typeshare

467 :デフォルトの名無しさん:2022/11/24(木) 13:01:03.30 ID:lMxgdHP2.net
日本語版ダメだと思うなら添削してくれればいいのに
英語出来る俺スゲーとかマウント取りたいだけの人なんかな

468 :デフォルトの名無しさん:2022/11/24(木) 13:14:00.92 ID:rSYd8nrB.net
仮に貢献してても5chじゃなくて別のコミュニティで表明するんじゃね

469 :デフォルトの名無しさん:2022/11/24(木) 13:18:22.75 ID:B8EZvrTz.net
横からだけど義務教育で人並みの勉強をして英語がまったくできないっていうのは
本人の資質に問題があると思っている
(もちろん面と向かってこんなことは言わないけど)

470 :デフォルトの名無しさん:2022/11/24(木) 13:26:27.68 ID:rSYd8nrB.net
やっぱり>>467の意見が正しいわ

471 :デフォルトの名無しさん:2022/11/24(木) 13:29:37.83 ID:B8EZvrTz.net
マウント取りたいではなく、それくらい基本的なことなので
日本語版が無いと無理、英語版は無理、的なこと言うのは
それだけで足元見られる可能性がある、という話です

472 :デフォルトの名無しさん:2022/11/24(木) 14:12:12.17 ID:Td5Dmo+3.net
余計なこと書くからマウント取りに来てると言われる
やりたくない理由とかいちいち書かなくてもいい

473 :デフォルトの名無しさん:2022/11/24(木) 14:16:41.96 ID:ZOGzuV/a.net
まあ本当に必要なんだったら、翻訳してくれる人にお金を出したらいいんじゃないか?

474 :デフォルトの名無しさん:2022/11/24(木) 14:22:39.63 ID:B8EZvrTz.net
足元見られるとも知らずにRustに関する発言、情報発信はしないで欲しい。
背伸びしなくて良いよ、一発逆転なんて無いよと思う。
日本語版はそもそも無い方が良い。訳注満載の付加価値がない限り。(>>473には同意)

475 :デフォルトの名無しさん:2022/11/24(木) 14:31:48.71 ID:Td5Dmo+3.net
日本語版ダメだよ

だったら直してよ

金出して訳してもらえ

こんな感じ?「俺に金出せ!」でもないらしい。

476 :デフォルトの名無しさん:2022/11/24(木) 14:36:47.65 ID:L4U2ehwP.net
金出して本買え

477 :デフォルトの名無しさん:2022/11/24(木) 14:39:33.49 ID:B8EZvrTz.net
>>475,476
エンコーディング周り、OS毎の違いなど付加価値要素はたくさん有るので
誰かが有償orタダでやってくれるのには文句はない。
ところで、大人になって英語を敬遠している人って、学校時代、
授業で良い発音で教科書を読む人をクスクス笑ってた人でしょ?

478 :デフォルトの名無しさん:2022/11/24(木) 14:50:48.56 ID:7DmT43os.net
そりゃあ個々人としては英語を読めりゃあそれに越したことはないがなぁ。
だけど自国のコミュニティ、自国語の資料をそろえることが出来ないというのは格好悪い話であるのも確かだよな。

479 :デフォルトの名無しさん:2022/11/24(木) 14:59:33.05 ID:B8EZvrTz.net
>>478 クスクス笑ってた側の人ですか?
あと、このスレ、執筆家が何人かいる気がするのは何故?

480 :デフォルトの名無しさん:2022/11/24(木) 15:18:32.24 ID:/JtPgST+.net
>>469みたいな主張の人は能率の高低論を読める読めない論にすり替えている
日本の義務教育の英語レベルは英語の技術資料を日本語と同等にすらすら
読めるとはほど遠いだろう
英語が読めても日本語と比べたら低能率って人は少なくないという点を無視している

481 :デフォルトの名無しさん:2022/11/24(木) 15:23:14.78 ID:SV+v/fkD.net
ここはRustスレなので、英語の話がしたいなら英語スレへ

482 :デフォルトの名無しさん:2022/11/24(木) 15:33:59.04 ID:rSYd8nrB.net
一方rustコミュニティはコンパイラのdiagnosticの翻訳者を募集していたのであった
https://blog.rust-lang.org/inside-rust/2022/08/16/diagnostic-effort.html

>>474はこういうのもやらない方が良いと思ってる?

483 :デフォルトの名無しさん:2022/11/24(木) 15:36:53.62 ID:rSYd8nrB.net
bookもどんどん翻訳するなら支援するとのこと
> We'd love help translating the book!

https://github.com/rust-lang/book

484 :デフォルトの名無しさん:2022/11/24(木) 15:41:27.99 ID:3VG0Xg5C.net
とりあえず日本語で学びたいという人はちゃんとした日本語書籍を買って読むことをすすめる
とにかく最初からあの低品質の日本語訳読むのはオススメしない

ただThe Bookレベルの英語は読めるようにしないとリファレンスも読めないしStackOverflowや公式フォーラムも読めないからすぐ詰むよ

485 :デフォルトの名無しさん:2022/11/24(木) 15:41:58.17 ID:B8EZvrTz.net
>>480
>英語が駄目って人は百倍かけても読めない。
これを受けて、読める読めない論を展開していたんだけど、読解力の問題?
>>482,483
>まあ本当に必要なんだったら、翻訳してくれる人にお金を出したらいいんじゃないか?
なんにしても、必死に日本語版、自国語の資料を擁護する勢力がいることに新鮮な驚き。
クスクス笑ってた側の人ですか?

486 :デフォルトの名無しさん:2022/11/24(木) 15:45:21.17 ID:B8EZvrTz.net
>>484 前半、後半、ともに同意です

487 :デフォルトの名無しさん:2022/11/24(木) 15:55:09.50 ID:rSYd8nrB.net
個々人の生存戦略としてはそりゃ英語読めた方が良いけど
コミュニティとしては裾野を広げるために各種言語のリソースは用意されてた方が良い
bookの翻訳が不十分なのは課題だが、だからといって翻訳の取り組み自体を否定するのは違うんじゃないの?
それとも英語等のハードルを越えた人間のみ触れるものであるべきという思想なのかな

488 :デフォルトの名無しさん:2022/11/24(木) 15:59:42.08 ID:gyRXVBW5.net
Rustの翻訳コミュニティって以前から揉めてるけど
それがよくわかるスレだね

489 :デフォルトの名無しさん:2022/11/24(木) 16:03:48.82 ID:B8EZvrTz.net
>>487
いやいや、英語を奉り過ぎだって。
それくらい基本的なことなのに英語を敬遠する勢力がRustコミュニティで発言、情報発信はしないで欲しい。
クスクス笑ってた側の人かどうか、そろそろ表明してくれませんか?

490 :デフォルトの名無しさん:2022/11/24(木) 16:11:10.23 ID:rSYd8nrB.net
>>489
残念ながらその態度はCoCに反するのでコミュニティで行動していけないのはあなたの方なんだよなぁ
https://www.rust-lang.org/policies/code-of-conduct

491 :デフォルトの名無しさん:2022/11/24(木) 16:19:22.01 ID:B8EZvrTz.net
>>490
ポリコレを真に受けて衆愚コミュニティにしたいなら、あなた自らが翻訳を率先するのが筋です。

492 :デフォルトの名無しさん:2022/11/24(木) 16:23:22.95 ID:rSYd8nrB.net
>>491
平気でライセンス違反とかしちゃう人?
少なくとも自分がコミュニティで望まれてない人材とは自覚しておいてね

493 :デフォルトの名無しさん:2022/11/24(木) 16:32:29.37 ID:B8EZvrTz.net
>>492
多分それは別人です。
自分はRustコミュニティに何の貢献もしてませんが、
あなたは、The Book日本語版(Rust 1.58)に携わった方ですか?
それともライターさんですか?

494 :デフォルトの名無しさん:2022/11/24(木) 16:38:28.16 ID:WiL1nOOz.net
Rust は崇高なものであるべき
みたいな人がいるんだな…

495 :デフォルトの名無しさん:2022/11/24(木) 16:39:48.68 ID:t2djUU2z.net
てかそんなやつばっかじゃん。プライド高くてさ。

496 :デフォルトの名無しさん:2022/11/24(木) 17:03:55.18 ID:B8EZvrTz.net
>>494,495
そんな思い上がりは全くありません。英語一つでここまで必死に拒絶する、単純翻訳を崇め奉る勢力の存在、その資質に興味があるだけです。
こちらは翻訳の際の付加価値について認めているのに、翻訳活動を全否定されたかのような反応、読解力。
最初は冗談半分でしたが、本当にクスクス笑ってた側の人、うぇーい、したいだけの人のイメージが浮かんで来ます。
純粋に、資質に興味があるだけです。
それとも、本当にライターさん(ネットメディア?)か何かなんですかね。

497 :デフォルトの名無しさん:2022/11/24(木) 17:36:37.60 ID:rSYd8nrB.net
>>496
あなたの言う付加価値はローカライゼーションにまつわる固有事情の記事を追加せよという話だよね
付加価値があって初めて価値があるという発言は翻訳そのものには価値を認めてないんだから翻訳自体を全否定してるんじゃないの

あなたの発言は英語もできないやつは人間のカスだからrustに近づくんじゃないとしか読めないんだけど、解釈間違ってる?

498 :デフォルトの名無しさん:2022/11/24(木) 17:46:15.18 ID:B8EZvrTz.net
>>497
前半:全否定されたかどうかが気になってしょうがないのでしょうが、こちらはそこに含意は無く、付加価値が満載なら文句は無いです、有償無償問わず。
後半:ずいぶん卑屈な受け止め方ですね。なんでそんな感性が身にしみついちゃったんですか?拡大解釈し過ぎです。

499 :デフォルトの名無しさん:2022/11/24(木) 17:49:09.85 ID:B8EZvrTz.net
追加:自分は一言多いとよく言われます。誤解されやすい人です。

500 :デフォルトの名無しさん:2022/11/24(木) 17:52:10.07 ID:CxyqHr52.net
仮に日本語で読解に1時間かかるとする。英語だと読解に1.5時間かかるとする
100人いたらその差は50時間
これを英語は読めれば問題ないなどと正当化していたら競争力が落ちるのは当然であろう

501 :デフォルトの名無しさん:2022/11/24(木) 18:12:49.43 ID:/hunkqEb.net
俺は人に教える時に重宝してるけど
初めはざっくり理解できればいいし

502 :デフォルトの名無しさん:2022/11/24(木) 18:13:50.45 ID:B8EZvrTz.net
>>500
その仮定、その足し算に何の意味があるのか、誰の競争力の話か分かりませんが、とにかく頑張ってください。付加価値期待してます。
追加:1.5倍くらいなら英語で頑張り続けたら長くても1~2ヶ月くらいで、≒1倍になるのが適正な資質
その間の努力、時間配分が出来ないならタダの背伸び、無いものネダリ、わがまま、甘え

503 :デフォルトの名無しさん:2022/11/24(木) 18:15:51.60 ID:B8EZvrTz.net
>>501
わかります。ものになるかわからない人に時間を掛けたくないですよね。

504 :デフォルトの名無しさん:2022/11/24(木) 18:16:33.16 ID:7DmT43os.net
入門ってのは基本的な概念を知らん状態なわけだもんな。
母語の資料があってもそれなりにしんどいので英語は勘弁してつかぁさい。

基本理念がわかればそこから後はまあまあわかるよ。

505 :デフォルトの名無しさん:2022/11/24(木) 18:19:43.47 ID:tZHOriba.net
言うてまあこれが一発目の言語ならともかく
普通は(?)CもC++もやってからこれに手を出すやろ?
今更英語とかどうとか言う話になる?
プログラミング言語一般のリテラシーが英語を乗り越えてしまうやろ?

506 :デフォルトの名無しさん:2022/11/24(木) 18:20:35.82 ID:4/0XLjMc.net
Rust入門レベルを英語で読むって学部1年レベルの線形代数を英語で読むようなものだよ

507 :デフォルトの名無しさん:2022/11/24(木) 18:46:40.03 ID:VGz25HBF.net
>>502
その理屈が通るなら日本語に限らず母国語の資料なんて不要になる
もちろんそんなことはない時点であなたの主張は破綻している

508 :デフォルトの名無しさん:2022/11/24(木) 19:08:31.32 ID:B8EZvrTz.net
>>504 100倍の人ですね。
>>505 せめてPython/JavaScriptでも十分(失礼)ですから先にやっておいて欲しいですよね。
>>506 線型代数、高校のベクトル・行列とは何だったのかレベル。
新概念習得と外国語(英語)は相性が良いですよ。すべてが専門用語だとみなせます。むしろ日常会話の単語チョイスに支障が出ますが。

509 :デフォルトの名無しさん:2022/11/24(木) 19:16:37.71 ID:B8EZvrTz.net
>>507 拡大解釈し過ぎです。何の話をしている文脈なのか、読解力、国語力とは。
1~2ヶ月くらいの努力、時間配分を怠ると、一生ローカライズ産業(非最先端)の食い物にされます。食い物にする側に組する立場ですか?
ライターさん?今後のRust記事注目します。

510 :デフォルトの名無しさん:2022/11/24(木) 19:18:22.16 ID:RwBqHjG8.net
どうしちゃったの、このスレw
まあ、それほど王道と言えるルートが無くて
多少混沌とした落とし穴のある、いばらの道なのかな

511 :デフォルトの名無しさん:2022/11/24(木) 19:31:21.34 ID:tZHOriba.net
>>510
常にどうかしちゃってるのがこのスレ
意味不明なマウント合戦や
「所有権の複製」なる謎用語が平気で飛び交うスレ

512 :デフォルトの名無しさん:2022/11/24(木) 19:34:18.21 ID:gyRXVBW5.net
トレイト境界の翻訳で一生揉めてたから
翻訳の話題はNGにしないか?

513 :デフォルトの名無しさん:2022/11/24(木) 19:44:14.11 ID:wuF6EKEG.net
いっそのこと日本語での書き込み禁止で

514 :デフォルトの名無しさん:2022/11/24(木) 19:50:46.51 ID:5MNsXfkj.net
みこちは一兎(ぺこら)しか追ってないのに得られないよね…

515 :デフォルトの名無しさん:2022/11/24(木) 19:52:52.93 ID:5MNsXfkj.net
誤爆した恥ずかしい(*/□\*)
ちなみにこちらです↓
【バーチャルyoutuber】兎田ぺこら#254【ホロライブ/hololive】ID無し
https://egg.5ch.net/test/read.cgi/sugiuraayano/1669282879/

516 :479:2022/11/24(木) 20:23:00.17 ID:B8EZvrTz.net
決して面と向かっては言えない私的な世界観ですが、予想以上の反応がありためになりました。
特に、執筆家・ライター・翻訳家・ネット記事・出版などと推測される、母国語資料勢・ローカライズ産業の存在を意識したことはこれまでなかったので。逆に英語一つで足元見る奴がいることに驚いた人もいるかもしれません。
自分的には、今後ネットのRust記事(日本語)と5chスレの関連性に注目してみます。

517 :デフォルトの名無しさん:2022/11/24(木) 20:27:49.73 ID:aQORibhF.net
この手の奴って英語なんて読めて当然だ言うくせに国語を英語にすればいいとか言わないよな
結局の所イキりたいだけの自己中なんだろう。社会にとって有害なタイプじゃね

518 :デフォルトの名無しさん:2022/11/24(木) 20:33:45.50 ID:sBZ5giiA.net
日本語版見て勉強してたけど英語版から欠落した情報があるんだな
よく分からなかったところを見比べてみるわ

519 :デフォルトの名無しさん:2022/11/24(木) 20:45:47.88 ID:ZPzzCY+f.net
英語読めるに越したことはないし翻訳怪しい所は原文見た方がいいけど日本語版あるのにわざわざ日本人が英語版を読む必要はない
英語の勉強するならそれ専用でやった方がはるかに効率的なので

520 :デフォルトの名無しさん:2022/11/24(木) 20:46:18.83 ID:tqD1idY4.net
あの日本語訳はこういうのが盛りだくさん

「最後の違いは、定数は定数式にしかセットできないことです。関数呼び出し結果や、実行時に評価される値にはセットできません。」

時間を使って読むに値しない

521 :デフォルトの名無しさん:2022/11/24(木) 20:55:01.86 ID:V/Uo5ox3.net
英語もコンピュータ言語も全くできない人は無理せず日本語で勉強すればいいと思うけど、JavaScript を読めるレベルなら、英語読まないでコードから読んで英語は補助的に読んでみたりとか、工夫のしようはあるで。

522 :デフォルトの名無しさん:2022/11/25(金) 00:02:56.61 ID:HP+HUenZ.net
文句言うばっかりで誰もpull req出さないから変な日本語が放置されるという
変だなと思ったら気軽に修正案投げられるような仕組みがあるとよいね

523 :デフォルトの名無しさん:2022/11/25(金) 00:11:51.41 ID:mKVQfMbx.net
プルリク何百個だせばいいんだよってなる
サンクコストとして捨てちゃったほうが日本のRustコミュニティにとってはプラスなんじゃないかな

524 :デフォルトの名無しさん:2022/11/25(金) 00:14:11.06 ID:9EBigD0X.net
>>520
確かにいい訳ではないけど
理解できない原因は
専門用語をちゃんと理解していないことに
起因することが多い

この文も「定数」「定数式」「セット」が理解できれば
そんなに難しいことは書いていない

525 :デフォルトの名無しさん:2022/11/25(金) 00:32:29.91 ID:HP+HUenZ.net
>>523
何百くらいなら一人一回PR送るだけでもほぼ直るんじゃね

526 :デフォルトの名無しさん:2022/11/25(金) 00:39:08.22 ID:+ImZ41H+.net
>>524
誰かが理解できないって言ってた?

527 :デフォルトの名無しさん:2022/11/25(金) 00:39:41.10 ID:FYsweZxP.net
>>524
本当に書いてること理解できてるか
もう一度よく読み直そうか

528 :デフォルトの名無しさん:2022/11/25(金) 07:45:02.58 ID:HZEumDr5.net
>>526
理解できるなら問題なくね?

529 :デフォルトの名無しさん:2022/11/25(金) 07:48:42.32 ID:6Yi+j4c1.net
安心安全のために少し日本語がスパゲッティ状態になるのは仕方がないんだろ

530 :デフォルトの名無しさん:2022/11/25(金) 08:02:50.13 ID:v7fq4Pg1.net
プログラム一般論だけど
書籍抜きで進めて、分からない事をぐぐって行くと
最終的には stackoverflow 辺りにたどり着くんじゃない

531 :デフォルトの名無しさん:2022/11/25(金) 08:11:39.93 ID:m5nB+QH5.net
>>520
これ原文は

The last difference is that constants may be set only to a constant expression, not the result of a function call or any other value that could only be computed at runtime.

だけど、どう訳すのが適切なの?

532 :デフォルトの名無しさん:2022/11/25(金) 08:12:56.32 ID:ROoDFC7c.net
日本の商業技術書は中身がググるレベルのクソ雑魚なのはあるある
特に流行物はその確率が高く、下手すると同人技術書の方がマシまである

533 :デフォルトの名無しさん:2022/11/25(金) 08:19:17.40 ID:8BzXPUw/.net
日本での旧Xam○rinコミュニティの構図が思い出されます。
技術本位で勝負している人たちの大多数に見透かされましたからね。
Rust日本語訳勢の一部もそういう構図があるんですな。

英語苦手同士で助け合いましょ

わかる

機械翻訳を手作業で体裁整えました。すごい努力でしょ?

時間を使って読むに値しない

英語得意な人、普通に助けてくれるでしょ?一人一回PR送るだけなんだからね!

は?学生時代、クスクス笑ってた側を助けるわけないじゃん

私をマウントしないでください。英語苦手な人の方が多数派でコミュニティの裾野を広げるため...

は?繋がりピラミッド構図作ってマウントしたがってるのはそっち

534 :デフォルトの名無しさん:2022/11/25(金) 08:23:37.14 ID:tPlp31O1.net
学生時代にクスクス笑われたのがトラウマになってんのか、かわいそうに

535 :デフォルトの名無しさん:2022/11/25(金) 09:06:15.37 ID:fjezKZFE.net
旧Xam○rin(現MAUI)の話で言うと、多数の別スレで毎日大暴れのMAUI君、英語苦手なのにガンガン成果?を見せてくるあたりは技術志向が強くてバイタリティーがあるので、問題発言だらけだけど許容範囲かな(Flutter側にもバイタリティーが欲しい)
英語苦手って人もいろんな貢献の仕方があるよね。

536 :デフォルトの名無しさん:2022/11/25(金) 10:07:23.50 ID:9BOxb4Qm.net
>>534
あ〜あ言っちゃいましたね。Rustでガリ勉してる人の事も内心ではクスクス笑ってるんだろ。

537 :デフォルトの名無しさん:2022/11/25(金) 11:07:23.77 ID:vXLNQ2UM.net
機械翻訳使うなっていうのは志賀の件で合意得られたはずなのになんでやるかなぁ

538 :デフォルトの名無しさん:2022/11/25(金) 11:15:50.25 ID:cn0AfbS4.net
英語読めないやつはRustそもそも向いてないと思う
日本語の情報が充実している言語にしておいた方がいいよ

539 :デフォルトの名無しさん:2022/11/25(金) 11:22:23.99 ID:4bp1jaeM.net
被害妄想なんかにまじめに付き合ってられないよ

540 :デフォルトの名無しさん:2022/11/25(金) 11:22:31.94 ID:2L/AZJad.net
あれ?いつの間にか機械翻訳使ってるなんて証拠でも出たんか?
またいつもの人が妄想膨らませてるだけと思ってたけど

541 :デフォルトの名無しさん:2022/11/25(金) 11:33:46.83 ID:HP+HUenZ.net
>>531
定数は定数式にしかセットできない

定数には定数式しかセットできない
の方がすんなり読めるんだけどセットの意味合いが他と整合性とれなくなったりする?

542 :デフォルトの名無しさん:2022/11/25(金) 11:47:02.77 ID:PJRcnhAQ.net
そもそもの内容を理解していないのなら翻訳をする資格はないよね。
そっとしておいてほしい。機械翻訳なんてもってのほか。

543 :デフォルトの名無しさん:2022/11/25(金) 12:05:22.61 ID:v5uvIKgG.net
あるいは、原文の疑問点になりそうな箇所は須らくコードで実証すべし
機械翻訳がやってくれない人間による付加価値

544 :デフォルトの名無しさん:2022/11/25(金) 12:17:11.54 ID:9A6C+y48.net
>>538
これでいいと思う。

545 :デフォルトの名無しさん:2022/11/25(金) 12:21:48.12 ID:OY9VtEiW.net
>>538
現状はそれでいいと思う

546 :デフォルトの名無しさん:2022/11/25(金) 12:24:24.73 ID:tJ38pL4L.net
>>541
かく乱しないで欲しい。

547 :デフォルトの名無しさん:2022/11/25(金) 12:32:01.12 ID:pYHT3oH4.net
今構造体の勉強してんだけどユニット構造体ってどう言う時に使うの?
トレイトで使うって見たけどいまいちわからん

548 :デフォルトの名無しさん:2022/11/25(金) 12:32:35.70 ID:3NnLJm/9.net
マジで荒らすな
ここに来るな
単発Ngするぞ

549 :デフォルトの名無しさん:2022/11/25(金) 12:32:54.94 ID:hG6NI52Y.net
>>531
deepl下敷きにして修正すりゃいい。

最後の違いは、定数は定数式にのみ設定でき、関数呼び出しの結果や実行時にのみ計算される他の値には設定できないことです。

any otherが残念だけど、まあOKだろ。

550 :デフォルトの名無しさん:2022/11/25(金) 12:37:02.65 ID:9dhUDnXy.net
>>549
ダメだろ
ところで>>541 はSF時間で仕事している人かな?

551 :デフォルトの名無しさん:2022/11/25(金) 12:39:37.74 ID:hG6NI52Y.net
>>550
駄目な理由を指摘できない無能がマウントしてくるからRustは駄目なんだよ。

552 :デフォルトの名無しさん:2022/11/25(金) 12:39:46.16 ID:scn2u8sN.net
>>549
DeepL とか英語全く出来ない人の発想なので、他所では言わん方がいいで。
使うのはいいけど、コッソリ使ってね。

553 :デフォルトの名無しさん:2022/11/25(金) 12:44:43.95 ID:dNgwgIBZ.net
>>531
そういえば以前、全訳に挑んでいる、とかいう妄想を見たけど関連あったりする?

554 :デフォルトの名無しさん:2022/11/25(金) 12:48:03.92 ID:hG6NI52Y.net
>>552
内容を見ないで手段に文句をつけるのは無能のやることだよ。

555 :デフォルトの名無しさん:2022/11/25(金) 12:57:12.51 ID:qsZx06Ly.net
>>551
マジでRustはどうでもよくてピラミッド作りたい奴なのか。
ここにいるお人好しhelperさんを底辺に組み込みたいのか?

556 :デフォルトの名無しさん:2022/11/25(金) 13:00:28.35 ID:Y7KZiKcU.net
どうせ素人相手にマウント取っているアフィカスだろ
素人に毛が生えた程度なので突っ込まれても反論できない
具体的な議論は出来ないから話題そらしに終始する
最近この手の輩はここだけじゃなくあちこちのスレで見るわ

557 :デフォルトの名無しさん:2022/11/25(金) 13:02:05.70 ID:HZEumDr5.net
>>541
そもそも
> 定数は定数式にしかセットできない

> 定数には定数式しかセットできない
じゃ意味違うよね
上は「定数式 = 定数」
下は「定数 = 定数式」
英文読む限りは上のような気がするが言語仕様的には下のような気がする
どっちが正しいんだ?

558 :デフォルトの名無しさん:2022/11/25(金) 13:08:19.55 ID:ZVM62PVL.net
>>556
このスレは何処かでまとめられてるの?

話題そらし:
旧Xam○rin(現MAUI)の話で言うと...
今構造体の勉強してんだけどユニット構造体ってどう言う時に使うの?
ところで>>541 はSF時間で仕事している人かな?
どっちが正しいんだ?

559 :デフォルトの名無しさん:2022/11/25(金) 13:21:30.46 ID:D+kphDHJ.net
>アフィカス
まだ気が早いけどワッチョイを使えば多少は防げるもんなの?

560 :デフォルトの名無しさん:2022/11/25(金) 13:31:54.44 ID:j44SSeWl.net
>>557
be setだから下だろバカ

561 :デフォルトの名無しさん:2022/11/25(金) 14:44:15.84 ID:wOyL9/CI.net
>>555
???
>>550のどこにhelper要素ある?

マウントばかり取ろうとする役立たずの無能を底辺に組み込みたいというのは肯定するけど、
>>550がお人好しhelperというのは否定するわ。

562 :デフォルトの名無しさん:2022/11/25(金) 14:52:48.53 ID:NT6Ragjt.net
>>560
set A B (SVOO)…(ア)

A := B

set B to A (SVOC)…(イ)

A := B

(ア)は以下2通りの受動態に書き換えられる
A is set B …(1)
B is set to A …(2) (O2を主語にする場合O1の前にtoを補う必要がある)

(イ)は以下1通りの受動態に書き換えられる
B is set to A …(3)

(1)と(2)(3)ではA, Bの並びが逆になるから「be setだから下だろバカ」は間違いで、「be set toだから上だろバカ」が正しいように思える

しかしGoogle翻訳だと、
The variable is set to "バカ"
を英語に翻訳すると、
変数は「バカ」に設定されています
に、
"バカ" is set to The variable
を英語に翻訳するとこちらも、
変数に「バカ」を設定
に、
なるんだよなぁ…
不思議!

563 :デフォルトの名無しさん:2022/11/25(金) 15:02:34.88 ID:TzWxad5d.net
>>557
https://www.enago.jp/academy/set-to-be/

In the first case, gamma is set to 1.
で「最初のケースの場合、gammma は 1 に設定される」
みたいな意味らしいから、
I set X to 1.
は、「私は X を 1 に設定した」のような意味になることが有る。
一方、
I assign 1 to X.
は、「Xに1を代入する」の意味になる。
to Y と書いたとき、Y が代入先(dest)なのか、代入元(src)なのかは、
動詞や文脈によって変わってきてしまうのかも知れない。
assgin の場合は、assign src to dest に固定されているはず。
set の場合は、文脈によってどちらも有りうるかも知れない。

564 :デフォルトの名無しさん:2022/11/25(金) 15:04:42.52 ID:RgnS8UuF.net
>>559
ならない。IDコロコロがワッチョイコロコロになるだけだし常識ある人が離れる分悪化する可能性が高い
奴の主張によればワッチョイが違うから別人だ!になるのは明らかだし、それで盲目信者の巣窟になった
スレをいくつも見てきた
てかアマゾンや一部のブログを弾いているくせにアフィYoutbeが野放しになっている時点で・・・

565 :デフォルトの名無しさん:2022/11/25(金) 15:06:25.98 ID:v7fq4Pg1.net
定数をバインドする式を定数式と呼ぶってことだろ
公式原文も色々怪しくて論議があるから、脳内で意訳しとけ

566 :デフォルトの名無しさん:2022/11/25(金) 15:08:01.76 ID:TzWxad5d.net
>>563
[続き]
I set X to 1.
とかけて、Xがdest(式の左辺)、1が src(式の右辺)であり、
X = 1;
の意味になる。
「The last difference is that constants may be set only to a constant expression,
not the result of a function call or any other value that could only be computed at runtime.」
の意味は、定数の右辺は、定数式、つまり、
constants = constant expression.
だけが許されて、
consttants = f(・・・);
などの、実行時に計算するしか結果が分からないような値は、右辺に来ることは無い、
という意味になるようだ。

567 :デフォルトの名無しさん:2022/11/25(金) 15:13:16.78 ID:TzWxad5d.net
>>562
>set B to A (SVOC)…(イ)
>も
>A := B
set以外の動詞の英語の基本原則からするとその通りで、
動詞 A B

動詞 B to A
は多くの場合、同じような意味になることが多い。
ところが、set の場合、話がややこしいらしく、
実は、
set B to 1
は、
B := 1
の意味になるらしい。
setだけが原則を破って必ず逆になっているのか、それとも、
文脈によって変わってきてしまうのかは不明。

568 :デフォルトの名無しさん:2022/11/25(金) 15:21:16.45 ID:HP+HUenZ.net
>>565
バインドの主従が逆じゃね
定数は定数式しかバインドできない
const文の左辺が定数、右辺が定数式

569 :デフォルトの名無しさん:2022/11/25(金) 15:22:45.12 ID:TzWxad5d.net
>>567
[補足]
(例)
He gave me a chocolate. (1)
He gave a chocolate to me. (2)
は、原則的な意味としては同じ。ただし、meの様な代名詞の場合(1)で書くとは
聞いたことがある。
I assing 1 to X.
I assing X 1.
も同じ意味になるはず。
ところが、
I set X to 1.
は言えても、
I set 1 X.
は多分言えないような気がする。
英語は難しい。

570 :デフォルトの名無しさん:2022/11/25(金) 15:26:46.87 ID:8N49L/hO.net
力説中のところ申し訳ありませんが、大事なことだと思いますので。

日本語訳の方には、ページごとに原文の特定バージョンへのリンクがあると良いと思いました。

理由
>>531が持って来た原文が現在の原文
The last difference is that constants may be set only to a constant expression, not the result of a value that could only be computed at runtime.
と違うので、はて?と思いHistoryを調べました。

Committed on Jul 24, 2021
https://github.com/rust-lang/book/commit/05d9c4c2312a6542f792492d17a62f79ad6dfd7b#diff-babf686b8b57cc7dd67fd06d087303fe92115f8a5d9fd5dca7cef8645a25bb58R104

日本語版のトップに書いてある日付よりも多少ラグがありました。
https://doc.rust-jp.rs/book-ja/title-page.html
>このテキストのこの版ではRust 1.58(2022年1月13日リリース)かそれ以降が使われていることを前提にしています。

探すのは難しいことではありませんが、手間と言えば手間で、せっかくのcontributeの意欲を削ぎかねません。

571 :デフォルトの名無しさん:2022/11/25(金) 15:35:57.85 ID:TzWxad5d.net
>>569
どこの話なのかと思っていたが、
https://doc.rust-lang.org/book/ch03-01-variables-and-mutability.html
に書いてあるものだった。
こうなっているから、>>566の解釈で有っている気がする :

The last difference is that constants may be set only to a constant expression, not the result of a value that could only be computed at runtime.

Here’s an example of a constant declaration:

const THREE_HOURS_IN_SECONDS: u32 = 60 * 60 * 3;

572 :デフォルトの名無しさん:2022/11/25(金) 15:41:09.30 ID:TzWxad5d.net
>>571
[補足]
>const THREE_HOURS_IN_SECONDS: u32 = 60 * 60 * 3;
>The constant’s name is THREE_HOURS_IN_SECONDS and
>its value is set to the result of multiplying 60 (the number of seconds
>in a minute) by 60 (the number of minutes in an hour) by 3
>(the number of hours we want to count in this program).
と書いてあり、能動態に直すと
XXX set its value to 60 * 60 * 3.
となるから、
set A to B

A = B
の意味を伝達しようとしていると考えられて、裏づけが取れた。

573 :デフォルトの名無しさん:2022/11/25(金) 15:45:19.49 ID:xaW1nBc4.net
>>571,572
混乱の極みを見事に体現してる。原文見た方が良いでしょ?

574 :デフォルトの名無しさん:2022/11/25(金) 15:55:04.06 ID:THLf878Z.net
>>571,572
昨日の1.5倍の人か100倍の人かわかんないけど、原文見たら0.1倍だったね。

575 :デフォルトの名無しさん:2022/11/25(金) 16:13:51.74 ID:scn2u8sN.net
プログラム関連で出てくる単語とか限られているから、慣れたら英語でも速く読めるからね。

576 :デフォルトの名無しさん:2022/11/25(金) 16:53:44.00 ID:BP7ibfc5.net
>>553
いや、全くないが
「読むに値しない」とまで言い切ったからにはどんなすごい名訳が出てくるんかと気になっただけ

577 :デフォルトの名無しさん:2022/11/25(金) 17:08:35.12 ID:N+Zpejdn.net
>>576
×「読むに値しない」→名訳が出てくる
〇「読むに値しない」→原文を読む

578 :デフォルトの名無しさん:2022/11/25(金) 17:37:57.21 ID:XtySliSs.net
The Book日本語版、issueやPRが放置気味
https://github.com/rust-lang-ja/book-ja/issues
https://github.com/rust-lang-ja/book-ja/pulls
4人でメンテナンス?頑張ってる方かな?
https://github.com/orgs/rust-lang-ja/people

579 :デフォルトの名無しさん:2022/11/25(金) 18:51:27.43 ID:bTqKud61.net
日本語かどうかの話とちょっと逸れるけど
MDNのドキュメント初めて見たとき感動したな
親切というか見やすいというか

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/from
↑これは今てけとーにクリックして開いたページだけど
・最初の一行目付近で概要は十分掴める
・実行して試せる
・解説や例が充実

こーいうレベルまでまとまってると捗るよね

580 :デフォルトの名無しさん:2022/11/25(金) 18:55:07.58 ID:HP+HUenZ.net
>>579
標準ライブラリのrustdocとかこんな感じでは

581 :デフォルトの名無しさん:2022/11/25(金) 19:51:17.64 ID:6Yi+j4c1.net
英語できないやつはRust禁止でいいだろ

582 :デフォルトの名無しさん:2022/11/25(金) 20:14:50.25 ID:HZEumDr5.net
>>572
なるほど、なら

The last difference is that constants may be set only to a constant expression, not the result of a function call or any other value that could only be computed at runtime.



最後の違いは定数には関数呼び出しの結果や実行時に計算される値ではなく定数式のみを設定できる事である

くらいかな

583 :デフォルトの名無しさん:2022/11/25(金) 21:44:29.00 ID:6OlwGlFl.net
日本語訳読んだだけで秒で間違いに気付ける箇所を指摘したつもりだったんだがw

そうならないのは>>524が書いてるように「定数」「定数式」「セットする」「値」あたりの意味を理解してないってことなんだよね

584 :デフォルトの名無しさん:2022/11/25(金) 22:47:54.20 ID:GlJDmObA.net
> 確かにいい訳ではないけど
用語以前に誤訳なわけだが

585 :デフォルトの名無しさん:2022/11/25(金) 22:51:14.61 ID:OHrntoLc.net
>>547
RangeFullやSinkがunit-like struct
structの中身は空でtrait implのみ

でもそういう用途よりもジェネリックと一緒に使って状態を型で表現して
状態ごとに呼べる関数を制限したいときに使われることが多い
struct NotActivated;
struct Active;
struct Expired;
struct License<State> {…}
impl<State> License<State> {…}
impl License<NotActivated> {…}

586 :デフォルトの名無しさん:2022/11/25(金) 23:36:14.56 ID:9EBigD0X.net
原文がちょっと不親切ではあるな
これはいい、これは駄目という例を
挙げてくれれば文とかはどうでもよくなるのに

587 :デフォルトの名無しさん:2022/11/26(土) 07:16:42.40 ID:PBcpo5Pj.net
さんざん他言語・多言語愛好者をこけにしておちょくり倒してヘイト集めまくって、
挙句の果てに寄ってたかって素人騙してたくせに、その歴史が消える訳ないだろ。
今度は被害者のふり。最近ちょっと大人しくして良い人ぶって許されたと思ったら大間違い。

588 :デフォルトの名無しさん:2022/11/26(土) 09:45:44.06 ID:jkgTkEQQ.net
ちょっと何言ってるのか分からない

589 :デフォルトの名無しさん:2022/11/26(土) 13:29:02.11 ID:NN/Ee4C5.net
「定数は定数式にしかセットできません」だけならともかく
「定数は関数の呼び出しの結果にはセットできません」
「定数は実行時に評価される値にはセットできません」
と重ねてダメ押しされてるのに間違いに気づかないのは致命的すぎるわな

590 :デフォルトの名無しさん:2022/11/26(土) 21:14:12.05 ID:WPAl7BZB.net
翻訳者の能力の問題もさることながら体制がダメなんだろ

591 :デフォルトの名無しさん:2022/11/26(土) 23:30:38.96 ID:MK1npdNM.net
1コードブロックに3つもバグが埋め込まれて本番環境で不具合でてるのに中の人は誰も気づかない状態

恐ろしい

592 :デフォルトの名無しさん:2022/11/26(土) 23:44:35.96 ID:cbpgSLEO.net
>>582
「定数に定数式を設定」という言葉はsrcとdstがどっちなのかに曖昧さが残るので
「定数を定数式で初期化」または、
「定数に定数式を代入」
「定数=定数式のように初期化」
とはっきり書いたほうが分かり易い。

593 :デフォルトの名無しさん:2022/11/27(日) 02:00:12.48 ID:PMZ9qEdk.net
日本語としてものすごく読みにくいとは思うが
どっちをどっちに設定するかという部分の曖昧さはないだろ

594 :デフォルトの名無しさん:2022/11/27(日) 02:20:50.36 ID:uyoA8rg1.net
タイムアウト時間を30秒に設定する
timeout_secondsに30を設定する

595 :デフォルトの名無しさん:2022/11/27(日) 07:55:44.11 ID:azI8+vf1.net
こんなところじゃなくて翻訳版bookのレポジトリで議論してきなよ

596 :デフォルトの名無しさん:2022/11/27(日) 10:18:44.07 ID:8gJa+XiI.net
個々人の生存戦略としてはそりゃ英語読めた方が良い

同意

コミュニティとしては裾野を広げるために各種言語のリソースは用意されてた方が良い

Rustコミュニティは英語に集中してリソース拡充してきている段階では?

翻訳版bookのコミュニティが、日本でのRustコミュニティとして中心的な位置を取りたいという野望でしょうか?
そんな求心力は無いと思いますが。

497: デフォルトの名無しさん sage 2022/11/24(木) 15:55:09.50 ID:rSYd8nrB
個々人の生存戦略としてはそりゃ英語読めた方が良いけど
コミュニティとしては裾野を広げるために各種言語のリソースは用意されてた方が良い
bookの翻訳が不十分なのは課題だが、だからといって翻訳の取り組み自体を否定するのは違うんじゃないの?
それとも英語等のハードルを越えた人間のみ触れるものであるべきという思想なのかな

597 :デフォルトの名無しさん:2022/11/27(日) 10:36:54.77 ID:Zv27eWsM.net
>>594
「30秒にはタイムアウト時間を設定できる」とか言わんやろ
英語を誤訳したやつみたいに日本語ネイティブじゃないやつが誤訳する可能性でも考えてんの?

598 :デフォルトの名無しさん:2022/11/27(日) 11:01:37.30 ID:gXtPf0qn.net
>>596 日本でのRustコミュニティとして中心的な位置を取りたいという野望
>>597 日本語ネイティブじゃないやつ

えっ、この二つリンクしてるのか?
なんとか協会とか資格試験を作るんですか?
そんなことしたら乗っ取りじゃないですか!
英語原文主義者でも捨て置きならないぞ!

599 :デフォルトの名無しさん:2022/11/27(日) 11:59:56.08 ID:azI8+vf1.net
>>596
>>482にもあるがすでに翻訳も拡充していこうとしている
というかローカライズにリソース割くのやめたところで英語版の執筆ペースが速くなるわけでもなかろう

600 :デフォルトの名無しさん:2022/11/27(日) 12:31:41.07 ID:H/u9072G.net
>>599
翻訳版bookの中の人ですね。
本家公認だからって、日本人作のcrate等で活躍している人達を差し置いて
日本Rustコミュニティの中心見たいな態度はどうかと思うぞ。

605: デフォルトの名無しさん sage 2022/11/27(日) 07:55:44.11 ID:azI8+vf1
こんなところじゃなくて翻訳版bookのレポジトリで議論してきなよ

601 :デフォルトの名無しさん:2022/11/27(日) 12:41:05.07 ID:iW9ldzKP.net
>>ID:azI8+vf1
こんなところでリクルート活動してないで率先してガンガン品質向上しろよ

本家の代弁者見たいな顔するな。
説得力ゼロ

602 :デフォルトの名無しさん:2022/11/27(日) 12:48:50.89 ID:f1nHPrCO.net
クスクス

603 :デフォルトの名無しさん:2022/11/27(日) 13:27:25.24 ID:/KqYda7b.net
おれ、この気持ち共感できる
>日本人作のcrate等で活躍している人達を差し置いて

これだけは断固反対
>なんとか協会とか資格試験を作るんですか?

翻訳版book中の人は、やらないと誓約する必要がある

604 :デフォルトの名無しさん:2022/11/27(日) 13:59:45.41 ID:WnQW1xBa.net
翻訳議論スレ作れよ

605 :デフォルトの名無しさん:2022/11/27(日) 14:35:21.35 ID:azI8+vf1.net
>>600
ちょっと思い込みが激しすぎやしないですかね
こんなところで翻訳案議論しても何の役にも立たないからせめてコントリビューションして来なさいよという意味

606 :デフォルトの名無しさん:2022/11/27(日) 14:44:21.27 ID:obDxoM1f.net
横失礼します。
>>603そのものは共感に値します。
>>605さんも同感ですよね?

607 :デフォルトの名無しさん:2022/11/27(日) 15:01:53.97 ID:uyoA8rg1.net
低レベルな内容ほど議論が紛糾する
英語ではbikesheddingと言います

608 :デフォルトの名無しさん:2022/11/27(日) 15:41:13.95 ID:Cs02dWTs.net
>>585
どうもありがとう
なんかスレが殺伐としてるね

609 :デフォルトの名無しさん:2022/11/27(日) 16:55:26.99 ID:uHmuK07x.net
>>597
30秒などの具体的な数値が有る場合には誤解は無い。ところが、
「XをYに設定する。」と書いた場合、
X=Y
Y=X
のどちらにも解釈可能。

610 :デフォルトの名無しさん:2022/11/27(日) 17:09:13.26 ID:N296u3Hi.net
>>609
「XにはYを設定できる」や「XにはYのみ設定できる」という文がY = Xの意味にとれるのか?

日本語ネイティブじゃない人には分かりにくいというのなら理解できなくもない

611 :デフォルトの名無しさん:2022/11/27(日) 17:16:08.15 ID:TRua3A2I.net
>>610
>>520はそのどれでもなくて「XはYにしかセットできない」の形式だけど
これはどう思う?

612 :デフォルトの名無しさん:2022/11/27(日) 17:17:31.45 ID:F7pPowDS.net
怪しい部分も大半は文脈と照らし合わせつつコード読めば理解できるレベルの翻訳なのに一々文句付けるぐらいなら翻訳に参加した方が早いのでは?としか思わない

613 :デフォルトの名無しさん:2022/11/27(日) 17:20:04.83 ID:ZSA0r6oY.net
まあそんな些細なことよりさ
項目が抜けてるところに<未翻訳の項目があります>って表示したら、かなり親切になるんじゃないかな

614 :デフォルトの名無しさん:2022/11/27(日) 17:26:26.85 ID:97SCWnfr.net
>>611
どう思うも何も>>520はダメだろ
間違った逆の意味にしか取れないよ
そこに異論がある人はいなくね?

615 :デフォルトの名無しさん:2022/11/27(日) 17:29:51.04 ID:uHmuK07x.net
>>610
日本語訳では、「定数は定数式にしかセットできない」と書いてあるので、
定数=定数式 (1)
定数式=定数 (2)
のどちらにも解釈可能。
しかし、原文読むと正しいのは、(1)。

616 :デフォルトの名無しさん:2022/11/27(日) 17:32:52.38 ID:BVKfKgFe.net
>>612
ちゃんと読もうとすればほぼ原文全部読まないといけない品質だぞ
あの日本語訳に飛びつくやつがそんなことするとでも思ってるの?

617 :デフォルトの名無しさん:2022/11/27(日) 17:33:05.29 ID:lJvzY49o.net
google翻訳にかけたらそうなったんだから、しょうがないだろ
という事では

618 :デフォルトの名無しさん:2022/11/27(日) 17:47:05.67 ID:UmH2UGTE.net
>>615
定数や式についての知識が全くない人か
日本語ネイティブじゃない人でなければ
(1)の解釈は無理

619 :デフォルトの名無しさん:2022/11/27(日) 17:58:03.70 ID:Tzlpv0SL.net
>>611
>>582 の話じゃないのか?
なぜ今更 >>520 の話なんてしてるんだ?

620 :デフォルトの名無しさん:2022/11/27(日) 18:01:08.13 ID:AOVlF7rL.net
>>617
ところがgoogle翻訳のほうがマシな場合も多々あるんだよこれが

621 :デフォルトの名無しさん:2022/11/27(日) 18:48:05.90 ID:WjtNHhGH.net
ざっと見た感じこの流れが気になる。こんなの秒で同意できるのに。

613: デフォルトの名無しさん sage 2022/11/27(日) 13:27:25.24 ID:/KqYda7b
おれ、この気持ち共感できる
>日本人作のcrate等で活躍している人達を差し置いて

これだけは断固反対
>なんとか協会とか資格試験を作るんですか?

翻訳版book中の人は、やらないと誓約する必要がある

615: デフォルトの名無しさん sage 2022/11/27(日) 14:35:21.35 ID:azI8+vf1
>>600
ちょっと思い込みが激しすぎやしないですかね
こんなところで翻訳案議論しても何の役にも立たないからせめてコントリビューションして来なさいよという意味

616: デフォルトの名無しさん sage 2022/11/27(日) 14:44:21.27 ID:obDxoM1f
横失礼します。
>>603そのものは共感に値します。
>>605さんも同感ですよね?

622 :デフォルトの名無しさん:2022/11/27(日) 18:52:53.78 ID:WnQW1xBa.net
翻訳の話題NG
想像以上の闇がありそう

623 :デフォルトの名無しさん:2022/11/27(日) 19:05:09.68 ID:vnIlphb/.net
今の状態でいきなり協会が立ち上がったら遺恨を残すだけ。

624 :デフォルトの名無しさん:2022/11/27(日) 19:25:30.10 ID:oBBhjDqK.net
てか現状の雑翻訳の張本人=英語マウント君の可能性すらある

625 :デフォルトの名無しさん:2022/11/27(日) 20:48:36.17 ID:Bc2lJjRX.net
rust-jpあたりに私怨ある人が盛り上がってる感じかな
お大事に

626 :デフォルトの名無しさん:2022/11/27(日) 21:42:32.15 ID:lFtjfrKw.net
書いてもないことを勝手に読み取って燃え上がるタイプっぽいからいろいろ大変そうだね…

627 :デフォルトの名無しさん:2022/11/27(日) 21:46:47.14 ID:ZNWbm5aC.net
次スレのテンプレから
日本語訳へのリンクは削除で
>>980

628 :デフォルトの名無しさん:2022/11/27(日) 22:01:49.36 ID:WnQW1xBa.net
翻訳の話題禁止も追加しといてくれ

629 :デフォルトの名無しさん:2022/11/27(日) 22:07:24.37 ID:berpMXHg.net
協会立ち上げるならRust検定も必要だろね。

630 :デフォルトの名無しさん:2022/11/27(日) 23:00:31.47 ID:N2XeKp1i.net
協会立ち上がったらRustの保証範囲内で国内法損害賠償に応相談?

631 :デフォルトの名無しさん:2022/11/27(日) 23:11:10.98 ID:berpMXHg.net
プログラムに起因する損害を全て保証すれば、Rustの名声も高まるだろうな。

632 :デフォルトの名無しさん:2022/11/27(日) 23:12:33.38 ID:berpMXHg.net
Rustにおいてコンパイルを通るとは、すなわちバグが無いと保障されること。
と宣伝してたからな。

633 :デフォルトの名無しさん:2022/11/27(日) 23:14:15.63 ID:berpMXHg.net
Rustサムライという映画があったような。

634 :デフォルトの名無しさん:2022/11/27(日) 23:29:35.46 ID:NsWs/3+t.net
rustの勉強に前に英語の勉強を

635 :デフォルトの名無しさん:2022/11/27(日) 23:44:50.88 ID:berpMXHg.net
日本が世界に誇るRust言語。

636 :デフォルトの名無しさん:2022/11/28(月) 08:14:55.76 ID:u/1oLUrZ.net
リンクトリストやグラフ構造が地獄という話題に戻ろう
GC無し言語のRuneはrelationという機能で解決してて素晴らしいのではないでしょうか?
有向グラフのコード例↓
https://github.com/google/rune/blob/main/doc/rune4python.md#the-directed-graph-example

637 :デフォルトの名無しさん:2022/11/28(月) 09:39:33.33 ID:MVujw8Ga.net
>>636
その言語が何を保証しているのか解説よろ

638 :デフォルトの名無しさん:2022/11/28(月) 09:52:18.49 ID:sJQkfuAF.net
>>633
ググったら何かいそうなのww

639 :デフォルトの名無しさん:2022/11/28(月) 11:16:45.67 ID:BYOiineU.net
>>585
このジェネリック使った静的チェック付きのStateパターンは他の言語では見ないんだがRustと同じように実装できるんだろうか?

640 :デフォルトの名無しさん:2022/11/28(月) 11:26:51.11 ID:VpBGmQkI.net
>>636,639
保証がないなら無意味なのでは

641 :デフォルトの名無しさん:2022/11/28(月) 11:48:49.74 ID:ysUCvAXy.net
>>639
C++で言うところのタグディスパッチ

642 :デフォルトの名無しさん:2022/11/28(月) 11:51:10.38 ID:cwhW39fK.net
>>640
保証の有無は分からないんだけど、
仮になかったとしても、rustのunsafeと同じでプログラマの責任で自由にできる部分があるのは意味のあることでは

643 :デフォルトの名無しさん:2022/11/28(月) 12:37:21.67 ID:B8Z/qDA7.net
>>641
タグディスパッチの場合はある状態がサポートしない操作もオーバーロードできるように書かないとダメじゃない?
それだと他の言語の一般的なStateパターンの実装方法と基本的には同じ

644 :デフォルトの名無しさん:2022/11/28(月) 13:02:49.16 ID:wvJe/vpd.net
>>643
一般的なStateパターンではなく、静的チェック付きのStateパターンだと何が保証されるのですか?

645 :デフォルトの名無しさん:2022/11/28(月) 14:37:02.92 ID:goiShTMa.net
>>644
ある状態でサポートされてない操作を呼び出す(可能性のある)コードはコンパイル通らない
ジェネリックを使わない形の静的チェック付きStateパターン実装は他言語でもよく見るよ

646 :デフォルトの名無しさん:2022/11/28(月) 15:00:23.08 ID:pom2iae5.net
>>645 全体的にちょっと回りくどい表現で理解できません。

>>645は、Rustではコンパイルが通れば実行時エラーが起きない事が保証される、
という事を言っているのでしょうか?
(他の言語との比較ではなく)

647 :デフォルトの名無しさん:2022/11/28(月) 15:00:27.21 ID:pom2iae5.net
>>645 全体的にちょっと回りくどい表現で理解できません。

>>645は、Rustではコンパイルが通れば実行時エラーが起きない事が保証される、
という事を言っているのでしょうか?
(他の言語との比較ではなく)

648 :デフォルトの名無しさん:2022/11/28(月) 15:01:45.50 ID:pom2iae5.net
すみません。マウスのチャタリングかな。。

649 :デフォルトの名無しさん:2022/11/28(月) 15:23:59.23 ID:mX/IntZU.net
>>646
Stateパターンに明るくないようならthe bookに2種類のStateパターンの実装が出てるので読んでみて
https://doc.rust-lang.org/book/ch17-03-oo-design-patterns.html

1つめの実装はある状態でサポートされない操作が呼び出されたら何もせずselfを返したり空文字列を返したりしてる
2つめの実装はある状態でサポートされない操作を呼び出すコードが有ればコンパイルエラー

>>585のやり方は2つめの実装をジェネリックとmarket typeを使ってPost<Draft>みたいな形にするもの

650 :はちみつ餃子 :2022/11/28(月) 15:38:39.29 ID:26iHAu1B.net
Modern C++ Design で Policy と呼ばれているパターンに近くない?
基本的な言語機能が違うので単純に比較はできないかもしれないけど。

651 :デフォルトの名無しさん:2022/11/28(月) 16:45:22.66 ID:gmgHbWWJ.net
>>649 ありがとうございます。おかげ様で理解が深まった気がします。

>>645が言っていることから理解したこと
静的"型"チェックの出来る言語なら適切なStateパターン実装を用いれば、
各状態に対応した型に実装されていない操作をコンパイルエラーで検出できる。

>>645が言及を意図的に避けている単語
保証

652 :デフォルトの名無しさん:2022/11/28(月) 17:30:33.44 ID:CGc28UZt.net
ん〜、Rustで保証を持ち出さないんだったら、>>639=653?は何をマウントしようとしたのかすら不明
あと655は別人じゃね?

653 :デフォルトの名無しさん:2022/11/28(月) 17:41:27.83 ID:/aP8eVMy.net
話の流れとは全く関係無いが、
twitterでは、rustで検索するとゲームが多数を占めてしまうので問題だが、
rustlang lang:ja
で検索すると割りと上手く行く。

654 :デフォルトの名無しさん:2022/11/28(月) 17:53:52.03 ID:x/Rrw6wy.net
ググったら一発で出てきた

doc.rust-jp.rs/rust-nomicon-ja/
>また、様々な種類の安全性や保証についてもたくさん説明します。

655 :デフォルトの名無しさん:2022/11/28(月) 18:00:25.08 ID:JOAT4gaO.net
>rust-jpあたりに私怨ある人
こんなやついるのか?保証に敏感な人はrust-jpの何を拗らせたの?濡れ衣でしょ

656 :デフォルトの名無しさん:2022/11/28(月) 18:15:54.07 ID:hRO2AtDN.net
言及する価値無し

657 :デフォルトの名無しさん:2022/11/28(月) 18:19:33.94 ID:9jvbe+te.net
誰もYesかNoか答えない(含む自分)5chアンケート調査

Rustではコンパイルが通れば実行時エラーが起きない事が保証される

(ちなみに拗らせてないしrustjpに私怨ありません. >>625のデマでは)

658 :デフォルトの名無しさん:2022/11/28(月) 18:33:51.31 ID:LDNjf6uN.net
実行時エラーを心配するって、どういうレベルの人たちだよ

659 :デフォルトの名無しさん:2022/11/28(月) 18:35:25.02 ID:kKtU7ET1.net
「Rustではコンパイルが通れば実行時エラーが起きない事が保証される」
これ自体が大嘘だろう?I/Oのある呼び出しは必ずRuntimeパニックの可能性があるし、実行時エラーが起きない事が保証されるのは
一部の実行時エラー(主にメモリー関連、例:配列インデックス範囲外など)であり、unsafeでもチェックが働く部分を強調してるだけ

660 :デフォルトの名無しさん:2022/11/28(月) 18:47:02.30 ID:cwhW39fK.net
そんなに慌てて連投なさらなくても大丈夫ですよ
おちついてください

661 :デフォルトの名無しさん:2022/11/28(月) 18:48:22.90 ID:/aP8eVMy.net
RustがC++に勝るのは(原因特定の難しい)メモリー関連バグが防げるというだけで、
その他のバグは防げない。
しかも、メモリー関連バグですら、実行段階で始めて発覚するものがRustでも
有りえる。ようは、メモリー関連バグの原因特定がし易くなるというだけで、
メモリー関連バグを綺麗さっぱりなくせるという意味ですらない。
また、FORTRAN、BASIC、Perl、Ruby、PHP、Java、C# などはメモリー安全で
メモリー関連エラーは発生しないが、古来、バグはいくらでも入る。

662 :デフォルトの名無しさん:2022/11/28(月) 19:09:17.89 ID:sJQkfuAF.net
twitter で検索するのって若者かな。
欲しい情報にたどり着けるのだろうか。
https://togetter.com/li/1977794
これを思い出した

663 :デフォルトの名無しさん:2022/11/28(月) 20:00:00.32 ID:nxIypHTQ.net
The Book にコンパイルは通るけど実行時エラーが出る例あるじゃん、何の話をしてるの?

664 :デフォルトの名無しさん:2022/11/28(月) 20:03:31.87 ID:Wp/I5FPo.net
実行時エラーが起きないことが保証されると書かれている公式サイトのURLを下さい
文脈も合わせて読まなければ判断できないので
日本語で引用しているということは誤訳の可能性もあるし

665 :デフォルトの名無しさん:2022/11/28(月) 20:04:25.28 ID:ptllJlnS.net
>>661
>古来、バグはいくらでも入る。
Rustでもバグfixが追いつかない実例->lapce
code editorは数人(+ごく稀なcontributor)で対応するには余りにも複雑なプログラムだと思う。

666 :デフォルトの名無しさん:2022/11/28(月) 20:07:06.18 ID:TT/P6KwG.net
他の言語ってインターフェースを関数から返せるっけ?
Rustはトレイト返せるけど

667 :デフォルトの名無しさん:2022/11/28(月) 20:09:20.88 ID:ptllJlnS.net
https://github.com/lapce/lapce/issues

他スレで上がってたのを思い出して見てみたら放置されてた
https://github.com/lapce/lapce/issues/1668

668 :デフォルトの名無しさん:2022/11/28(月) 21:13:58.78 ID:2w53O7+w.net
>>664
文脈あって範囲を限定すると今度は証明が~となるので、そうなると正直判断できない。
結局大雑把な文脈での話しか出来ない自分です。

669 :デフォルトの名無しさん:2022/11/28(月) 21:38:31.45 ID:LooEy8MN.net
>>666
返せるでしょ
むしろRustはなんで直接trait返せないんだ?ってなるのが普通

670 :デフォルトの名無しさん:2022/11/29(火) 00:09:28.41 ID:zwTDTYOm.net
これ一番速いのはいいんだけどなんでバイナリサイズGoの倍もあるんだ?そこが不服だわ
https://ecostack.dev/posts/wasm-tinygo-vs-rust-vs-assemblyscript/

671 :デフォルトの名無しさん:2022/11/29(火) 00:28:33.22 ID:fvnZTYNV.net
>>670
GoじゃなくてTinyGoだから別コンパイラじゃないのか?
しらんけど

672 :デフォルトの名無しさん:2022/11/29(火) 00:29:24.71 ID:bjuqnrsq.net
確かに。GC無いから転送サイズ小さくなる、と言う触れ込みは再考の必要があるのか。
https://i.imgur.com/nCVoHXW.png

673 :デフォルトの名無しさん:2022/11/29(火) 00:40:07.72 ID:zwTDTYOm.net
なんかこうやって纏められるとAssemblyScriptがわりと高いレベルでバイナリサイズ・実行速度・メモリフットプリントのバランス取れてていい感じがするな
wasmターゲット専用言語だからセットアップ単純だし
Rustはwasmターゲットだと若干セットアップ手間だけど速度は文句無しだからバイナリサイズだけせめてGoよりは小さくなってくれ
てかGo(TinyGo)よりサイズが必要な道理はないよな?
まさかデバッグビルドか何かかしら?

674 :デフォルトの名無しさん:2022/11/29(火) 00:51:42.61 ID:GvyrOa7B.net
randじゃね?
Math.randomで揃えたほうが意味のある比較が得られるかも

675 :デフォルトの名無しさん:2022/11/29(火) 01:20:35.39 ID:zkGFWomx.net
これが最新情報かどうかわからないけど、wasm-bindgenに対応していないかも
https://blog.logrocket.com/comparing-random-number-generators-rust/
>Note: Unlike JavaScript, there is no Math.random method equivalent currently available in Rust.

randの方は、これで行けた
[dependencies]
wasm-bindgen = "0.2.63"
rand = {version = "0.7", features = ["wasm-bindgen"] }

デバッグビルドの心配はなさそう
https://i.imgur.com/Y1Cut3b.png

676 :デフォルトの名無しさん:2022/11/29(火) 07:42:30.08 ID:SJ6gC8Ff.net
>>670
https://zenn.dev/dozo/articles/14b76b561f3b45

677 :デフォルトの名無しさん:2022/11/29(火) 10:50:30.64 ID:kK2YPnkZ.net
>>676のリンクには
>WebAssemblyを使う上で、最早定番となっているwasm-pack, wasm-bindgenだが、これらを使うことでサイズが小さくなる。
と書いてあって、>>670の手法と同じ

今は
サイズ我慢で速度重視→Rust
トータルバランス重視→AssemblyScript

AssemblyScriptでループアンロール→最強の可能性

678 :デフォルトの名無しさん:2022/11/29(火) 18:52:25.76 ID:K9a8IO+l.net
文脈を限定すると答えられる5ch意識調査

RustはGC無いから○○では○○が有利/不利。自由に○○を埋めてください

679 :デフォルトの名無しさん:2022/11/29(火) 18:55:24.50 ID:t+w4gnFQ.net
次スレはワッチョイ付けとくか

680 :デフォルトの名無しさん:2022/11/29(火) 19:25:03.39 ID:KYdU3S5N.net
>>679
次スレ待たなくていいからワッチョイスレ建ててよ

681 :デフォルトの名無しさん:2022/11/29(火) 19:54:15.57 ID:VRBW4+C+.net
プログラミング言語 Rust 4【ワッチョイ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

あるやん

682 :デフォルトの名無しさん:2022/11/29(火) 20:07:43.93 ID:oIl8dOKJ.net
>>681
表面的にはひどい荒らしスレに見えますが、ワッチョイなしスレに誘導したい思惑でしょうか

683 :デフォルトの名無しさん:2022/11/29(火) 20:14:44.32 ID:VRBW4+C+.net
スレタイしかみてないから知らんがな (´・ω・`)

> ワッチョイなしスレに誘導したい思惑
ここがそうなんだけど、どういうこと???

684 :デフォルトの名無しさん:2022/11/29(火) 20:25:34.24 ID:XdsjIrxf.net
次回からこう聞くように

限定された文脈なのに誰もYesかNoか答えない(含む自分)5chアンケート調査

RustはGC無いからwasmでは転送サイズ小さくなる可能性がほぼほば100%

685 :デフォルトの名無しさん:2022/11/29(火) 20:44:54.77 ID:CCXgN4qQ.net
>>684
何と比べてるのか限定されていません。

RustはGC無いからwasmでは、GC付き言語のGoと比べて転送サイズ小さくなる可能性がほぼほば100%

これだと大嘘です。GCマウント禁止

686 :デフォルトの名無しさん:2022/11/29(火) 23:14:29.40 ID:JTTSm0Nf.net
ワッチョイでスレが健全化された例ってあるん?

687 :デフォルトの名無しさん:2022/11/30(水) 01:36:38.11 ID:CGVOYd9m.net
新規ワッチョイスレを他言語比較マウント禁止のスレとして立ててくれませんか?

複オジがマウントするから荒れるわけなので、こちらは隔離スレ
こちらの隔離スレではたぶん複オジが嘘つきマウントし放題だけど、心ある人が都度、嘘認定をする流れで

688 :デフォルトの名無しさん:2022/11/30(水) 08:15:37.71 ID:zxU0c19+.net
>>686
自分は知らないな。原理主義者の言論弾圧に使われるのがオチ
センシティブな話題も客観的に議論できるようになった例は見たことない

689 :デフォルトの名無しさん:2022/11/30(水) 08:41:56.63 ID:5hu//ubR.net
スレは健全化しないけど、NG指定が簡単になるからchリーダー使用者の恩恵は大きい。

690 :デフォルトの名無しさん:2022/11/30(水) 08:50:23.49 ID:JOQsrdYp.net
やる気のある荒らしにとってはワッチョイスレの方が自作自演やりやすい

691 :デフォルトの名無しさん:2022/11/30(水) 08:52:45.01 ID:G7Z4SD5Z.net
>>680,687
自分で立てなよ

692 :デフォルトの名無しさん:2022/11/30(水) 09:59:30.85 ID:GLbLL33e.net
翻訳論議が一段落して、次はワッチョイ論議
つまりこのスレは話題があんまり無い

693 :デフォルトの名無しさん:2022/11/30(水) 10:15:08.01 ID:oBo+tKG7.net
リンクトリストやグラフ構造が地獄という話題に戻ろう

694 :デフォルトの名無しさん:2022/11/30(水) 11:14:03.81 ID:i6HTre51.net
>>689
論理的な主張をする人が消えるからデメリットはかなりある

>>690
ほんそれ。ワッチョイ入れると情報リテラシーが低い奴の比率が増えて荒らしにとっても
議論を誘導しやすく都合が良い
ワッチョイ導入したスレはネガティブダメ絶対で盲目信者の巣窟と化した所ばかりだわ

695 :デフォルトの名無しさん:2022/11/30(水) 11:39:08.76 ID:zgBPYpzJ.net
>>694
C++相談室 part162
https://mevius.5ch.net/test/read.cgi/tech/1667194175/

を見る限り、論理的一貫性をもった主張の出来る人ほど、コテハンやワッチョイを長期間維持しているように見えます。

ワッチョイスレを否定したり、建てられても過疎化させようとしている人の側に複オジおよび複オジ軍団?がいると思います。

696 :デフォルトの名無しさん:2022/11/30(水) 11:45:59.09 ID:GLbLL33e.net
そのスレ、先週の木曜から丸1週間
連想配列とハッシュについて、用語の使い方でもめててカオスなんだが

697 :デフォルトの名無しさん:2022/11/30(水) 12:04:15.09 ID:/jkyAEdJ.net
だから、>>686,688,690,694がその、複オジおよび複オジ軍団?、の工作だと思われ
C++スレにも複オジ軍団が居て、事実を捻じ曲げておちょくってる

ワッチョイはブラウザ次第で結構似たものになるので、他の板で実験してから紛らわしいワッチョイになるようにして工作している

もっと効果の高い、地域表示があるワッチョイスレ、どうやって立てるのか教えてくれ

698 :デフォルトの名無しさん:2022/11/30(水) 12:13:40.18 ID:cmtce+MC.net
複オジ軍団はここしばらくは他スレを荒らして、このスレではバレバレな潜伏しているのはなぜ?

699 :デフォルトの名無しさん:2022/11/30(水) 12:15:14.45 ID:jPWRqkwi.net
自作自演できないとめっちゃ困るヤツがいるみたいだなw

700 :デフォルトの名無しさん:2022/11/30(水) 12:23:21.21 ID:2gwAbMS9.net
>>693
じゃ、まずRustで書いた地獄のようなコードを公開しようか

701 :デフォルトの名無しさん:2022/11/30(水) 12:23:29.98 ID:OzkchGTR.net
地域表示があるワッチョイスレ、これでいい

702 :デフォルトの名無しさん:2022/11/30(水) 12:39:01.46 ID:pEwW8jKj.net
このスレ他の荒らされスレも自衛のために地域表示があるワッチョイスレを導入するべき

703 :デフォルトの名無しさん:2022/11/30(水) 12:39:21.42 ID:IuI5QH4S.net
test
http://hobby23.net/archives/wacchoi-ng/
ID+W
!extend:checked:vvvvv:1000:512
ID+IP
!extend:checked:vvvv:1000:512
ID+W+IP
!extend:checked:vvvvvv:1000:512

704 :デフォルトの名無しさん:2022/11/30(水) 12:52:42.68 ID:AuqILHPE.net
ワッチョイを入れるともっともらしい事を書きつつ論理性のない奴ばかりになるんだよな

705 :デフォルトの名無しさん:2022/11/30(水) 12:58:59.97 ID:pEwW8jKj.net
でも地域コロコロは相当な手間だろうから効果的

706 :デフォルトの名無しさん:2022/11/30(水) 13:15:44.12 ID:qQx/nUVl.net
いやいやw
ボタン一押しで変えられるからw

707 :デフォルトの名無しさん:2022/11/30(水) 13:22:01.95 ID:UkkEZSxh.net
>>706 複オジ軍団おつ
本当にそこまでしてると犯罪集団の疑いがかかるよ
大人しく納得してよ

708 :デフォルトの名無しさん:2022/11/30(水) 13:31:07.04 ID:RA9ND8/X.net
>>695
まともなスレなのかと思ってみたら予想以上に酷かった
NGが捗るのだけは間違いない

709 :デフォルトの名無しさん:2022/11/30(水) 13:33:05.03 ID:HgZFIyO3.net
>>707
おいおいw
複オジ軍団に入れるなよ
リテラシーの低さを指摘してやっただけだぞ

つか複オジに軍団がいるわけないじゃんw

710 :デフォルトの名無しさん:2022/11/30(水) 14:33:18.63 ID:bBS0BhSp.net
そう思ってよく見ると、これ軍団?なのかは知らないけど

C++相談室 part162
https://mevius.5ch.net/test/read.cgi/tech/1667194175/392-393

アウアウウー Sa5b-*
ちょくちょく話の腰を折るのが楽しくて仕方ない、ポエオジに見えてきた

711 :デフォルトの名無しさん:2022/11/30(水) 15:11:10.30 ID:WOTWHh4+.net
その人競プロスレにもいる
そのワッチョイだとよそ者扱いなの気づいてないかも
その仲間もいる

712 :デフォルトの名無しさん:2022/11/30(水) 15:45:12.01 ID:pJupgOvS.net
アウアウウーはNGにしてるわ
同じやつかもしれんがロクなやついないので

713 :デフォルトの名無しさん:2022/11/30(水) 16:09:27.62 ID:luaLXMjy.net
>>697
妄想乙。陰謀論とかすぐに信じちゃいそうだから気をつけような

714 :デフォルトの名無しさん:2022/11/30(水) 16:26:36.69 ID:C5ItOzWN.net
C++スレ、だいたい見分け付くから安心して

715 :デフォルトの名無しさん:2022/11/30(水) 16:45:35.81 ID:Wzirhnl9.net
そこに某オジが混ざってるのは確か

716 :デフォルトの名無しさん:2022/11/30(水) 19:27:06.50 ID:FAHQHXzj.net
ワッチョイ導入を吠える奴に限ってワッチョイコロコロだよな

717 :デフォルトの名無しさん:2022/11/30(水) 19:33:03.35 ID:VjUnhy87.net
オイコラミネオの方が特徴を出している

718 :デフォルトの名無しさん:2022/11/30(水) 19:47:27.00 ID:wYxb0V08.net
競プロスレではオイコラミネオがマウントしてアウアウウーがたしなめてる?

719 :デフォルトの名無しさん:2022/11/30(水) 20:19:35.44 ID:30W6u2RH.net
オイコラミネオはかのMAUIと意気投合してる

WPF(.NET, WinUI) GUIプログラミング Part30
https://mevius.5ch.net/test/read.cgi/tech/1667010874/279
279: デフォルトの名無しさん sage 2022/11/26(土) 11:06:15.13 ID:1ldKsJnP

これの少し上(265以降)からx:Nameの話のやり取り。質問者は別人で知ったかしてるのがオイコラミネオ

ID:1ldKsJnP == ID:1ldKsJnPM (オイコラミネオ MMab-ykd8)
http://hissi.org/read.php/tech/20221126/MWxkS3NKblBN.html

720 :デフォルトの名無しさん:2022/11/30(水) 20:25:16.86 ID:dptuEtJz.net
オイコラミネオ語録
天才
漏れ
のであった
のであっる

721 :デフォルトの名無しさん:2022/11/30(水) 20:50:59.01 ID:D0f5nOYN.net
語録 意味論+のであった コンボ

次世代言語29 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1663409149/352
352: デフォルトの名無しさん sage 2022/09/22(木) 06:32:39.62 ID:KYC2ssXj
>>333
意味論(semantics)はコンピューターサイエンスでは常識かつ必須のものであり
今回のような証明においてももちろん不可欠のもの
そして>>309の論文を見てみたら当然のように今回の核心部分で意味論(semantics)が出てきている
皆が言及しているのも当然なのであった

722 :デフォルトの名無しさん:2022/11/30(水) 20:56:14.68 ID:xA9q89X1.net
こういう単発ガイジの対策になるわけですよ

723 :デフォルトの名無しさん:2022/11/30(水) 20:58:56.08 ID:3owZWjDR.net
Doc本家代弁者の思い込み? 本スレ ID:rSYd8nrB

>>482: デフォルトの名無しさん sage 2022/11/24(木) 15:33:59.04 ID:rSYd8nrB
一方rustコミュニティはコンパイラのdiagnosticの翻訳者を募集していたのであった
https://blog.rust-lang.org/inside-rust/2022/08/16/diagnostic-effort.html

>>474はこういうのもやらない方が良いと思ってる?

724 :デフォルトの名無しさん:2022/11/30(水) 23:53:41.68 ID:BfCpCYnc.net
これは他の開発環境でもよくあることだけど、こんなの訳されたらググりづらくなるだけじゃねえのか

725 :デフォルトの名無しさん:2022/12/01(木) 00:17:38.55 ID:8yYXZOAf.net
rustcの場合はURLやエラーコード出るからメッセージが日本語でも特に支障はないのでは

726 :デフォルトの名無しさん:2022/12/01(木) 08:02:15.14 ID:CTIQwGqT.net
英語のメッセージでググっても中身のないアフィカス日本語サイトしか出てこないようになっているからどっちもどっち
日本語のメッセージがアフィカスサイトを上回るならメリットあるね

727 :デフォルトの名無しさん:2022/12/01(木) 10:50:28.62 ID:aRdHv5SW.net
昨日のヒントで掘ったら、某オジがなんでPerl偽装するほどハッシュを拗らせてるのか分かった

728 :デフォルトの名無しさん:2022/12/01(木) 12:18:36.87 ID:C8o9eLrx.net
すごく久しぶりにRust関連みたらめっちゃ荒れてんのな。
一体何で揉めてんの?

729 :デフォルトの名無しさん:2022/12/01(木) 13:18:45.22 ID:hut8tsqa.net
翻訳の話題になると単発Rustガイジが急に湧いてきたから
そこに関わって雑に扱われた人なんだろう
私情がむき出しになってる
怖い怖い

730 :デフォルトの名無しさん:2022/12/01(木) 13:36:00.00 ID:fiJuDPd3.net
そうかな?おれは某オジが公式のお手伝い的立ち振る舞いをする事が迷惑

731 :デフォルトの名無しさん:2022/12/01(木) 13:40:04.93 ID:QSGflsTk.net
↑単発Rustガイジ

732 :デフォルトの名無しさん:2022/12/01(木) 13:48:38.39 ID:LRCAz4YI.net
オイコラミネオさ~ん、別室で呼ばれてますよ~

733 :デフォルトの名無しさん:2022/12/01(木) 14:10:19.16 ID:+8V7DDLQ.net
オイコラミネオさ~ん、先生がお待ちですよ! #確率的探索中

734 :デフォルトの名無しさん:2022/12/01(木) 14:15:29.05 ID:p39MirQK.net
オイコラミネオさん、じゃあ始めますね~

735 :デフォルトの名無しさん:2022/12/01(木) 14:17:59.07 ID:qbMIrOAL.net
言われてみれば低品質翻訳オジと某オジは言葉使いが似てるな

736 :デフォルトの名無しさん:2022/12/01(木) 14:33:23.35 ID:o5v4IIF+.net
おれは某オジがそういうフリをしている可能性を問題視してる

737 :デフォルトの名無しさん:2022/12/01(木) 14:39:13.55 ID:jvRfhEdy.net
私怨論に話をそらせたいのが某オジ >>625,729

738 :デフォルトの名無しさん:2022/12/01(木) 14:47:44.37 ID:FTdOeqRZ.net
rust-jpに私怨てw
自意識過剰もいいところ

739 :デフォルトの名無しさん:2022/12/01(木) 14:58:55.31 ID:KbSqTJy2.net
#オイコラミネオさ~ん、知らない事は調べてきて答えてくださいね!
当分の間はコロコロ禁止ですよ!
お友達もあとから呼び出しがありますから伝えておいてくださいね!

740 :デフォルトの名無しさん:2022/12/01(木) 15:18:16.92 ID:QSGflsTk.net
ここまで単発Rustガイジ
もうおわりだよこのスレ

741 :デフォルトの名無しさん:2022/12/01(木) 15:27:01.81 ID:3qQOITc+.net
お友達さ~ん、ま~た数学拗らせて~
Rustの保証は数学的証明付きだとかホラふかないで~
恥ずかしいからやめてくださいね!

742 :デフォルトの名無しさん:2022/12/01(木) 16:19:19.59 ID:jEoqaGTE.net
別室での話だけど、
別人が誤ったから、同じ主張やその後の間違いを放り投げて幕引きとか、特徴出し過ぎ

743 :デフォルトの名無しさん:2022/12/01(木) 16:29:41.61 ID:jAeBwf3w.net
こんな所でコソコソしてて草

744 :デフォルトの名無しさん:2022/12/01(木) 16:37:42.16 ID:xrmQW8I1.net
>>743
#某オジはお願いだからこっち来ないで #MAUIとお幸せに!

745 :デフォルトの名無しさん:2022/12/01(木) 16:38:32.69 ID:35O+q6ze.net
なんでID変えたの?

746 :デフォルトの名無しさん:2022/12/01(木) 16:46:32.24 ID:aw0kAUIM.net
>>745
意味不明

747 :デフォルトの名無しさん:2022/12/01(木) 16:49:44.04 ID:jAeBwf3w.net
>>744
>>742みたいなアホを排除したらよくね?w

748 :デフォルトの名無しさん:2022/12/01(木) 16:54:15.87 ID:xSaC71UL.net
いや俺のプロファイルだと間違いなく関わってる人間だ

749 :デフォルトの名無しさん:2022/12/01(木) 17:00:53.18 ID:SU5R7n94.net
すごいな。万が一、仮に裏方かなんかで関わっていたとしても、もう表舞台は無理だよね

ちなみに別の別室も注目>>746

750 :デフォルトの名無しさん:2022/12/01(木) 17:09:30.19 ID:fD4PDcdr.net
C++隔離部屋のくだらないレスバをRustスレに持ち込まないでくれる?

751 :デフォルトの名無しさん:2022/12/01(木) 17:23:29.67 ID:uXbJjnno.net
即解決じゃないでか。手元でやってませんがvalgrindでしょうね

コンパイルエラー→Rust (マウントじゃなく)
valgrind/sanitizer/etcで確認→C/C++

それぞれの流儀に従うまでです ← ここ重要

C言語なら俺に聞け 159
https://mevius.5ch.net/test/read.cgi/tech/1659623547/707
707: デフォルトの名無しさん(ワッチョイ ff63-RPwI) sage 2022/12/01(木) 16:47:51.25 ID:knNtAgEU0
y[200001];とd[200001]がスタック壊してしまいます涙

752 :デフォルトの名無しさん:2022/12/01(木) 17:28:44.40 ID:uXbJjnno.net
一つ言えるのは

C言語なら俺に聞け

即解決、機能した

753 :デフォルトの名無しさん:2022/12/01(木) 17:38:11.07 ID:fp7Y5Vje.net
今なら貼っていい?

RustとModern C++によって目が醒める
https://codezine.jp/article/detail/16769?p=5&anchor=4

754 :デフォルトの名無しさん:2022/12/01(木) 18:17:06.08 ID:Wq6wsgb9.net
別室の先生方は毎日ボクシングして切磋琢磨している、という説
くだらないレスバだけ、に見えるようでは青い、という説

755 :デフォルトの名無しさん:2022/12/01(木) 18:40:23.81 ID:PeHv0CKI.net
#某オジはこれを作って活躍してください

Rust言語なら俺に聞け

コテハン/ワッチョイ有の方が徳を稼げると思います
#MAUIもこの手法で少数?の支持を得始めたかもです

756 :デフォルトの名無しさん:2022/12/01(木) 22:44:34.30 ID:cwSC/i2f.net
本気で提案したつもりでしたが残念です。

私は書き込みせず見ただけですかが、
#某オジ = ID:mPKw+fm5 ですね。
http://hissi.org/read.php/tech/20221201/bVBLdytmbTU.html

757 :デフォルトの名無しさん:2022/12/01(木) 23:06:28.23 ID:oYnak1Dn.net
#某オジは自分に球があると自他共に認める状況が発生するとすかさず放り投げて、
空いた回線で他のスレを荒らしに行く

>>648-649の懸念が現実化してRustに泥を塗らなぬよう即刻やめろ

758 :デフォルトの名無しさん:2022/12/01(木) 23:47:30.33 ID:VP+MjCQ6.net
今更Modern C++に目覚めるぐらいならGoogleのCarbon Langに人生賭けた方が良くない?

759 :デフォルトの名無しさん:2022/12/01(木) 23:54:13.57 ID:Vi6mnuHJ.net
いろいろプロファイルすると、複オジ軍団説、完全否定できない。

Carbon Langの状況なんて無視して話を逸らす>>758 複オジ軍団ですか?

760 :デフォルトの名無しさん:2022/12/01(木) 23:57:07.42 ID:xX1TOujC.net
複オジ軍団に次世代言語にやたら興味がある人物がいるようだ

761 :デフォルトの名無しさん:2022/12/02(金) 00:12:34.82 ID:TMuqcbhv.net
C++の本 //鈍器
Rustのほん // ペラペラで字が大きい
こんなイメージなので勉強する気Maxの時はビャーネ・ストラウストラップの本を買ってしまおうかと、気の迷いが起こる

762 :デフォルトの名無しさん:2022/12/02(金) 00:15:42.04 ID:U8ThSRxs.net
>>758がyes/no答えない質問

Rustのメモリ安全性の何らかの保証に関して数学的証明がされている?
yesの場合はその、何らかの保証、を詳しく

俺らに恥かかせないでよね

763 :デフォルトの名無しさん:2022/12/02(金) 06:22:19.71 ID:1evFSF3k.net
このスレはオジをNGワードにすると割とスッキリする。

764 :デフォルトの名無しさん:2022/12/02(金) 06:28:40.89 ID:dhVfz/AS.net
複オジww

765 :デフォルトの名無しさん:2022/12/02(金) 16:07:31.52 ID:ef8lBYgh.net
>>761
いまさら禿本とか

766 :デフォルトの名無しさん:2022/12/02(金) 16:15:41.71 ID:KasCtwYY.net
本の厚さと内容の濃さは比例しない
良本なら反比例することもよくある

767 :デフォルトの名無しさん:2022/12/02(金) 18:41:11.95 ID:zxUfj+om.net
C++は余計な機能が多すぎて、解説する本が分厚くなっている面もある。
シンプルイズベストという言葉もあるくらいなので、HSP最強説。

768 :デフォルトの名無しさん:2022/12/02(金) 19:55:07.44 ID:xiR4WMyB.net
ハゲ本は結構良いよ
ただ難しい内容を説明してるわけでもないのに
説明が回りくどいのでそこが好みと合うか

769 :はちみつ餃子 :2022/12/02(金) 20:25:09.96 ID:mKFQqkua.net
解説は平易に越したことはないけど本来もつ複雑さより平易には出来ない。
解説が回りくどいように見えるかもしれんが C++ が回りくどい分がそういう形で表れてるだけ。
回りくどくない C++ 本は何か省いてる。

Stroustrup の本は D&E しか読んだことないから他は知らんけど。

770 :デフォルトの名無しさん:2022/12/03(土) 00:26:57.58 ID:dPKr1JJo.net
>>769
ところで、C++は他にどんな本で学びましたか?

771 :デフォルトの名無しさん:2022/12/03(土) 14:07:20.58 ID:6D7qwbVS.net
C++の人がRustも使っているだけで、大半の人は両刀使いって事でOK?

772 :デフォルトの名無しさん:2022/12/03(土) 14:34:57.98 ID:jUK3mt1e.net
今の段階でC/C++全く使えないでRust使える人は見たことがない

773 :デフォルトの名無しさん:2022/12/03(土) 14:49:09.11 ID:PqbNO9jz.net
自分の周りには普通にいるけどな、Web系メインだった人とか
単にやったことないってだけで別に今からやればできるようになるとは思うけど

774 :デフォルトの名無しさん:2022/12/03(土) 14:50:45.29 ID:wt3jQGAX.net
自分もC/C++は書いたことないよ

775 :はちみつ餃子 :2022/12/03(土) 15:13:46.08 ID:riW5om/o.net
>>770
私は古い世代の人間だからそんなことを聞いてもこれからの役には立たないよ。
とりあえず入門したのは「注解 C++リファレンスマニュアル」だなぁ……。
あとは雑誌を見たりウェブ上のリファレンスとかニュースとかで細々としたことは知った感じ。

776 :デフォルトの名無しさん:2022/12/03(土) 15:24:14.86 ID:uzIr2bMT.net
Windows の場合、Visual Studio に追加で入れるから最初はC# か何かは使ってないと拒絶しそう

777 :デフォルトの名無しさん:2022/12/03(土) 15:37:09.41 ID:nkG5MvF7.net
C++も書けるが最近はPythonメインで使っていて今はRustに傾倒してる

778 :デフォルトの名無しさん:2022/12/03(土) 17:06:05.61 ID:ecXQ+fMx.net
Rust の Vec::vec は、push() で末尾追加できますが、
このメソッドの signatureを見ると戻り値は存在しておらず、
メモリー確保に失敗すると panic するという理解で合ってますか。
仮にそうだとして、それを C++ の try catch 構文の様なもので補足することは
できませんか。別に構文はそれに限らずなんでもいいのですが、メモリー不足
が起きた時はpanic して強制的に必ずアプリが終了してしまってアプリ
からの制御は何も出来ない、ということですか。

779 :デフォルトの名無しさん:2022/12/03(土) 17:08:41.38 ID:ltklWITu.net
モダンC++はハゲ本か独習C++くらいしかまともな入門書がない

780 :デフォルトの名無しさん:2022/12/03(土) 17:09:29.11 ID:yu/BUrHT.net
>>777 Rustに傾倒中の勢いで力試しだと思って、春先からやられっ放しのCountWords最適化に挑戦してはくれないか?

781 :デフォルトの名無しさん:2022/12/03(土) 17:58:23.87 ID:8XRumJlQ.net
これからcodezineでモダンC++の連載始まるぞ

782 :デフォルトの名無しさん:2022/12/03(土) 18:16:35.82 ID:SoE3tSBB.net
>>778
try_reserve

783 :デフォルトの名無しさん:2022/12/03(土) 18:54:46.71 ID:AI9TLj2L.net
最初から全部モダンな書き方だといいな。
本によっては昔のものと混ざっている。

784 :デフォルトの名無しさん:2022/12/04(日) 14:50:02.38 ID:Mg8RdVSD.net
自分がモダンc++で書いてても旧式と絶対に出会ってしまうのでそっちもできるようにしないといけない
これが困る

785 :デフォルトの名無しさん:2022/12/04(日) 16:14:46.07 ID:RV2/jwt7.net
モダンモダンって、意味不明。
自分の生誕年と比して新しいってだけで、どんだけ自己中心的なの。

786 :デフォルトの名無しさん:2022/12/04(日) 16:22:30.31 ID:qWdYVkpM.net
実は、Modern C++というものは厳密には存在しません。
プログラミング言語C++の、あるバージョン以降をそのように呼んでいます

787 :デフォルトの名無しさん:2022/12/04(日) 16:57:30.52 ID:fmKWV/wp.net
生誕年とか関係なくてC++11以降の新機能を優先的に使うことを一般的にモダンと呼ぶだけだぞ

788 :デフォルトの名無しさん:2022/12/04(日) 17:20:06.36 ID:OHPAilb6.net
C++11も10年以上前だし今モダンと言ったらもう少し新しいんじゃないの

789 :デフォルトの名無しさん:2022/12/04(日) 18:17:34.92 ID:SUiviY+F.net
CodezineのModern C++連載はC++14、C++17、C++20の3バージョンを主題してるなぁ。

790 :デフォルトの名無しさん:2022/12/04(日) 18:18:58.95 ID:E8sA5vC6.net
飛び越えられる程度の低い段差が盛段な気がしている

791 :デフォルトの名無しさん:2022/12/04(日) 18:28:19.68 ID:EQ4pAAP6.net
Rustと関係ないC++の話は隔離相談室でやれ

792 :デフォルトの名無しさん:2022/12/04(日) 21:28:17.17 ID:oPsAeS3X.net
どんなにモダンな書き方してもそれがレガシーになっていくんだからそれなりの対応力がなけりゃプログラマなんて無理

793 :デフォルトの名無しさん:2022/12/04(日) 22:42:17.79 ID:SnbSooMc.net
そう、Rustはもう時代遅れ

794 :デフォルトの名無しさん:2022/12/04(日) 23:35:05.06 ID:pqDz82uP.net
『モダンRust入門』

795 :デフォルトの名無しさん:2022/12/04(日) 23:48:46.52 ID:mqdeTGzg.net
レガシーRustってどんなやつだろう?
・try!マクロを使ってる


796 :デフォルトの名無しさん:2022/12/05(月) 00:26:29.50 ID:pon/y3Oa.net
clippyに直せって指摘されるやつ

797 :デフォルトの名無しさん:2022/12/05(月) 00:27:02.53 ID:pon/y3Oa.net
edition2018以前はレガシー

798 :デフォルトの名無しさん:2022/12/05(月) 03:26:17.69 ID:IAPEqd2s.net
>>174
そのpythonの添え字の-1で配列の一番最後を表す仕様は完全に失敗した
プログラミングのミスで添字がマイナスとなった時もエラーとならず最後から数えた場所を指して意図せぬ動きで混乱を招いている
別途アクセスメソッドを用意するのが正解

799 :デフォルトの名無しさん:2022/12/05(月) 21:58:50.38 ID:zZIMoY87.net
>>798
同意

800 :デフォルトの名無しさん:2022/12/05(月) 22:20:16.15 ID:85vlj8hv.net
最初にnegative indexを採用したのはPascalだが-1が最後の要素を表さない。恐らくメジャーな言語で最初はRubyかLuaだわ。
Pythonは1.4から入りだして完全にサポートされたのが2.4なので主犯ではない
それを君は間違いだといいたいだろうが、カタナシのスクリプト言語で長々としたプログラムを書くのがそもそも間違っているYO!
それでアクセスメソッドという結論に安易に行き着くのはget(-1)と同じで正直やめてほしい....
だからと言ってRustのusizeインデックスは正当化できない、使いづらいだけ

801 :デフォルトの名無しさん:2022/12/05(月) 22:21:07.81 ID:m5vf/Aut.net
打ち間違い?がたまたま文法的にOKなんてことは、
どの言語でも、いくらでもシチュエーションとしてあり得ることだろ

802 :デフォルトの名無しさん:2022/12/05(月) 22:38:33.84 ID:NTxK7UYQ.net
利便性とリスクのトレードオフだからね
いちいち長さから計算する時代じゃない

803 :デフォルトの名無しさん:2022/12/05(月) 22:47:56.84 ID:jQ8cc2lX.net
>>800
そんな細かいことってどうでもよくね?

804 :デフォルトの名無しさん:2022/12/05(月) 22:54:27.15 ID:9YGPhFSH.net
>>800
> 最初にnegative indexを採用したのはPascalだが
ALGOL だろ

805 :デフォルトの名無しさん:2022/12/05(月) 23:11:47.28 ID:MKpQGtij.net
Cの入門書を読んで一応ある程度理解したつもりというレベルですが、Rustの入門におすすめの本やサイトがあったら教えていただけませんか?

806 :デフォルトの名無しさん:2022/12/05(月) 23:44:22.33 ID:PMru5zTg.net
>>805
オライリー本

807 :デフォルトの名無しさん:2022/12/05(月) 23:51:52.39 ID:MKpQGtij.net
>>806
Amazonの試し読みで2章Rustツアーを読みました
オライリー本が置いてあるような本屋が近くになく試し読みでも3章以降が読めないのですが、辞書的な感じでしょうか?
通読にも向いてますか?

808 :デフォルトの名無しさん:2022/12/05(月) 23:54:41.51 ID:uIcr3Drw.net
目次を見て判断しなさいよ

809 :デフォルトの名無しさん:2022/12/06(火) 01:04:16.95 ID:AYQzZ/1Z.net
>>807
辞書的な本じゃないよ
The Bookと同じように通読するタイプのRust入門本

810 :デフォルトの名無しさん:2022/12/06(火) 03:26:07.35 ID:SqysrJ92.net
>>800
.last()と.get(-1)は全然違うと思うんだが

811 :デフォルトの名無しさん:2022/12/06(火) 07:58:01.16 ID:zEklaQTD.net
>>805 The Book
https://doc.rust-jp.rs/book-ja/index.html

812 :デフォルトの名無しさん:2022/12/06(火) 10:02:55.32 ID:EPp4mQNt.net
>>811
それは低品質版の勝手日本語訳
本物のThe Bookはこっち
https://doc.rust-lang.org/book/

本気で学びたいなら日本語訳のThe Bookに手を出したらダメ

813 :デフォルトの名無しさん:2022/12/06(火) 10:31:58.81 ID:vigVXzh5.net
>>812
勝手日本語訳ってどういう意味?

814 :デフォルトの名無しさん:2022/12/06(火) 10:38:42.71 ID:6z0cppnT.net
>>812 基本的には日本語版で問題ない
それどころか英語版をGoogle翻訳しながら読むよりは質良いから気になるとこがあったら原文読む感じでいい

815 :デフォルトの名無しさん:2022/12/06(火) 10:57:55.33 ID:aMDIqhh+.net
釣られんなよ (´・ω・`)

816 :デフォルトの名無しさん:2022/12/06(火) 11:05:39.12 ID:aMwchw3Z.net
こうして、日本におけるRustの学習曲線はさらに険しくなるのであった。

817 :デフォルトの名無しさん:2022/12/06(火) 11:20:31.41 ID:HA2LFIoo.net
定数すら知らないやつが訳した誤訳をそのまま垂れ流してるのが問題ないってww
頭わいてるのかな
そんなんだから所有権を複製しちゃうんだろ

818 :デフォルトの名無しさん:2022/12/06(火) 12:32:25.37 ID:rE8cfGd/.net
出版社/著者の為にも、本を買ってあげて。

819 :デフォルトの名無しさん:2022/12/06(火) 12:39:34.84 ID:swsmryOJ.net
数値型やブール型などは所有権の移動はなく常に複製される

820 :デフォルトの名無しさん:2022/12/06(火) 12:46:01.49 ID:6z0cppnT.net
>>817
https://doc.rust-jp.rs/book-ja/ch03-01-variables-and-mutability.html
> 最後の違いは、定数は定数式にしかセットできないことです。関数呼び出し結果や、実行時に評価される値にはセットできません。

ここの話だと思うが、読み間違いやすい文章だな
誤訳と言うほど間違ってはないけど要改善

821 :デフォルトの名無しさん:2022/12/06(火) 12:58:10.61 ID:tS6tYBbH.net
またその話やんの

822 :デフォルトの名無しさん:2022/12/06(火) 13:04:06.15 ID:6z0cppnT.net
ほんそれ
アホ臭いから突っかかってこないでほしい

823 :デフォルトの名無しさん:2022/12/06(火) 13:16:01.68 ID:lM2TuwNH.net
>>820
なるほど
あの日本語訳はこの日本語が誤訳だとすら思えない人向けってことなんだな
ガベージイン・ガベージアウトのいい例

824 :デフォルトの名無しさん:2022/12/06(火) 13:40:54.01 ID:Vu2BcSww.net
>>823 お前が誤訳だと思うならそれでいいから黙ってろ

825 :デフォルトの名無しさん:2022/12/06(火) 13:41:28.90 ID:FStkMgHU.net
>>819
複製されないよwww

826 :デフォルトの名無しさん:2022/12/06(火) 13:45:42.32 ID:vtEUfIF0.net
>>820
>読み間違いやすい文章だな
明らかな誤訳を読む側に責任転嫁しちゃうのか

827 :デフォルトの名無しさん:2022/12/06(火) 13:52:05.31 ID:tS6tYBbH.net
機械翻訳あるいはどこの誰とも知らぬ人でしょ
そんなの相手にムキになってないで、言語の話しろよ

828 :デフォルトの名無しさん:2022/12/06(火) 15:15:37.73 ID:RihiShBF.net
もうそれ飽きたから誤訳言うなら他の場所の誤訳をあげてくれ
まだその方がみんなのためになるし

829 :デフォルトの名無しさん:2022/12/06(火) 15:39:16.64 ID:vigVXzh5.net
ここから日本語版へのリンク張られてるけど外してもらうように働き掛けた方が良いのかね?
https://doc.rust-lang.org/stable/book/appendix-06-translation.html

830 :デフォルトの名無しさん:2022/12/06(火) 16:53:25.53 ID:rE8cfGd/.net
>>829
止めて下さい。
日本語も見ます

831 :デフォルトの名無しさん:2022/12/06(火) 17:08:44.79 ID:5YlTlO+b.net
普通に「翻訳の改善に協力しては?」って言われるだけでは
5chならともかくリアルのGithubアカウントでそんな恥ずかしいPR出せんな…

832 :デフォルトの名無しさん:2022/12/06(火) 18:40:54.66 ID:vigVXzh5.net
https://blog.rust-lang.org/2022/12/05/survey-launch.html
今年もrust survey来たぞ
日本語訳もある

833 :デフォルトの名無しさん:2022/12/06(火) 20:00:08.84 ID:sedVUjKM.net
本当に日本人って何もせず文句だけ言う人が多すぎだな
改善してほしくて改善点も分かってるなら自分でやった方が圧倒的に早いのに

834 :デフォルトの名無しさん:2022/12/06(火) 21:25:02.08 ID:RDoWQe9F.net
あの日本語訳の改善なんて誰も望んでない

835 :デフォルトの名無しさん:2022/12/06(火) 21:37:33.14 ID:FCw1RUR4.net
問題ありまくりの日本語訳を参考にするのはやめましょうって話であって改善しようって話ではないわな

836 :デフォルトの名無しさん:2022/12/06(火) 22:49:17.43 ID:zEklaQTD.net
>>829 無いよりマシ

837 :デフォルトの名無しさん:2022/12/06(火) 23:00:32.77 ID:N+cyFIt6.net
元の英語もあんまりよくないな

最後の違いは、定数は定数式に対してだけしかセットできない
実行に計算されるかもしれない値の結果にはセットできない

838 :デフォルトの名無しさん:2022/12/06(火) 23:03:10.60 ID:h/ukiy7O.net
英語文献をありがたがる、典型的な舶来コンプレックス

839 :デフォルトの名無しさん:2022/12/06(火) 23:08:53.69 ID:gk9SZTYC.net
誤訳ですよって説得して修正させることができないなら結局主観でしかないってことよ

840 :デフォルトの名無しさん:2022/12/06(火) 23:43:26.61 ID:wxmB/YEK.net
>>837
それが誤訳だっての

841 :デフォルトの名無しさん:2022/12/06(火) 23:51:16.30 ID:Ow+XJZhk.net
主観を無くすには無人か少人数の方がよさそうなのに
人が多いほど主観が少ないって誰が言ったのか、それも人が多すぎて特定できない

842 :デフォルトの名無しさん:2022/12/07(水) 00:00:30.38 ID:xLbd5eMx.net
参考にするのやめた方が良いような情報ならやはり英語版からのリンクは外してもらった方が良いのでは
初学者惑わすだけでしょ

843 :デフォルトの名無しさん:2022/12/07(水) 00:02:06.86 ID:3JEhjr2d.net
>>838
英語文献をありがたがってるんではなく
某翻訳がゴミすぎるという話だぞ

844 :デフォルトの名無しさん:2022/12/07(水) 00:09:51.51 ID:IJoOi7Sy.net
文献や資料の質を見極める力もプログラマーにとってはかなり重要な能力
質の低い文献にひっかかったなら失敗から学べ

845 :デフォルトの名無しさん:2022/12/07(水) 00:21:26.68 ID:rpgrLTt2.net
AndroidもRustで書かれてたのかよ!
しかもRustの部分は脆弱性の報告0件って恐ろしいほどの安全性だな……
これマジでRust一強の時代がくるかも……
Ubuntuにデフォルトで入るまで待とうとのん気に構えてたけど急いで勉強しないと……!〆(.. )カリカリッ!!
https://japan.zdnet.com/article/35196972/

846 :デフォルトの名無しさん:2022/12/07(水) 00:35:34.36 ID:21cwGaas.net
>>845
まじ?
というか20%がrustってえぐいな

847 :デフォルトの名無しさん:2022/12/07(水) 00:41:52.20 ID:xT6Hu5AC.net
C/C++ の書き方の何が危ないのか、Rustはどうやって回避しているのかは何を読めば分かるの?
Out of memory なんか防げるんだっけ?

848 :デフォルトの名無しさん:2022/12/07(水) 00:58:54.43 ID:fQ3/NsZR.net
kLOCあたり1つ以上の脆弱性があったものが1500kLOCでゼロ
unsafeが量も気になるな

849 :デフォルトの名無しさん:2022/12/07(水) 01:00:43.82 ID:+scmKVbE.net
Google製のRustライブラリはどんなのがあんの?

850 :デフォルトの名無しさん:2022/12/07(水) 04:00:04.20 ID:0xPH+d9p.net
>>845
> システムプログラミングからCやC++を排除するつもりはないという。
これの理由を知りたいわ
まだRustでは書きにくい所があるんだろうか?

851 :デフォルトの名無しさん:2022/12/07(水) 04:05:04.23 ID:+scmKVbE.net
ってか、Googleはその分野で使うためにCarbon開発したんじゃなかったのか?

852 :デフォルトの名無しさん:2022/12/07(水) 04:17:31.35 ID:21cwGaas.net
CarbonもRust使えるならRust使えと言ってる

853 :デフォルトの名無しさん:2022/12/07(水) 09:06:42.16 ID:Mw8qZqut.net
google発のOSSって社員の個人プロジェクトをgoogle名義で公開してるだけの場合もあるからな

854 :はちみつ餃子 :2022/12/07(水) 09:19:24.95 ID:vqEtcxl0.net
どれがいい感じに発展するか事前にわかるもんではないからな。 狙いとは違う方向で結実することもあるし。
色々やっておく (それが出来る環境を用意する) とどれかは上手くいくし、上手くいかずに消えるものも多いってだけのこと。

855 :デフォルトの名無しさん:2022/12/07(水) 10:24:44.39 ID:G2nMx9FR.net
そこまで誤訳だと言うならコントリビューションすれば良いのではないの?

856 :デフォルトの名無しさん:2022/12/07(水) 10:39:11.42 ID:KNXoSnHr.net
>>845
結果だけみると凄まじい
システムプログラミング関係の置き換えは案外急速に進むかもしれんね

857 :デフォルトの名無しさん:2022/12/07(水) 11:16:25.80 ID:6Eaq6nhz.net
>>855
誤訳だらけでキリがない
ゴミから小さなゴミを取り除いてもゴミのまま
だれがそんなことに時間使うのさ

858 :デフォルトの名無しさん:2022/12/07(水) 12:26:52.65 ID:El0pJGUF.net
>>857
2chで文句言って他の話題を出にくくする方が有意義だと思うやつもいるんだな。

859 :デフォルトの名無しさん:2022/12/07(水) 12:31:58.03 ID:74PfFudB.net
複おじ以前と以後で明らかに話題の質が落ちてるよね
おのれ複おじ

860 :デフォルトの名無しさん:2022/12/07(水) 12:39:55.04 ID:m46mCwKQ.net
>>855
難癖つけて嘲笑って愉しんている奴がそんな無駄なことするわけがない。
自分がマウントできればいいだけだから、そもそもRustを良くする気なんて全く無いだろ。

861 :デフォルトの名無しさん:2022/12/07(水) 12:46:13.68 ID:g3+WCnxI.net
>>850
Cなら分かるがRustが分からない人
のことを老人と思うのは憶測で、むしろ子供である可能性が高い
子供を排除や淘汰しても進歩など起きない
少子化が加速するだけ

862 :デフォルトの名無しさん:2022/12/07(水) 12:53:44.84 ID:Mw8qZqut.net
>>850
元記事に以下とあるから既存のコードをrustで書き換えることまではしないという意味だと思われる

As we noted in the original announcement, our goal is not to convert existing C/C++ to Rust, but rather to shift development of new code to memory safe languages over time.

863 :デフォルトの名無しさん:2022/12/07(水) 12:54:18.57 ID:Mw8qZqut.net
>>862
元記事のurl貼り忘れた

https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

864 :デフォルトの名無しさん:2022/12/07(水) 15:17:49.39 ID:Xzjw4n/l.net
>>862-863
ありがとう、まあ普通はそうするよね
ただそうするとAndroid 13は20%が新規のコードなんだ...
それはそれで凄いな

865 :デフォルトの名無しさん:2022/12/07(水) 15:24:21.27 ID:3HHCfxiv.net
マジでrust本腰入れよ
ゾワってしたわ
C/C++書いてたけど取り残される

866 :デフォルトの名無しさん:2022/12/07(水) 15:28:39.71 ID:h/t9+qo5.net
>>846,864
違う
天然か煽りかわからなけどちゃんと読もうな

867 :デフォルトの名無しさん:2022/12/07(水) 15:40:23.08 ID:3HHCfxiv.net
せっかくモダンC++とoneTBB覚えて万能感感じてたのにさ
リセットかよ

868 :デフォルトの名無しさん:2022/12/07(水) 15:51:23.23 ID:Mw8qZqut.net
>>864
新規コードの20%ね
In Android 13, about 21% of all new native code (C/C++/Rust) is in Rust.

There are approximately 1.5 million total lines of Rust code in AOSP
ともあるからAOSPの全体のコード量分かればrustの割合も分かるはず

869 :デフォルトの名無しさん:2022/12/07(水) 15:52:33.64 ID:Mw8qZqut.net
>>868
新規コードの20%というのも不正確で新規のネイティブコードの20%
java等で書かれたものは除外したうちでの割合ね

870 :デフォルトの名無しさん:2022/12/07(水) 15:58:02.82 ID:JdTFl5al.net
There are approximately 1.5 million total lines of Rust code in AOSP
*Android Open Source Project (AOSP)

1.5mてどう考えても、例によってRustコンパイラやサードcrateのソースツリーも含まれている悪寒

871 :デフォルトの名無しさん:2022/12/07(水) 16:58:18.23 ID:Mw8qZqut.net
>>870
AOSPのソースツリーではrustcはpre-built binaryがコミットされてるから行数カウントには含まれてないっぽい
外部crateは含まれてるかも知れないけど、実際にそれだけのコードが使われているという意味では正しいんじゃないの

872 :デフォルトの名無しさん:2022/12/07(水) 17:03:21.31 ID:n0jQbyrj.net
>>871
その発想がrustクオリティ

Java/C++勢はそんな嵩増ししてない

873 :デフォルトの名無しさん:2022/12/07(水) 17:15:07.05 ID:g3+WCnxI.net
実際に使われているC/C++
を捨てることの正当性ももう無いんだからいいじゃないか

874 :デフォルトの名無しさん:2022/12/07(水) 17:35:07.63 ID:8PgDeggG.net
>>870
>1.5mてどう考えても、
同感。この短期間に150万行ってどの範囲?これが普通の感想

>>871
>AOSPのソースツリーではrustcはpre-built binaryがコミットされてる
何処?
github mirrorの方で教えて https://github.com/aosp-mirror

>>873
新規nativeコードの21%という数字が水増し、かどうかに係るので整理するべきかと

875 :デフォルトの名無しさん:2022/12/07(水) 17:40:15.78 ID:21cwGaas.net
割合とか増えていくんだからどうでもいいだろ
それよりAndroidでrustが使えるところはrustを使うという判断がとっくにされてたのが衝撃

876 :デフォルトの名無しさん:2022/12/07(水) 17:42:58.56 ID:NHS9DFe3.net
珍しく良い記事紹介だったのに
急に下らない議論になっちゃうのな

877 :デフォルトの名無しさん:2022/12/07(水) 17:44:20.91 ID:Mw8qZqut.net
>>874
GutHubでどこにあるのかは分からないがAndroid Code Searchでは以下が出てきたのでpre-built binary使ってるのかなと判断した

https://cs.android.com/android/platform/superproject/+/master:prebuilts/rust/linux-musl-x86/1.63.0/bin/rustc;l=1?q=rustc&sq=

C++もrustも外部ライブラリはexternal配下にまとめられているようなので、それぞれで集計の仕方を変えるなんて事をしてない限りは、同一条件での比較になるんじゃないかな

あと150万行ってのはAndroid13の話じゃなくて累積のコード量がって話しだよ

878 :デフォルトの名無しさん:2022/12/07(水) 17:44:50.45 ID:8PgDeggG.net
>>874 追記
なんかRust批判みたいな印象になっているけど、881が多少調べたっぽいので詳しく知りたいだけ

879 :デフォルトの名無しさん:2022/12/07(水) 17:47:35.12 ID:JLiaiVk0.net
>>876
次世代隔離スレがなくなると暇してるオジサン達が溢れてくるのよ

880 :デフォルトの名無しさん:2022/12/07(水) 17:55:32.50 ID:8PgDeggG.net
>>877 ありがと
ただし、ここ見るだれでもrustコンパイラを構成するソースファイルが山ほどある
https://cs.android.com/android/platform/superproject/+/master:prebuilts/rust/linux-musl-x86/1.63.0/src/

さすがにgccの方はsoになってる
https://cs.android.com/android/platform/superproject/+/master:prebuilts/gcc/linux-x86/

>C++もrustも外部ライブラリはexternal配下にまとめられている
こうした統計ではソースとしておいてあるかどうかで結構差がある

881 :はちみつ餃子 :2022/12/07(水) 17:59:46.34 ID:vqEtcxl0.net
割合で言えば大したことは無くてもある程度は積極的に使おうとする雰囲気は感じなくもないってところかな。

882 :デフォルトの名無しさん:2022/12/07(水) 18:00:13.04 ID:8PgDeggG.net
>>877
>あと150万行ってのはAndroid13の話じゃなくて累積のコード量がって話しだよ

累積のコード量で、Android向け書き起こしRustソースが150万行、という主張であれば水増しの疑いを持ってる

883 :デフォルトの名無しさん:2022/12/07(水) 18:01:45.15 ID:8PgDeggG.net
>>881
>ある程度は積極的に使おうとする雰囲気
それは同感

884 :デフォルトの名無しさん:2022/12/07(水) 18:01:53.83 ID:Mw8qZqut.net
>>880
コンパイラじゃなくて標準ライブラリのことね
確かにlibcとは扱いに差があるかもね

詳細な数値が気になるならソースダウンロードして測定してみたら良いのでは
https://source.android.com/docs/setup/download/downloading

885 :デフォルトの名無しさん:2022/12/07(水) 18:04:39.07 ID:8PgDeggG.net
>>884
そんな手間かけたくないから聞いたんだけど、皆そうなんだろうな

>累積のコード量で、Android向け書き起こしRustソースが150万行、という主張であれば水増しの疑いを持ってる
これで継続だな

886 :デフォルトの名無しさん:2022/12/07(水) 18:06:43.25 ID:Mw8qZqut.net
>>885
> Android向け書き起こしRustソースが150万行、という主張
原文ではそんな主張はしていないよ

887 :デフォルトの名無しさん:2022/12/07(水) 18:11:19.10 ID:8PgDeggG.net
>>886
そう。原文は意図的かどうかは分からないが、あやふやな表現なので範囲を問うてみた
ここだけ読んでそう捉えて誤解をした人がいたら、まず範囲を疑うのが普通、と思った

888 :デフォルトの名無しさん:2022/12/07(水) 18:13:51.76 ID:8PgDeggG.net
ちなみにPhoronixで読んだが、LinuxのRust対応は賞味2万行

889 :デフォルトの名無しさん:2022/12/07(水) 18:20:26.12 ID:wjXnim/d.net
>>857
じゃあ一から訳したら?
誰かがそうやったから存在するんだが…

>>860
情けないよね。マージされたらそれなりに嬉しいのに。

890 :デフォルトの名無しさん:2022/12/07(水) 18:24:03.55 ID:8PgDeggG.net
例えば、ここだけど、150万行はおろか、2万行すら程遠いかな
https://github.com/aosp-mirror/kernel_common/tree/android-mainline/rust

891 :デフォルトの名無しさん:2022/12/07(水) 18:36:53.47 ID:M+Adnv0G.net
もっと有意義な話しようぜ
fn<T>foo(x: &T); のTにSized制約付くの邪魔くせーとかさ

892 :デフォルトの名無しさん:2022/12/07(水) 18:39:18.13 ID:CifLjB7G.net
>>868
そうするとまたはじめの疑問が...
> まだRustでは書きにくい所があるんだろうか?

893 :デフォルトの名無しさん:2022/12/07(水) 18:41:18.29 ID:Mw8qZqut.net
>>891
x: TのときはSizedついて欲しいけど、&Tのときはついて欲しくないということ?
Box<T>やRc<T>やユーザー定義のスマートポインタの扱い考えるとめんどくさいから一律Sizedがデフォルトでよくない?

894 :デフォルトの名無しさん:2022/12/07(水) 18:48:05.32 ID:Mw8qZqut.net
>>892
今出てきている情報だけではなんとも言えないかと
Android開発者の内Rustを使える人の割合が少ないだけの可能性もある

895 :デフォルトの名無しさん:2022/12/07(水) 18:51:46.12 ID:8PgDeggG.net
>>892,894
その21%が水増しかどうかは重要なわけではなく

>ある程度は積極的に使おうとする雰囲気
これに意義がある

896 :デフォルトの名無しさん:2022/12/07(水) 18:53:03.86 ID:21cwGaas.net
そりゃC++とのInteropが絶対に必要だしRustはそこが弱い
そういう用途としてはCarbonがあるけどセキュアではない
(C++よりはマシだろうが)

897 :デフォルトの名無しさん:2022/12/07(水) 18:58:45.38 ID:8PgDeggG.net
>>896
は20%(水増し?)で浮き足立ったり、Carbonの話に拘ってるけど
当分の間はCarbonの話をすると鬼が笑うと思う

898 :デフォルトの名無しさん:2022/12/07(水) 19:02:37.66 ID:glN0FB8M.net
Androidの中のRustはGabeldorsche, keystore2, DoH, UWBくらいだっけ
もう3年くらいかかってるからそれなりの行数になってる気もするけどどうなんだろ
aospのrepo sync全部やるの時間かかるんだよな…

899 :デフォルトの名無しさん:2022/12/07(水) 19:05:40.97 ID:8PgDeggG.net
>>898
>aospのrepo sync全部やるの時間かかるんだよな…
そこを何とかお願いします
どの範囲を集計したら150万行に到達するのか皆気になってます

900 :デフォルトの名無しさん:2022/12/07(水) 19:09:14.99 ID:/TInWduh.net
repo sync 終わらんよな
今3時間経過

901 :デフォルトの名無しさん:2022/12/07(水) 19:14:14.71 ID:8PgDeggG.net
期待大

原文では
>There are approximately 1.5 million total lines of Rust code in AOSP across new functionality and components such as Keystore2, the new Ultra-wideband (UWB) stack, DNS-over-HTTP3, Android’s Virtualization framework (AVF), and various other components and their open source dependencies.
となってますので、

Keystore2
Ultra-wideband (UWB) stack
DNS-over-HTTP3
Android’s Virtualization framework (AVF)
and various other components and their open source dependencies.
これで150万行の大半を占めているかのような書き方です

まさかこれが大半を占めていたり
>open source dependencies
rustコンパイラのソースツリーが入っているとは言えませんよね

902 :デフォルトの名無しさん:2022/12/07(水) 19:30:47.68 ID:/TInWduh.net
期待すんな
gitとpython入ってるwsl環境とかあれば簡単にとってこれるぞ
https://source.android.com/docs/setup/download/downloading
ただ時間がかかるだけ
この程度出来ない奴がrustについて云々言うとか片腹痛い

903 :デフォルトの名無しさん:2022/12/07(水) 19:35:42.75 ID:8PgDeggG.net
>この程度出来ない奴がrustについて云々言うとか片腹痛い
そうだね(笑)

こっちでもやってみるかな

904 :デフォルトの名無しさん:2022/12/07(水) 19:35:54.12 ID:glN0FB8M.net
半年ほど前のやつがあったのでそれでtokeiかけてみた
とりあえずexternal内が180万行でprebuiltsが500万行くらい
なので1.5mの根拠はexternalの方かな
prebuiltsの方に上で挙がってたmuslとか入っている
external内はrustディレクトリ内の依存クレートが150万くらい
依存クレートでないので最大はcrosvmが30万行くらい

というわけでAndroidのために150万行書き下ろしたというのは言い過ぎ
ただ150万行のソースコード使ってるという原文の主張は正しそう(コンパイラのコードとかは入ってない)
まぁ依存クレートにも明らかにAndroid用っぽいのもあるし
これ以上の切り分けは難しいな

905 :デフォルトの名無しさん:2022/12/07(水) 19:50:48.43 ID:CifLjB7G.net
>>894
それなりに優秀な人たちだと思うんたけどそれでもハードル高いのかな...

>>895
水増しとかどうでもいいのでいちいち絡んで来ないでね

906 :デフォルトの名無しさん:2022/12/07(水) 20:03:05.60 ID:glN0FB8M.net
一応依存クレートも一通り見てみたけど大きいのはメジャーなやつだね
というわけでAndroidのために書かれたコードは全体で40万行以内ってとこかな

まぁtokioやらcrossbeamがちゃんと使われているのは水増しと批判するようなことではなく
むしろいいことなんじゃないか?

907 :デフォルトの名無しさん:2022/12/07(水) 22:19:15.93 ID:Lb4jZ7zf.net
それにしても無駄の多いコーディングだな。
そもそもAndroidで使われたというだけであって、Rustが広まったという訳ではない。

908 :デフォルトの名無しさん:2022/12/07(水) 22:24:52.03 ID:Lb4jZ7zf.net
かつてCが流行したのは、LatticeC、SmallC、TurboC、MS-C、WatcomC など
色んな企業がコンパイラ作りを競い合った結果だったかも知れん。
TurboCが流行ったが、それ以前からCは雑誌I/Oなどでも取り上げられて、
さまざまな人が話をし、良い言語であるという噂が立っていた。
当時を知っている俺が言わせて貰えば、なぜか、Rustはビビっとこない。
Cはビビっと来た。
C++は、初期の頃にびびっときたが、C++11では、こりゃもう駄目だ、
と思った。

909 :デフォルトの名無しさん:2022/12/07(水) 22:39:14.39 ID:UARY1o0b.net
>>908 蓋を開けてみれば様々なバグ(特にメモリ関連)の元凶だったから、その感覚の逆が正解かな

910 :デフォルトの名無しさん:2022/12/07(水) 22:42:23.65 ID:cTs8jKu4.net
アセンブラとBASICしか無かった所に
Cが登場したから、そりゃ喜んで使うわ

911 :デフォルトの名無しさん:2022/12/07(水) 22:59:32.88 ID:Odhm3loP.net
>>908
今は何にビビっと来るの?

912 :デフォルトの名無しさん:2022/12/07(水) 23:01:58.13 ID:Xa+0WmXy.net
>>908
LSI C-86も入れといてね

913 :デフォルトの名無しさん:2022/12/07(水) 23:23:48.68 ID:g3+WCnxI.net
スタックかグローバル変数しか無い文化でCを流行らせてもヒープのバグは少ない

ヒープを使わないなら変数の寿命は固定長、という伏線が回収されたことに
まだ気付いてない人もいる

914 :デフォルトの名無しさん:2022/12/07(水) 23:25:35.88 ID:21cwGaas.net
>>908
ロートルは去れ

915 :デフォルトの名無しさん:2022/12/07(水) 23:26:15.82 ID:Lb4jZ7zf.net
>>911
そうだな、まだ決め手となるものは無いが、(個人的には好きではないが)JSに
人気が有るのはブラウザがそれしか使えなかったから「では無い」と思ってる。
Rubyと比較すればJSの方が優れているように感じる。
また、C#はJavaよりは改良されていると感じる。但し、これも好きではない。
Pythonも好きではない。人気が有る理由は恐らくAIのライブラリと使用例が
多いからではないかと思ってる。
ということで、今はびびっとくるものが無い。

916 :デフォルトの名無しさん:2022/12/07(水) 23:31:51.79 ID:Xa+0WmXy.net
結局RUSTに限った話じゃなかったかw

917 :デフォルトの名無しさん:2022/12/07(水) 23:34:48.20 ID:Lb4jZ7zf.net
Rustは大々的には流行らないんじゃないと思うぞ。
理由は色々有るが、
・流行ってる言語は、JS、Python、Java、PHP、C#、Ruby、VB など、初心者向けの
 簡易言語が多い。
・Rustは中途半端。伝統を無視。習慣を無視。直感的でない。
・そもそもRustは低レベル向け言語、上記に書いた簡易言語のターゲット層には
 被らない。
なお、Googleは色んな言語に手を出す企業。
使ってる言語も幅広く、(同列に入れるべきでないものも混ざるが)
C++、NaCL(*)、Java、Kotlin(*)、Go(*)、Dart(*)、Carbon(*)、Rust、Wasm、
などなど。[(*)は自社製言語や自社製仮想言語(?)]
自社製言語だけでも4つ、仮想言語が1つ。

918 :デフォルトの名無しさん:2022/12/07(水) 23:36:08.15 ID:cTs8jKu4.net
MS-DOS 向けで最初に入ってきたのは
optimizing C86 だったと思う

919 :デフォルトの名無しさん:2022/12/07(水) 23:40:24.00 ID:Lb4jZ7zf.net
そもそも低レベル言語でもココまでメモリ管理に気をとられる言語はなく、
直感的に書けた。
Rustはメモリ管理ばかりに気をとられる言語。論理に集中しにくい。
また、JavaやC#、C、C++では直感的に書けることがRustでは書けない。
なお、「それはおまえがバグのコードを書いているから」と反論されるが、
はっきり言って、そのコードでも全くバグは無いから。

920 :デフォルトの名無しさん:2022/12/07(水) 23:49:55.59 ID:51+7TkbX.net
隔離スレがないからとにかく昔話をしたいお爺ちゃん達のたまり場になっちゃったね

921 :デフォルトの名無しさん:2022/12/07(水) 23:56:19.06 ID:Lb4jZ7zf.net
Cが流行ったのはリンクリストが作れたからだ。
Strousutup氏はリンクリストを全否定に近い形で否定しまくっているが、
彼は机上の空論であり、彼が自分で実験してvectorの方が速いとしたものも
実際に合わない机上の空論的なベンチマークテストだったろう。
そしてそれを信じてしまったRustの作者はRustではリンクリストを
まともには使えない状態にしてしまった。

922 :デフォルトの名無しさん:2022/12/07(水) 23:59:45.09 ID:sHYfIE3H.net
なんだお前だったのか

923 :デフォルトの名無しさん:2022/12/08(木) 00:03:22.42 ID:kNVI3qAc.net
スレ立てろよ
手持ちの回線だと全部無理なんだ

924 :デフォルトの名無しさん:2022/12/08(木) 00:08:02.18 ID:QroOE5Fs.net
ID:Lb4jZ7zfのプライドだけ高い老害感すごいな 狙ってできるもんじゃない

925 :デフォルトの名無しさん:2022/12/08(木) 00:20:06.52 ID:pMPEGjtK.net
一般人は馬鹿だから偉い学者さんが言った間違った言説を信じるしかない。
実験したことが現実的な状況と合ってなければ実験結果は無意味。
だから、他の経験者はリンクリストが速くてメモリー効率もいいことを知っている
のに机上の空論者であるところのStroustrup氏は、自分がやった机上の空論的な
実験結果を縦に徹底抗戦を仕掛けている。
しかし、実際と有って無いから反感を買っている。
それも、C++から人が離れていっている原因の一つ。
C++もRustもどちらも机上の空論になってる。

926 :デフォルトの名無しさん:2022/12/08(木) 00:22:10.33 ID:pMPEGjtK.net
>>924
老害はStroustrup氏とRustの信者の方。
Rust信者には本の謳い文句に騙された哀れな宗教信者も多いが。

927 :デフォルトの名無しさん:2022/12/08(木) 00:29:07.90 ID:WCqcOtXz.net
即NG㌧

928 :デフォルトの名無しさん:2022/12/08(木) 00:32:17.18 ID:pMPEGjtK.net
LinkedListがキャッシュ効率が悪いというのも机上の空論。
なぜなら、机上の空論者は、LinkedListのノードのアドレスが「ランダム」で
あると間違った仮定するから。
実際には基本的に連続しており、多くの場合は連続して無いとしても
軽微な数バイトの隙間がところどころ空いているだけ。
大きく変化することもあるが、それは全体の数箇所だけ。
なぜなら、挿入箇所は、一箇所から始まってその周辺を押し広げてノードを挿入している
だけで、それが少数あるだけだから、アドレスが大きく変わる箇所はわずかで、
「バースト的」になっているから。
机上の空論者は、ノードアドレスをランダムだと考えるから、キャッシュ・ミスが常に
起きると考えてしまう。ところが、そんな状況はまず有りえない。

929 :デフォルトの名無しさん:2022/12/08(木) 00:35:48.02 ID:pMPEGjtK.net
>>928
さらに、LinkedListのメモリー効率が悪いというのもウソで、むしろ、
std::vectorの方が悪いことが多い。
なぜなら、後者は、濃度ーを末尾追加していくと、スプリアス的に
今までの配列の入ったテーブルの1.5倍のサイズのテーブルをヒープ領域から
確保してしまう。
これが物凄く致命的で、std::vectorは、要素 T のサイズが大きい場合、
物凄くメモリー効率が悪くなる。
一方、std::list は、要素 T のサイズが大きい場合、std::vectorより遥かにメモリー効率が良い。

930 :デフォルトの名無しさん:2022/12/08(木) 00:39:53.26 ID:pMPEGjtK.net
>>929
[補足]
std::vectorは、sizeがcapacityを越えそうになると、今までのcapacityの
1.5倍のテーブルを新たに確保するので、今までのテーブルと合わせると、
一時的に 1 + 1.5 = 2.5 倍のメモリー領域を確保してしまう。
std::list ならこんなことは起きない。
なおさらに悪いことに、std::vectorはことの時、全要素を move するので
キャッシュが大規模に汚染されてしまう。
キャッシュ汚染という点では、std::vectorは、先頭や途中への要素追加
の際もキャッシュが大規模に汚染されてしまう。

931 :デフォルトの名無しさん:2022/12/08(木) 00:45:56.87 ID:pMPEGjtK.net
stroustrup氏の言説はデタラメが多くてストレスがたまる。
そして、自分が間違った説を後ろ盾するために、間違った仮定の元に
実験を行なっている。
コンピュータの実験の場合、正しい仮定のもとで行なうことが重要で、
実験して時節を裏付ける結果が出たとしても、仮定がまるっきり
間違っているのだからどうしようもない。
ベンチマークテストでも、もし、実際と合わないような内容をテストしても
意味が無い。そんな状況は滅多に起きないから。
コンピュータの測度は「加重平均値」で決まる。どういう「加重」かが、机上の空論者
には分からないからデタラメになる。
言語仕様の策定においても、実際にはそんなことをやってもほとんど意味が無いことを
優先的に簡単化しようとする一方で、もっとも重要なことがめんどくさくなるような
仕様を追加してしまったりする。
だから、C++は机上の空論といわれる。
ところが、同じことがRustにも言える。

932 :デフォルトの名無しさん:2022/12/08(木) 00:46:30.49 ID:rnWAZYk7.net
gccのrustフロントエンドがマージされるそうだけど、これってどういう時に便利なの?
gccでビルドしたCとのcross-language LTOとかできるの?

933 :デフォルトの名無しさん:2022/12/08(木) 01:02:47.82 ID:D2mGrKMe.net
>>904,906
ありがとうございます とても参考になります

こちらはパーティションを小分けにしていたせいで要領不足にあっていました
これ全体だと300GB以上あるのでしょうか?

仕方ないので
repo init -u https://android.googlesource.com/platform/manifest --depth=1 --partial-clone --clone-filter=blob:limit=10M -b android-13.0.0_r18
としたら100GB位に収まって何とか完走したところです

android-12.1.0_r26も取ってきて21%がcrosvm(当初はChromeOS向け)の移行を含んでるのかどうか見たかったのですが
話のネタが変わってしまったので週末かどこかでやり直すことにしました

934 :デフォルトの名無しさん:2022/12/09(金) 01:41:09.99 ID:Sh2LVmg/.net
LinkedList信者まだいるんだ....
リンクリストなんて既にETHやMITでも、コンピューターサイエンスで多くの人が間違いなく否定するものなのに。別にStrousutupだけじゃないぞ?ほぼ全否定で言ってるのは
キャパを越えそうな事を無理やりするのはほぼ設計の問題だし、途中への要素追加が起きるようなコードを書いてて問題ないと思ってるのはプログラマの能力の問題。
バースト的なんて言ってるけど、連続するメモリー領域へのアクセスと比べて明らかにリンクリストが不利になるのは自明だ、さらに逆に途中追加した場合のキャッシュミスを汚染なんて言ってるけど
それこそ現代の多段キャッシュアーキテクチャを甘く見すぎてる。そりゃ容量を超えるような操作を行えばメインメモリに取りに行くけど、言うまでもないがリンクリストの要素の先はメインメモリー散らばってる。
それがキャッシュされるとしてもCPUのキャッシュは1Byteとか8Byteをキャッシュするものじゃなく1キャッシュブロックで連続するメモリーをk単位でキャッシュする。
StrousutupのC++は明らかに欠陥言語だが、それとデーター構造の理解は別の問題。 コンピュータの速度は加重平均なんていう単純なもんではない
すべてがキャッシュに乗るなら一番早く動くが、メインメモリを頻繁にアクセスするなら100倍遅くなる。メインメモリにさえ載りきらないデータを扱いHDDならそこからさらに1000倍遅い。
だがキャッシュの容量しかデータを扱えないプログラムは役に立たたないし、Swapしまくりのプログラムは実用に耐えない。
まだLinkedListを擁護する人が多いのは、欧米のように日本のプログラマーは文系や高卒がやり、明らかにまともに計算機科学というものを受けていないからだ
Rustこそ欧州主体で行われている計算機科学にあまり即してない、FORTRANみたいな米国主導のLinkedListのような産物

935 :デフォルトの名無しさん:2022/12/09(金) 02:35:24.01 ID:wDDTmzGU.net
なんだかRubyガイジみたいな論法だよな
Rubyでできることはすばらしいこと
Rubyでできないことは必要ないこと

いや必要あるか、使うかどうかは検討の上こっちが決めるんで😅

936 :デフォルトの名無しさん:2022/12/09(金) 08:53:27.93 ID:eLXAv6sJ.net
関数型のElixir は、先頭だけに追加できる片方向リストで、
データが変更されない・immutable だから、バグらない

x = a-b の時に、
先頭に、c を追加して、y = c-a-b となった時に、
a-bの部分が変更されないので、x, y 両方で再利用できる

937 :デフォルトの名無しさん:2022/12/09(金) 09:23:54.41 ID:Bd/06DhF.net
>>934
絶対ネタで書いてるだろw

938 :デフォルトの名無しさん:2022/12/09(金) 13:50:41.90 ID:3DNXTGzR.net
>>934
CPUにおいて、基本的に cache block と cache line は同じ意味だが、
https://stackoverflow.com/questions/14707803/line-size-of-l1-and-l2-caches
のように、Intel CPUにおけるcache lineの大きさは 64バイト。
先読み機能が有るので、少し先まで読むことがあるが、
1KBみたいに大きくは無い。

939 :デフォルトの名無しさん:2022/12/09(金) 13:58:22.82 ID:3DNXTGzR.net
>>934
コンピュータ科学ではむしろ、LinkedListがArrayListより速いことがあることを学ぶ。

940 :デフォルトの名無しさん:2022/12/09(金) 14:00:08.53 ID:3DNXTGzR.net
>>934
>言うまでもないがリンクリストの要素の先はメインメモリー散らばってる。
現実的な使用法では、バースト的になっていて、散らばってない。
散らばっていると思っている人が現実を知らない机上の空論家だと言っている。

941 :デフォルトの名無しさん:2022/12/09(金) 14:03:46.44 ID:3DNXTGzR.net
>>940
[補足]
バース的で無い場合においても、非常に近いアドレスになっていることが多い。
例えば、ノードを削除してから追加すると、最後に削除されたアドレスが再利用されるから、
データ列を加工する場合にはキャッシュがとても強く働く。
また、ソートにおいてもノードの繋ぎ方を変えるだけだから、コピーはおろか、
ムーブすら発生せず、要素Tのバイト数sizeof(T)が十分大きい場合は、
std::vectorより速い。

942 :デフォルトの名無しさん:2022/12/09(金) 14:08:27.79 ID:3DNXTGzR.net
>>934
>コンピュータの速度は加重平均なんていう単純なもんではない
加重平均である事と、単純である事は同じことでは無い。
単純ではないが、加重平均である。
実行時間 T = Σ_i w_i T_i
w_i = 処理 i に対する重みパラメータ
T_i = 処理 i に掛かる時間

w_i は、経験を積まないとわからなくて、机上の空論家はこれを誤って見積もる。
偉いとされる先生を筆頭とした「象牙の塔」の集団幻覚の様な現象が起きる。

943 :デフォルトの名無しさん:2022/12/09(金) 14:13:39.03 ID:3DNXTGzR.net
>>941
[さらに補足]
・ノードを削除してから追加する--->malloc や new が、直近に
 削除したノードのアドレスを再利用されるのでキャッシュが良く効く。
・削除したノードのメモリ・ブロックが全部使われた場合、
 malloc や new がHeapやOSから新しくアドレスを確保してくる -->
 OSは後続の連続アドレスを返してくるので、アドレスはほぼ連続
 するので、キャッシュが良く効く。

故に、実際的な使用においては、LinkedListはキャッシュがよく効く。
 
 

944 :デフォルトの名無しさん:2022/12/09(金) 14:18:24.24 ID:3DNXTGzR.net
たとえば、馬鹿な人は、通信経路においてのエラーは「ランダムに起きる」から、
「本当にランダム」のケースを脳内で勝手に想像して、
「CRC符合は一般には役に立たない」
と結論付けてしまうかも知れないが、それは机上の空論で、
実際のエラーはバースト的に起きるから、CRC符合は非常に強力に働く。
それと同様にLinkedListもキャッシュが良く効く。
なぜならノードのアドレスが「ランダム」ではないから。

945 :デフォルトの名無しさん:2022/12/09(金) 15:08:04.74 ID:gsPXBpPV.net
どっちもヤバくて草w

946 :デフォルトの名無しさん:2022/12/09(金) 16:41:02.60 ID:WiULU0Bz.net
自己完結すれば最速で完結するが
机上で完結しないことを望むなら呪術的な対価を要求されるんだよ

947 :デフォルトの名無しさん:2022/12/09(金) 17:13:50.21 ID:TeKO8AU2.net
>自己完結すれば最速で完結する
アタオカの巣窟になりつつあるな

948 :デフォルトの名無しさん:2022/12/09(金) 18:30:00.75 ID:rq1aZYl+.net
絶対にベンチマークの数値は出せないリンクリストおじさん
いつまでrustに粘着してんの

949 :デフォルトの名無しさん:2022/12/09(金) 21:16:01.37 ID:o+3mnUPM.net
馬鹿は想像力が無いから、理論から計算できない上に、仮定も間違っているから
間違った条件で実験して間違った実験結果を出して、それを信じてしまう。
Stroustrup氏もその一部。

950 :デフォルトの名無しさん:2022/12/09(金) 21:33:34.50 ID:o+3mnUPM.net
>>949
そんな馬鹿でも実際にプログラムしてる人は自分の間違いに気付くが、
彼と彼の取り巻き達はベンチマーク以外のプログラムはしないので
一生気付かない。そして自分達は実験したから正しいんだと主張し
まくって、それを信じた人類は謝った認識を持って文明の発達が遅れる。

951 :デフォルトの名無しさん:2022/12/09(金) 22:18:43.15 ID:STy7gq1K.net
真面目に言うならStroustrupの指摘したリンクリストは、愚直で安直な1要素で次を示すようなデータ構造はバカのすることで間違いない。
というかStroustrupはプログラマのために教え諭してるのに対して、自分が攻撃されたと思い込み、稀なケースで「LinkedListがArrayListより速いことがある」なんていい年してイキっててもしょうもないだろう?
「非常に近いアドレス」とか自分で参照効率が悪いことを理解してるのに、何がしたいのかサッパリわからん。ぴろゆきみたいに見えない仮想的にロンパーしたいの?
https://www.youtube.com/watch?v=YQs6IC-vgmo

ま、今ではUnrolled Linked listとか普通の配列やB-Treeなどと区別がつかない参照の局所性が大幅に向上しているものもあるから
そんなことで騒ぐのはもはやジジイの域だなあ、10年前の出来事じゃん・・・・

952 :デフォルトの名無しさん:2022/12/09(金) 22:39:25.91 ID:rOm/uTcN.net
ジジイと言うかその人は
1) 頭が悪くて
2) 経験もなくて
3) その自覚が無い
というかわいそうな存在だからあんま刺激しちゃダメ
こうなってくるとこの手のひとは
あとは粘着するだけのマシンと化すから要注意だぞみんな

953 :デフォルトの名無しさん:2022/12/10(土) 00:05:08.23 ID:s9w4cjy9.net
自己完結は悪と思ってるから他者に粘着するんでしょ

954 :デフォルトの名無しさん:2022/12/10(土) 01:32:53.73 ID:ExYz252Q.net
コンピュータサイエンスやプログラミング関連の学者は、アホばっかだからな。

955 :デフォルトの名無しさん:2022/12/10(土) 01:33:28.16 ID:CrLmIOQg.net
Rustではポインタの代わりに要素のインデックスで管理するのが基本であり安全
リストもツリーもグラフもこれで実装可能
これはポインタがない言語では当たり前のように使われていた方式
これまでが間違ってた
ポインタなどというものは数百万行とかあるプログラムで正しく使うのは無理
世界中のエンジニアがそのために苦労している
ポインタとNULLは完全に失敗

956 :デフォルトの名無しさん:2022/12/10(土) 01:36:13.33 ID:CrLmIOQg.net
ちなみにインデックス管理がゴミだったのはCみたいに配列の要素チェックがなく
生アドレスを直接触れる仕様だったせい
本来この仕様があり得ない
これならポインタの方がマシだし楽だからという理由でポインタが乱用されてきた

957 :デフォルトの名無しさん:2022/12/10(土) 01:42:29.86 ID:ExYz252Q.net
>>951
その動画のジジイはまさに馬鹿。
老害。

958 :デフォルトの名無しさん:2022/12/10(土) 01:44:30.98 ID:ExYz252Q.net
アメリカのコンピュータ学者は馬鹿。
自ら馬鹿な方法ばかり想定しているから遅いと思い込んでいる。
それを鵜呑みにしてる学生は大ばか者。

959 :デフォルトの名無しさん:2022/12/10(土) 01:46:18.37 ID:ExYz252Q.net
だからアメリカ人の作るソフトは遅い上にサイズも大きいんだな。
日本人の作るソフトはコードも小さいし、データも小さいし、速度も速い。
全然違う。
なぜなら、アメリカ人がイマジネーションが足りなくて馬鹿なのに自覚が無いから。
なのに、詐欺的手法によってアメリカ製ソフトを蔓延させた。

960 :デフォルトの名無しさん:2022/12/10(土) 01:47:54.33 ID:48CeiLls.net
ポインタてのは、CPUの汎用レジスタの
アドレッシングモードを考慮して
OSをコーディングしやすくする仕組みだから

961 :デフォルトの名無しさん:2022/12/10(土) 01:51:53.77 ID:ExYz252Q.net
>>957
おっと、こいつが、Stroustrup氏だったのか。
どうりでデタラメな事言ってると思った。まさに、彼が自書で言ってる通りの内容。
この人は計算量などを考えるイマジネーションが不足している。

962 :デフォルトの名無しさん:2022/12/10(土) 02:00:02.88 ID:ExYz252Q.net
仮に、彼の間違った仮定であるところの、リンクリストのノードのアドレスが
ランダムに近い状態だったとして(それ自体がウソの仮定なのだが)も、
キャッシュペナルティーは、一回当り20クロックほどだ。
だから、この場合、次のノードに移るのに20クロック掛かることになる。
しかし、それでも、ノード数がNの場合に、20*N クロックほどで済むから
そんなに致命的ではない。Nを100倍しても、100倍の時間がかかるだけで、
大した増加ではない。
一方、std::vectorの場合、挿入や削除一回当り、O(N)の時間が掛かるから、
N回それを繰り返すと、O(N^2)の時間が掛かる。
これは致命的で、Nを100倍すると、1万倍の時間になってしまう。
Stroustrup氏は、オーダーの考え方が経験的に身についてない。

963 :デフォルトの名無しさん:2022/12/10(土) 02:06:32.68 ID:ExYz252Q.net
>>962
[補足]
CPUの速度はこの30年間で、1コアあたりに限定しても300倍以上になっている。
良いアルゴリズムを使えば、扱うデータも300倍に増やすことが出来る。
ところが、std::vetcorを使った挿入や削除を行なっていた場合、300*300=9万倍
にクロック数が増えるから、CPUの速度がせっかく300倍になっても、300倍の
時間が掛かることになる。
一方、std::listを使った挿入や削除を行なっていた場合には、クロック数が
300倍で済むから、CPUが300倍になったことにより、時間は昔のままで済む。
つまり、std::listの場合、CPUの速度が300倍になった現在、
データを300倍に増やしても、挿入や削除が昔と同じ時間で済むのに対し、
std::vectorは、同じことをするとなんと昔の300倍の時間が掛かるということだ。

こういう基本をstroustrup氏は理解出来て無い。
探索の時間は関係無い。探索しなければいいのだから。

964 :デフォルトの名無しさん:2022/12/10(土) 02:29:35.43 ID:ExYz252Q.net
>>951
>稀なケースで「LinkedListがArrayListより速いことがある」なんていい年してイキっててもしょうもないだろう?
稀ではない。
今はCPUが速くなりすぎて実感がわかないだけ。
だから、遅いCPUでトレーニングした方が良いと言われている。

965 :デフォルトの名無しさん:2022/12/10(土) 03:06:45.22 ID:EiHCMpy7.net
プロファイルでは粘着というより、論破された時の憂さ晴らし自演が延々と続くパターン
ID:Lb4jZ7zf = ID:pMPEGjtK = ID:3DNXTGzR = ID:ExYz252Q +α
今回は ID:Mw8qZqut だな

966 :デフォルトの名無しさん:2022/12/10(土) 08:26:05.03 ID:wI0qdr5j.net
CPUが早くなったんだからRustで多少遅くなっても大丈夫

967 :デフォルトの名無しさん:2022/12/10(土) 08:49:37.65 ID:pTzP7Jq7.net
Goも大丈夫

968 :デフォルトの名無しさん:2022/12/10(土) 08:52:02.51 ID:QB2FhiiS.net
>>965
ID:Mw8qZqut だけどこの人と同一人物判定されるのは不名誉すぎるからやめてくれ

969 :デフォルトの名無しさん:2022/12/10(土) 08:54:11.81 ID:5JJKT/6S.net
>>968
そうかな?流れ的には水増し論に決着して放り投げてるよ

970 :962:2022/12/10(土) 09:12:41.82 ID:pmPytGrf.net
誤解は避けたいからいちおう書いとく

> ジジイと言うかその人は

これはもちろん連投してる哀れなID:ExYz252Qのことね
C++やハゲに文句言うとか身の程知らずもいいとこやわ

971 :デフォルトの名無しさん:2022/12/10(土) 09:19:33.69 ID:5JJKT/6S.net
>>970
その人C++スレの自称天才でRustに傾倒していてChatGPT並みに尤もらしい適当をこいている人

972 :デフォルトの名無しさん:2022/12/10(土) 09:22:07.09 ID:5JJKT/6S.net
その人自演が大好きなので ID:Mw8qZqut だとしてもおかしくない

973 :デフォルトの名無しさん:2022/12/10(土) 09:25:57.47 ID:5JJKT/6S.net
流れ的には水増しの話が再開するはずなので、ID:Mw8qZqut = >>968がどう反応するか楽しみ

974 :デフォルトの名無しさん:2022/12/10(土) 09:30:48.75 ID:pmPytGrf.net
>>971
C++スレも荒らされてるのか
自称天才の粘着力すげえな

975 :デフォルトの名無しさん:2022/12/10(土) 11:09:35.00 ID:/zXB1Eur.net
C++ vs Rust Part4建てとく?

976 :デフォルトの名無しさん:2022/12/10(土) 12:35:14.53 ID:QB2FhiiS.net
>>973
Androidのソースコード量については、
* コンパイラはカウントされていない
* 外部の依存関係はカウントされているぽい
ということで、事実関係についてはだいたい確定したのでは

977 :デフォルトの名無しさん:2022/12/10(土) 13:03:40.38 ID:f/x7hc9i.net
>>976
横からですが、その回答だと、適切かどうかに関して、はぐらかそうとしているだけでは?
論理的に考えてC++でboostを使ってhello_asioとか書いたら、
そのレポジトリの行数にboostのソースもカウントするのが適切かどうかと照らし合わせて考えて見ては?

978 :デフォルトの名無しさん:2022/12/10(土) 13:23:37.96 ID:s9w4cjy9.net
行数の正確さを保証しているのは行数をカウントするアルゴリズムの質だよ
だから、質を保証するために量を根拠にするのはもう違和感しかない

979 :デフォルトの名無しさん:2022/12/10(土) 14:01:34.35 ID:aynhf3Gg.net
>>977
目的次第やろ

使ってるライブラリも含めてそのプログラムに含まれる脆弱性をカウントする際の分母として使いたいならboostのコードをカウントするのも一つの考え方

Googleが実際にどうカウントしたかは知らんけどRustとC++を異なる条件でカウントしてるんじゃなければここで何言っても無駄だよ

980 :デフォルトの名無しさん:2022/12/10(土) 14:17:34.56 ID:CrLmIOQg.net
糖質にかまうな

981 :デフォルトの名無しさん:2022/12/10(土) 14:23:19.49 ID:++bfMBzJ.net
盲目的に現状肯定する集団には見られたくないから言うけど
個人的には誤認する人が多発するから不適切だと思うよ

>目的次第
何の目的があって依存関係のソースもカンウトするのか、AndroidのRustチームの考えを知りたい

>>979
Androidがboost依存があって、boostソースがカウントされていない場合はどうなるの?
RustとC++を異なる条件でカウントしてる、に該当するよね

>>979がいう事が正しければ、新規ネイティブコード21%の下りでも依存関係ソースの増減も含めるのが同条件なんだよね?

982 :デフォルトの名無しさん:2022/12/10(土) 14:29:10.10 ID:++bfMBzJ.net
>>980
その発言で ID:CrLmIOQg の内容全部が地に落ちたよ

983 :デフォルトの名無しさん:2022/12/10(土) 15:17:06.99 ID:hJa6mCIB.net
>>981
仮に○○なら対等な条件の比較ではないという主張は真だと思うけど、
そもそもRustとC++が異なる条件で比較されてると考える根拠はなんかあるの?

984 :デフォルトの名無しさん:2022/12/10(土) 16:30:04.48 ID:/zXB1Eur.net
行数をカウントする目的:
利用状況の度合いをバカにも分かる数字で説明するため

依存関係を含めるのが適切か?:
数字を出すのが目的なのでどちらでもよい

985 :デフォルトの名無しさん:2022/12/10(土) 17:08:17.02 ID:+r0o6+3M.net
>>981
>何の目的があって依存関係のソースもカンウトするのか、AndroidのRustチームの考えを知りたい

Rustチームとかじゃなくセキュリティ監査をするチームが計測してるんだぞ
本当に計測方法の詳細や理由が知りたいなら記事書いた本人にTwitterとかで聞けばいいよ
この辺のエンジニアは普通に答えてくれるぞ

986 :デフォルトの名無しさん:2022/12/10(土) 17:13:44.96 ID:bYLLjzjY.net
>>970
>C++やハゲに文句言うとか身の程知らずもいいとこやわ
分かってはいたが、この板はレベル低いな。

987 :デフォルトの名無しさん:2022/12/10(土) 17:50:19.42 ID:8gOJz6B3.net
次スレは平和になりますように

988 :デフォルトの名無しさん:2022/12/10(土) 17:51:40.13 ID:s9w4cjy9.net
死者の数をカウントしてみろ、平和だぞ

989 :デフォルトの名無しさん:2022/12/10(土) 21:25:51.87 ID:AuQEELto.net
Androidドメインに限定したコードの量を測るよりも、Androidに搭載されうるコードの量を測る方が適切だと思うから外部ライブラリ含んでいいんじゃね。

990 :デフォルトの名無しさん:2022/12/10(土) 22:05:26.23 ID:s9w4cjy9.net
C,C++,Rustの三者は対等として、
C/C++とかいう概念はRustと対等か?

991 :2ch.net投稿限界:Over 1000 Thread
2ch.netからのレス数が1000に到達しました。

総レス数 991
270 KB
掲示板に戻る 全部 前100 次100 最新50
read.cgi ver.24052200