Rust part20

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 11/12 15:27 / Filesize : 289 KB / Number-of Response : 1017
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Rust part20

1 名前：デフォルトの名無しさん mailto:sage [2023/03/03(金) 00:45:28.73 ID:vTVY069B.net]: 公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

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

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part19
https://mevius.5ch.net/test/read.cgi/tech/1673926892/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/
2 名前：デフォルトの名無しさん mailto:sage [2023/03/03(金) 01:05:27.64 ID:5jfhiVlm.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 名前：デフォルトの名無しさん mailto:sage [2023/03/03(金) 01:09:18.66 ID:5jfhiVlm.net]: Rust Reference Book
https://doc.rust-lang.org/reference/
Rust Standard Library
https://doc.rust-lang.org/st
4 名前：d/ 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 macro Book https://danielkeep.github.io/tlborm/book/ Rust CLI (Command Line Interface) apps Book https://rust-cli.github.io/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 []: [ここ壊れてます]
5 名前：デフォルトの名無しさん mailto:sage [2023/03/03(金) 02:38:11.23 ID:g7UDV3mc.net]: >>2,3
それ追加すんなって
公式見ないで質問するようなやつが増えるだけから
6 名前：デフォルトの名無しさん mailto:sage [2023/03/03(金) 04:50:59.80 ID:5+VE8dsn.net]: >>4
マクロとデザインパターン以外は全て公式とその日本語版じゃね？
7 名前：デフォルトの名無しさん mailto:sage [2023/03/03(金) 06:29:29.67 ID:3EPD3050.net]: 質問はChatGPTにどうぞ

ってやればいいか
8 名前：デフォルトの名無しさん mailto:sage [2023/03/03(金) 10:06:00.63 ID:EsJwG25J.net]: >>4
ゴミ日本語訳に誘導したくて仕方がない関係者だろな
9 名前：デフォルトの名無しさん mailto:sage [2023/03/03(金) 11:36:41.01 ID:JQSTwLJ6.net]: >>7
複製オジが関係者なのか！！
だとしたらあの日本語品質は納得
近寄ったらダメなやつだな
10 名前：デフォルトの名無しさん mailto:sage [2023/03/03(金) 11:57:20.14 ID:BFvq14eB.net]: 日本語訳は2年近く前のThe Bookをもとにしてるにも関わらず
約1年前の1.58時点のThe Bookをもとにしてるかのようにミスリードしてるのが悪質
倫理観が欠如してるとしか思えない
11 名前：デフォルトの名無しさん mailto:sage [2023/03/03(金) 21:55:56.58 ID:6WvBOcY6.net]: あちゃーまじかー
技術スキルも日本語能力もないやつにやらせんなよ
12 名前：デフォルトの名無しさん mailto:sage [2023/03/03(金) 21:59:35.11 ID:IWtB3OsL.net]: Rust公式でもJP公式でも他の有志翻訳ページでも
もし本当にヤバいミスがあるなら正しい情報をそれぞれに出すのがいいんじゃないか
それで直らないなら新たなサイトを作るとか新たな言語を作るしかない
これらでない言いがかりをつけるだけの荒らし行為はやめとけ
13 名前：デフォルトの名無しさん mailto:sage [2023/03/03(金) 23:16:10.01 ID:wWtECe2y.net]: 所有権複製おじさんも仮の所有権おじさんも日本語訳が生み出したものだと思ってたが因果関係が逆なら根本原因は明らかだね
14 名前：デフォルトの名無しさん mailto:sage [2023/03/03(金) 23:34:12.09 ID:WGG+yJpD.net]: >>11
JP公式って何の公式なん？
日本ユニセフ協会はUNICEF公式みたいな？
15 名前：デフォルトの名無しさん mailto:sage [2023/03/04(土) 00:17:04.01 ID:73wkOS2W.net]: >>13
その例でいくと日本ユニセフ協会公式ってことだろ
略してJP公式
16 名前：デフォルトの名無しさん mailto:sage [2023/03/04(土) 13:59:40.63 ID:VYEasP1j.net]: https://github.com/rust-lang-ja/book-ja/tree/master-ja/src
の更新日がバラバラだからな
title-pageだけ更新したから>>9みたいになってる
一旦全部AI翻訳にかけた方が早いかもしれない
17 名前：デフォルトの名無しさん mailto:sage [2023/03/04(土) 14:18:14.66 ID:u2BMKDBQ.net]: 本家に追従しきれないよりは機械翻訳のほうがマシだけど
可能ならちゃんとした技能のある人が翻訳するに越したことはないのも確かなんだよなー。
18 名前：デフォルトの名無しさん mailto:sage [2023/03/04(土) 18:04:28.01 ID:LDufCtSs.net]: 翻訳やってる人の言葉使いが複オジとそっくりだから本人っぽいな
19 名前：デフォルトの名無しさん mailto:sage [2023/03/04(土) 23:12:51.88 ID:zScYEmg5.net]: いつ時点のものを訳したのかさえ管理できてないって翻訳プロジェクトとしてはもう終わってんね
そんなのよりThis Week in Rustみたいな役立つリンクをテンプレに入れた方がいい
20 名前：デフォルトの名無しさん mailto:sage [2023/03/05(日) 08:10:28.29 ID:Eop1iDrL.net]: https://gihyo.jp/article/2023/03/tfen009-rust_progress
let-elseも1.65から利用可能になり、if let構文（例：if let Some(b) = a {} else {}）をlet Some(b) = a else {}と書けるようになりました。
この変更により、ネストが減ってコードの見た目がスッキリしたり、処理の流れが読みやすくなったりというメリットを享受できるようになります。
先日let-elseを使いたくなったので、チームでRustのバージョンを1.65に上げて、これからはlet-elseに変えられるところは変えていこう、ということになりました。
21 名前：デフォルトの名無しさん mailto:sage [2023/03/05(日) 12:20:05.12 ID:NLajm9a+.net]: いつも常駐してるオジサンがダンマリ決め込んでるところを見ると
JP公式==複オジ説は本当なんだな
最悪
22 名前：デフォルトの名無しさん mailto:sage [2023/03/05(日) 15:24:37.63 ID:78Ic7w+o.net]: どこかのおじさんが自称公式を名乗っていようが正直どうでもいい
このスレ的にはあそこの日本語訳は害が大きいので必ず公式ドキュメント(英語)を参照することを>>1に入れておけばそれで十分
23 名前：デフォルトの名無しさん mailto:sage [2023/03/05(日) 15:43:27.49 ID:T9VmDwru.net]: ここまで複オジの戯言
24 名前：デフォルトの名無しさん mailto:sage [2023/03/05(日) 16:04:09.72 ID:k8KjXA8F.net]: >>21
それでいいんじゃね
実際前スレ前々スレとそれで良かったわけだから
25 名前：デフォルトの名無しさん mailto:sage [2023/03/05(日) 18:09:02.89 ID:LJW1dSxX.net]: >>20
隔離スレには出没してるからそういうことなんだろう
26 名前：デフォルトの名無しさん [2023/03/07(火) 11:59:08.95 ID:808C7eOs.net]: メモリが足んなくて、FP16とかBF16とかに興味が出てきたんだけどさ
https://docs.rs/half/latest/half/struct.bf16.html
こういうのをx64系のCPUで使うと、FP32の場合より(SIMDがバシッと効く場合を除いて)どんぐらい遅くなるもんなの？
27 名前：デフォルトの名無しさん mailto:sage [2023/03/07(火) 15:51:39.46 ID:n6pI5I+D.net]: >>21
公式があの日本語訳は非公式翻訳版ですよとちゃんと明記したからあれを公式翻訳かのように言ってたあのおじさんは無視でOK
https://www.rust-lang.org/ja/learn
28 名前：デフォルトの名無しさん mailto:sage [2023/03/07(火) 17:36:45.89 ID:foOMuD7h.net]: 単精度のときに全部L1に乗るなら0.6倍、そうでないなら半精度のほうが早くなる模様
https://www.isus.jp/others/half-precision-floats/
29 名前：デフォルトの名無しさん mailto:sage [2023/03/07(火) 17:39:18.38 ID:j2LIvzFC.net]: おじさんの個人ブログ&リンク集を
JP公式などと呼称するのがそもそもの間違いなんだよな
わかってる人は訪れてもそっ閉じするだけなので
初心者向けの注意喚起だけ書いておけばいいよ
30 名前：デフォルトの名無しさん mailto:sage [2023/03/07(火) 17:47:17.93 ID:I20MXGms.net]: なんでIDコロコロするの？
31 名前：デフォルトの名無しさん mailto:sage [2023/03/07(火) 19:42:26.18 ID:NkW3dTMM.net]: >>26
どこにその記載あるの？
32 名前：デフォルトの名無しさん mailto:sage [2023/03/07(火) 19:48:30.54 ID:NkW3dTMM.net]: >>30
と思ったらリンクに「非公式」とあるだけで、否定しているわけじゃないんだな。中国語とかと同じじゃない？

そもそもリンクある時点で「公式の推奨」的な位置づけになってるんじゃないのかね。
33 名前：デフォルトの名無しさん mailto:sage [2023/03/07(火) 20:33:26.94 ID:/0bgQhyZ.net]: >>27
大きなデータ処理でL3キャッシュに乗らない時は半精度を使ったほうが単精度の1.6倍速くなるわけか

>>31
日本語版へのリンクを本家が貼って推奨してるようにみえる
34 名前：デフォルトの名無しさん mailto:sage [2023/03/07(火) 21:12:05.81 ID:I20MXGms.net]: 推奨も非推奨もしていない書き方だと思うけど、どうやったら推奨してるように見えるんです？
35 名前：デフォルトの名無しさん mailto:sage [2023/03/07(火) 21:24:18.71 ID:/0bgQhyZ.net]: >>33
本家がフランス語版や中国語版など各言語に応じてその言語版へのリンクを貼っている
非推奨ならばリンクを貼ることはない
36 名前：デフォルトの名無しさん mailto:sage [2023/03/07(火) 21:29:32.54 ID:YzY/wVtd.net]: 日本語コミュニティの中心的な人物は本家コミュニティでも活動してる。
推奨もクソもないんよ。同じ人が日本語でも英語でも議論や発信してるってだけなんだから。

でも本家コミュニティのほとんどの人は日本語なんて知らんのだから翻訳の質にお墨付きを与えられる立場でもない。
本家コミュニティの中に日本語コミュニティへの橋渡し役がいるから
日本語コミュニティの拠点だと認識しているところにリンクしてるんだわ。

リンクは質についての保証ではなく活動実態がある (と本家コミュニティが認識している) という保証なんだわ。
37 名前：デフォルトの名無しさん mailto:sage [2023/03/07(火) 21:31:53.30 ID:I20MXGms.net]: >>34
リンクが貼ってあるから推奨ってのはなんとも面白い解釈だね
38 名前：デフォルトの名無しさん mailto:sage [2023/03/07(火) 22:07:18.53 ID:nFWrM4z5.net]: >>980
次のテンプレにこれをいれとけ

「The Book非公式翻訳版について」
The Bookには有志による非公式な日本語翻訳版が存在しますが
日本語訳の品質に問題があるとの声が多いことや
数年以上前の古いThe Bookの翻訳となっておりアクティブな更新が行われていないことから
混乱を避けるために当スレでThe Bookを参照する場合は非公式翻訳版ではなく必ず公式のThe Book(英語)を参照するようにして下さい
39 名前：デフォルトの名無しさん mailto:sage [2023/03/07(火) 22:33:00.74 ID:xkCydgep.net]: >>37
いいね
改行はもう少し揃えたほうが読みやすいとは思う
40 名前：デフォルトの名無しさん mailto:sage [2023/03/07(火) 22:42:05.39 ID:bUqVPH8L.net]: >>37
そんなバカなアンチ活動みたいなことはやめとけ
その唯一の日本語版にもし致命的な間違いが仮にあるとすれば直せばいいだけじゃないのか？
おそらく間接的な協力も直接的な協力のどちらもできるだろう
41 名前：デフォルトの名無しさん mailto:sage [2023/03/07(火) 23:23:41.62 ID:/0bgQhyZ.net]: 改善すべき点があるならば改善する方向へ動くのが良いと思う
42 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 07:09:44.47 ID:/qygPgTx.net]: >>39
なんでそんなにセンシティブになってるの？
43 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 07:14:43.18 ID:9h+oJZcX.net]: >>37はいつものRustの足を引っ張るアンチっぽい
44 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 07:54:43.28 ID:STUjH1uW.net]: 本気でなにか変えたいならGitHubなり公式フォーラムなりで活動すればいいわけで
ここで文句言ってるだけってことは単に言いたいだけなんだろう
45 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 08:08:57.29 ID:vHYmPy/j.net]: >>41
足の引っ張り合いがコミュニティーを殺すから。
否定だけして改善しない無能がはびこると誰もコミュニティーに貢献しなくなる。
46 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 08:31:57.93 ID:OMAPV4fU.net]: >>37
数年以上前の古い翻訳との指摘は勘違いかあるいは意図的なガセか？
英語版が2021 Edition対応になったときに
日本語版もその2021 Edition対応になっていて特に問題ないようだが
47 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 10:39:24.48 ID:FNKYRc64.net]: 一人だけ必死オジねww
48 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 11:13:15.11 ID:PxKx6CUr.net]: >>45
それ以降更新されてなければ数年以上前の古い翻訳で間違いないね
49 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 11:25:12.41 ID:l8ZbUL/a.net]: 「数年以上前の古い翻訳」は更新があれば嘘になっちゃうから
更新状況の確認方法を挙げて確認を促すことができればそれがよいね
50 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 12:03:18.15 ID:YxWGdUuX.net]: >>36
本家が「紹介する価値がある」と判断したからリンクしているのであって、一般的な感覚としては推奨の範疇に入るんだけど。
少なくとも読み手はそう考える。
51 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 12:09:51.90 ID:WGL5Sjj5.net]: >>37の「数年以上前の古いThe Bookの翻訳」で正しい
翻訳の元になっているThe Bookが古いということ
52 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 12:24:02.51 ID:fO6VixLz.net]: >>37
ウソでしょ
日本語版を見に行ったら最初に2022年と書いてあるよ
数年以上前ってなんのこと
53 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 12:26:44.45 ID:W3VafHEB.net]: 関係者にも関わらず
それを明かさず必死擁護してると
ステマ規制で罪に問われるよ
54 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 12:28:09.23 ID:AVy9425f.net]: >>49
読み手っていうか君がそう感じてるだけでしょ？
真に推奨ならば「THE BOOKを読もう！」のリンク先が日本語版になってるよ
だから公式としては推奨も非推奨もしていない、案内だけしてるという状態
55 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 12:35:05.90 ID:YsAFI89D.net]: >>51
非公式翻訳版は公式のどのブランチのどのコミットバージョンをもとにしてるのかな？
どこに記載されてるののかな？
56 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 12:38:42.68 ID:bQZD4wXW.net]: >>51
2022はさすがに嘘だろ
もっと前に変更されてた内容がが日本語版では古いままだったのが数スレ前に出てだぞ
あれから更新された気配はない
57 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 12:46:44.11 ID:zFvjdLUz.net]: 必死オジのわざとらしいミスリードだろ

翻訳版がもとにしているThe Bookのバージョンが古いままという指摘に対して
非公式翻訳版を見たら2022年と書いてたよーだもんwww
58 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 12:57:34.44 ID:YxWGdUuX.net]: >>53
それも君がそう感じてるだけでしょ？

特別に案内している唯一の和訳なのに推奨していないとか、日本語圏の読み手を騙そうとしているとしか思えないね。
59 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 13:00:40.45 ID:AVy9425f.net]: >>57
推奨も非推奨もしていないと推奨していないは別なんですが...
60 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 13:32:34.88 ID:lVG18cq8.net]: 今気付いたけど本家のThe Bookから正式に日本語版を含む各言語版のレポジトリへリンクが張られてるんだね
https://doc.rust-lang.org/book/appendix-06-translation.html

日本語版の各セクションの更新日を見てみたら
https://github.com/rust-lang-ja/book-ja/tree/master-ja/src
数ヶ月前がいくつかあるから更新されてるんじゃない？
61 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 14:23:51.90 ID:GIrZN4Te.net]: 複オジは非公式翻訳を
公式からリンクされてるという理由で
公式な日本語訳と偽っていた罪を償うのが先

嘘つきの言うことは誰も信用しない
62 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 14:28:59.70 ID:MGmZ5+PV.net]: >>59
で？
翻訳のもとになってる公式The Bookがいつ時点のものなのかがわからないなら無意味
63 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 14:38:17.99 ID:k26S3184.net]: 評判の悪い日本語訳で勉強するより公式でやったほうがいいのは当然だよな
反対する理由は見当たらない
64 名前：デフォルトの名無しさん [2023/03/08(水) 14:49:29.41 ID:yw6CL/M8.net]: >>59
二つの問題が一気に片付いたな
日本語版は公認されている
日本語版は更新されている
65 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 15:29:08.93 ID:xMERxfms.net]: 非公式おじさん涙目ワロw
66 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 17:16:33.70 ID:YxWGdUuX.net]: 結局、足を引っ張るだけの無能は口だけ番長ということでいいのかね。

githubの日本語訳リポジトリに改善版のプルリクエスト出して貢献すりゃいいのに。
67 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 17:43:46.69 ID:VNQhgWjd.net]: >>37
わかりやすくていいと思う
内容がすでに古くなっていることに気付かずに利用する人がこのスレでも結構いたからね
そういう人達がテンプレを読むとは限らないけど注意書きは絶対あったほうがいいと思う
68 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 17:49:07.09 ID:WJ2h17EM.net]: まだ件のAIで翻訳は無理なのか
69 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 18:03:44.14 ID:dhvL467/.net]: なんか頑張って擁護してる人は日本語版が古くないっていう根拠全く示せてないよね？
70 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 18:11:20.27 ID:K08tGqYA.net]: 事実を書くと足を引っ張るだけの無能になるらしい
GitHub のリポジトリに Issue も PR もいくつかあるけど放置されてるじゃん
71 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 18:21:29.08 ID:DM+uPewN.net]: >>37の案でok
日本語版の問題点の話ばっかりでこれ以上スレ消費しても仕方ない気がする
72 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 18:27:52.80 ID:BrWt4HZU.net]: >>69
放置されてるね～
これもしかしてメンテナ兼レビュワー1人体制？
73 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 19:27:32.79 ID:mW0hpgEv.net]: >>69
ならメンテナに立候補すりゃいいんじゃない？
74 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 20:56:54.94 ID:+7TMvH3q.net]: もしかしてメンテナご本人？
75 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 22:28:52.95 ID:cNf5UxLu.net]: 日本語版に問題がある
→じゃお前がPR送れ
IssueもPRも放置されてる
→じゃお前がメンテナやれ

なんなのこれ
こんなのが関係者にいるんなら改善される見込みゼロでしょ
76 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 22:29:48.23 ID:RPZ0ODVG.net]: ここの皆Rust大好きな筈なのに日本語コミュニティに貢献の痕跡がないってやばない？
77 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 23:02:50.55 ID:ijMIMHq8.net]: 非公式日本語翻訳には手を出さないよう
積極的に初心者を啓蒙するのが
日本のRustコミュニティにとっての最善手
78 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 00:46:37.28 ID:ehuwCZc+.net]: >>75
今や匿名じゃないと困っちゃう人の巣窟ですからね
79 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 01:16:43.58 ID:Z9xocO1d.net]: 常駐してるアンチRustによる妨害連投だろ
何でも文句をつけてRustの足を引っ張ることが目的
日本語版の件も同じ
80 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 02:21:45.87 ID:ehuwCZc+.net]: そして>>69に戻る
81 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 08:46:28.38 ID:NWRX1mim.net]: >>78
どう見てもあなたの方が常駐してるアンチですよ
何の貢献もせずRustコミュニティの足引っ張るのやめてもらえます？
82 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 09:02:51.43 ID:3zbp+azX.net]: Rustアンチを見分けるのは簡単
今までどの話でも「改善案や代替案を出したり協力したり」せずに「批判したり言いがかりをつけたり潰そうとしたりする」

今回の話も同様
もし仮に具体的に深刻な問題があるならば改善する方向へ動けばよいだけの話
83 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 09:14:52.26 ID:bx/t5YIt.net]: >>37の具体的なテンプレ改善案に対して
>>39のように最初からヒステリックなレッテル貼りをして理性的な反論をしないあなたは間違いなくアンチですね

簡単に見分けられます
84 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 09:20:15.59 ID:0a1GOjgJ.net]: > 「批判したり言いがかりをつけたり潰そうとしたりする」
確かに日本語版の問題点が指摘されると
とにかく言いがかりをつけて潰そうとする人がいるね
85 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 09:27:52.51 ID:pceol7Cc.net]: 誤訳も放置
イシューも放置
プルリク来るけど知らんぷり

文句言うな
お前がやれ
今日も5chをぐーるぐる

オラこんなリポいやだ
オラこんなリポいやだ
86 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 09:41:16.94 ID:cLGdo+Dg.net]: >>83
問題点を指摘するだけでもコミュニティに対する立派な貢献なのにな
それを必死に潰そうとするやつこそアンチだわな
87 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 09:41:31.57 ID:5eT48dzr.net]: 本家にある程度追いついてて誤訳があるとか未訳があるなら貢献しやすいけどそうじゃないからなぁ
まずはそこまでメンテナー側でやってくれたら貢献する人も現れるんじゃない？
88 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 09:42:37.79 ID:ch2FekEs.net]: >>84
草
89 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 09:51:30.09 ID:MrYHSR72.net]: Rustアンチは具体的に日本語版Bookのどの章のどの節にどういう問題があって改善案がどうなのかを言えない
RustアンチはRustやその普及を潰すことだけを目標にしている
90 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 09:56:19.19 ID:5eT48dzr.net]: >>88
>>86で言ってるやんけ
github.com/rust-lang/book/graphs/commit-activity
github.com/rust-lang-ja/book-ja/graphs/commit-activity

これ見りゃ分かるけど本家の更新が全然入ってないのよ
改善案としては>>86に書いた通りか、リポジトリをアーカイブしてもう更新しないことをこれから見る人に通知するかがいいと思う
91 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 09:56:38.71 ID:bUyZbGMm.net]: >>85
ですよね
自分が経験した問題点を共有して後進の初心者に注意を促すような行為も十分立派な貢献
あとは受け手が内容を判断すればいいわけで
92 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 10:05:17.42 ID:DF6AT3du.net]: Rustコミュニティに貢献しても
非公式翻訳版の品質改善のために
PR出さずに批判するやつは全員アンチ扱い
93 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 10:07:21.23 ID:fiidGuJR.net]: >>89
オジ恥
94 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 10:20:37.62 ID:5eT48dzr.net]: >>92
事実に対して反論できず捨て台詞を吐くだけなら何も書かないほうがいいと思います
95 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 10:26:46.29 ID:0ZUHbZyh.net]: >>91
自分達がコミュニティ代表という選民意識だろうね

都合の悪い問題点を指摘されると>>82の言うようにヒステリックなレッテル貼りで言論封殺という行動に出ちゃうあたりは高市とそっくり

やってることはRustコミュニティに対するアンチ活動でしかないんだがこの手の人たちは自分たちの私欲が満たせればあとはどうでもいいんだろう
96 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 10:39:22.78 ID:JRh3xELi.net]: もしかしてforkしてブランチ切る程度のこともやってないわけ？
ちょっと信じられないんだが
97 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 10:45:17.46 ID:dzdLgXqT.net]: >>95
プルリク出しても無視されることが分かってるのに修正する気になるわけないじゃん
98 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 10:51:11.72 ID:tzQKIk8q.net]: 日本語版には問題があるから英語版を使ったほうがいいという意見に対して
批判するならイシューやプルリク出せというのは論点のすり替え
99 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 10:57:51.77 ID:Nh0+4dpq.net]: 日本語版を潰すことだけに力を入れてるのかー
マジでアンチじゃん
100 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 11:02:16.65 ID:ehuwCZc+.net]: 全員単発
応仁の乱
101 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 11:02:36.11 ID:5eT48dzr.net]: 問題点・改善点をあげてもアンチ乙で片付けられるんだから無敵だな
102 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 11:36:59.36 ID:I6UUv7Kk.net]: >>96
そういう意味じゃない
翻訳プロジェクトが英語版リポジトリをforkしたり翻訳用リポジトリに取り込んだりしてないのかという意味
103 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 11:41:54.63 ID:vunFCsf3.net]: まぁ実際のところ日本語版を読みたい初心者がこんなスレに来るわけないし
このスレのローカルルールとしては>>37でいいと思うけどな
もし日本語版を本気でどうにかしたい人がいるならその議論はzuilpなりGitHubのissueでやればいい
104 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 11:59:25.10 ID:IPNUA449.net]: >>101
なるほど
元々が fork じゃない形態をとってるからよく分からないんだよね
まぁこれは各言語版そうなってるっぽいけど
105 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 11:59:38.63 ID:Js3muVMH.net]: >>101
どっちもやってないみたいだぞ
信じられんよな
最低限のソース管理も碌にできない人が
俺のやることに文句を言うなとかどの口で言ってんだか
106 名前：96,103 mailto:sage [2023/03/09(木) 12:07:13.82 ID:NxdTjqu4.net]: もしもしはすぐID変わるからダメだな
これじゃIDコロコロするやつと変わんねぇよ
107 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 12:23:44.08 ID:WMBmvI2V.net]: >>102
日本語版を殲滅するようなローカルルールを決めるのはやり過ぎ
そこまでするのはRustのアンチと言われても仕方ないかな
108 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 12:53:07.30 ID:vunFCsf3.net]: >>106
単にこのスレでは取り扱わないってことでいいんじゃないかと思うけど
普通の初心者はこのスレ見る前にググればすぐにたどり着くんだし
109 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 13:38:49.60 ID:tfi/zejU.net]: >>102
同意
110 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 13:56:08.35 ID:qMTKidpI.net]: 5chの1スレで扱わなくなると殲滅されてしまうよう物なら
近いうちに自然淘汰されるだけだから
ここでは扱わないのが正解ということになる
111 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 14:02:00.14 ID:KrFX8l8a.net]: 傍から見てるだけだけどさ
わざわざ日本語版を排除しようというのはアンチにしか生じない動機・感情よね
112 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 14:10:10.57 ID:WYfWQgCO.net]: 不正確なもんは排除しとくほうがマシ
それを許して欲しいと言う甘えは通用しない
所有権の複製とかいう用語が世間で通用しないのと同じ
113 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 14:12:34.91 ID:za1QZKNx.net]: 更新が英語版のmainに追い付いたらテンプレに戻すという条件付き除外措置なら誰も文句無いですか？
114 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 14:13:47.86 ID:KrFX8l8a.net]: 日本語版で不正確なところはどこなの？
所有権？？
115 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 14:16:43.77 ID:lc0skjdv.net]: 総務省の公文書のことか
116 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 14:47:46.87 ID:WYfWQgCO.net]: Rustアンチっていう表現がそもそも疑問なんよね
単にここじゃあ複オジが馬鹿にされてたり
rust-jpに疑問が持たれてたりするだけであって
それがなぜだか
ある人にとっては「Rustアンチ」ってことにすり替わっちゃう
117 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 14:50:24.91 ID:TbSLyHqM.net]: >>110
これから始める人が不正確な物を見ないように配慮するのがアンチ行為になるんですか？

>>113
100レスちょっとしかないんだから頭から流し読みしてくればいいじゃん
118 名前：デフォルトの名無しさん [2023/03/09(木) 14:51:04.12 ID:yQuaEoeh.net]: cargoを使用していると、過去のクレートのキャッシュ？なのかなんなのかわからないものがどんどん溜まっていってしまいます
これって使い続けるとどこまでも増えていってしまうのですか？何か容量を抑える策はあるのでしょうか？
SSDがしょぼいので気になってしまいます
119 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 14:52:40.57 ID:5eT48dzr.net]: >>117
cargo clean
120 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 15:28:35.84 ID:SZrfwfYj.net]: 会話や議論のベースとするには信頼が置けないというのが最大の理由でしょ
だからこのスレでは信頼のおける公式The Bookを使うローカルルールにするというだけのこと

日本語版の問題箇所を一つ一つ具体的にあげて改善していくためのスレじゃないんだからそれをやりたい人は>>102が言うようにzuilpなりGitHubでやるのが適切
121 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 15:45:47.39 ID:hrQLf9QV.net]: アンチというレッテル貼りしてるだけの人の動機は何なんだろう？
122 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 15:53:09.08 ID:RjLT18Ud.net]: >>120
どうも日本語版のメンテしてる関係者らしいよ
こんなところで一日中書き込みしてるくらいなら
放置してるIssueやPRの対応すればいいのにね
123 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 16:11:36.62 ID:od/fqKtF.net]: バカが2人に増えたね
信者複製おじさんと謎のrust-jp陰謀論おじさん
地獄
124 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 18:38:23.80 ID:wqVFkatU.net]: Bookの日本語版を一通り読んでみたけど特に間違ったことはなさげ
訳語は一部意見割れるかもしれないけど不可はない感じ
ネット上の日本語のRust入門としてベストじゃないかな
125 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 18:53:24.39 ID:1oUy2fzR.net]: え、内容が古いことは無視ですか？
126 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 19:03:49.80 ID:wqVFkatU.net]: なにか古くて間違ってるようなことなかったと思うよ
127 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 20:59:36.65 ID:5eT48dzr.net]: >>125
古いっていうのは本家と比べてだから誤りがあるかどうかは別だよ
そして少なくとも Box 使用箇所でコンパイル通らないコードがそのままになってたりするよ
128 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 22:00:09.63 ID:TpJxaXq0.net]: >>126
具体的に間違い箇所がわかってるならissue立てたらいいんじゃない？
メンテナの人とやりとりしたことあるけど、間違ってるから優先して直してって言えば対応してくれると思う
129 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 22:25:18.34 ID:5eT48dzr.net]: >>127
Box 使用箇所は本家では直ってるところだからここだけ言ってもしょうがないよ

> 間違ってるから優先して直してって言えば対応してくれる
issue,pr は何個かあるけどどれも放置だから無駄だよ
130 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 22:28:14.00 ID:Qg5Vw7uS.net]: 日本語訳の話はもういいよ
>>37に同意しない人は1人だけで有効な反論は出なかったからここでの結論は出た
日本語訳の品質改善に取り組みたい人はそれ用のGithubかZulipへどうぞ
131 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 23:01:25.11 ID:bker4XmI.net]: じゃスルーしてたlet-else話でもするか
>>19のリンクに書いてあるlet-elseのリファクタリングってあり？
Afterでもダメってほどじゃないが俺はBeforeのほうがいいように思える

//Before
pub async fn close(&mut self) -> Result<()> {
if let Some(mut file) = self.file.take() {
debug!("File {} closed", self.filenam
132 名前：e()); file.flush().await?; } Ok(()) } //After pub async fn close(&mut self) -> Result<()> { let Some(mut file) = self.file.take() else { return Ok(()); }; debug!("File {} closed", self.filename()); file.flush().await } []: [ここ壊れてます]
133 名前：デフォルトの名無しさん mailto:sage [2023/03/09(木) 23:19:16.56 ID:17jElPHd.net]: >>37
ネットで読める日本語のRust入門のベストはThe Bookの日本語版です
そんなテンプレは理解できないので反対します

>>130
その長さと深さならどちらでも個人の好み次第でしょう
長く深くなるとlet elseが読みやすくて推奨かな
134 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 07:39:28.49 ID:eGAweG+/.net]: >>129
「日本語訳は最新版を取り込めていないところもあるから注意」くらいならまだしも、>>37は狭量で排他的だからだめ。
こんなのと同類扱いされたくない。
135 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 12:26:56.89 ID:5qa3scwI.net]: >>132
追記。
日本語訳を（forkするなりした）修正バージョンを作ってそちらに誘導する、というのならあり。ユーザーにとってより良い改善策になるし。
136 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 13:39:34.28 ID:YUaQrZ1H.net]: >>130
その2つならif letバージョンの方が読みやすいね
137 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 17:33:37.91 ID:THb1tZPF.net]: >>130
前者だな
Okでも違う値を返すようになったりネストが深くなったりした段階でリファクタリングを考慮すれば十分
その例ではtake、flush、dropの一連のつながりを切るほどのメリットが全くない
あと後者はfile.flush.await.into()にする必要があるかもしれない
138 名前：デフォルトの名無しさん [2023/03/10(金) 17:46:09.19 ID:Lf3CpR6K.net]: >>111
不正確なもんは排除しとくほうがマシ、と考えるのも自由だし、5chで主張するのも自由。
もちろんそれによって誰も何の影響も受けない。
139 名前：はちみつ餃子 ◆8X2XSCHEME mailto:sage [2023/03/10(金) 17:46:47.36 ID:wtzqTKjF.net]: >>130
私も前者だと思う。
見通しが特に悪くなるほど複雑な場合でないならやろうとしていることがそのままコードに表れているほうが良くて、
前者のほうが何をやろうとしているのかスッと読める感じがする。
140 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 18:03:17.42 ID:Qo+lY2qI.net]: >>130
if letとlet elseは場面に応じてどちらが向いているのか変わるから
その特定の例を比較してもなんの意味もないと思うが
一般的にif letが多段になるとその各else部分を先にlet elseで処理したほうが見やすくなる
一段でもif letの中が長くelse処理があって短いならばlet elseが見やすい

今回の>>130は返り値がResult<()>でelse処理が無い極めて特殊な例だから
当たり前のようにif letで良い
むしろそんな特殊な例を持ち出して議論することに意味がない
141 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 19:08:36.07 ID:HKUOk1Tv.net]: >>138
場面に応じてどちらが向いているのか変わるから場面がわかる特定の例で比較することに意味があるのでは？
142 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 19:13:36.55 ID:Qo+lY2qI.net]: >>139
返り値がResult<()>でelse時にErrではなくOk(())という極めて特殊な偏った例になんの意味があるんだ？
143 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 19:17:05.20 ID:ha1WEkSQ.net]: 意味の有る無しを断じるあたり幼稚やな
周り見てご覧
キミ以外はそんなとこに拘っとらんやろ？
144 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 19:36:05.08 ID:YsUJsRqF.net]: >>141
そのあたりも本質の一つじゃね？
まあ俺なら>>130のif letにelse節がないことも問題視するけどな
そんな例ならif letを使うのがいいと自明だから問う価値がない
>>130がアホ
145 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 19:40:18.95 ID:F+OjF9fC.net]: 好きな方使ってろバカども
前スレそれで使い潰してまだ反省してねえのか
146 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 20:24:59.10 ID:7c0jaWrI.net]: >>130
前者は表明を表していて、後者は処理の条件を表している。
基本的に関数全体の条件を明示したほうが関数を使う側にとって使いやすいので、前者のほうが望ましい。
147 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 21:43:27.35 ID:+jgRtbOv.net]: 現在のIT業界に「代替メモリレイアウト」という概念はありますか？
148 名前：130 mailto:sage [2023/03/10(金) 22:22:59.62 ID:IYh2ezPU.net]: >>130のコードは>>19のリンク先で「let-elseが便利すぎる」と銘打って紹介してたものなんだけど
let-elseを使う例としてはあまり適切な例ではないように感じたので他の人の意見を聞いてみたかった

理由はそれぞれ違うけどおおむね前者のほうがいいという意見が多くてスッキリした
ありがとう
149 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 22:39:57.98 ID:IYh2ezPU.net]: >>142
少なくとも>>19のリンク先ではif let Someでelse節が必要ない状況だからこそ
let-elseを使うケースとして>>130の例を紹介している
150 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 23:34:37.12 ID:/vLExm3P.net]: 好きにしたらええ
それより前スレ埋めない？
151 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 23: ]: [ここ壊れてます]
152 名前：46:20.34 ID:Ug/D0/8N.net mailto: >>145
「代替メモリレイアウト」という概念は聞いたことがないが悪魔の証明は無理なのでそういう概念がある可能性を完全に否定することはできない

非公式の日本語翻訳で使われてる用語みたいだけどこのスレで質問する際は公式のドキュメント(英語)を参照するようにしてね []: [ここ壊れてます]
153 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 23:54:51.68 ID:0dyEfhS9.net]: if letを使うかlet elseを使うかはケースバイケースでどちらもありうるのだから揉めるようなことではないと思うんだよな
let elseは要らないから削除せよ！と言ってた人はここを荒らすためだけに言ってただけだと思うし
154 名前：デフォルトの名無しさん mailto:sage [2023/03/11(土) 00:35:13.78 ID:fYMzQaF5.net]: >>150
ケースバイケースだからこそ具体的な特定のケースを例にどちらがいいかを話してるんだろ
155 名前：デフォルトの名無しさん mailto:sage [2023/03/11(土) 00:54:45.06 ID:48Pa/Qcy.net]: Rust標準ライブラリのソースを見るとよくわかるよ
let else構文はもちろん使われまくっている
可読性が良くなるからね
156 名前：デフォルトの名無しさん mailto:sage [2023/03/11(土) 06:31:08.87 ID:nd+w7sZp.net]: インストールでつまずいたのでチラ裏させてくれ
サンプルプログラムをコンパイルしたら`link.exe` not foundでコンパイルできなかった。
原因は、Build Tools for Visual Studio 2022をインストールしてしまったこと、アンインストールして
Build Tools for Visual Studio 2019をインストールしてコンパイルできた。
157 名前：デフォルトの名無しさん mailto:sage [2023/03/11(土) 11:07:27.22 ID:ShQc/Olf.net]: 相も変わらず1人だけズレてるな
158 名前：デフォルトの名無しさん mailto:sage [2023/03/11(土) 11:07:29.53 ID:phgAMXMr.net]: >>152
ネストが深くならないように積極的にlet else使うのが良いみたいやな
130の例はネストが無いことがif letのままでいい根本的な理由となるわけだ
159 名前：デフォルトの名無しさん mailto:sage [2023/03/11(土) 12:18:40.44 ID:JdznY9pT.net]: let-elseはパターンに合致しないと処理を継続できない場合に早期離脱（return、break、etc.）するための構文でしょ
それ以外でも使えるだろうけど逆に可読性が落ちそう

従来の言語で

if (nullable_obj == null) { continue; } // この行を書き忘れるとえらいことになる
nullable_obj.do_something();
...

みたいに書ける処理を今までのRustだと

if let Some(obj) = nullable_obj {
　obj.do_something();
　...
} else { // ループの末尾ならここは不要
　continue;
}

か無理やりunwrapして

if nullable_obj.is_none() { continue; } // この行を書き忘れるとえらいことになる
let obj = nullable_obj.unwrap();
obj.do_something();
...

みたいに書くしかなかったけど、let-elseを使うと従来の言語に近い形で書けるようになる

let Some(obj) = nullable_obj else { continue; }; // この行を書き忘れることはできない
obj.do_something();
...
returnだと?演算子で十分な場合もあるだろうから敢えてcontinueにした
160 名前：デフォルトの名無しさん mailto:sage [2023/03/11(土) 12:36:22.58 ID:GtLfWJGz.net]: let elseはcontinueでもbreakでもreturnでもpanicでも!なら何でも使えるし使われている
returnの時にErr返しなら?を使ってもよいが
.ok_or_else(|| Error)?; とするか
elseでreturnするか
どちらが見やすいかは意見が別れそうだ
161 名前：デフォルトの名無しさん mailto:sage [2023/03/11(土) 12:39:50.82 ID:WrUJ3YdB.net]: Rustに限った話ではないがリファクタリングの良し悪しを判断するためには該当箇所を含む関数の全容(特に関数シグニチャ)とその関数を呼び出すコード例が最低限必要
関数シグニチャも呼び出すコードもない例では話にならない

呼び出し側が絶対変更できない前提なら前者だけでもいい場合があるが往々にして部分最適になりがち
>>130の例でも呼び出す側を考慮するとまた違った選択肢が見えてくる
162 名前：デフォルトの名無しさん mailto:sage [2023/03/11(土) 12:48:32.01 ID:Us0DtIzW.net]: コーディング規約で早期リターンが推奨される開発現場であれば
その規約に準拠した表現が書きやすくなったのは良いこと
つうかそのつもりで読んでたから後者のほうが読みやすかったわ
163 名前：デフォルトの名無しさん mailto:sage [2023/03/11(土) 13:41:29.57 ID:+LV0PjS3.net]: >>158
?とOptionとResultの影響があるから
他の言語よりも関数シグニチャーの持つ意味が余計に大きいように思う
164 名前：デフォルトの名無しさん mailto:sage [2023/03/11(土) 14:09:20.55 ID:zozTFx1B.net]: 隔離スレでやれ
165 名前：デフォルトの名無しさん mailto:sage [2023/03/11(土) 20:53:29.08 ID:YsMYadXT.net]: https://qiita.com/namn1125/items/ccedf9cc06b8cef71557#let-else文のユースケース
この人が書いてるように?演算子のイディオムを踏襲してればlet-elseの出番は多くはない
逆に本来使うべきでないところでも乱用されやすいから注意が必要
166 名前：デフォルトの名無しさん mailto:sage [2023/03/11(土) 23:05:55.56 ID:ChsfUoNW.net]: >>159
多くのところで言語に関わらずでifネストを深くせずに早期離脱をすることが好まれる
Rustではif let時にそれができなかったためlet else導入まではこうなってしまっていた
let foo = if let Some(foo) {
　foo
} else {
　(早期離脱前の処理があればここ)
　早期離脱
}
これはfooが三重に冗長で不格好
そのためlet else以前は早期離脱をあきらめる本末転倒なことも起きていた

具体的にlet elseが適している早期離脱は「範囲」が広い
・break
・continue
・エラー以外のreturn
・早期離脱前の処理があるエラーreturn

>>162
？が使える「範囲」はlet else より狭く早期離脱前の処理がないエラーreturnのみ
もちろん「量」は多いけどね
167 名前：デフォルトの名無しさん mailto:sage [2023/03/12(日) 11:57:58.73 ID:HouQiurI.net]: カルパッチョ
168 名前：デフォルトの名無しさん mailto:sage [2023/03/12(日) 12:41:14.42 ID:UHnNkdpy.net]: 初見

VS code使い始めたんだが、カーソル移動系のショートカットキーの編集ってできないのか?
さくらEditorみたいにカーソル移動・ドラッグ編集を全部キーボードでやりたいんだが
169 名前：デフォルトの名無しさん mailto:sage [2023/03/12(日) 12:42:40.81 ID:C0R72d/J.net]: なぜここできく
170 名前：デフォルトの名無しさん mailto:sage [2023/03/12(日) 14:07:53.88 ID:BVlbavKU.net]: File > Preferences > Keyboard Shortcutsで設定画面開いて
cursorでフィルターかければcursorLeftみたいなコマンド出てくるから大体は変更できると思う
知らんけど
171 名前：デフォルトの名無しさん mailto:sage [2023/03/12(日) 14:14:14.53 ID:C6Uwumzj.net]: vimでもemacsでもrust-analyzer動くよ
172 名前：デフォルトの名無しさん mailto:sage [2023/03/12(日) 15:10:27.15 ID:UHnNkdpy.net]: >>166
プログラム板で一番勢いあるのここだから
173 名前：デフォルトの名無しさん mailto:sage [2023/03/12(日) 16:06:30.84 ID:nONlRGBh.net]: 大学生が書いたQiita記事のほうがこのスレの住民より要点おさえてるじゃんw
おまえらも見習えよ
174 名前：デフォルトの名無しさん mailto:sage [2023/03/13(月) 11:54:44.62 ID:38Ewlrdq.net]: Qiitaは秀才だらけだし
5chム板は文字通り住民がrustだし
175 名前：デフォルトの名無しさん mailto:sage [2023/03/16(木) 07:24:49.76 ID:M0AuqK/y.net]: >>162
その記事を読んでみたが漏れもあり
>>163のまとめで十分と思った
176 名前：デフォルトの名無しさん mailto:sage [2023/03/16(木) 10:05:31.80 ID:3ZknUEKY.net]: 複オジにいちいち突っ込むのは疲れたよ
>>163見れば素人だとすぐわかる
もう騙される人もいないから注意する必要もない
177 名前：デフォルトの名無しさん mailto:sage [2023/03/16(木) 10:12:16.89 ID:xtobTOZe.net]: 具体的に何が問題なの？
178 名前：デフォルトの名無しさん mailto:sage [2023/03/16(木) 18:23:03.08 ID:O0F78LdH.net]: >>174
いつもの自演だろ。
真面目な話題はワッチョイスレにしようぜ。
179 名前：デフォルトの名無しさん mailto:sage [2023/03/16(木) 18:54:09.77 ID:sXs ]: [ここ壊れてます]
180 名前：K9Uns.net mailto: オジおじ言ってたら自演
スレ荒らしが目的 []: [ここ壊れてます]
181 名前：デフォルトの名無しさん mailto:sage [2023/03/17(金) 18:16:56.57 ID:XLm6gsUd.net]: こういうコードを書くとエラーになります。
Bar を実装しているのは &T であって T ではないからだというのはわかるのですが、
どういう形で書けばいいのかわかりません。
T そのものではなく &T が Bar を実装しているという制約はどう表現すればよいのでしょうか？

trait Bar {
fn func(&self) {}
}

fn baz<T>(x: &T)
where
T: Bar, // どう書けばいいの？
{
let a = x.func();
}

struct Foo {}
impl Bar for &Foo {}

fn main() {
baz(&Foo {});
}
182 名前：デフォルトの名無しさん mailto:sage [2023/03/17(金) 19:14:05.96 ID:NC4w42Nt.net]: >>177
✕ impl Bar for &Foo {}
○ impl Bar for Foo {}
183 名前：デフォルトの名無しさん mailto:sage [2023/03/17(金) 19:33:27.88 ID:7IpB+MOB.net]: >>178
それは変えられない前提の部分です。
制約の付け方 (where句の書き方) を質問しています。
184 名前：デフォルトの名無しさん mailto:sage [2023/03/17(金) 19:35:54.06 ID:NC4w42Nt.net]: どうしてもimpl Bar for &Foo {}で行きたいなら
こうするしかない

trait Bar: Sized {
fn func(self) {}
}
fn baz<T>(x: T) where T: Bar,
185 名前：デフォルトの名無しさん mailto:sage [2023/03/17(金) 19:56:30.88 ID:TZnQdWAf.net]: いやできるが……
fn baz<'a, T>(x: &'a T) where &'a T: Bar
186 名前：デフォルトの名無しさん mailto:sage [2023/03/17(金) 19:59:29.44 ID:XLm6gsUd.net]: なるほど、寿命を省略できないのですね。
ありがとうございます。
187 名前：デフォルトの名無しさん mailto:sage [2023/03/17(金) 20:06:51.73 ID:kImSYq8C.net]: >>182
Rustコンパイラからのエラーメッセージを見てる？
参照に対してライフタイム付けろと出ているはず
188 名前：デフォルトの名無しさん mailto:sage [2023/03/17(金) 20:28:03.09 ID:VjFaSUfW.net]: 寿命！
189 名前：デフォルトの名無しさん mailto:sage [2023/03/17(金) 21:08:25.10 ID:XLm6gsUd.net]: >>183
答えを見たら全く自然なことだということは理解できるんですが
explicit lifetime というのがなんのことかすらぴんと来ない程度なんです……。
190 名前：デフォルトの名無しさん mailto:sage [2023/03/18(土) 11:19:09.17 ID:KAD/gYE9.net]: >>185
Rustを学びたい人はまず最初に”公式”のThe Bookを読むこと
https://doc.rust-lang.org/book/
191 名前：デフォルトの名無しさん mailto:sage [2023/03/18(土) 11:40:54.04 ID:yS+7OZFn.net]: >>186
>>177て”公式”のThe Bookに書いてあったっけ？
192 名前：デフォルトの名無しさん mailto:sage [2023/03/18(土) 11:42:47.58 ID:l9YNpI31.net]: lifetime 周りは書いてあるだろ
193 名前：デフォルトの名無しさん mailto:sage [2023/03/18(土) 11:53:17.34 ID:VtoeVuok.net]: >>188
>>181とかどこだっけ？
194 名前：デフォルトの名無しさん mailto:sage [2023/03/18(土) 11:57:09.36 ID:kHUlERx3.net]: >>185
ライフタイムは全てにあるが省略できることが多い
省略できないときはコンパイラがエラーとし教えてくれるのでライフタイムを付ければいい

>>186
日本語版もある
https://doc.rust-jp.rs/book-ja/
195 名前：デフォルトの名無しさん mailto:sage [2023/03/18(土) 14:05:24.60 ID:PyzwqGcC.net]: >>190
誤訳だらけの粗悪な非公式日本語訳はお勧めしない
簡単なエラーメッセージの意味も分からないような状態なんだからまずは公式The Bookをしっかり読むべき
196 名前：デフォルトの名無しさん mailto:sage [2023/03/18(土) 16:08:20.29 ID:QSo2KHpO.net]: 「非公式な日本語訳」を「日本語版」と呼称するのはそれがあたかも公式かのように錯覚させる意図が見えるので優良誤認の疑いがある
197 名前：デフォルトの名無しさん mailto:sage [2023/03/18(土) 16:13:56.89 ID:6WtXixvi.net]: >>187
The Bookはクックブックじゃないからな
特定の方法が書いてるか書いてないかよりも
読んで理解してれば自己解決できる問題かどうかが重要
198 名前：デフォルトの名無しさん mailto:sage [2023/03/18(土) 17:11:12.32 ID:NQWJ1KgL.net]: 日本語訳の話題は生産的じゃないのでやめよう
このスレのローカルルールは>>37の通り
199 名前：177 mailto:sage [2023/03/18(土) 18:27:39.58 ID:XgD5JQEe.net]: 読んだのは日本語訳のほうの The book ですが、個々の機能はたぶん分かってると思います。
ライフタイムを省略した場合には一定のルールで補われること�
200 名前：熬mってました。 ただ、型が満たすべき性質を書くのが where 句なので (エラーメッセージを見てすら！) ライフタイムが必要ということがぴんと来なかったというのと、 引数と同じ記法でライフタイムをここに書けるのだということがわからなかったんです。 []: [ここ壊れてます]
201 名前：デフォルトの名無しさん mailto:sage [2023/03/18(土) 18:38:31.92 ID:l9YNpI31.net]: > 引数と同じ記法でライフタイムをここに書けるのだということがわからなかったんです。
英語版でも日本語版でもどっちでもいいけど 10.3 にちゃんと書いてあるよ
202 名前：デフォルトの名無しさん mailto:sage [2023/03/18(土) 19:09:39.09 ID:YhY+O2tk.net]: whereの:の左辺に参照とか書けるのをまず知らなかったんでしょ
the Bookにそんな例無いし
203 名前：デフォルトの名無しさん mailto:sage [2023/03/18(土) 19:27:58.81 ID:sUMBdqo8.net]: 日本語版を読まなければこんなことにはならなかった
日本語版を許すな
204 名前：デフォルトの名無しさん mailto:sage [2023/03/19(日) 04:14:30.76 ID:JYAaHQUF.net]: >>183
ラストコンパイラって響きカッコいいな
205 名前：デフォルトの名無しさん mailto:sage [2023/03/19(日) 13:06:57.80 ID:j6t6IVCD.net]: >>193
この場合に必要なのはクックブックだろ。
せめて>>196みたいに誘導しないと。

「読んで理解すれば自己解決できる」とか、そもそも読むところも示していないのにできるわけない。読み手を無視してマウントする自慰行為にしか見えん。
206 名前：デフォルトの名無しさん mailto:sage [2023/03/19(日) 13:09:44.94 ID:E3Ip09fl.net]: そりゃ「個々の機能はたぶん分かってると思います」とか言われたら分かってねーじゃんって言いたくなるだろ
207 名前：デフォルトの名無しさん mailto:sage [2023/03/19(日) 13:23:44.49 ID:6gmOWdI+.net]: >>196
where 句の制約で書いてる事例はないよ。
208 名前：デフォルトの名無しさん mailto:sage [2023/03/19(日) 14:19:01.09 ID:8hEI7b0p.net]: >>200
訳の分からない日本語訳読んでわかったつもりになってるだけだからそう感じるんだよ
つべこべ言わずに全部読め
209 名前：デフォルトの名無しさん mailto:sage [2023/03/19(日) 14:25:09.74 ID:RMEG+oCh.net]: >>202
grepだけじゃ答えは見つからない
読んでないから調べ方もわからない
210 名前：デフォルトの名無しさん mailto:sage [2023/03/19(日) 20:29:29.27 ID:Pq7wYRkP.net]: >>203
順調に日本Rustは錆びているようですね。いや、めでたい。
211 名前：デフォルトの名無しさん mailto:sage [2023/03/19(日) 20:49:16.05 ID:UVlxeYfB.net]: ちゃんとあるじゃん
https://doc.rust-jp.rs/book-ja/ch10-03-lifetime-syntax.html#%E3%83%A9%E3%82%A4%E3%83%95%E3%82%BF%E3%82%A4%E3%83%A0%E6%B3%A8%E9%87%88%E8%A8%98%E6%B3%95
212 名前：デフォルトの名無しさん [2023/03/19(日) 21:36:02.67 ID:XN9u9qop.net]: Rustはベンチマーク速いから気になってるんだけど
iPhoneやAndroidの開発で将来的に使えるようになる話はないの？
213 名前：デフォルトの名無しさん mailto:sage [2023/03/19(日) 21:40:34.06 ID:C8hzWYTf.net]: ゴミだな
214 名前：デフォルトの名無しさん mailto:sage [2023/03/19(日) 21:41:36.36 ID:/nL/Z/hW.net]: >>207
普通に使えるやろ
215 名前：デフォルトの名無しさん mailto:sage [2023/03/19(日) 21:48:03.22 ID:1LqNQBrB.net]: >>177見て思うんだじぇど
ゆとり教育超大国日本ではゆとり脳な奴が多数になって
エラーがでたよ、でも、エラー内容は書かないようなコミュ力の低い奴が
普通になっているんかな。
216 名前：デフォルトの名無しさん mailto:sage [2023/03/19(日) 22:05:41.03 ID:pmaEpt3C.net]: >>210
いくつか落ち度はあっても>>177は自分の考える最小限の再現可能なコードを提示してるからめっちゃくちゃマシな質問者
質問者としての偏差値63くらい
217 名前：デフォルトの名無しさん mailto:sage [2023/03/19(日) 22:08:47.66 ID:pmaEpt3C.net]: 5chでの偏差値ね
Stackoverflowだと47くらい
218 名前：デフォルトの名無しさん mailto:sage [2023/03/19(日) 22:25:46.74 ID:6gmOWdI+.net]: >>207
ネイティブコンポーネントには Rust は使える。
Android の根本設計が Linux+JVM で、 JVM は変に高級な設計だからその高級な機能に噛み合うように設計された言語じゃないとうまくいかない。
LLVM バックエンドで JVM バイトコードを生成するものもあるらしいから無理すりゃ Rust でもなんとかなるかもしれないけど……
それよりも現在の情勢を見ると Android に WASM サブシステムが入るとかのほうがあり得そうな気がするよ。
219 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 00:55:07.77 ID:rG0fuScP.net]: 自然言語自体に落ち度があると思った方がプログラミング言語の価値が分かりやすい
翻訳にも質問にもChatGPTにも過度の期待をしなくてすむ
220 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 01:31:12.77 ID:OPxEUMsA.net]: 言語の問題と言語を扱うやつの問題を同一視するアホ
221 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 01:42:28.65 ID:+AEvN8jR.net]: 正常動作する正規品を期待してたのに
不具合だらけで役に立たないジャンク品でした
222 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 02:15:13.67 ID:rG0fuScP.net]: はした金ではジャンク品しか買えない
インフレか
物価の問題と品質の問題のような二つの問題を無関係と考えるのがアホだったんじゃないか？
223 名前：デフォルトの名無しさん [2023/03/20(月) 03:09:08.81 ID:KC0EWXje.net]: prettierの代替のdprintがRust製だった
普及してるものがRust製に置き換わるってが今後も続くだろうね
224 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 03:46:46.02 ID:8+GC48xI.net]: >>217
ところが実際はジャンク品のほうが正規品より高いんだなこれが
正規品に見せかけて売ってるからいわゆるジャンク扱いではなく蓋を開けたらゴミでしたという落ち

でもありがたいことに今は購入前に中身を確認可能なのでよほどの情弱じゃなければ騙されないんだけどね
225 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 10:04:17.69 ID:UnL767mB.net]: >>217
物価の意味も知らんのかww
恥ずかしいから辞書引けよ
226 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 10:58:26.51 ID:uuArbTr3.net]: このあたりを読んでおけば大丈夫
Advanced Lifetimes
https://doc.rust-lang.org/1.30.0/book/second-edition/ch19-02-advanced-lifetimes.html
227 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 11:08:21.33 ID:XflJK2ct.net]: >JVM は変に高級な設計だからその高級な機能に噛み合うように設計された言語じゃないとうまくいかない。

相変わらずいい加減なこと書いてるなぁ
228 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 11:41:00.74 ID:rG0fuScP.net]: アプリもコンパイラも動くLinuxが正規品
コンパイラは不要とされアプリしか動かないLinuxがジャンク
229 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 11:59:59.11 ID:IoVEULD8.net]: >>223
GNUにケンカ売る気かよ
230 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 14:23:43.87 ID:YI144KAX.net]: Iterator<Item = Option>の時
filter(|o| o.is_some()).map(|o| o.unwrap()).map(|x| f(x))を
iflet(|Some(x)| f(x))みたいに1つにまとめてくれるメソッドある？
231 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 17:14:18.78 ID:dpT4FG92.net]: flattenとかflat_mapとかfilter_mapとか
232 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 19:58:13.92 ID:EBVsuSrE.net]: flat_mapはmap(f).flatten()の順だから無理だな
filter_mapはOption外しに使えるがmap(f)は別途必要
filter_map(|opt| opt).map(f)　または参照なら
filter_map(Option::as_ref).map(f)
したがって正解はこれ
flatten().map(f)
233 名前：デフォルトの名無しさん [2023/03/20(月) 20:22:03.14 ID:9WmeSXDj.net]: flattenのOption/Resultはずし知らんかった
234 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 20:32:22.28 ID:45aFG7he.net]: >>227
どれでもできるぞ
初手で一番素直な選択はfilter_map
235 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 20:46:14.12 ID:YI144KAX.net]: flattenを使ってできました
let v = vec![None, Some((1, 2)), None, Some((3, 4)), None];
assert_eq!(14, v.iter().flatten().map(|(a, b)| a * b).sum());

>>229
filter_mapを使うと簡単ならば知りたいです
236 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 21:35:03.62 ID:adpwtvX/.net]: 複オジかよっw
237 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 21:41:30.44 ID:EBVsuSrE.net]: 前述したようにfilter_map自体のmapではOption外ししかできないので別途map(f)が必要になる
filter_map(|opt| opt).map(f)
あるいは
filter_map(|opt| opt.map(f))
簡単なのはflatten().map(f)
238 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 23:15:03.64 ID:dBJpnlWY.net]: flat_mapはfilter_mapを汎用化したものなので
filter_mapは常にflat_mapで書き直せる
flattenと理屈は同じ
239 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 23:20:21.79 ID:I3aedYRP.net]: 唐突に妙に具体的な質問が飛んできたらあの人だと思ってればいい
240 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 23:20:56.30 ID:c1bWUyRU.net]: どの人だよ
241 名前：デフォルトの名無しさん mailto:sage [2023/03/20(月) 23:49:46.77 ID:K17OWm6q.net]: >>234
いやー俺は今回まんまと騙されたわ
自演力と自画自賛力にステ振りすぎとちゃう？
242 名前：デフォルトの名無しさん mailto:sage [2023/03/21(火) 00:12:49.49 ID:lhwbZ9up.net]: >>226 >>233
質問はOption列が対象のようだからflat_mapとfilter_mapは対象外やろ
それらはむしろOptionを作る関数を与えて使う
元から既にOptionになってるのだからflattenが正解
243 名前：デフォルトの名無しさん mailto:sage [2023/03/21(火) 10:42:06.27 ID:El4m1VCp.net]: Someだけ拾って関数をmapすると考えれば
filter_map(|opt| opt.map(f))
だな
元のSome/Noneをそのまま利用するのがトリッキーかもしれないけど
244 名前：デフォルトの名無しさん mailto:sage [2023/03/21(火) 11:33:54.48 ID:aqrydfrP.net]: ところで、ラムダには自由変数というものがありその反対が束縛変数だが
ラムダや自由変数を意識する必要がない文脈で束縛という用語が出ると
その語源を説明する手間がかかるよな
245 名前：デフォルトの名無しさん [2023/03/21(火) 13:02:51.29 ID:3dx+Qi3k.net]: scalaやっているせいかmatchとか
すごく使いやすいわん
iterator nextなんてJavaでも使わんけど
これ使い人いるの？
246 名前：デフォルトの名無しさん mailto:sage [2023/03/21(火) 13:17:10.53 ID:lhwbZ9up.net]: >>240
nextはIterator全ての基礎
nextだけを定義すれば他のメソッドはnextで作られているので自動的に定義される
for文もnextを使っている
247 名前：デフォルトの名無しさん mailto:sage [2023/03/21(火) 13:27:49.15 ID:gPDO4YWu.net]: >>238
入力から出力までのパイプラインの全体像を見ればトリッキーに感じることはないと思うよ
例えば>>230にあるvec![None, Some((1, 2)), None, Some((3, 4)), None];みたいなのはこれがすでに入力値に対して何かしら関数適用した結果なんだよね
248 名前：デフォルトの名無しさん mailto:sage [2023/03/21(火) 13:35:41.08 ID:lhwbZ9up.net]: >>242
関数適用せずとも
None初期化配列やVecで一部indexにだけ値がSomeは普通によくあるパターン
249 名前：デフォルトの名無しさん mailto:sage [2023/03/21(火) 14:20:03.57 ID:El4m1VCp.net]: 元の入力で「値の有無」を表してたOptionをfilter_mapの「要素の残存判定」に転用する形だから
Optionの意味が微妙に変わってて引っ掛かる人もいるかなって思った
250 名前：デフォルトの名無しさん mailto:sage [2023/03/21(火) 14:35:08.73 ID:4Vr7UtW/.net]: 昔の言語だと配列に初期値として使っていないことを示すために-1とか0とかnullとかundefinedを入れてしまうことが多かったパターンか
いわゆるデータのnull安全性がなかったことろをRustはOptionのNoneとSome利用でnull安全性が保証
データが0にならならNonZeroを使えばNone時に0が使われて余分なメモリ消費もないしな
251 名前：デフォルトの名無しさん mailto:sage [2023/03/21(火) 14:39:43.43 ID:xxXQcN5m.net]: 隔離スレでやれ
https://mevius.5ch.net/test/read.cgi/tech/1677286186/
252 名前：デフォルトの名無しさん mailto:sage [2023/03/21(火) 14:40:28.73 ID:4Vr7UtW/.net]: >>238
そこを出発点として考える場合でも
filter_map(|opt| opt.map(f))
↓　Optionのままmapしても剥がしてからmapしても同じ
filter_map(|opt| opt).map(f)
↓　Optionに対して恒等関数になってるのでflattenと同じ
flatten().map(f)
と辿り着く
253 名前：デフォルトの名無しさん mailto:sage [2023/03/21(火) 17:23:17.80 ID:El4m1VCp.net]: >>247
自分は途中のイテレータ減らしたい派だから一番上で落ち着いてしまう
ラムダ式減らすなら下だろうけどfilter_mapが便利すぎてね…
254 名前：デフォルトの名無しさん mailto:sage [2023/03/21(火) 18:14:49.79 ID:lhwbZ9up.net]: >>244
Optionは常に値の有無を表している
filter_mapも値の有無を残存判定に用いている
Optionの意味が変わることはない
255 名前：デフォルトの名無しさん mailto:sage [2023/03/21(火) 19:05:07.54 ID:Kxmr6Met.net]: >>243
いかにも競プロっぽい考え方だね
現実のプログラムでは最低でも(K, V)で管理するから計算対象の値だけを素のOption配列で管理したりしないよ
256 名前：デフォルトの名無しさん mailto:sage [2023/03/21(火) 19:18:56.96 ID:8T+PSGNQ.net]: >>250
インデックス値で管理できるものま無駄なコストがかかるハッシュマップでを用いる気軽な連想配列な考えこそコスト無視のスクリプト言語な考えだよ
インデックス値で管理できるものはRustでは配列かVecを使う
257 名前：デフォルトの名無しさん mailto:sage [2023/03/21(火) 21:39:30.39 ID:Hb26aB9L.net]: HashMap<K, V>はhash計算コストに加えてkey比較コストがhash衝突回数の分かかるからなー
indexになれる値があって上限が許容されるならVecが有利
258 名前：デフォルトの名無しさん mailto:sage [2023/03/21(火) 23:56:44.92 ID:UIyRFaA6.net]: >>250が経験不足と知識不足で知らなかったんでしょ
259 名前：デフォルトの名無しさん mailto:sage [2023/03/22(水) 13:00:26.42 ID:KFnwa6CM.net]: >>251
おいおいなんで急にハッシュマップが出てくるんだよ
そんなんで大丈夫か？

Vec<Option<V>>みたいなデータがどこからともなく自然発生するわけないんだから全体のパイプラインを考えろって言ってるの
現実的かつ具体的なユースケースで考えような
260 名前：デフォルトの名無しさん mailto:sage [2023/03/22(水) 18:31:25.27 ID:KdbjtxZL.net]: ナイーブなハッシュテーブルをVec<Option<T>>で実装する人はいるかもしれない
261 名前：デフォルトの名無しさん mailto:sage [2023/03/22(水) 21:00:04.56 ID:ax9KtLpr.net]: うちも値域が限定されてる離散値はArrayかVec<Option<T>>使う
262 名前：デフォルトの名無しさん mailto:sage [2023/03/22(水) 21:30:41.78 ID:Bu7rNmu4.net]: マニュアルに書いてるような内容をやたら饒舌に語るとChatGPT感出るね
263 名前：デフォルトの名無しさん mailto:sage [2023/03/22(水) 21:32:36.00 ID:VRM+VuH6.net]: >>255
>ナイーブなハッシュテーブルをVec<Option<T>>で実装する人はいるかもしれない
その場合でもTは(u64, K, V)
264 名前：デフォルトの名無しさん mailto:sage [2023/03/22(水) 21:36:57.10 ID:fGWMZjSN.net]: Vec<Optionは普通に使うぞ
今書いてる部分と似たようなことをしてるregexのソースを見たらVec<Option使ってる
普通そうなるよな
265 名前：デフォルトの名無しさん mailto:sage [2023/03/22(水) 22:15:33.42 ID:ngpWOwSU.net]: >>257
まるで知能は互角で内容だけが違うみたいな言い方だが
知能の差を見せつければいいだけだよ
266 名前：デフォルトの名無しさん mailto:sage [2023/03/22(水) 23:19:58.21 ID:M/QYX+I6.net]: Vec<Option<T>>が使われないなんていう話は誰もしてないのにね
話が通じなくてもう面倒くさ過ぎるわ
267 名前：デフォルトの名無しさん mailto:sage [2023/03/22(水) 23:35:18.64 ID:3T9wSwPZ.net]: たぶん論点はfilter_mapの話からここ

> vec![None, Some((1, 2)), None, Some((3, 4)), None];みたいなのはこれがすでに入力値に対して何かしら関数適用した結果なんだよね

> Vec<Option<V>>みたいなデータがどこからともなく自然発生するわけないんだから全体のパイプラインを考えろって言ってるの

でもこの主張は間違っていて
疎なデータ構造ならいきなりVec<Option<T>>が現れる
初期値オールNoneから飛び飛びにSome化していく
そのVec<Option<T>>は何度も使うからのイテレータ処理の一時的に現れるものでもない
268 名前：デフォルトの名無しさん mailto:sage [2023/03/23(木) 00:27:50.25 ID:WQSgJ4cO.net]: 構うから暴れるんすよ
269 名前：デフォルトの名無しさん mailto:sage [2023/03/23(木) 07:45:41.23 ID:ZvBDBUI1.net]: グラフ構造でVec<Option<usize>>使うこともある
さらにインデックス自体のマッピングにも使われたり
// Maps old index to new index. None if not yet visited.
let mut remap: Vec<Option<usize>> = vec![None; self.nodes.len()];
270 名前：デフォルトの名無しさん mailto:sage [2023/03/23(木) 08:16:41.69 ID:uJzov1zR.net]: 公式ドキュメントとchatgpt
これだけあれば全て滅びる
271 名前：デフォルトの名無しさん mailto:sage [2023/03/25(土) 10:51:05.32 ID:F0OLKMhM.net]: 人間があれやこれやするよりも
全部 AI 翻訳に任せりゃインジャネーノ
272 名前：デフォルトの名無しさん [2023/03/27(月) 10:33:42.84 ID:IqXvBms8.net]: >>263
本当にそうだったね
273 名前：デフォルトの名無しさん [2023/03/27(月) 13:18:10.65 ID:hjxGI+jP.net]: そのうち
課題を見つける能力
課題を提起する能力
がメインとなるんやろな
1人会社が当たり前になりそう
274 名前：デフォルトの名無しさん [2023/03/27(月) 17:47:50.73 ID:ppqykIl7.net]: >>268
今までもそうだったけど気づいてない人が多かったというだけ
解けることが事前にわかってる問題を与えられて解くだけの人は今までも価格競争にさらされ段階的に置き換えられてきた

機械学習による変化は機械に解かせることのできる問題の抽象度が上がったこと
275 名前：デフォルトの名無しさん [2023/03/30(木) 21:28:14.05 ID:O05INV+E.net]: samタレットを壊されないかつ迎撃もできる状態で設置する方法ってない？
拠点屋根に四台設置してんだけどログインする度に毎回壊されてるわ
276 名前：デフォルトの名無しさん [2023/03/30(木) 21:34:58.46 ID:O05INV+E.net]: ごめんスレ間違えた
277 名前：デフォルトの名無しさん mailto:sage [2023/03/31(金) 12:09:07.07 ID:lEKZGT8D.net]: それはrustだろ？ここはrustスレ。間違えるなよ
278 名前：デフォルトの名無しさん mailto:sage [2023/04/01(土) 04:03:16.63 ID:ncnK4efa.net]: Interface 2023年5月号
550号特別企画　2大特集　Linuxでも正式サポート，組み込みや車載で注目を集める　質実剛健 Rust言語
3月25日発売 (定価 1,200円＋税)

第1特集：C言語と比べて理解する
第2特集：マイコンで動くフル機能Rust
特別付録：初めてのRustプログラミング
新連載：毎号実験！自律移動ロボット
279 名前：デフォルトの名無しさん mailto:sage [2023/04/01(土) 16:12:14.56 ID:MxqBV1k0.net]: >>273
面白そうだな。組み込みだと実装依存のCコードがまかり通っていたりするからな
280 名前：デフォルトの名無しさん mailto:sage [2023/04/02(日) 17:52:37.39 ID:w9dFgeBH.net]: interface読んでる連中には難しいんじゃないの？
281 名前：デフォルトの名無しさん mailto:sage [2023/04/02(日) 18:01:44.10 ID:Xkdfgrgv.net]: むしろこれを機に組み込みの勉強でも始めてみようかしら
282 名前：デフォルトの名無しさん mailto:sage [2023/04/02(日) 18:02:25.20 ID:oh3DHZZg.net]: >>273
本屋で見てきた。個人的にめぼしい解説はCMSIS-DAPくらいで
大体The Embedded Rust Bookで十分かな
283 名前：デフォルトの名無しさん mailto:sage [2023/04/02(日) 19:09:06.81 ID:w9dFgeBH.net]: 組み込みだったらmrubyだよね
しらんけど
284 名前：デフォルトの名無しさん mailto:sage [2023/04/03(月) 00:25:42.34 ID:XRTgFvZO.net]: そのうちrust謹製の組み込み OS とか出てくるんじゃねえの
285 名前：デフォルトの名無しさん mailto:sage [2023/04/03(月) 00:53:16.98 ID:OPvO6xnV.net]: >>279
Google が KataOS を発表してる。今は CantripOS と改名してるっぽいな。
どこまで本気なのかよくわからんけどコードは Github に有るから見物してみたらいいんじゃない？
286 名前：デフォルトの名無しさん mailto:sage [2023/04/03(月) 09:12:06.30 ID:45NlJXFV.net]: 組み込み分野を目指す学生はPythonばっかり
これを機にRustやCやC++にも目を向けて欲しい
組み込み分野の実務でPythonはつぶしがきかない
287 名前：デフォルトの名無しさん mailto:sage [2023/04/03(月) 11:15:42.36 ID:wQbZbh4b.net]: 組み込みでPythonとか使うのか
一番親和性の感じられない組み合わせやな
288 名前：デフォルトの名無しさん [2023/04/03(月) 11:32:22.07 ID:AEelnK5w.net]: ラズパイでしょ
289 名前：デフォルトの名無しさん mailto:sage [2023/04/03(月) 11:39:22.47 ID:DEHD7IX8.net]: ラズパイは組み込みじゃないだろｗ
組み込み向けだと MicroPython とかあった気がするけど使われてるのかねぇ
290 名前：デフォルトの名無しさん mailto:sage [2023/04/03(月) 11:55:49.94 ID:weCnHsyM.net]: ラズパイはLinux系OSが動いていてX Windowを立ち上げてデスクトップPCにすることも可能な環境
昔からからの組み込みが指すのはOSがないもしくは簡易なものしかない環境でありそこでPythonは使われない
291 名前：デフォルトの名無しさん mailto:sage [2023/04/03(月) 12:04:38.11 ID:GLvgK6Zq.net]: 組み込みかどうかと言うより
ミッションクリティカルかどうかと言ったほうが正確か
292 名前：デフォルトの名無しさん mailto:sage [2023/04/03(月) 12:08:34.80 ID:+ZHaYieR.net]: 同等以上に曖昧に思う。
293 名前：デフォルトの名無しさん mailto:sage [2023/04/03(月) 12:26:19.63 ID:NFGj33Dp.net]: 組み込みならFORTHだよね。
294 名前：デフォルトの名無しさん [2023/04/03(月) 15:05:13.27 ID:KUJKPBk4.net]: ミッションクリティカルの意味わかってないだろw
295 名前：デフォルトの名無しさん mailto:sage [2023/04/03(月) 15:14:52.29 ID:bhpxOZS2.net]: javaですら使われるんだから場所によってはpythonもあるだろう
296 名前：デフォルトの名無しさん mailto:sage [2023/04/03(月) 16:24:30.55 ID:0x65F9Io.net]: このスレ複製おじ来なくなって平和になったなｗ
297 名前：デフォルトの名無しさん mailto:sage [2023/04/03(月) 17:14:33.32 ID:XRTgFvZO.net]: 10年後くらいには組み込みの指すやつが10GHz・20GBくらいになってんだよ
298 名前：デフォルトの名無しさん mailto:sage [2023/04/03(月) 22:15:51.09 ID:OPvO6xnV.net]: Python だって組み込みに使われるのはわかるよ。
でもそれをホスティングする環境は何で書くんだって話よ。
アプリケーション部分だけ書ければ良しというわけにもいかんだろう。組み込みってのは。
299 名前：デフォルトの名無しさん [2023/04/03(月) 22:22:41.19 ID:6LaoLj6b.net]: 組み込みの定義次第
300 名前：デフォルトの名無しさん mailto:sage [2023/04/03(月) 22:46:10.84 ID:uCVDtc7z.net]: 自分の中の組み込みはリアルタイムシステム
CかC++
301 名前：デフォルトの名無しさん mailto:sage [2023/04/03(月) 23:08:31.70 ID:NUuZ0KjY.net]: >>290
javaですらというか、javaはもともと組込みを視野に入れて開発されたものだしな
302 名前：デフォルトの名無しさん mailto:sage [2023/04/04(火) 12:59:01.65 ID:9wA8JWJA.net]: 普通のWindowsPCを何かの筐体に入れればそれは組み込みだがそういう話じゃないよな
実装的には一般的なアプリと何も変わらないわけだし
303 名前：デフォルトの名無しさん mailto:sage [2023/04/04(火) 19:20:19.03 ID:WPLXkRn6.net]: みんな、組み込みに食いつくね
連想するの分野がひとそれぞれなんだね
おいらは組み込みといったらファームウェアだな
304 名前：デフォルトの名無しさん mailto:sage [2023/04/04(火) 20:28:06.15 ID:ktWoV7jH.net]: PICじゃなきゃ組み込みじゃないって感じなのかな？
数年前に関わった仕事じゃFPGAとARMが両方乗っかってて
OSも入ってるやつで測定データをCのソケットでUDP送信させたけどこれ組み込み？
305 名前：デフォルトの名無しさん mailto:sage [2023/04/04(火) 20:50:26.77 ID:vWHz0hKB.net]: >>297
それも組み込みだがなんらかのデバイスの制御はするだろ。
しないってのならさすがに組み込みとは言わんと思うが……。
306 名前：デフォルトの名無しさん mailto:sage [2023/04/04(火) 21:47:02.28 ID:LgI/21ca.net]: 技術的には低レイヤーと称する方が適しているのだろうな。せいぜい軽量のRTOSあたりまで

>>300
汎用性に乏しい装置は原則組み込みじゃね
ゲームコンソールもどちらかと言えば組み込みだと思うし
デジタルサイネージとかも該当するだろう(ラズパイ使っている例もあるらしい)
307 名前：デフォルトの名無しさん mailto:sage [2023/04/05(水) 02:16:43.52 ID:SGxKhieo.net]: >>301
steam deckがLinuxベースという話もあるので
ゲームコンソールが組み込みかどうか…

テレビもLinuxが入ってたりするしなあ
308 名前：デフォルトの名無しさん mailto:sage [2023/04/05(水) 11:08:42.58 ID:vYYfy7R4.net]: >>302
Steam Deckは携帯ゲーム機の形をしているだけで任意のOSを使用できるのだからPCでしょ
>>301でいうゲームコンソールはCS機やAC機等のゲームを実行することしか想定していない装置のこと
テレビもどちらかと言えばゲームコンソールよりでは
309 名前：デフォルトの名無しさん mailto:sage [2023/04/06(木) 10:45:28.99 ID:E/e3rQLj.net]: >>303
デバイスドライバやファームウェアをひとつも書いてないってことはなかろうし、
デバイスに固有の低レイヤプログラミングの部分は組み込みと言ってもいいんじゃないの。
310 名前：デフォルトの名無しさん mailto:sage [2023/04/06(木) 11:27:07.02 ID:k0Faa7D2.net]: 普通組み込み用途と言えばコンピュータ制御の電子機器のために使う用途やろな
・メモリなどのリソースが少ない環境でも使える
・応答時間などのタイミング制御のために実時間処理ができる
こういうのにRustが強いのは何となくわかる
コンパイル時に静的に解決できる範囲が広いからな
311 名前：デフォルトの名無しさん mailto:sage [2023/04/06(木) 12:37:50.23 ID:HSw9WEQy.net]: 全然違う話でごめん
以下のような処理がある時にf(**item)と参照外しを2回も必要とするのは違和感あるけどそういうもの？

let v: Vec<i32> = vec![1, 8, 4, 5, 9, 6, 3];
let valid_index_list: Vec<usize> = v
.iter()
.enumerate()
.filter(|(_, item)| f(**item))
.map(|(index, _)| index)
.collect();
312 名前：デフォルトの名無しさん [2023/04/06(木) 12:42:05.41 ID:0BpFn4iz.net]: 組み込みシステムと組み込みプログラミングで微妙に境界線が異なる

例えばサーマルカメラ内蔵のAndroid端末を使った検温システムは組み込みシステムだけど
サーマルカメラのSDKを利用した検温アプリ開発は組み込みプログラミングとは呼ばないかもしれない
サーマルカメラのSDKを作る開発は組み込みプログラミングと呼べる
313 名前：デフォルトの名無しさん mailto:sage [2023/04/06(木) 12:56:01.04 ID:UmwXRZgB.net]: 確かにSoCや基板の事情がソフト側から見えてると
（memory mapped I/O直接叩くとか）
OSの有無によらず組み込みっぽい感じはするな
314 名前：デフォルトの名無しさん [2023/04/06(木) 15:14:50.96 ID:f3OaQ0al.net]: >>306
なんかオジっぽいコードだね
普通はDeref Coercionを活用する
その例ならfを&i32 -> boolにすれば明示的derefは不要
filter関数がownership取るのは変

ついでにfilter_mapでまとめて
.filter_map(|(index, item)| f(item).then_some(index))
シグニチャ変えられない特別な事情があるならパターンマッチで|(index, &item)|としてderefしておく
315 名前：デフォルトの名無しさん mailto:sage [2023/04/06(木) 16:55:58.17 ID:E/e3rQLj.net]: >>306
値を返すイテレータも参照を返すイテレータもあるから
どちらでも不都合のない仕組みにしようとするとそうなるんじゃないの。
参照が二重になるのはごく普通のこと。

その二重の参照をどうやって剥がすかには選択肢があるけど。
316 名前：デフォルトの名無しさん mailto:sage [2023/04/06(木) 18:19:32.48 ID:ypjpS3Va.net]: >>306 >>309
Vecのインデックスをフィルタリングしているだけだから
iter()もenumerate()もmap部分も不要
シンプルにこれだけでよい
(0..v.len())
.filter(|&index| f(v[index]))
.collect();
317 名前：デフォルトの名無しさん [2023/04/06(木) 18:50:13.90 ID:uKOnYkHi.net]: 俺はそれやだな
318 名前：デフォルトの名無しさん [2023/04/06(木) 19:01:16.65 ID:1W2y5liy.net]: 俺もそれはちょっと遠慮したい

でもまぁそこは論点じゃないんでしょ
iter().filter()は常に&&Tになるから**itemするのが一般的かどうかを聞いてるんだよね？
319 名前：デフォルトの名無しさん mailto:sage [2023/04/06(木) 19:34:52.41 ID: ]: [ここ壊れてます]
320 名前：E/e3rQLj.net mailto: >>311
イテレータでのアクセス (シーケンシャルアクセス) とランダムアクセスが混ざるのがなんか嫌な気持ちになる。
Vec や配列であることが分かっているときなら問題はないというか、
むしろ状況が整理された良いコードだとも思うんだけどなんか心理的な抵抗感が……。 []: [ここ壊れてます]
321 名前：デフォルトの名無しさん mailto:sage [2023/04/06(木) 21:02:27.27 ID:cLuUm0Wb.net]: またイテレータの話してる
322 名前：デフォルトの名無しさん mailto:sage [2023/04/06(木) 22:26:13.61 ID:Ejh1MMKT.net]: >>313
into_iter()でT自体を回してるときにfilterで消費しないように&Tを使っているために
iter()で&Tを回してるときは&&Tになってしまうわけだな
3つの点
・&&Tを考える概念的なわかりにくさ
・記述と可読性
・最適化後の最終コード
それそれで不利があるのかどうか？
323 名前：デフォルトの名無しさん mailto:sage [2023/04/08(土) 17:58:41.25 ID:mPm1zhb4.net]: イテレータおじさん.....。
324 名前：デフォルトの名無しさん mailto:sage [2023/04/08(土) 23:26:42.03 ID:JVh6Wuqn.net]: 多数の文字列をいくつでも追加で登録できて、
その登録した各文字列の参照(&str)を、
その登録オブジェクトが生きてる間は自由に使えるような機能のクレートありますか？

追加のみで削除機能がなければ安全に参照&strを返してその参照をずっと安全に使い続けられるインタフェースを提供できそうですが、
実現にはunsafeを使わざるを得ないため何かデファクトスタンダードなクレートがあるか知りたいです。
325 名前：デフォルトの名無しさん mailto:sage [2023/04/09(日) 00:21:16.51 ID:mvoikQEA.net]: Vec<String>
326 名前：デフォルトの名無しさん mailto:sage [2023/04/09(日) 00:32:20.15 ID:optZAiB4.net]: Vecは追加のために&mutを使うから&strを持ち続けられないか
327 名前：デフォルトの名無しさん [2023/04/09(日) 01:16:25.16 ID:uCQZ544j.net]: は？
328 名前：デフォルトの名無しさん mailto:sage [2023/04/09(日) 01:36:27.91 ID:o+9ttclI.net]: もしかしてこういうこと？
let mut v = Vec::new();
v.push("first".to_string());
let first: &str = &v[0];
v.push("second".to_string());
let second: &str = &v[1];
println!("{first} and {second}");
コンパイルエラーだな
329 名前：デフォルトの名無しさん mailto:sage [2023/04/09(日) 01:42:07.16 ID:Xj6NS6Ie.net]: 文字列専用じゃないけどarena系の実装でいいのかな
typed_arena（https://docs.rs/typed-arena/latest/typed_arena/index.html）がよく使われてるみたい

use typed_arena::Arena;

fn main() {
let arena = Arena::new();
let a: &mut str = arena.alloc_str("abc");
let b: &mut str = arena.alloc_str("def");
let c: &str = arena.alloc_str("ghi");
println!("{a}, {b}, {c}"); // abc, def, ghi

a.make_ascii_uppercase();
b.make_ascii_uppercase();
let d: &str = arena.alloc_str("jkl");
println!("{a}, {b}, {c}, {d}"); // ABC, DEF, ghi, jkl
}
330 名前：デフォルトの名無しさん [2023/04/09(日) 01:56:50.49 ID:awfxf9QU.net]: だとしたらinterior mutabilityでやる話だね
331 名前：デフォルトの名無しさん mailto:sage [2023/04/09(日) 02:19:43.49 ID:fcL4nlHr.net]: use string_cache::DefaultAtom;

fn main() {
let s1 = DefaultAtom::from("example");
let s2 = DefaultAtom::from("example");

assert_eq!(s1, s2);

let s1_ref: &str = &*s1;
let s2_ref: &str = &*s2;

assert_eq!(s1_ref, s2_ref);
}
332 名前：デフォルトの名無しさん mailto:sage [2023/04/09(日) 02:43:31.70 ID:vz6m7/QT.net]: シンボルテーブルか
333 名前：デフォルトの名無しさん [2023/04/09(日) 16:31:56.46 ID:CdUYcfdD.net]: >>323,325
質問者はコレクションを求めてるんだろ
334 名前：デフォルトの名無しさん [2023/04/10(月) 08:37:09.69 ID:DyZbTzV6.net]: Rustのwebフレームワークって2023年現在どれがおすすめですか?
335 名前：デフォルトの名無しさん mailto:sage [2023/04/10(月) 10:35:11.69 ID:wa5pv4tn.net]: そんなに数多くないと思うから10～20個くらい試して何が良かったか教えてよ

オススメ聞くってことはここで挙げられるようなやつ全部試して感想聞かせてくれるってことでしょ
決めるのに好みも入ってていいんだから
なんなら「名前が気にくわない」「アイコンがダサい」くらいの理由でもいい
336 名前：デフォルトの名無しさん mailto:sage [2023/04/10(月) 10:45:58.73 ID:yiM3eSrr.net]: 規模とか構成とかでも良い選択は違うのでなんとも言いにくいな。
比較的に万能で定番なものは actix, axum, rocket あたりだと思うが。
337 名前：デフォルトの名無しさん mailto:sage [2023/04/10(月) 12:38:17.63 ID:GqegRxcS.net]: Tide 使っとけば間違いない
338 名前：デフォルトの名無しさん mailto:sage [2023/04/10(月) 15:48:33.90 ID:4HpjR3/Y.net]: パフォーマンスより、単純明快なwebフレームワークが知りたいな
PythonならFlask的な
どうせDBがボトルネックになるし
339 名前：デフォルトの名無しさん [2023/04/10(月) 18:28:14.17 ID:Mdv85xt7.net]: そういうの自分で調べられない人はもう少しエコシステムが成熟してからRustを検討した方がいいよ
340 名前：デフォルトの名無しさん mailto:sage [2023/04/10(月) 19:05:09.35 ID:sUqOZltz.net]: どうせ○○がボトルネックになるし
↑
こういう発想は大事
細かいところにだけ着目してvtableのコストがどうのとか
クロック数でいくらどうのとか
そういう連中よりは遥かにセンスがある
341 名前：デフォルトの名無しさん mailto:sage [2023/04/10(月) 19:20:23.61 ID:yiM3eSrr.net]: >>334
クラウドだとCPU時間やメモリに課金されるから
「ユーザの体感速度にほんど影響がないからいいや」とはならない。
スループットだけ見てればよい時代は終わった。

ローカルでちょっとした GUI がわりにする程度ならどうでもいいけど……。
342 名前：デフォルトの名無しさん mailto:sage [2023/04/11(火) 23:57:13.30 ID:+2ozf4Lx.net]: ディスパッチの話で負けた負け犬が遠吠えこいてんのか
343 名前：デフォルトの名無しさん [2023/04/26(水) 20:19:48.59 ID:WZHTU1Do.net]: Rustに限った話じゃないけど非線形(条件分岐を少なからず含む)な関数のテスト条件って普通どうやって作るの？
例えばRGB888フォーマットの色1と色2を飽和加算合成する関数を作ったのでテストしたいとする
すべてのパターンをテストすれば確実だが2の24乗もあってあまり現実的ではない
最小値と最大値と線形から非線形に移行する付近のみテストするとか？
344 名前：デフォルトの名無しさん mailto:sage [2023/04/26(水) 20:42:58.19 ID:NF11/Xrv.net]: 境界付近をテストするので良いと思う。
網羅的にテストしたつもりでも実際の問題ってのはどうせ
想定してないところから出てくるもんだから事前に何もかも盛り込むのは無理。
問題が出たときにテストを追加して同じ問題をもう出さない (後退はしない) ようにして
徐々に良くしていくしかない。
345 名前：337 mailto:sage [2023/04/29(土) 21:52:25.06 ID:+xgAqXRk.net]: >>338
あと追加するなら加算のテストくらいかな
0+1=1、1+1=0+C、1+0=1・・・ビット単位ならパターンはそこまで多くないし
ググっても具体的に何をテストすべきかみたいな解説はあまり出てこない気がする
346 名前：デフォルトの名無しさん mailto:sage [2023/05/02(火) 10:56:16.58 ID:j5a6+bQW.net]: スレに人が来なくなったのはGWなのとchatGPTでPG需要減ってきたからか
347 名前：デフォルトの名無しさん [2023/05/02(火) 12:05:52.42 ID:+0ZRIFR4.net]: sudoとsuがRustで書き直される。メモリ安全性向上へ
https://news.yahoo.co.jp/articles/296d15d7c1f7190ff1646f4d52f8df8c56c0e132
348 名前：デフォルトの名無しさん mailto:sage [2023/05/02(火) 12:09:31.43 ID:XVCLDAkP.net]: このままLinuxの公式言語になってしまうのだろうか？
それはそれでちょっと寂しい
349 名前：デフォルトの名無しさん mailto:sage [2023/05/02(火) 12:15:20.08 ID:GEufc0we.net]: へぇ、Rustって知らないところで着実に市民権獲得し始めてるんやな
まぁ確かに“安全性”、“堅牢性”ってのは売りになるわな
350 名前：デフォルトの名無しさん mailto:sage [2023/05/02(火) 12:21:25.01 ID:xcMXGreF.net]: とは言ってもパラダイムが違うものを組み合わせるのは
それはそれで色々としんどいから
新規プロジェクトからということにはなるわな。
あるいはモジュール単位で徐々に……といったところか。
351 名前：デフォルトの名無しさん mailto:sage [2023/05/02(火) 13:10:44.65 ID:SH4oCjNk.net]: 純粋に質問なのですが、Windowsだとユーザ権限プログラムから感知できない全画面確認画面(コード署名表示付き)を
手動クリックすることによって権限昇格するAPIやファイル実行オプションを用いるのですが、
Linuxのsudo、suはそういうOS提供APIの単純ラッパ以外の処理が必要なのですか？
352 名前：デフォルトの名無しさん mailto:sage [2023/05/02(火) 14:14:52.25 ID:kqtJfIHI.net]: >>345さんの祖末なチソチソもっとよーく見たぃナ☆
>>345さん、またみんなの前でチソチソ出してくださいね☆
353 名前：デフォルトの名無しさん mailto:sage [2023/05/02(火) 15:20:08.53 ID:HqctS3p2.net]: Qiitaで調べものをしていたらRustを広めたいというユーザーを
見かけたのですが実のあるRustの記事がありません

ここにいらっしゃるのですか？
354 名前：デフォルトの名無しさん mailto:sage [2023/05/02(火) 16:34:54.41 ID:IqyS7yAG.net]: Rustはアマチュアがいじいじするだけの言語だから
355 名前：デフォルトの名無しさん [2023/05/02(火) 17:29:28.03 ID:DSQza21A.net]: Rustや情報科学みたいなものは、完全に自分の教養のためと思って勉強してるけど・・・・・
いつまで経っても実用の域に届かない
356 名前：デフォルトの名無しさん mailto:sage [2023/05/02(火) 17:34:42.24 ID:KHYt4fkx.net]: R&D関係者と交流があるだけの人ってアマチュア？
357 名前：デフォルトの名無しさん [2023/05/02(火) 17:49:30.32 ID:IqyS7yAG.net]: アマチュアがあーでもないこーでもないと
持て余したヒマでいじくり回した結果
しょうもないポエムを生み出すだけ

この言語そのものというより
この言語を取り巻く状況はずっとこう
358 名前：デフォルトの名無しさん mailto:sage [2023/05/02(火) 19:13:07.37 ID:XhxCeHYa.net]: Linux 6.3.1のtokeiしました

https://i.imgur.com/1xgblDP.png
359 名前：デフォルトの名無しさん mailto:sage [2023/05/02(火) 19:48:58.54 ID:TWDhbUOL.net]: YouTube で有名な雑食系エンジニア・KENTA が、
初心者に推奨するキャリアパスは、Ruby on Rails → Go のみ

Rust, Elixir は普及のキャズムを超えなかった。
オワコン認定した言語は、Scala, PHP

米国年収でも、Rails, AWS Solution Architect が13万ドル

Ruby, Elixir : 9.3 万ドル
Go : 8.9
Rust : 8.7

多くの言語 : 6.5～7

PHP : 5
Dart : 4.4

日本では、バックエンドの求人倍率が数倍で、
フロントが0.5倍と、10倍の開きがある。
フロントは供給過剰で、低価格競争になっている

欲しい人材は、Rails, Linux, Docker, AWS が出来る香具師。
つまり、ウェブサービスを作れる香具師

Railsは、作者のDHH が言うように、バックエンド技術者がフロントも兼ねるから、
バック/フロントの打ち合わせコストが掛からないのが強み

その代わり、あまりCSS を知らないので、デザイン性に欠ける。
Bootstrap, Tailwind などが多い

つまり、これが文系の低学歴でも、簡単に高収入を得られる方法。チート職業。
だから皆、月千円のKENTAの初心者向けRailsサロンへ入る。稼げるから
360 名前：デフォルトの名無しさん mailto:sage [2023/05/02(火) 20:03:17.56 ID:6g8Nsfp3.net]: >>341,345
sudu-rsとsudo(original)のtokeiしました
LOCが違い過ぎて機能的に同等とは思えませんが誰か確認してください
https://i.imgur.com/wqUfNLQ.png
361 名前：デフォルトの名無しさん [2023/05/02(火) 22:59:03.14 ID:3h/NlzQK.net]: >>354
機能的に同等そうかどうかは
テストを比較すればいいよ
362 名前：デフォルトの名無しさん mailto:sage [2023/05/03(水) 00:18:13.49 ID:g1uPDP/x.net]: >>355
なるほどテストを比較よろ
363 名前：デフォルトの名無しさん mailto:sage [2023/05/03(水) 00:24:35.35 ID:BA7Ot0nV.net]: 現時点のCurlからRustの跡形なくなってる

3年前のアナウンス
Memory Safe ‘curl’ for a More Secure Internet - Oct 9, 2020
https://www.memorysafety.org/blog/memory-safe-curl/

言及されてるhyper(-rs)がなくて、C実装になったc-hyper
https://github.com/curl/curl/blob/master/lib/c-hyper.c
Rustlsはそれらしきものが全くない
364 名前：デフォルトの名無しさん mailto:sage [2023/05/03(水) 00:49:48.46 ID:CZOik0F4.net]: >>341
これ別にsudo(sudo.ws)やsu(GNU)がRustに移行しますって発表じゃなくて
GNU grepに対するripgrep的なプロジェクトってことで合ってます？
365 名前：デフォルトの名無しさん mailto:sage [2023/05/03(水) 08:45:46.83 ID:I87taHnB.net]: >>357
HTTPバックエンドとして使えるって話だから元々本体にRustコードは入ってないと思うけど
この辺見ればわかるけど、hyperやrustlsは別途ビルドしてるよ
https://github.com/curl/curl/blob/master/.github/workflows/linux.yml
366 名前：デフォルトの名無しさん mailto:sage [2023/05/03(水) 11:25:57.48 ID:iEII6Ca5.net]: もうChatGPTあるしRustの存在意義がほとんど無くなっちゃったね
367 名前：デフォルトの名無しさん [2023/05/03(水) 12:08:28.90 ID:QeIlVi4X.net]: >>360
どういう関係が？
368 名前：デフォルトの名無しさん [2023/05/03(水) 15:58:21.31 ID:FU/0xIZ5.net]: >>358
移行を目指して開発するということです
369 名前：デフォルトの名無しさん mailto:sage [2023/05/03(水) 17:41:36.60 ID:gBESz1Qj.net]: >>360
Linuxをrustで書き直して
↓
はい、できました
370 名前：デフォルトの名無しさん [2023/05/03(水) 20:37:19.00 ID:C/1gxzck.net]: 数千トークンの単位でしかやり取りできないって知らないんだろうな
371 名前：デフォルトの名無しさん mailto:sage [2023/05/05(金) 20:25:46.02 ID:zl0JqMlo.net]: この手のシステムプログラミング？できる言語って何から始めたら良いんですかね
いきなりRustから入ってもいいのかそれともC言語から始めるべきなのか

シェルスクリプトで作った自作ツールをバイナリ化して動作を早くしたいとかそれくらいしか今は用途ないんですけど
いやでも、既存のツールのソースが読めるようになるから難しくてもまずCをやるべきか…
372 名前：デフォルトの名無しさん mailto:sage [2023/05/05(金) 20:44:06.81 ID:ug2cMp38.net]: >>365
隔離スレに帰れゴミ
373 名前：デフォルトの名無しさん mailto:sage [2023/05/05(金) 21:21:06.18 ID:zl0JqMlo.net]: >>366
ええ…単にRustで検索してたどり着いて書き込んだだけなんだけど
374 名前：デフォルトの名無しさん [2023/05/05(金) 21:21:49.38 ID:ZIYROKTz.net]: >>365
そういう用途ならとりあえずはGoからはじめるといいよ
目的を実現するまでにかかる時間が5倍くらいは違うと思うから

シェルスクリプトも外部ツールをうまく利用してたら実質Cに近い速度で動いてる場合もあるからCやRustで自作したからといって速くなるとは限らないよ
375 名前：デフォルトの名無しさん [2023/05/05(金) 21:25:04.73 ID:ZIYROKTz.net]: Rustを学ぶために事前にCを学んだほうがいいかと言えば全くそんなことはない
376 名前：デフォルトの名無しさん mailto:sage [2023/05/05(金) 21:46:33.98 ID:zl0JqMlo.net]: >>368,369
ありがとうございます

事前にCの知識が不要であれば、既存のツールのソースを読むのに便利くらいな感じなんですかね、Cは
自作スクリプトは最初からOSに入ってるコマンドを組み合わせる形で動いていて
なのでまあ多少早くなればいいなくらいで、後は趣味兼勉強で覚えたいと思ってます

GoについてはRustと双璧で名前が出てきますね
Rustの方が使われてる印象があったんでそっちを検討してたんですけど
GoについてもRustと違いを把握できる程度で調べて、どっちかで検討してみようと思います
377 名前：デフォルトの名無しさん mailto:sage [2023/05/05(金) 23:01:41.02 ID:6VYfhEYJ.net]: >>370
システムプログラミングというのはシステム (OS やそれに近い層) のプログラミングを
想定したもので、システムのドキュメントでの説明やツールキットに C が使われていることはそれなりにある。
アプリケーション層でも C や C++ で書かれたライブラリと結合したいこともたまにはある。
(人気のあるライブラリなら Rust 用のラッパーライブラリが提供されていると思うが。)
そういうことをしたいのなら C を多少は読み書きできないとしんどいこともあるかもね。
そうでないなら C を扱える必要はない。

大きなコンポーネントを組み合わせる程度の使い方の場合は
シェルスクリプトを他の言語に置き換えても性能はほとんど変わらない。
実行時間のほとんどがそのコンポーネント内のコードの実行に費やされることが多いので
自分が書く部分の性能が少しばかり高性能でも全体の実行時間にはそれほど大きくは影響しない。
378 名前：デフォルトの名無しさん mailto:sage [2023/05/05(金) 23:23:10.17 ID:A/rFKldr.net]: >>365
何らかの言語経験があるならいきなりRustで大丈夫だけど
C言語の基礎レベルの知識(ポインタ、スタックとヒープ、ヒープメモリ確保と解放)の有無の差を埋めておくのはよいかもね

>>370
GoはGC(ガベージコレクション)がある言語なのでどうしてもC/C++/Rustとは決定的な違いがあるね
例えばスクリプト言語の高速なライブラリを作るといったような速さや省メモリを追及するならC/C++/Rust
379 名前：デフォルトの名無しさん [2023/05/06(土) 04:59:19.62 ID:cJf94Ar1.net]: C++もGC使えるけどな
380 名前：デフォルトの名無しさん mailto:sage [2023/05/06(土) 05:26:55.29 ID:ZbAqT6nN.net]: 言語システムとしてGCを必須とする言語との区別がつかないアホか
381 名前：デフォルトの名無しさん mailto:sage [2023/05/06(土) 06:16:27.47 ID:6JUtkYO4.net]: C++マネージ拡張
プログラミング言語
382 名前：デフォルトの名無しさん [2023/05/06(土) 06:21:14.86 ID:cJf94Ar1.net]: 文字列は動的なアロケーションが必要な場合があるだろ？
じゃあ、文字列を動的配列に入れる場合どうなる？
コピーなどは動的配列のメンバで行われるだろ？
C++は、コンテナが使用するメモリーはGC、文字列のメモリー確保はマイアロケータ、なんてことが出来る
動的配列のメンバが文字列のメンバにマイアロケータを使わせるようになるってことだぞ
383 名前：デフォルトの名無しさん [2023/05/06(土) 06:22:08.86 ID:cJf94Ar1.net]: >>375
標準C++で使えるぞ
384 名前：デフォルトの名無しさん mailto:sage [2023/05/06(土) 06:47:02.36 ID:BGrqS5mo.net]: GCが不可欠な言語とライブラリでGCする話は全く異なり関係ない
385 名前：デフォルトの名無しさん mailto:sage [2023/05/08(月) 01:15:08.03 ID:4H9Xfh5A.net]: パーサジェネレータっていろいろあるけど今だと何が良いんだ？
パースターゲットはgas風のアセンブラリスト。取り扱いは今風な方が嬉しい
386 名前：デフォルトの名無しさん mailto:sage [2023/05/08(月) 02:27:34.26 ID:6qkGyJAY.net]: 文法にも種類があって文法と解析アルゴリズムの組み合わせ次第では定義不可能なこともある。
具体的な文法を検証しないとどれを使うのが妥当かは言えない。
387 名前：デフォルトの名無しさん mailto:sage [2023/05/08(月) 06:50:07.08 ID:4H9Xfh5A.net]: >>380
gas系のIA-32/AMD64アセンブラリスト
gccやclang等が吐くものを想定している
388 名前：デフォルトの名無しさん mailto:sage [2023/05/08(月) 08:35:46.67 ID:Kh0HUP9F.net]: nomでいいんじゃないかな
389 名前：デフォルトの名無しさん mailto:sage [2023/05/08(月) 10:53:50.62 ID:6qkGyJAY.net]: gas の文法なら最も素朴な文法カテゴリである LL 文法の範疇に収まるはずなので
PEG 系のパーサコンビネータライブラリが適していると思う。

でも LL 文法は再帰下降で書いてもたいした手間ではないので
凝ったツール (またはライブラリ) を導入しても劇的に楽になるってほどでもない。
コードの見通しが良くはなるかなぁ……。
390 名前：デフォルトの名無しさん mailto:sage [2023/05/08(月) 20:28:58.82 ID:4H9Xfh5A.net]: >>383
ググるとpegってクレートが引っかかるけどこれでいいのだろうか
というかgas系の文でもISAによって使えないパーサジェネレータとかあるのかな
391 名前：デフォルトの名無しさん mailto:sage [2023/05/12(金) 21:22:48.00 ID:rQCSntAC.net]: わび、さび
が分かる日本人↓
392 名前：デフォルトの名無しさん mailto:sage [2023/05/13(土) 06:51:26.85 ID:7jqHwrc+.net]: 滑ってるぞ
393 名前：デフォルトの名無しさん mailto:sage [2023/05/20(土) 16:33:08.50 ID:w2uVrX5O.net]: --emit asmをつけるとアセンブラリストを出力できるけどstaticlibやrlibをつけても一部の関数が
出力されないように見える。例えばpanic!を呼ぶとうちの環境(1.69 x64 MSVC)では
callq _ZN4core9panicking5panic17h3445eebb4065373cE
が生成されるけどリスト中にこのラベルはない。マングリングされているけど実体はおそらく
ttps://doc.rust-lang.org/core/panicking/fn.panic.html
と思われるけどこのあたりのアセンブラリストを得るにはどうしたらいいんだろ？
394 名前：デフォルトの名無しさん [2023/05/20(土) 18:33:58.33 ID:Sx1e1bwr.net]: インライン化されてるだけでは？
panicだと分岐とpanicハンドラが出てくるから分からないってことはないと思うんだが
最小再現コードをgodboltにても上げてみては？
395 名前：デフォルトの名無しさん mailto:sage [2023/05/20(土) 19:27:31.19 ID:w2uVrX5O.net]: Compiler Explorerの使い方がよくわかっていないので変だったらスマン
ttps://godbolt.org/z/nxz95xejr
こんな感じ。明示的にrip相対になっているのでコンパイラはLinux版と思われる
core::panicking::panicを呼び出していることはわかるがその中身は出てこない
396 名前：デフォルトの名無しさん [2023/05/20(土) 23:56:16.81 ID:5KQ3IHQ1.net]: >>389
no_stdなライブラリだと基本的に使う側がpanic_handlerを定義するので実体なくてもしょうがないような
no_stdをコメントアウトして表示される結果と比べてみれば？
397 名前：デフォルトの名無しさん mailto:sage [2023/05/21(日) 00:24:43.05 ID:bfWEYksH.net]: >>390
[no_std]を外すと
callq *std::panicking::begin_panic::{{closure}}@GOTPCREL(%rip)
とかになるみたい。ただしその中で呼んでいるラベルすべてが含まれるわけではない模様

例えば
#[panic_handler]
fn panic(_panic: &PanicInfo<'_>) -> ! {
loop {};
}
などとパニックハンドラを足してもcall先のラベルがrust_begin_unwind(上記panic関数の実体)になったりはせず
core::panicking::panicが呼ばれるっぽい。そこからユーザー定義のハンドラを呼び出す隠れたコードがあるはず
ついでにabort=unwindの場合はpanic発生時にrust_begin_unwindが呼ばれるはずだけどその辺も隠れているように見える
398 名前：デフォルトの名無しさん mailto:sage [2023/05/23(火) 16:03:35.67 ID:Jpx1nTNj.net]: 初心者の相談ここでいい？
RustやってみようとWin ＋VisualStudioCodeに　
RustAn
399 名前：alyzer と　CodeLLDBを入れ PythonもPath付きで入れた cargo newも走った なのにデバッガが使えない Hello Worldにブレイクポイント一つ置いただけなのに F5押したら帰ってこない　もう一回押したら Debugは既に開始しています　別のインスタンスを開始しますか？ なんかワクチンが悪さしてるかと思ってESETも30分止めてみたけれど同じ 誰もこんなところで躓いてないのになんでかな，，， []: [ここ壊れてます]
400 名前：デフォルトの名無しさん mailto:sage [2023/05/23(火) 17:27:20.12 ID:Jpx1nTNj.net]: デバッグなしの実行だと　Hello, world!　が普通にターミナルに出力されるのに
なんで　デバッガ動かないんだか，，，
401 名前：デフォルトの名無しさん mailto:sage [2023/05/23(火) 17:30:06.95 ID:QaZRkUju.net]: >>392
下ペインの出力タブで何かエラーメッセージ出てないか確認しなさい
402 名前：デフォルトの名無しさん mailto:sage [2023/05/23(火) 18:02:22.62 ID:QWj3a5zv.net]: >>392
launch.jsonを生成してみれば？
403 名前：デフォルトの名無しさん mailto:sage [2023/05/23(火) 18:04:39.75 ID:Jpx1nTNj.net]: へい

コード側に表示されている
Run/DebugのうちのDebugを押しても
ターミナル側にはPS C:\Users\xxx\xxx\hello >　
みたいにpathが見えているままで　何も追加表示されない

launch jsonは自動的に作られている
コールスタック表示には　プロセスについて　run ｘｘと表示が出て
Debug押すたびに　run xx 2とかプロセスが増えていくだけ
404 名前：デフォルトの名無しさん mailto:sage [2023/05/23(火) 18:11:32.54 ID:Jpx1nTNj.net]: "configurations": [
{ "type": "lldb", "request": "launch",
"name": "Debug executable 'hello'",
"cargo": { "args": [ "build", "--bin=hello", "--package=hello" ],
"filter": { "name": "hello", "kind": "bin" } },
"args": [　], "cwd": "${workspaceFolder}" },
{ "type": "lldb", "request": "launch",
"name": "Debug unit tests in executable 'hello'",
"cargo": { "args": [ "test", "--no-run", "--bin=hello", "--package=hello" ],
"filter": { "name": "hello", "kind": "bin" } },
"args": [　], "cwd": "${workspaceFolder}" } ]　}
誘導に乗るままに自動生成されたlaunch json なんかおかしいのかなこれ
405 名前：デフォルトの名無しさん mailto:sage [2023/05/23(火) 18:14:16.03 ID:QaZRkUju.net]: >>396
出力タブってそれじゃなくて[表示(V)]→[出力(O)]で出るやつね
右上のセレクタで関係ありそうなやつを片っ端から確認
406 名前：デフォルトの名無しさん mailto:sage [2023/05/23(火) 18:26:24.50 ID:Jpx1nTNj.net]: へい
今日はもうPCから離れてしまったので
(お仕事の時間
明日の午後　出力をここに転記してみます
よろしくお願いします
407 名前：デフォルトの名無しさん mailto:sage [2023/05/24(水) 14:06:06.92 ID:r6J0oqAK.net]: 昨日の続きです　出力>Debugdセレクタで
Launching debug configuration:
{
"type": "lldb",
"request": "launch",
"name": "run hello",
"program": "C:\\Users\\ochia\\Downloads\\RustTry\\hello\\target\\debug\\hello.exe",
"args": [],
"cwd": "C:\\Users\\ochia\\Downloads\\RustTry\\hello",
"sourceMap": {},
"sourceLanguages": [
"rust"
],
"env": {
"RUST_BACKTRACE": "short",　以下略
408 名前：デフォルトの名無しさん mailto:sage [2023/05/24(水) 14:08:03.26 ID:r6J0oqAK.net]: ＞LLDBセレクタ
relativePathBase: 'c:\\Users\\xxx\\Downloads\\xxx\\hello',
_adapterSettings: {
displayFormat: 'auto',
showDisassembly: 'auto',
dereferencePointers: true,
suppressMissingSourceFiles: true,
ev
409 名前：aluationTimeout: 5, consoleMode: 'commands', sourceLanguages: null, terminalPromptClear: null, evaluateForHovers: true, commandCompletions: true, reproducer: false } } []: [ここ壊れてます]
410 名前：デフォルトの名無しさん mailto:sage [2023/05/24(水) 14:09:28.83 ID:r6J0oqAK.net]: Resolved debug configuration: {
type: 'lldb',
request: 'launch',
name: 'run hello',
program: 'C:\\Users\\xxx\\Downloads\\xxx\\hello\\target\\debug\\hello.exe',
args: [],
cwd: 'C:\\Users\\xxx\\Downloads\\xxx\\hello',
sourceMap: {},
sourceLanguages: [ 'rust' ],
env: {
RUST_BACKTRACE: 'short', 以下略
411 名前：デフォルトの名無しさん mailto:sage [2023/05/24(水) 14:17:47.42 ID:r6J0oqAK.net]: launch jsonの内容をなぞっているように見えますけれど　どこが問題なんですかね
412 名前：デフォルトの名無しさん mailto:sage [2023/05/24(水) 19:14:40.08 ID:P3DEOWau.net]: その後は何もないの？
413 名前：デフォルトの名無しさん [2023/05/27(土) 20:30:35.69 ID:MtF41Uws.net]: 生行列をallocするベストプラクティスを教えてください
doube **a=malloc(sizeof(double*)*100);
for (i=0; i < 100; i++) {
a[i]=malloc(sizeof(double)*1000);
}

//a[i][j]でアクセス

みたいなやつです

条件としてC/C++より遅くはならないこと
かつある程度安全であることです

普通にやVecで良い」ならそれで行きます
414 名前：デフォルトの名無しさん mailto:sage [2023/05/27(土) 21:43:25.68 ID:gMKf+OGS.net]: 何に使うかによります
415 名前：デフォルトの名無しさん mailto:sage [2023/05/27(土) 22:55:13.87 ID:A+Fg27pW.net]: >>405
とりあえずVecで作るので良いよ
性能は別途検証しましょう

bound checkが必要になる使い方か
auto vectorizationが働く使い方か
などが差が出るポイント
416 名前：デフォルトの名無しさん [2023/05/27(土) 22:56:24.11 ID:3vAeCl3M.net]: ドキュメントを調べたらRawVecが良さそうなんですが
まだ安定版で早い模様
https://github.com/rust-lang/rust/blob/master/library/alloc/src/raw_vec.rs

うーむ
417 名前：デフォルトの名無しさん mailto:sage [2023/05/27(土) 23:03:14.16 ID:A+Fg27pW.net]: Vecの中身がRawVecなんだけど
RawVecを直接使ったほうが速くなるような使い方なのかな？
418 名前：デフォルトの名無しさん [2023/05/27(土) 23:15:57.87 ID:3vAeCl3M.net]: 数万要素の行列演算なので極力余計な処理はして欲しくない感じかな
419 名前：デフォルトの名無しさん mailto:sage [2023/05/27(土) 23:38:53.11 ID:vyw6vGV+.net]: >>405
Cのコード見るにそんな速度にこだわり無さそうだけどｗ
420 名前：デフォルトの名無しさん mailto:sage [2023/05/28(日) 00:21:22.19 ID:zeE7KVbL.net]: 今のご時世に行列計算の速度を気にするならSIMD使えでFAじゃね？
421 名前：デフォルトの名無しさん [2023/05/28(日) 00:34:27.16 ID:TDETqQQX.net]: 今の時代は普通にGPU使うのがベストだよ
ただしクラウドでやるとなると金がかかる
今こそCPUで限界まで性能を出し切ることが「男の夢」じゃあないか
マルチスレッド、ベクトル命令、メモリのプリフェッチを駆使して
GPUなしでどの程度性能を引き出せるか？という実験をやっているところ
Cなら普通に書けるのだけどRustの方が色々ライブラリも豊富だから
アプリケーション化するとき楽かなあと思った次第
422 名前：デフォルトの名無しさん mailto:sage [2023/05/28(日) 00:34:40.65 ID:druolHmT.net]: 詳しくないけどBLAS/LAPACKっていうの使えばいいんじゃないすか
そもそも行列計算するつもりなのかすら明言されていませんが
423 名前：デフォルトの名無しさん mailto:sage [2023/05/28(日) 00:42:17.84 ID:A/FYSLVX.net]: GPUは環境依存が激しいからなぁ。自分しか計算しないならそれでもかまわないかもしれないが
不特定の環境で動かすソフト用には使いづらい
424 名前：デフォルトの名無しさん [2023/05/28(日) 02:13:41.27 ID:TDETqQQX.net]: とりあえず行列を適当なブロックに区切ってそれをスレッドで計算、ブロックは転置したりしてキャッシュメモリに乗るように調整する
それを最終的にreduceする
こうすればマルチノードでも実行可能

>>414
それも使ってみるよ
numpyは内部でそれを使ってるらしいけどね
ただライブラリ使ってハイ終わりってのは味気ない
そしてやってることは俺が上に書いた技術以上のことは現状ない
425 名前：デフォルトの名無しさん [2023/05/28(日) 18:01:21.95 ID:ouzH40Jy.net]: 「The Rust Programming Language 日本語版」の日本語訳が微妙すぎる。自分は英語が苦手なのでできるだけ日本語で分かりやすくRustの使用について書いてあるドキュメントが読みたい。
だれか日本語的にもう少しちゃんとしたRustのドキュメントを作ってくれないだろうか？
426 名前：デフォルトの名無しさん [2023/05/28(日) 18:48:08.28 ID:zw3BCEgM.net]: >>417
しっかり学びたいならオライリー本がいいよ
427 名前：デフォルトの名無しさん mailto:sage [2023/05/29(月) 09:19:07.96 ID:THthJ00e.net]: 本家に追従できていないのは不備だがそれは単なるリソース不足だから訳者が増えないとどうしようもないし、
文章表現の中に学習に障害になるほどおかしいようなところがあるとは思えないので
分かり難いと感じる箇所は本当に翻訳由来なのか？と思う。
428 名前：デフォルトの名無しさん mailto:sage [2023/05/29(月) 11:00:00.74 ID:0py62bgw.net]: >>417
日本語訳にそのような問題はない
429 名前：デフォルトの名無しさん mailto:sage [2023/05/29(月) 11:14:03.62 ID:Ukb2D43H.net]: せめて具体的にどの部分かくらいは言ってくれないと
翻訳の問題なのか原文自体が417に合わなかったのかも分からんしなぁ
430 名前：デフォルトの名無しさん [2023/05/29(月) 11:31:04.88 ID:FT7slsJB.net]: そんなレベルじゃないだろ
あの日本語訳を普通に読めるやつって普段どんな文章読んでんだよ
431 名前：デフォルトの名無しさん mailto:sage [2023/05/29(月) 11:43:48.21 ID:NzRLe/wE.net]: >>420
前にずっと翻訳でゴタゴタしてたのはもう解決してたんだな
知らなかった
432 名前：デフォルトの名無しさん mailto:sage [2023/05/29(月) 11:49:14.32 ID:ZdZrmK0s.net]: 日本語訳は原文読むための補助くらいの感覚がいいと思う
std含むライブラリのドキュメントは基本的に全部英語だから英語苦手とか言ってられない
MDNみたいに片っ端から翻訳されるならいいけどそんなリソースないでしょ
433 名前：デフォルトの名無しさん [2023/05/29(月) 13:13:50.43 ID:35XvpH6w.net]: The Book以外の入門書や入門方法を求めたり提案したりするのは構わないけど
The Book日本語訳自体はこのスレでは扱わないことになってるので
日本語訳の個別具体的な問題点についての話はGithubなど別の場所でどうぞ
434 名前：デフォルトの名無しさん mailto:sage [2023/05/29(月) 14:20:40.96 ID:iwZJC5k1.net]: 所有権の複製ですか？( ･`ω･´)
435 名前：デフォルトの名無しさん [2023/05/29(月) 15:10:37.76 ID:O87suSPk.net]: ぶっちゃけ非公式日本語訳より機械翻訳の方がずっとわかりやすいよ
ChatGPTのようにコンテキストを理解してくれるやつなら機械翻訳特有の不自然な言い回しはあっても誤訳は遥かに少ないから
436 名前：デフォルトの名無しさん mailto:sage [2023/05/29(月) 16:08:06.98 ID:THthJ00e.net]: デタラメをハキハキとしゃべる人のほうが好人物に思われやすい。
人間は自然さ (流暢さ) を正しさと誤解するバグがある。
そのバグを突かれてるだけ。
437 名前：デフォルトの名無しさん mailto:sage [2023/05/29(月) 16:51:09.81 ID:wn8XGwh5.net]: >>417
こんな感じだから、他人に期待するだけ無駄だよ。
自分でやるか、金を出してやらせるか。どちらも嫌なら諦めな。
438 名前：デフォルトの名無しさん [2023/05/29(月) 17:04:22.45 ID:4yvEjXWf.net]: いまだに1ページ目から誤訳盛り沢山
リソース不足というより能力不足とやる気不足
439 名前：デフォルトの名無しさん [2023/05/29(月) 18:20:04.93 ID:Qw0OFueK.net]: >>430
能力のある人間が英語が読めないやつのためだけにわざわざ時間を割いてタダ働きで非公式な翻訳に参加する理由がない

英語が苦手な人による英語が苦手な人のためのもの
過度な期待は良くない
440 名前：デフォルトの名無しさん mailto:sage [2023/05/29(月) 20:58:34.38 ID:14JJPgZq.net]: 誤訳でも元の英語が大体思い浮かぶから問題なし
441 名前：デフォルトの名無しさん [2023/05/29(月) 21:18:54.45 ID:ZWlF7ESV.net]: そうして生まれたのが複製おじさんや仮の所有権おじさん
442 名前：デフォルトの名無しさん [2023/05/29(月) 21:36:32.72 ID:fyU8ZoqD.net]: >>432
元の英語が大体思い浮かぶようなやつが
誤訳だらけの日本語訳なんて読むわけないやん
443 名前：デフォルトの名無しさん [2023/05/29(月) 22:51:14.31 ID:/vmU8chJ.net]: アハハバカね！嘘つくならもっとマシな嘘ついてよね･･･
444 名前：デフォルトの名無しさん mailto:sage [2023/05/30(火) 00:04:02.24 ID:/771ql8l.net]: 明瞭に「誤訳」だとわかるくらいの能力があるなら issue 立てるくらいしてくれよ。
445 名前：デフォルトの名無しさん mailto:sage [2023/05/30(火) 11:47:11.26 ID:0Tfb139m.net]: このスレも日本語を禁止して英語だけにした方が話が早くね？
446 名前：デフォルトの名無しさん mailto:sage [2023/05/30(火) 13:54:02.69 ID:m0YhPkee.net]: Good Idea desune～
447 名前：デフォルトの名無しさん mailto:sage [2023/05/30(火) 21:02:05.18 ID:H+AZ7xQ9.net]: 可変変数という摩訶不思議な用語・・・・・
448 名前：デフォルトの名無しさん [2023/05/30(火) 21:41:45.99 ID:6nHNYy1Z.net]: おっさんになって覚えがわるいのか言語のせいなのかわからんがRust難しいなおい…
449 名前：デフォルトの名無しさん mailto:sage [2023/05/30(火) 21:44:11.50 ID:wiPQkzC+.net]: >>436
issue も pr も放置されてる現実を見ような
450 名前：デフォルトの名無しさん [2023/05/31(水) 12:34:12.39 ID:mN2Hu6K3.net]: ハードウェア依存のライブラリってのはパッケージ管理ソフトが扱いづらいんだよ。
cargoがそういうの取り込むとは思えん。
451 名前：デフォルトの名無しさん mailto:sage [2023/05/31(水) 21:01:36.14 ID:YdF423Zw.net]: >>440
どうだろ。それは知識背景によると思う。
最初に学ぶ言語なら Rust はしんどいと思う。
ウェブ系でアプリケーションレイヤしか触ってないみたいな経歴でも Rust は異質かも？

C++ を充分に習得してるくらいなら Rust はそんなにハードルは高くないと思う。
まあ隅々まで理解しようと思うとなんだって大変だが及第点レベルまではドキュメントを読めば普通にわかる。
Rust の型システムは ML 系言語で実績があるものだからその感覚で使えるし、
唯一の面倒なところはライフタイムの管理くらいじゃないかなぁ。

そのライフタイムにしたところで参照より先にオブジェクトの寿命が終わったらダメという当たり前の根本ルールを
成立させられるように考えたら詳細を知らんでも自然に出来そう。
452 名前：デフォルトの名無しさん mailto:sage [2023/05/31(水) 23:09:20.99 ID:wcJUGwzN.net]: >>442
xargoはもうチェックした？
見当違いだったらすまね
453 名前：デフォルトの名無しさん mailto:sage [2023/06/02(金) 15:23:50.48 ID:xBaj60Ia.net]: >>443
用途次第でもあるんじゃね
自分なんて豪華なC程度にしか使ってなくてトレイトとか理解できていない
454 名前：デフォルトの名無しさん mailto:sage [2023/06/02(金) 16:09:01.15 ID:IDHD031H.net]: >>445
C++ のコンセプトなんかだと無ければ無くてもなんとかなるが
Rust のトレイトは理解できてないとコンパイルが通るものを書くことすら難しくない？
455 名前：デフォルトの名無しさん mailto:sage [2023/06/02(金) 19:09:06.58 ID:iTDmv0FSX]: Rustって流行ってんですか。Rustでの仕事がたくさんあるんですか。
456 名前：デフォルトの名無しさん mailto:sage [2023/06/03(土) 20:44:16.65 ID:oycqQ//J.net]: >>446
簡単なプログラムだと自分で書く範囲でトレイトで抽象化するのを避けると意外と避けたまま済んじゃうんだよね。
457 名前：デフォルトの名無しさん mailto:sage [2023/06/03(土) 23:52:21.19 ID:JeZxIQ3D.net]: 新しい型を作らない程度の使い方だとトレイトの理解が不
458 名前：十分でも意外と何とかなっちゃうかも？ []: [ここ壊れてます]
459 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 08:41:55.61 ID:rt4nzg3U.net]: みんなRust使って何開発してるの？
一通り勉強したけど用途が今の俺にはあまり縁が無い事に気付いた

普通のアプリならGC走って少しレスポンス遅い時があっても問題無い
Webフレームワークで早いっていっても色んな機能が無いだけ
あれもこれもそれもとフルスタックなら既存言語ので良い

結局仕事として使ったのってセンサー系だけ
確かにIoTセンサーには向いてると思った
460 名前：デフォルトの名無しさん [2023/06/04(日) 09:02:25.58 ID:QzSyb99b.net]: 毎年の調査結果にも出てるように
Rustを使っているのが多いのはWeb
低レベルhyperの上のフレームワーク本命axumが熱い
461 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 09:11:57.71 ID:rt4nzg3U.net]: やっぱりWebなん？

でもWebシステムだとアレコレソレって色々必要じゃん
足りてる？
言語云々じゃ無くてミドルウェア
462 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 09:19:10.72 ID:MHoxWKtY.net]: 今どきのウェブはクラウドに載ってることが多い。
CPU やメモリを使った分だけコストがかかるのでレスポンスタイムが問題なくても
リソース消費量を削減すれば大幅なコスト削減が見込める。

ライブラリはなんだかんだでそこそこ充実してるし、
むしろ何か足りないものってある？
具体的にこれが足りないって言える？
463 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 09:34:57.16 ID:rt4nzg3U.net]: そこまでガッツリとRustでWeb開発して無いから聞いてる感じかな

例えばASP.NET系でAzureAD認証だと設定しとけば勝手に認証機能付く
それこそアクセストークンがどうだのリフレッシュトークンがどうだの開発者は気にしない
勝手に内部でアクセストークンが期限切れならリフレッシュトークンで再取得して処理する
リフレッシュトークンが期限切れでも勝手に認証ページ飛んで認証したら続きから処理する

そういうミドルウェアあるんかな？
アレもコレも実装しなきゃってのは充実してない
C#ならNugetでライブラリ読み込んで設定用の数行記述したらそれで終わり
コレが充実
464 名前：デフォルトの名無しさん [2023/06/04(日) 09:59:54.28 ID:6x+rjW9P.net]: そういうのはない
でも俺もwebで使ってる
465 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 10:02:25.33 ID:QzSyb99b.net]: ASP.NETに全く興味ないので知らないが
そこまでやりたいことがはっきりしてるなら自分で調べればいいだけではないのか？
何をしようとしたが何ができなくて困っているのかをはっきりさせよ
466 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 10:08:15.10 ID:rt4nzg3U.net]: >>456
いやRustはWebには向いてないって思ってたから調べてさえいないよ
そして試してもいないから困ってもいない

最初に質問したように俺の感覚ではIoTとかみたいな変なタイミングでGCしちゃってみたいなのは困る場面ぐらいしか用途は無いと思ってた
だから何に使ってるのかを聞いた
コレが俺の知りたい事で既に書いてる

そこでWebで使ってると返ってきたから突っ込んで聞いてみただけよ
でもってやっぱり無理矢理使ってるだけって印象を更に深めた結果になってる
467 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 10:08:26.66 ID:M4a45GKO.net]: そりゃAzureADとかやりたいならC#で良くてわざわざRust使うこともないよ
でもWebのすべてがそういった要件を必要とするわけでもないし、Rustが向いてるとこに使えばいいってだけ
自分の分野で向いてるとこがないって判断ならそれでいいと思うけど
468 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 10:10:46.55 ID:rt4nzg3U.net]: >>458
それはその通り
規模とか使う場所によるわな

それこそルーターに組み込む管理画面のWebページ程度ならRustのWebで良いわな
今でもPHPとかで動いてるわけだし
469 名前：デフォルトの名無しさん [2023/06/04(日) 10:12:15.45 ID:E551jt0y.net]: 俺は実用のコードを専らC#で書いていて、コンピューターサイエンスやRustの言語は単なる修行だと思って学習してるんだけどさ
10年ぐらい前に廃れたような構造でWebアプリを作ろうとする人を見ると、「年をとっても学習を止めちゃだめだ」と改めて感じたね
470 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 10:13:17.36 ID:rt4nzg3U.net]: ちなみに認証だけならRustでもあるぞ
本当に認証するだけで期限切れがどうとかリフレッシュトークンがどうとかは自分で書く感じ

最低限のライブラリは一応あるけどミドルウェアにはなってないって感じ
471 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 10:15:03.74 ID:QzSyb99b.net]: >>457
むしろWeb向き
クラウド含めたサーバは今はWebベースであり
CPUコストメモリコストが言語により数倍変わってくる
472 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 10:17:45.38 ID:M4a45GKO.net]: あとはWASMも結構多いかもね
Amazon Prime Videoとかディズニーの動画配信はRustで書いてたはず
473 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 10:18:49.32 ID:rt4nzg3U.net]: >>460
そこは難しいんじゃね

開発者の問題ってより経営者の問題
新しい技術は良いけど補償出来るの？って感じやん
他社での実績は？ノウハウは？トラブった時に解決出来る？って感じ

企業がシステムに望むのは安定稼働
なので数年前から10年前の技術が現在の主流になる
実績があってノウハウがあって技術持った人が外部にも多いから求人も楽でコンサルしてくれる所も有る

こういう要素無いと稟議通らないでしょ
474 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 10:20:54.57 ID:rt4nzg3U.net]: >>462
そこは思うわ
要はコスパが良いんやな
金が有れば確かにクラウド出水平分散出来るがって事やな
475 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 10:28:10.92 ID:xOmzDhxR.net]: 複おじ共々隔離スレにお帰りくださいませ
476 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 10:29:49.43 ID:MHoxWKtY.net]: 実行中のプロセスを実行中のままで別のサーバに移動するみたいなことも出来るしな。
負荷分散とか CDN みたいなことを考えたら WASM の利用価値は高いと思う。

ただ、逆に言えば大規模にクラウドを活用するという場合でないのなら
必要そうなものが最初から載ってるフレームワークが楽というのは確かにそう。
既存のシステムがあるなら既存のシステムでやればいい。

そうでないときが有るから新しいシステムが発明されるわけなんで。
477 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 10:29:57.16 ID:rt4nzg3U.net]: >>462
これビューエンジンは何使うの？
調べてみたけど貧相なテンプレート機能しかない感じだけどマジ？

Razorみたいにガッツリ中でコーディング出来ないの？
それともJavaScript系の何か使うの？
もしかしてコーディング量で言えばRustの方が少なくてJS書く方が多い？
マジ？
478 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 10:31:29.87 ID:rt4nzg3U.net]: >>467
動かしたまま別サーバーに移動ってAzureやらAWSじゃ普通に出来るやんw
479 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 11:27:05.07 ID:IpWrAX+2.net]: 画面周りなんかHTMLで書いた方がだいぶ楽だろ。
480 名前：デフォルトの名無しさん [2023/06/04(日) 11:45:54.52 ID:2fzIybDH.net]: 延々と自演してて草
481 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 12:12:07.87 ID:rt4nzg3U.net]: >>470
これはただの馬鹿w
482 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 12:29:26.42 ID:ckCJmvWc.net]: Rustってlinuxコマンドのリプレースを作るための言語だろ
483 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 12:33:51.42 ID:+vxIFgp1.net]: いつからそんな地位を？w
484 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 12:54:38.29 ID:yBN53eMB.net]: 個人開発で技術力高いならコスト削減の効果があるが
エンタープライズは人件費の方が高いわけでコスト削減にそもそもならない
AWSとかマンパワーのある企業なら別だけど

このことをわかってるから、Web系企業は普通Rustを採用しない

基本はC、C++の代替言語だね
ランタイムが薄
485 名前：くてシステムプログラミング向け そもそもWebサーバーをCで普通書かないから同様にRustも向いてないということになる IT土方向け言語じゃなくてOS開発とか一部のエリート開発者向け言語 []: [ここ壊れてます]
486 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 12:56:42.06 ID:rt4nzg3U.net]: つまりRustでWeb云々言ってる奴は小規模開発の経験しか無い土方って訳か
そりゃ意見が合わん訳だ
487 名前：デフォルトの名無しさん [2023/06/04(日) 13:04:09.42 ID:S8P2kIF5.net]: Rustって戦争の準備じゃないの？
サイバー攻撃に備えましょうって事とか
爆弾搭載したドローン制御するのにとか
488 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 13:06:29.56 ID:QZNMuBNC.net]: RustでWebっていうとCloudflareみたいにHTTP直接扱うようなのも多いしな
PHPでWebアプリ、みたいな層はターゲットではないと思う
489 名前：デフォルトの名無しさん [2023/06/04(日) 13:14:25.68 ID:Yc44DpOp.net]: >>475
> そもそもWebサーバーをCで普通書かないから
> 同様にRustも向いてないということになる

いえいえ
WebサーバーはこれまでCで書かれてきました
apacheもnginxもC言語で書かれています
Rustが最適な分野です

>>476
逆です
490 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 13:18:05.37 ID:rt4nzg3U.net]: >>479
いや言いたい事ってそういう事じゃ無いと思うよw
そこが分かってないのは技術力が無い証拠
491 名前：デフォルトの名無しさん [2023/06/04(日) 13:28:02.69 ID:Yc44DpOp.net]: >>480
CDNやクラウドなど含めてWebサーバーシステムの新たなものはRust製
Rustの世界的な利用調査結果からみてもWeb方面での利用が多い
この分野で現在プログラミング言語のうち最も適しているのはRust
492 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 13:38:27.69 ID:M4a45GKO.net]: Webにも低レイヤ（HTTP3とかSSLみたいなライブラリ）から高レイヤ（Railsで作るようなWebアプリ）まであって
まとめてWebっていうから話が合わないんだろうね
高レイヤしかやってない人はそもそも低レイヤの存在自体知らなかったりするし
Rustに向いてるのは低レイヤ側で、Railsの代わりに使えるなんて言う人はいないんじゃないかな
493 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 13:39:46.54 ID:R98I/Q0o.net]: 実際ウェブアプリを速攻で作ってみるというなら
Railsは何でもライブラリやドキュメントが揃ってるから楽

規模が大きくなるとRubyのせいで辛いことが増えてくるけど
最初から高度なこと目指してない人には
Rustから始めるのは現状では立ち上がりの苦労が多いとは思う
494 名前：デフォルトの名無しさん [2023/06/04(日) 13:46:22.68 ID:wTbdEHgi.net]: 俺はいわゆるwebアプリ作ってるよ
最近は重厚なフレームワークは避けられるでしょ
495 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 13:58:39.33 ID:s0MiwY6r.net]: 高レイヤwebは形式上プログラミング言語を使っただけのお絵描きや職人芸みたいなものであって、Rustユーザーが言うプログラミングとはかなり異なる世界
496 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 13:59:58.35 ID:YjKn3ZKa.net]: Webブラウザサイドで重い計算処理はRustで書いてWasmにやらせている
関連するUIやviewもWasmから
497 名前：デフォルトの名無しさん [2023/06/04(日) 15:22:57.88 ID:6x+rjW9P.net]: 楽だという理由でwebで使っているよ
498 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 15:26:41.80 ID:rt4nzg3U.net]: >>487
どういう部分が楽だって聞いても良い？
更に言えば同じ部分が他言語ではこういう感じで面倒的な話とか
499 名前：デフォルトの名無しさん [2023/06/04(日) 15:49:15.47 ID:6x+rjW9P.net]: 平たくいうと品質を保つのが楽
スクリプト言語は作るのは楽だけど維持するのが苦痛すぎ
500 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 16:05:09.85 ID:rt4nzg3U.net]: それってJavaとかC#でも良くね？
Rustである意味はないよね
501 名前：デフォルトの名無しさん [2023/06/04(日) 16:06:21.66 ID:6x+rjW9P.net]: なぜそう思うの？
502 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 16:14:24.49 ID:JwBn0wcZ.net]: Rustを活用できないクソ雑魚が使わない理由の正当化に必死っすな
503 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 16:22:16.38 ID:rt4nzg3U.net]: >>491
要はスクリプト言語を排除出来れば良い訳じゃん
Rustじゃ無くても出来るよねって話
504 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 16:23:34.73 ID:rt4nzg3U.net]: >>492
今のところ“活用”出来てる例は出てないけど？
“使用”は出来るって話だよね
505 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 16:26:51.47 ID:rt4nzg3U.net]: ちなみに俺のそもそもの質問は何に使ってるのかって話なんだから“活用”出来る場所を教えてくれよ

OSやら低レイヤWeb以外でさ
506 名前：デフォルトの名無しさん [2023/06/04(日) 16:40:10.04 ID:ydxF9Sga.net]: RustのWebアプリ個人的にrailsより遥かにわかりやすいと思うんだけど
507 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 16:46:31.48 ID:rt4nzg3U.net]: シンプルな機能しか無いからだろ
508 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 16:46:36.28 ID:3zj6xUo2.net]: エコシステム全体が代数的データ型前提で作られていて
型宣言だけでほぼAPIの使い方がわかる、みたいな体験は他言語ではちょっとないかもね
だから一度Rust書けるようになったら全部Rustでいいじゃんってなりがち
509 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 16:47:18.61 ID:iNT4RVPT.net]: railsの分からなさは、どこのコードがいつ動いてるのか、分からんとこ
510 名前：デフォルトの名無しさん [2023/06/04(日) 16:55:53.89 ID:6x+rjW9P.net]: >>493
ジャバもダメだね
C#はちょっとしか触ってないから評価できないな
511 名前：デフォルトの名無しさん [2023/06/04(日) 16:59:31.44 ID:6x+rjW9P.net]: >>499
レイルズに限らずフレームワークというのはえてしてそういうものだよね
それって作る時はいいけど維持することを難しい
なので避けられるようになってきた
512 名前：デフォルトの名無しさん [2023/06/04(日) 17:00:30.76 ID:CvW15b8Y.net]: 高レイヤーのWebアプリでもRustがつかわれるようになるよ
支配的にはならないけど
513 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 18:26:31.67 ID:R98I/Q0o.net]: ID:rt4nzg3Uからは議論や情報交換より
「論破」したい気持ちは強く伝わるな
514 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 18:31:18.83 ID:rt4nzg3U.net]: 論破なんてどうでも良いです
515 名前：デフォルトの名無しさん [2023/06/04(日) 18:56:40.97 ID:Yc44DpOp.net]: >>494
AWS (Amazon Web Service)など様々なものがRust製になっていってる現実を受け入れられない？
もしRust製である必要がないと主張したいならばどの言語を使うのがベストなのか明確にすべき
516 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 19:11:40.33 ID:rt4nzg3U.net]: >>505
既に言われてるけど低レイヤーの話でしょ
そこは得意分野だろ

でお前はその低レイヤーな部分を作るの？
要はApacheもどきを自分で作るんか？
517 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 19:12:48.96 ID:rt4nzg3U.net]: OS開発に向いてますって言われてもOS作る開発者は一般的じゃ無いやろ
518 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 19:13:29.18 ID:yBN53eMB.net]: >>479
言おうとしてたのはWebサーバーじゃなくてWebアプリね

で、企業でnginxやapacheみたいなHTTPサーバースクラッチで作ってる日本の企業ってどこにあるんだ？
Webアプリ作ってるのが大半だろ？
H2Oぐらいしか知らないけどあれはほぼ個人開発だしな
なんでかって言うと既にOSSで優秀なエンジニアが作ってるから、企業でそれをやるのは意味がないから
普通のエンジニアはこういう車両の再発明的なことを業務ではやらない

だからWeb系企業にRustは普通採用されないと言ってるの

一部のエリート向けって言ったのはまさにこういうこと
nginxもredisもCで書かれてるけどほぼ一人のエリートよって作成されてるからな
Linuxカーネル書いてる人もエリートしかいないだろ
そう言う人向けの言語
519 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 19:13:51.05 ID:rt4nzg3U.net]: 議論が出来ない馬鹿の良くある事

極論で語る

これが出てきたら無能確定
520 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 19:36:06.85 ID:yBN53eMB.net]: でその一部のエリートは通常C、C++を使いたがる
新しい言語自体には興味がなくメモリを自分で管理できる自信があるから

Rustが輝くのはAWSとか一部のエリート企業に限られるだろうね
企業でやる場合はメモリ安全は重要だろう

俺たちIT土方はまずこういった低レイヤーやミドルウェアを触れる機会がないので間違ってもイキってWebアプリとかでRust使わない方がいいと思うよ
ほとんどのケースで向いてないし、企業でもまず採用されないから
521 名前：デフォルトの名無しさん [2023/06/04(日) 19:55:56.27 ID:Yc44DpOp.net]: >>506
Webにそんな区別はない
HTTPベースで通信するものがWebと呼ばれておりAWSのWもその略

Rustでも他の言語と同様にHTTPは自分で実装する必要がなく利用するだでよい
低レイヤという区別をするならばRustではhyperというHTTPを担うライブラリが低レイヤと呼ばれている
だからRustでもその低レイヤ部分を自分で実装する必要はない

さらにその低レイヤhyperの上に作られた様々なフレームワークがある
つまり低レイヤ部分のhyperを自分で直接使う必要はなく各フレームワークを用いてWebのプログラムを書くことができる

したがってRustでは低レイヤ部分を自作もできるが既に標準的なものがあり
フレームワークも自作できるが既に様々なものがあり自分で作らなくても利用可能

Rustを否定しているあなたがRustの代わりに使うべきだと考えているプログラミング言語は何ですか?

>>510
Rustを否定しているあなたもRustの代わりに使うべきだと考えているプログラミング言語は何ですか?
522 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 22:38:12.29 ID:rt4nzg3U.net]: 何でRust否定してる事になってるの？
妄想酷くねw

長々と書いてるけど的外れなんだよ
523 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 22:52:44.00 ID:Lgm9jhwY.net]: 結局なにがしたいのかがわからん
相手にしてるやつも
524 名前：デフォルトの名無しさん mailto:sage [2023/06/04(日) 22:57:08.43 ID:YjKn3ZKa.net]: 速さ省メモリに保守性の良さからRustがベストで間違いない
525 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 01:02:48.45 ID:G39bRhEA.net]: この人の中ではRustの適用範囲は決まってて
他の人が範囲外の事例出すと否定のための否定を
したいだけなのが明白だから相手しても不毛
526 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 01:11:33.27 ID:9wHuhZD9.net]: 言いたいことはこれなのだろう

>>490
> それってJavaとかC#でも良くね？
> Rustである意味はないよね

JavaとかC#である意味こそないよな
527 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 01:41:08.29 ID:FV749zD+.net]: まとめて隔離スレに帰れゴミカスども
528 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 07:49:28.36 ID:GAWgQYcM.net]: >>469
ライブマイグレーションって今でもあまり普通じゃないと思うけど。冗長化構成とって切り替えが多いだろ。
529 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 11:19:07.49 ID:9Zk1qYqb.net]: >>515
違うかな

逆に言うとC#でもOSは書けるし実際に有る
でもソレって無理矢理感有るでしょ

Rustも同じでやろうと思えば出来る
でもそれってRustである意味は無いよねって話

高速で動く必要があって
GCが走って一時的にレスポンスが遅くなる事態が不味い
って場面がRustの出番って事だと思うんだけどね

WebアプリについてはまさしくRustであるある必要は無い
せめて他言語のフレームワーク並みに各種ミドルウェアが充実してるならまだしもその分野では貧相としか言えない
だからこそ流行ってないとも言える
530 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 11:31:56.47 ID:G39bRhEA.net]: >>519
そうだねすごいね
531 名前：デフォルトの名無しさん [2023/06/05(月) 12:29:52.32 ID:AdIugMi7.net]: 自分で考えて調べて判断を下せない人にはRustは向かない
良い悪いじゃなく適性と置かれている環境の違い
532 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 12:41:59.19 ID:GjYw3Sbx.net]: DiscordでGC云々ってのもGoのアップデートで解消できる内容だしな
（Go作者のRuss Coxさん曰く）

Webでいちいちスタックだとかヒープだとかメモリの所有権だとか考えながらコードを書くメリットは別にそこまでないよな
nginxみたいなミドルウェア的な立ち位置のWebサーバーを作るならともかく

システムプログラミング言語だからあくまでもC, C++の代替言語
GoやJavaとは全く別用途の言語
533 名前：デフォルトの名無しさん [2023/06/05(月) 13:16:05.91 ID:dGVU/GMJ.net]: 15年くらい前の考え方だね
534 名前：デフォルトの名無しさん [2023/06/05(月) 13:34:19.17 ID:UReP7Es5.net]: >>519
C#である必要もない
535 名前：デフォルトの名無しさん [2023/06/05(月) 13:43:03.69 ID:UReP7Es5.net]: >>522
あるよ
ここまで外部データを扱う分野もない
つまり内部でメモリアロケーションが頻発する
メモリをどうアロケート
536 名前：するか？で天と地の差が出るのが現代のマシンのアーキテクチャだ キャッシュメモリに全部乗せるようにプログラムを書くのは今や常識 いちいちヒープからメモリを確保していたらページフォルトで尋常じゃないスピード劣化を招く ましてやGCなどそんなプログラムを遅くするようなもんよく採用したな？というレベル Webこそスタックとヒープとメモリアロケーションを明確に制御できるべき分野 []: [ここ壊れてます]
537 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 13:46:53.65 ID:UReP7Es5.net]: >>510
何度も言うがスタック、ヒープ、ベクター化(SIMD)、キャッシュメモリなどを意識することは一昔前よりはるかに有効になっている
キャッシュメモリの速度が比べ物にならないくらい速くなっているからだ
むしろ今こそスタックとヒープを意識して「メモリをちゃんと使い回す」ことを意識すべきなんだよ
所有権ってのはマシンアーキテクチャの視点で見ると
メモリ領域をうまく使い回すための技術ともいえる
余計なアロケーションを防ぎメモリリークを防ぎ
ページフォルトを防ぎベクター化を容易にする
このような現代的なプログラミング技術についてまともに解説されることは少ないのだが
優れたプログラマは常に意識している
538 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 13:51:56.62 ID:UReP7Es5.net]: 「Rustが速い」と言われてるのはこのようなメモリの使い方が優れているから結果として速くなっているというのが事実
これは他の言語が捨てた部分だ
他の言語は「メモリなんて富豪的でいいっしょ」と言う姿勢を貫いていた
しかし現代のアーキテクチャにおいては他の言語が捨てた部分こそが高速化の肝だったのだ
Rustの初期のメンバーがここまで意識できてたかはわからないが
メモリ安全を追求した結果現代アーキテクチャにとって最適な形になったのは偶然ではない
539 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 14:02:53.03 ID:v+V2Ynpr.net]: >>522
TypeScriptで型レベルプログラミングに慣れた人たちは「せめて直和型くらいは欲しい」となってしまい
移行先としてGoもJavaも対象外になって、パフォーマンスが必要なくてもRustに行くケースがよくある
Goがもっとリッチな言語機能を目指してればこういう層は全部取れたんだろうけど
540 名前：デフォルトの名無しさん [2023/06/05(月) 14:21:53.12 ID:qHQdZEB1.net]: アレな人とアレを複製する人のアレな議論からは
反面教師とする以外に何も得るものがないな
541 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 14:27:59.36 ID:/xaXR3Rr.net]: >>522
かつてはウェブの世界だと細々と切り詰めて効率化するよりスケールアウトのしやすさのほうが重要視されてた。
プログラムを改良して性能を倍に延ばすよりもサーバの数を増やしたほうが安上がりだから。
プログラムの改良はやればやるだけ性能が伸びるというわけでなくて、
どうせどこかに上限があるなら数で補えるような設計のほうが良い。
それがかつてのウェブの思想だが、クラウドが前提の世界になって一変した。

スケールアウトを簡単に出来るインフラが整ってしまったんだ。
サービスを構築する側は CPU とメモリを使いたい分だけ金を払えばスケールアウトは当たり前に出来るものになった。
サーバの準備が投資ではなく消費になってしまったとも言える。
ま、経営者にとってみれば消費は減らしたいもんだ。
故に今はミクロ的な実行効率のほうを上げようとする圧力が発生している。

そんなわけで Rust を採用する動機はある。
もちろんサービスの規模が小さいならそんなに手間かける割に合わんということも多いだろうけど、
ウェブでも Rust を採用する動機は存在するんだよ。
542 名前：デフォルトの名無しさん [2023/06/05(月) 14:30:23.16 ID:SGaNfCKj.net]: おっさん、Rustは学歴勝負の言語なんだよ
高卒様はC#スレに帰ってくれ
543 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 14:36:08.40 ID:0sUVinjo.net]: Rustの言語機能の充実さが書きやすくて堅牢でメンテもしやすいね
メモリ管理はほぼ自動で慣れだけの問題で書くこともできるし
さらに踏み込んで頑張ることもできて幅広い利用者に適してる

Rustの唯一の弱点は慣れるまでの時間が他の言語より長いことだけど
慣れてしまえば消える弱点なので現存するベストなプログラミング言語かな
544 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 14:45:53.25 ID:DZ7CuRre.net]: 結局C++とRustってどっちが良いの？ 3traits
https://mevius.5ch.net/test/read.cgi/tech/1683154196/
545 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 14:47:01.66 ID:DZ7CuRre.net]: 他言語との比較は隔離スレでお願いします
546 名前：デフォルトの名無しさん [2023/06/05(月) 15:11:38.38 ID:vRd9123b.net]: ID変えないやつはNGしやすくていいけど
複オジはID変えてしかも複数人のふりして
同じ内容の長文を繰り返し繰り返し書くから
めちゃくちゃウザい
547 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 15:34:05.37 ID:AvaxKdII.net]: >>493
具体的にRust以外のどの言語？
548 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 16:59:55.04 ID:4ssR4odd.net]: 単発NGを推奨する
549 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 17:04:06.04 ID:GjYw3Sbx.net]: Webって何に対しても上限決まってないから動的確保が基本でヒープに確保しまくるだろ
Rustですらヒープ使うしかないのに何いってんだこいつ
550 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 17:19:13.55 ID:4NoCfZlh.net]: どういう書き込みに対するレスかわからないが
一般的にはヒープの使用をゼロというより最小限にすることが可能な言語かどうか
バックエンドをマイクロサービス化した場合は想定外のリクエストは来ないので更に最小化できる
いずれにせよGCのある言語は論外
551 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 17:34:34.25 ID:DZ7CuRre.net]: >>539
他言語との比較は禁止
隔離スレに移動せよ
552 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 18:09:21.14 ID:dww0BWyZ.net]: 論外坊を相手にしてはいけない、メモリ確保と解放を繰り返す原始的なダサい構造より搭載メモリに応じてアリーナ管理するほうが理にかなってる。Rustを使ってるのにアロケーターの自作や変更を考えたことのない子は最小の意味が分かっていない
553 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 18:15:03.73 ID:8ZF5QBOp.net]: ガベージコレクションのある言語はそれができず非効率だもんな
554 名前：デフォルトの名無しさん [2023/06/05(月) 18:29:07.02 ID:tOuh49Mt.net]: 書き心地のよさや近代的なエコシステムが好きで使ってる
チームで使うと品質を安定させやすい
実行時もリソースも安定させやすい
パフォーマンス面ではどちらかとコストの低い方を選択するよう努力するするが、そこまで突き詰めて考えないよ
555 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 18:33:55.89 ID:/S79/CE3.net]: Rustの良い面が多面的であり
どの面を重視するかは人によって様々だが
Rustに行き着く点では同じだ
556 名前：デフォルトの名無しさん [2023/06/05(月) 18:54:42.77 ID:M00yb3VA.net]: まーたクソみたいな複オジ節が連投されてんなw
557 名前：デフォルトの名無しさん [2023/06/05(月) 20:04:46.68 ID:5pPw8Ntr.net]: >>498
>>528
他の言語の標準ライブラリでも戻り型をOptionとResultにしてほしい
558 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 20:12:05.32 ID:sHX0h5A1.net]: ML系言語やればいいよ思うよ
559 名前：デフォルトの名無しさん mailto:sage [2023/06/05(月) 20:50:22.82 ID:UzHiRmXo.net]: 先日のStableのリリースでやっとOnceCellが安定化されたんですね。
Lazyはまだっぽいけど嬉しい。
560 名前：デフォルトの名無しさん [2023/06/06(火) 02:17:44.23 ID:puQ29V2U.net]: 去年から始めたけど、ここ2～3年で標準化された機能が必須に感じるので、最適なタイミングで始められたなと思う
561 名前：デフォルトの名無しさん mailto:sage [2023/06/06(火) 07:22:24.29 ID:o6YEf8qO.net]: >>543
＞書き心地のよさ
ｗｗｗ
562 名前：デフォルトの名無しさん [2023/06/06(火) 07:54:49.95 ID:8OPdxEUp.net]: 書き心地も良いが開発効率の高さだな
スクリプトで済むのはスクリプト言語を使うとして
プログラミングするならRust一択となった
563 名前：デフォルトの名無しさん mailto:sage [2023/06/06(火) 10:54:53.70 ID:6c57W+Lm.net]: 何の数字を比べて開発効率が上がったと言ってるんだ？
564 名前：デフォルトの名無しさん mailto:sage [2023/06/06(火) 11:12:32.78 ID:o1s33Rlj.net]: ありがとうRustAnalyzer
565 名前：デフォルトの名無しさん mailto:sage [2023/06/06(火) 19:31:13.22 ID:mkQOe4X2.net]: >>546
それは反対だ。副作用がない関数コールでOptionやResultはオーバースペックで邪魔でしかない、Rustだって-> i32とか出来るのは理由があるからで意味のないResultラッピングしてしまうのは邪悪でしかない。
566 名前：デフォルトの名無しさん mailto:sage [2023/06/06(火) 19:35:17.52 ID:5BE6aCuJ.net]: >>554
多言語で単に言語仕様の限界から来る異常を示すのに
nullとか-1とか例外とかなんとかならんかねえという
話では
567 名前：デフォルトの名無しさん mailto:sage [2023/06/06(火) 21:19:28.43 ID:n1ZdC4n5.net]: >>554
「他の言語の標準ライブラリでも」とあるから「(Rustと同じように)」の意味だろうね
Rustで書くと戻り型がOptionやResultとなるような関数のみが対象でしょう
具体的には>>555やerrnoなど
568 名前：デフォルトの名無しさん [2023/06/06(火) 22:39:17.85 ID:lWt7Neg4.net]: >>554
絶対にエラーが起きない場合も含めてインターフェースの戻り型を統一しなきゃいけない時に、
Resultで統一することで非効率になるのを恐れているのだと思うけど、
エラーが起きない場合の実装のみエラー型をstd::convert::Infallibleつまり戻り型をResult<Xxx, Infallible>とすれば、
最適化されるため気にせずResultラッピングのコードを書いても大丈夫だよ
569 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 02:16:00.81 ID:pdPmNlas.net]: Rustは文字列やネット系のライブラリが充実しているため、書き易いと
感じるのかもしれないが、言語自体の書き心地は悪い。
570 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 02:25:13.42 ID:VU6rdBvm.net]: >>558
スクリプト以外でRustより書き易い言語ある？
571 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 02:41:53.93 ID:pdPmNlas.net]: >>559
色々有るな。例えばJavaやC#とか。
572 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 02:52:36.10 ID:bLVp0x6K.net]: Javaは言語が古すぎ
機能不足で書くのが苦痛
今どきの言語を知っていてJavaを書きやすいと言う人はいない
573 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 03:13:16.86 ID:PASEDR7I.net]: お前ら本当にシステム屋か？

“描きやすい”ってのは人それぞれで定義が曖昧やん
なぜその定義や認識の統一をせずに議論始めるん？
574 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 03:15:24.35 ID:PASEDR7I.net]: 例えばだけどJavaは古くてというが昔からJavaやってるやつは慣れから書きやすいと感じる

Java歴15年
Rust歴1年

とかで比べたらどっちに軍配上がるか分かるやん
575 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 03:23:10.65 ID:2dySsIAz.net]: 議論を成立させるのが無理なの分かってるから隔離スレでやれっつってるんですよ
576 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 03:35:20.85 ID:PASEDR7I.net]: まあ言語スレで具体的なコードも出さずに議論しちゃう馬鹿ばかりだしな

せめて○○言語じゃこう書くけどRustではこう書ける
だから書きやすいってぐらいはして欲しいもんだ
577 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 03:35:24.21 ID:mYje0a9y.net]: >>563
それは言語の書きやすさではなく
その個人が慣れか不慣れかだろ

言語の書きやすさはその言語に十分慣れた上で
言語の機能が不足していて書きにくい点がないかどうかなどで決まる
その比較例だとJavaとRust両方に慣れた人たちにとって全員がJavaに❌をつける
578 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 04:14:00.36 ID:PASEDR7I.net]: 別の言語を長くやってても面倒臭いなって思う点は出てくるじゃん
例えばJavaやってるとC#のあの機能欲しい
なんでJavaには追加されないんだろとかさ
579 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 04:15:46.17 ID:mYje0a9y.net]: だから全員がJavaに✕をつける
580 名前：デフォルトの名無しさん [2023/06/07(水) 10:36:40.93 ID:o7otWeXk.net]: >>563
わかるやん、てあなたが勝手に言ってるだけですやんw
581 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 15:06:17.70 ID:3M1fBRd0.net]: でも、多数決では、Rustが最下位なんだよな。
582 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 15:44:42.75 ID:3M1fBRd0.net]: Rustの問題点を指摘すると、「それはあなたが・・・」
「馬鹿だから」「老害だから」「じじいだから」「化石みたいな人だから」
みたいな事言って人いるけど、それは
「若くて頭のいい人々が使うんだから、老害/馬鹿は黙っとけって」ことになるが、
それでは一般人に普及する言語には成れないであろう。
そもそも、高級言語の目的とは、簡単に安全にやりたいことが出来ると言う
ことであり、しかも、一部の人を除いては簡単にも思えないようなものであっては
普及は遠い。
583 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 15:54:04.41 ID:3M1fBRd0.net]: >>565
あなたは、そうやって、ここで、市場調査をして、次なる改良言語のネタに
したいということですね。
帰れ。
584 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 16:20:31.76 ID:QsxM8200.net]: 書きやすいか否かという話より、rustは意外にタイピング量は多い思想は考え直してほしい。
std::fmtなどの「::」だとか引数名・変数の後の型の「:」だとか、むろんmutも、戻り値の「->」もなぜ引数の「:」と戻り値の「->」を同じにしなかったのか？思想面が分かる人に教えてほしい。
ほかにもなぜマクロ呼び出しに「!」をいちいち付けるのかとか、関数はfnやpubで省略しているのに？アトリビュートも#[xxx]と異様に見える。なぜ@xxxでは駄目だったのか？
まあセミコロンはC/C++からの移行を重視したのだろうけど。言語をディスってる訳じゃなく完全論破されることを願う
585 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 16:59:17.90 ID:MyTs/b4R.net]: 細かい構文は互換性やらが重視されて一定の思想が徹底してないことも多いでしょうよ
暇ならissue掘り返してみればいい

とりあえず::はC++由来でattributeはC#由来
586 名前：デフォルトの名無しさん [2023/06/07(水) 18:36:58.20 ID:Rjy197CJ.net]: Rustが難しいと感じるのは経験不足だと思うわ
困難に立ち向かった経験が少ない
587 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 18:50:18.58 ID:JMx9Ekkp.net]: >>573
マクロ呼び出しに「!」を付けるのはコンパイラと人間の両方がマクロ呼び出しをすぐに識別できるようにするため
コンパイラの実装方法によっては無くすことは不可能ではないだろうけど効率が悪くなるし実装も難しくなる

最初は俺も無いほうが良いと思ってたけど
「!」をつけないといけないから不必要にマクロを作らなくて
結果的にメンテしやすいコードにつながってるので考え方変わった
588 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 19:54:20.54 ID:6MUTDsao.net]: >>573
タッチタイピングできない人？
もしくはVSCode使ってない人？
文字数なんて気にするやつ初めて見たぞ

::はC++由来
->はHaskell由来だよ
マクロの!や?はおそらくRuby由来だが別の意味で使ってる
#[]はわからん
589 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 20:20:10.95 ID:MyTs/b4R.net]: >>577
煽るなら最低限公式ドキュメントの内容はすべて頭に入れてからにしたまえ
https://doc.rust-lang.org/reference/influences.html

>>573が言いたいのはTypeScriptのごとくfn f(x: T): Uとかけないのは何故かということだろう
trait boundとの曖昧性が生まれる状況があるのかなと思ったが、ちょっと具体例が思いつかないので違うかも
590 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 21:01:38.64 ID:MyTs/b4R.net]: というかRustは元々めっちゃタイプ数気にする系言語だったんだよねむしろ
1.0以前にはreturnがretだった頃もあった
今日まで残るfnとかimplとか、比較的新しいdynもそうだが
実際かなり略したがりな言語ではあると思うよ
591 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 22:03:46.79 ID:juXVB+W2.net]: >>573
あらゆる言語で同じことが言えるが
基本的な文法記述方法を考え直してほしいと要求しても
今から変わるわけがないし変わったら利用者が困る
無意味な破壊的な要求をしていることになる

タイピング量が多いといってもわずかな誤差であり
ほとんどの記述方法は既存のメジャーな言語で実績があるものと同じ
現在のメモリCPU開発環境からも余裕で許容される範囲でもある
個人的に気に入らないと主張しているのと変わらない
592 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 22:23:55.97 ID:gvoW4qh7.net]: 記述方法が気に入らないのであれば
自分で変換器を作ればいいだけなのでは?
593 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 22:42:25.08 ID:JMx9Ekkp.net]: >>578
>TypeScriptのごとくfn f(x: T): Uとかけないのは何故かということだろう
基本的には視認性の問題
TypeScriptも関数の型を明記するときはファットアローを使ってる
594 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 23:12:17.03 ID:Y4/HSuwV.net]: 気に入らない部分くらいあってもいいだろうに過剰に攻撃的な人は落ち着いて欲しい
どんな人もある程度は興味があってきてるんだろうから建設的に話をしましょうよ
気に入らない部分も背景知ると納得できたりするしそういう情報知るの楽しいから書いてくれてる人はありがたい
595 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 23:20:10.61 ID:C+WmTRhv.net]: 戻り値型指定の->には returns や maps to 的なニュアンスを感じられるから個人的には好き
596 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 23:44:37.64 ID:ZHL7BfYm.net]: ->ってでも実際は不要でしょ？
無駄
597 名前：デフォルトの名無しさん mailto:sage [2023/06/07(水) 23:52:00.89 ID:PbTa+35j.net]: >>573が、Rustの思想を考え直して欲しい、と攻撃的にスタートしたのはマズかったかもね。
戻り値の型指定がなぜ「:」ではなく「->」なのかと、素直に質問すればよかったかも。
理由は視認性の良さに加えて、C++の関数の戻り型の後置記法「-> int」と、同じ記法にしたためでしょう。
例えばCarbonでは「-> i32」と、Rustと同じになります。
598 名前：デフォルトの名無しさん [2023/06/07(水) 23:58:55.09 ID:KhstQSkV.net]: int foo() {}　C/C++前置
auto foo() -> int {}　C++後置
fn foo() -> i32 {}　Carbon
fn foo() -> i32 {}　Rust
599 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 02:28:36.11 ID:EE2g7bKF.net]: Cと似ても似つかない。
600 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 02:35:35.53 ID:EE2g7bKF.net]: 嘘つき大国アメリカには、良いソフトウェアは作れない。
独占によって維持するのみ。
601 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 02:36:59.06 ID:EE2g7bKF.net]: 日本人を大量虐殺したことを反省せず、今度はウクライナとロシア人を
殺している。
そんな国に良いものは作りえない。ずるするのみ。
602 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 02:48:48.98 ID:EE2g7bKF.net]: 平均寿命がアメリカは日本より5歳も低いことをみんな知らない。
そんな後進国を先進国扱いしている。
603 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 02:53:24.84 ID:EE2g7bKF.net]: 特に、githubなんかは、わけの分からんソフトを作ってる人に別の左翼が
寄付する。左翼は相互扶助で虚構世界を作るのが好き。一般需要が全く無い
ソフトウェアに大金が寄付される。
このように、左翼は日本やアメリカにあってもお互いに虚構を流し合うことで
脳内で言論統制し合い虚構世界を生きている。
604 名前：デフォルトの名無しさん mailto:sagesage [2023/06/08(木) 03:00:18.36 ID:EE2g7bKF.net]: アメリカのやり口:
・需要が無いのに無理やり使わせる。
・不便なのに無料化することで構造上それしか存在しない状態になっている。
・無料化することでどんなに粗悪品でも対抗製品が現れ得ないからである。
・からくりは、検索エンジンの広告料で大金を永遠と稼ぐことで、ソフトを
　無料化し、検索エンジンを持たない通常企業の参入を永久阻止しているのである。
605 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 03:40:00.34 ID:aft4Kt1Y.net]: うーん
やはりﾜｯﾁｮｲなしスレは放棄する他ないか
606 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 03:57:30.29 ID:VBjeYwpm.net]: >>593
各プログラミング言語の本スレを無関係な話で荒らすのはマナー違反なので止めなさい
この一線だけは守りなさい
607 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 04:06:08.75 ID:EE2g7bKF.net]: >>595
アメリカは、基本ルールを守ってないので個別製品の話にまで進まない。
中国の知的財産権違反や著作権違反、不正コピーを言う前に、アメリカこそ、
まずは、基本ルールを守らないと。
608 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 04:07:01.06 ID:EE2g7bKF.net]: アメリカは基本ルールが守れて無いのに、Rustの仕様なんて語る権利が無い。
609 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 04:10:05.28 ID:EE2g7bKF.net]: 要は、アメリカは人殺しが刑務所で書いた本が売れて億万長者になっているようなものだ。
610 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 07:29:01.96 ID:ABj73STK.net]: C言語の戻り型の前置記述だとC++で色々と不便なことがわかり
C++11では戻り型を"->"により後置できるようになった
ラムダ式でも戻り型を指定する時に同じく"->"で後置する
つまりC++11の時点で"->"による戻り型の後置記法が導入されている
そして>>587のようにRustとCarbonもC++11の"->"を踏襲している
611 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 08:51:14.64 ID:9HUG8roo.net]: 他言語とか視認性置いておいてもfn f(x: T): Uは一貫性ないんだよな
Tはxの型だがUはfの型ではないわけで
:の左辺が名前で右辺が型という原則に従うなら fn f: (x: T) -> U となるはず
612 名前：デフォルトの名無しさん [2023/06/08(木) 08:52:05.56 ID:u/DD3jzo.net]: うちはインターンの女子大生すらRust使い始めたわ
ﾍﾟﾁﾊﾟｰには辛い世界になっていくだろうな
613 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 09:22:42.20 ID:c1TL2iD8.net]: >>573
お爺ちゃん🥺
614 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 13:15:19.62 ID:5t64h36a.net]: >>600
左辺が式だと思えば筋は通るやん？
615 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 14:14:27.48 ID:Iro3x2NJ.net]: >>573
関数を評価した結果の型と関数の型は違うものだから表現も異なる。
同じであると誤解するような説明がどこかにあるのならそれを指摘してほしい。
616 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 14:32:27.10 ID:5t64h36a.net]: 隔離スレにコピペしたからあとはあっちで頼むわ
617 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 15:00:38.73 ID:ybwEaSV3.net]: >>603
どう見ても式ではないが
仮に式っぽい何かだとしても関数宣言にだけ特別に書けるならやっぱり一貫性はないってことになるし
618 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 20:13:04.97 ID:rV/cB3of.net]: 関数型言語から拾っただけで深い考えはないだろ
関数型言語は　引数　-> 戻り値　とか　引数 ->　引数　-> 戻り値でカリー化したら引数の数が減ったりするので意味は通じるけど…
619 名前：デフォルトの名無しさん [2023/06/08(木) 20:15:30.41 ID:4tjPz2+ ]: [ここ壊れてます]
620 名前：B.net mailto: オレオレ一貫性w
全然一貫してない []: [ここ壊れてます]
621 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 20:45:27.43 ID:ABj73STK.net]: 「-> 戻り型」を批判してる人は先に採用したC++に対しても批判しているの？
ML系で何十年も使われて来た実績と視認性の良さからベストな記法
622 名前：デフォルトの名無しさん mailto:sage [2023/06/08(木) 21:09:50.06 ID:6OsjtmDb.net]: ML系は関数呼び出しにかっこを使わないし
関数定義と型注釈を分けて書くし
Cスタイルとはだいぶ違う文法体系だよね
同じ記号を使っているという以外に共通点はないと思うよ

そしてx: TはPascalスタイルの型の付け方なんですね
TypeScriptの他にもScala、Kotlin、HaxeなどがPascalに従って(x: T): Uのように戻り値型注釈をつけます
参考までに
623 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 02:12:57.64 ID:vRGkF7ww.net]: sigplan noticeではindentationとlexical syntaxの話は禁止だったw
624 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 17:20:52.23 ID:3c0vm8Dw.net]: syntaxで言うならライフタイムのsyntaxは今でも違和感あるわ。
具体的に使うわけでもない変数を定義するようなのはどうにかならんかったのか。
625 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 18:41:37.13 ID:2zdGi9Wu.net]: >>612
型変数と同じじゃない？
あれも変数として使ってるわけじゃなく、こことここの型は同じってことを示すだけの変数なわけで
626 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 18:57:57.14 ID:2zdGi9Wu.net]: 変数として使ってないわけじゃないな
具体的なインスタンスが生成されるときに具体的なライフタイムが代入されると思うべきか
627 名前：デフォルトの名無しさん [2023/06/09(金) 18:59:26.79 ID:FpUIfFmd.net]: 型パラメータは変数じゃありません
628 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 19:10:21.66 ID:9O24uU1k.net]: 違和感あるようにしてるんだぞ
Bad Partsはあえて汚くなるような構文を選んでる
629 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 19:42:24.19 ID:9O24uU1k.net]: >>610
Haxe草
君のバックボーンはなんとなくわかったよ
630 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 20:20:27.29 ID:JRGzkE91.net]: rustのstructってなんで中身をカンマで区切るんですか？
C/C++/C#/Swiftはセミコロンだし、影響受けたとされるhaskellの直積型はスペースですよね、デフォルトでメモリースペースが最小になるように再配置されるから？
でもそれだと配列のように直線的に配置されるように感じてしまう気がするのだが
631 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 20:32:17.49 ID:j7wYaK9P.net]: 内容の列挙だからカンマの方が自然だと思うけどセミコロンが使われがちなのは
構文解析（エラー復帰）しやすいからなのかな

let Point { x; y; } = p;
だと気持ち悪いからパターンマッチと関係あるかもしれない
632 名前：デフォルトの名無しさん mailto:sage [2023/06/09(金) 22:10:43.24 ID:JRGzkE91.net]: >>619
なるほど?構文解析が楽だからという理由はある程度は納得できるが、自然と感じる理由が個人的な嗜好で何となくなのかな?
ほかにカンマを使う場面は分割代入(destructuring)があるので、structを分解するときに対称性が良いからなのかと考えたり
633 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 08:59:06.95 ID:gJM3u8Zc.net]: cでエンディアン確認するとき

unsigned long x = 0x12345678;
for( int i = 0; i < sizeof(long); i++ ){
634 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 09:07:47.23 ID:gJM3u8Zc.net]: cでエンディアン確認するとき

unsigned long x = 0x12345678;
unsigned char *px = (unsingned char *)&x;
for( int i = 0; i < sizeof(long); i++ ){
　fprintf(stderr, "%X ", *px++ );
}
fprintf(stderr, "\n" );

てのをrustならどー書いたらええの>
635 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 09:44:12.87 ID:NYFdP8Rk.net]: それと同じこともできるけど、単にエンディアン知りたいだけならこんな感じで

if cfg!(target_endian = "big") {
// big endian
} else {
// little endian
}
636 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 09:56:44.54 ID:gJM3u8Zc.net]: >>623
エンディアンと書いたのは一例で
実際用意された型にバイトデータがどう格納されてるかを知りたい
ポインタキャストどー書くの?

forとかも変なことなってるけど
条件判断と goto ラベルさえあれば繰り返しは実行できるんだが,
rustにC/C++にあるgotoとかラベルってあるの?
637 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 10:05:08.69 ID:NYFdP8Rk.net]: >>624
その場合はtransmuteかな
https://doc.rust-lang.org/std/mem/fn.transmute.html

gotoはない
ラベルはネストしたループから脱出するためのはある
638 名前：デフォルトの名無しさん [2023/06/10(土) 10:07:35.39 ID:n814OtyQ.net]: >>622
let x: i32 = 0x12345678;

// 直訳すると生ポインタなのでunsafe
use std::mem::size_of;
let mut px = &x as *const i32 as *const u8;
for _i in 0..size_of::<i32>() {
print!("{:x} ", unsafe { *px });
unsafe { px = px.add(1); };
}
println!();

// byte列とみなすメソッドを使うとsafe
for b in x.to_ne_bytes() {
print!("{b:x} ");
}
println!();
639 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 10:13:46.29 ID:udyVxmRJ.net]: エンディアン君を、ウッカリ助平と命名したい....
640 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 10:25:42.92 ID:gJM3u8Zc.net]: >>625
>>626
641 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 10:26:30.43 ID:gJM3u8Zc.net]: >>625
>>626
わざわざありがと
勉強になります

>>627
何ソレ?
642 名前：デフォルトの名無しさん [2023/06/10(土) 10:35:25.62 ID:n814OtyQ.net]: to_ne_bytesのneはnative endianの意味でleやbeもある
neを使ってlittle endian環境ならば
assert_eq!(0x12345678_u32.to_ne_bytes(), [0x78, 0x56, 0x34, 0x12]);
assert_eq!(0x12345678, u32::from_ne_bytes([0x78, 0x56, 0x34, 0x12]));
643 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 15:12:50.25 ID:PsHn2Fx3.net]: テキストデータを画像にレンダリングして最終的に2値モノクロ画像を得たいんだけど
今だとどんなクレートを使うのがいいかな？
フォントレンダラはfont-rs・・・は放置されているしからfontdueとか？
2値化に影響するディザリングのオプションとかを指定できるとありがたい
644 名前：デフォルトの名無しさん mailto:sage [2023/06/10(土) 15:48:41.24 ID:UQF9pDDb.net]: rusttypeとかab_glyphってのがダウンロード数多いみたい
645 名前：デフォルトの名無しさん [2023/06/12(月) 12:58:17.77 ID:oql3AWnL.net]: ただの思いつきだが、CやC++はメモリセーフではないだろ。ってことはプログラム中で結構無駄なメモリを消費してたりしないの？Rustはそこの所最適化されてるから究極的にはRustの方がCやC++よりも高速に動作するのでは？
646 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 13:04:11.65 ID:RXOqFmSk.net]: ？
647 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 14:15:17.58 ID:krlNNb+N.net]: ちょっと何言ってるかわからない
648 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 16:35:03.90 ID:snPhjFNJ.net]: メモリセーフかどうかと
メモリを無駄使いしてるかどうかに直接の関係はない
649 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 16:47:01.05 ID:/yLe7ykR.net]: メモリ安全性とメモリの利用効率に関係はないが、
安全性のために導入したライフタイム管理が最適化に影響する部分がないとは言えない。
依存関係が明瞭だからエイリアス解析がしやすく、
結果的に効果的に最適化しやすい可能性は高い。

しかし実行時でないと安全なアクセスであるかどうか検出が不可能な場合もあるから
それも込みで考えると Rust のほうがやや不利であると言える要素もある。
全体的な性能は互角か Rust のほうがやや遅いくらいじゃないの。知らんけど。

性能が互角くらいでより安全ならそのほうがいいじゃろ。
650 名前：デフォルトの名無しさん [2023/06/12(月) 18:28:52.16 ID:EF0TFJgA.net]: メモリ安全にするために過剰なコピーや長いライフタイムになる実装をしてしまうことがあり、それをコンパイラがガードしてあげるからルールに従って書いてねってのがRustの思想だと思う。
逆に適当に書いても安全にするし出来るだけメモリ効率も配慮するよってのが他のGC言語
651 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 18:44:13.30 ID:A48fS+G5.net]: そんな話一般論で語れる訳ないぞ
コードを出しな？
652 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 20:02:49.65 ID:dpH2J6Rw.net]: >>637
そんなことはなくRustも適切な方法を選べる
そのRustがやや不利でやや遅いと思っている具体的なケースのコードを出してごらん
653 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 21:33:36.66 ID:/yLe7ykR.net]: >>640
ここではメモリ安全性が実行効率に寄与するわけではないというのがトピックなので
安全性 (自動的な安全性の検証) を捨てることも出来るというのは話題の外。
654 名前：デフォルトの名無しさん [2023/06/12(月) 21:39:50.33 ID:MIVgoZU9.net]: 意味のない議論がほんと好きだねー
655 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 21:44:05.58 ID:G7kVZgOF.net]: コードが一切出てこないのが本当不思議
656 名前：デフォルトの名無しさん mailto:sage [2023/06/12(月) 21:45:00.87 ID:dpH2J6Rw.net]: >>641
Rustは実行効率を保ちながら安全性もある
Rustがやや不利でやや遅いと思い込んでいる具体的なケースのコードを出してごらん
657 名前：デフォルトの名無しさん mailto:sage [2023/06/13(火) 11:32:39.43 ID:dzy+ZzAL.net]: >>640
>そのRustがやや不利でやや遅いと思っている具体的なケースのコードを出してごらん
ややどころか、大幅に遅くなるケースもあるぞ。
俺はこれ以上指摘しない。自分で分かるかどうかが技術力の試金石だ。
658 名前：デフォルトの名無しさん mailto:sage [2023/06/13(火) 11:35:33.48 ID:dzy+ZzAL.net]: また、
　「Rustは、どんな場合でも、効率を下げずに少数の関数の中に unsafe 箇所を閉じ込められる」
というのも嘘。
659 名前：デフォルトの名無しさん mailto:sage [2023/06/13(火) 11:43:16.69 ID:+SMK6i6B.net]: ならお前はこれ以上指摘すんなよ未来に渡って
660 名前：デフォルトの名無しさん [2023/06/13(火) 11:53:41.84 ID:+a/cV++y.net]: >>645
デタラメ屋さんまた来たのか
661 名前：デフォルトの名無しさん mailto:sage [2023/06/13(火) 14:38:11.20 ID:oknE//uE.net]: >>648
俺は一般プログラマより生まれつきだいぶ頭がいいので、通常のプログラマには
分からないのかも知れない。
662 名前：デフォルトの名無しさん mailto:sage [2023/06/13(火) 18:50:01.53 ID:t3PG4UqW.net]: >>649
ぷw
663 名前：デフォルトの名無しさん [2023/06/13(火) 23:11:29.90 ID:/Z2+rRnG.net]: >>649
だいぶ頭良いプログラマーはこんなとこ来ねーからw
664 名前：デフォルトの名無しさん mailto:sage [2023/06/14(水) 17:49:14.80 ID:yJueN6KQ.net]: 可変長のバイナリデータを扱う場合の型ってやっぱvec<u8>あたり？
独自の型を定義する以外に他によさそうな型って何かあるかな
665 名前：デフォルトの名無しさん [2023/06/14(水) 20:22:43.85 ID:kb1QmHED.net]: >>652
Trait std::io::Readのrequired methodが
fn read(&mut self, buf: &mut [u8]) -> Result<usize>;
であるように&[u8]でアクセスできれば何でもよい
そのうち可変で最もお手軽なのはVec<u8>
Trait std::io::Readのprovided methodの一つ
fn read_to_end(&mut self, buf: &mut Vec<u8>) -> Result<usize> { ... }
もVec<u8>の可変参照を渡す仕様
666 名前：デフォルトの名無しさん mailto:sage [2023/06/14(水) 20:28:50.68 ID:MiDa+oME.net]: よくわからないんだけど
ライフタイムの例でよく出てくる関数の引数a,bを同じライフタイムの指定にするってやつは
どちらが選ばれるか分からないから使わないほうも長い方の寿命に合わせて残しておきますと言う解釈でいいの？
667 名前：デフォルトの名無しさん [2023/06/14(水) 20:57:15.56 ID:VhTmt6N9.net]: >>654
その例となってる関数のコードくらいは書けよ
668 名前：デフォルトの名無しさん [2023/06/14(水) 23:11:40.84 ID:kb1QmHED.net]: たぶんこういう例のことかな
fn longest<'a>(s1: &'a str, s2: &'a str) -> &'a str {
if s1.len() >= s2.len() { s1 } else { s2 }
}
ここである呼び出しの時に
s1が'staticでs2が'x (!= 'static)だったとすると
'aとして寿命が短い'xの方が採用される
ただしこれはcovarianceである&Tの場合の話
invarianceである&mut Tの場合は逆になるので注意
669 名前：デフォルトの名無しさん mailto:sage [2023/06/14(水) 23:20:37.20 ID:yJueN6KQ.net]: >>653
サンクス。やっぱvec<u8>が無難か
読みやすさだと構造体だけど要unsafeな上に
環境依存性も出ちゃうからな
670 名前：デフォルトの名無しさん [2023/06/14(水) 23:43:12.09 ID:kb1QmHED.net]: 構造体とか要unsafeとか何をしたいのかわからないが
上限を決めてもよい用途ならば
ヒープを使わずともArrayVec<u8, CAPACITY>がスタック上のみで動く
671 名前：デフォルトの名無しさん mailto:sage [2023/06/14(水) 23:49:13.19 ID:yJueN6KQ.net]: データの一部だけ可変長とかブロック構造の個数が
可変(ブロックの中身は固定)とかね
672 名前：デフォルトの名無しさん mailto:sage [2023/06/14(水) 23:54:41.98 ID:MiDa+oME.net]: staticは消滅しないから実質参考にならんので無視して短い方をaとする
これは対象が2つだからであって
static 1
その他　2
ならその他2の長い方になると言う考えでいいのかな？
673 名前：デフォルトの名無しさん [2023/06/14(水) 23:58:17.85 ID:CT9YbjmP.net]: もう何言ってんだよ
674 名前：デフォルトの名無しさん mailto:sage [2023/06/14(水) 23:59:42.49 ID:hllwji0O.net]: >>656
ライフタイムに関しては&も&mutもcovariantなので違いはありません
675 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 00:08:38.46 ID:wST3qwRf.net]: Tに対して&Tはcovariant
Tに対して&mut Tはinvariant
676 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 08:25:03.26 ID:9aol5+Qr.net]: >>548
OptionとOnceCellの違い

&Tを得ることをgetと呼ぶようになった
【Option】fn as_ref(&self) -> Option<&T>
【OnceCell】fn get(&self) -> Option<&T>

&mut Tを得ることをget_mutと呼ぶようになった
【Option】fn as_mut(&mut self) -> Option<&mut T>
【OnceCell】fn get_mut(&mut self) -> Option<&mut T>

空にしてTを得ることをtakeと呼ぶのは同じ
【Option】fn take(&mut self) -> Option<T>
【OnceCell】fn take(&mut self) -> Option<T>

空(default)を作成することをnewと呼ぶこともできるようになった
【Option】fn default() -> Option<T>
【OnceCell】fn default() -> OnceCell<T> または fn new() -> OnceCell<T>
677 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 11:48:36.10 ID:7LFutjAG.net]: トヨタの車載OSってRUSTなんだ
678 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 18:17:26.02 ID:wrhp+okP.net]: ライフタイムもtraitも難しすぎてマジでわからん
679 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 18:21:52.25 ID:WlvOik+R.net]: ライフタイムの質問してたものだけど
コードを書いてて完全に誤解していたことに気が付いた
コンパイル時に範囲をチェックするために引数のライフタイムを最小限に揃える仕組みなんだな
多分一般向けには流行らないわな
680 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 18:38:09.80 ID:Ah9v0OFJ.net]: ライフタイムって該当のメモリがいつまで確保されているかって話であって難しいところはなくね？
所望のタイミングまで開放してほしくないがどのようにするのが望ましいか？って話ならまだわかるが
681 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 18:40:44.72 ID:QZKQzk+I.net]: 自明なときに省略できるせいで理解しづらくなってる気はする
682 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 18:44:18.80 ID:WlvOik+R.net]: 日本語がおかしかった
関数では引数に依存する戻り値の寿命がわからない
それで基本的に指定した複数の引数のライフタイムの一番短い奴に合わせて解釈する
そのライフタイムを元にコンパイル時にチェックしてダングリングを防いでる

一番寿命が短い奴に合わせてチェックしたら他はそれより長いのでダングリングが起こらないだろうと
こういうふうに言う人間があまりいないのが現状
683 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 18:47:34.83 ID:WlvOik+R.net]: 普通にコードを書いた時点でスコープや借用の関係で寿命は決まってる
それが範囲外になるかどうかボローチェックしてるんだけどそいつのためにライフタイムを明示してる

ライフタイムを明示してもコード上の寿命は伸び縮みしないけどエラーを見てコードを書いた人は修正ができる
684 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 18:52:46.39 ID:WlvOik+R.net]: と言う解釈なんだけど今のところ
普通に違ってるかもしれない
685 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 18:57:24.57 ID:uU1WiW+l.net]: OnceCellってようやく俺たちの欲しいものが来てくれたか
RefCellもCellも複雑なデータ構造作ると面倒だったからな
686 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 20:40:26.65 ID:bvsZhoj8.net]: Cellの種類が増えるってのは悪い兆候だね
687 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 20:43:39.64 ID:vyb4HXQ7.net]: Cellを使ったら負け
他の言語からの移植だと、なぜか増えてしまう
688 名前：デフォルトの名無しさん [2023/06/15(木) 21:23:13.49 ID:jjsgM8WL.net]: >>670
結構何を言ってるか分からないが引数のライフタイムを省略した場合は全部同じライフタイムを持つことになるよ
689 名前：デフォルトの名無しさん [2023/06/15(木) 21:54:27.47 ID:o+xWcDso.net]: >>670
main()→sub()→...と呼ばれている時に
'mainと'subをそれぞれの関数で持っている分の寿命とすると
寿命の長さは'static＞'main＞'subだが
「'sub以上の集合」⊃「'main以上の集合」⊃「'static以上の集合」なので
実は'staticの方がサブタイプ(下位)

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str において
寿命'aはジェネリックなパラメータなので
longest('main, 'static)と呼び出されれば'aは上位の'mainとなり
longest('main, 'sub)と呼び出されれば'aは上位の'subとなる

一方で
fn foo<'a, 'b>(x: &'a str, y: &'b str) -> &'b str という関数だと
foo('main, 'static)と呼び出されれば'bはそのまま'staticとなり
foo('main, 'sub)と呼び出されれば'bはそのまま'subとなる
この場合はもちろん引数の短い方の寿命になるわけではない

fn bar<'a, 'b>(x: &'a str, y: &'b str) -> Bar<'a, 'b> という関数は
返り型が構造体(か何か)のBarでその内部に寿命'aのものと寿命'bのものを持つ
このように様々なケースがある
690 名前：デフォルトの名無しさん [2023/06/15(木) 22:01:26.73 ID:o+xWcDso.net]: >>673
OnceCellは前からあって広く使われていて今回stdに採り入れられた
once_cell::unsync::OnceCell が std::cell::OnceCell となった
staticで使われてきたSyncなOnceCellの方は別名となり
once_cell::sync::OnceCell が std::sync::OnceLock となった
691 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 22:08:16.03 ID:yL2pOlPY.net]: >>670
データフロー解析を知らないのだろうか?
692 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 22:11:21.57 ID:R+Rv2ggs.net]: >>667
>コンパイル時に範囲をチェックするために引数のライフタイムを最小限に揃える仕組みなんだな
この”揃える”っていう感覚になる理由がこんがらがってる原因と見た
693 名前：デフォルトの名無しさん [2023/06/15(木) 22:12:42.39 ID:o+xWcDso.net]: >>675
負けではない
むしろCell類は内部可変性を与えてくれる便利で良いもの

>>674
性質の異なるものを使い分けられるから良いこと
コードの自由度や可読性も上がる
694 名前：デフォルトの名無しさん [2023/06/15(木) 22:15:38.46 ID:EOr7Ahlr.net]: >>677
上位下位にサブタイプにsubて嫌がらせか！
695 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 22:39:43.11 ID:WlvOik+R.net]: >>676
まずこれは間違いだよね？
ライフタイムを省力すると全部別扱い

>>680
こんがらがってはいない
違うなら違う個所を訂正したらいいけど君には出来ないとみた

引数側のライフタイムは戻り値のライフタイムの検証のためのヒント
696 名前：デフォルトの名無しさん [2023/06/15(木) 23:12:41.78 ID:ZgEGySwy.net]: >>683
こんがらがってないならまずは他人に理解できる日本語とコード例を書いてくれよ
間違いを指摘するとか以前に何を言いたいのかわからないんだって
俺だけじゃなくて何人も君が何を言いたいのか分からないって書いてるでしょ？
697 名前：デフォルトの名無しさん [2023/06/15(木) 23:29:09.39 ID:iPvlEIxp.net]: >>683
>まずこれは間違いだよね？
>ライフタイムを省力すると全部別扱い
コンパイルエラーになるケースを含めて言えば「省略したら」全部別扱いは正しい
コンパイルエラーにならずに「省略できるのは」基本的に入出力で同じライフタイム扱いになる場合だから>>676の感覚もよくわかる
&と&mut違いで推論できる場合だけ例外
698 名前：デフォルトの名無しさん mailto:sage [2023/06/15(木) 23:59:14.48 ID:sGVU6kWB.net]: >>683
ライフタイムの「仮引数」としては省略されると全部同じ扱いで合ってるよ。
https://doc.rust-lang.org/reference/lifetime-elision.html

一方で呼び出す側が認識しているライフタイムの「実引数」は違っていてもいい。
>>656の例で言えば、呼び出す側が x: &'b str と y: &'c str を渡して戻り値を z: &'d str に束縛するなら、'a は 'b: 'a, 'c: 'a, 'a: 'd を満たす最小のライフタイムに推論される。
そのような 'a があれば、&'b str <: &'a str etc. の部分型付け関係に基づいて、引数はすべて一度 &'a str にアップキャストされると思っていればいい。はず。
適切な 'a が無ければライフタイムに関するコンパイルエラーになる。
https://doc.rust-lang.org/reference/subtyping.html
https://rust-lang.github.io/rfcs/2094-nll.html
699 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 00:20:26.24 ID:Ej8ifuNd.net]: Rustのコードが'まみれになるのはそういう理由だよね
700 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 00:24:30.59 ID:0npxuivH.net]: >>686
＞　パラメーター内の省略された各ライフタイムは、別個のライフタイムパラメーターになります。
701 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 00:30:18.44 ID:rJ7TTESK.net]: >>686
いや、全部別になる
参照引き数が2つあれば'aと'b別になる

ソース
https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html

The first rule is that the compiler assigns a lifetime parameter to each parameter that’s a reference.
In other words,
a function with one parameter gets one lifetime parameter: fn foo<'a>(x: &'a i32);
a function with two parameters gets two separate lifetime parameters: fn foo<'a, 'b>(x: &'a i32, y: &'b i32);
and so on.

(snip)

Let’s look at another example, this time using the longest function that had no lifetime parameters
when we started working with it in Listing 10-20:

fn longest(x: &str, y: &str) -> &str {

Let’s apply the first rule: each parameter gets its own lifetime.
This time we have two parameters instead of one, so we have two lifetimes:

fn longest<'a, 'b>(x: &'a str, y: &'b str) -> &str {

このようにコンパイラは解釈する
そして戻り値が一意に決まらないのでコンパイルエラーとなる
そのためコンパイラは改善提案の一つとして全部同じにする提案コードを出す
fn longest<'a,>(x: &'a str, y: &'a str) -> &'a str {
全部同じ扱いと思い込んでいる人はこの提案をコンパイラが解釈したと逆に思ってしまったのではないか
702 名前：685 mailto:sage [2023/06/16(金) 01:37:43.97 ID:0a1PgEj3.net]: ほんまや申し訳ねえ
>>686はelisionのくだりは無視して明示した場合の話のつもりで読んでくだせえ
703 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 05:23:01.54 ID:VMczRTMU.net]: 厳格な言語て嫌いでな
Verilogはなんの問題もなかったのに
VHDLはとうとう挫折した
てか予約後長いし,マクロがないのが許せなかったんだが
その意味でJavaも結局書く気にもならなんだわ
704 名前：デフォルトの名無しさん [2023/06/16(金) 14:09:49.37 ID:J436PiNE.net]: >>676
だけど思い込みを書いてしまってごめん
勉強になりました
705 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 14:58:22.19 ID:KrMgX33B.net]: 水ノ都さんこんにちは
706 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 17:51:24.52 ID:fkGXFirN.net]: 組み込み向けの解説記事でよさそうなのってない？
The Embedded Rust Bookは有名だけどSTM32ありきで書かれているしリンカとか肝心な部分の説明もないように見える
日本の人が書いているっぽいEmbedded Rust Techniquesの方がマシだがこれでも最低限か・・・
707 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 18:25:34.38 ID:b/MZV ]: [ここ壊れてます]
708 名前：iq+.net mailto: >>694
The Book以外のドキュメントなら https://docs.rust-embedded.org/ からいろいろ探せるよ
あるいはEmbedded Rust Techniquesの人が書いてる「基礎から学ぶ組み込みRust」って本とか []: [ここ壊れてます]
709 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 18:39:22.38 ID:dwgGWWV8.net]: Rust好きがまあまあ見てそうなこのスレでもこのレベルなんだから一般に広まるのは無理ゲーだと思うわ
710 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 19:23:08.87 ID:PpmLuWiO.net]: 問題点を具体的に言えずに曖昧に批判してるつもりの人がいるね
711 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 19:40:36.76 ID:dwgGWWV8.net]: 自分でスレを読めばいい

お前の足りない脳を誰かがフォローしてボローチェックまでしてくれるなんて思うなよ
712 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 19:42:26.19 ID:QEmhRLek.net]: 言語の良し悪し以上にライブラリの分量が効いてくるんだわ。
そんでその大量にあるライブラリが利用しやすければなお良い。

やりたいことにマッチするライブラリがあるなら
自分で書かなくてよい部分が多くなるわけだし、
書く部分が少なければ少々の面倒くささなんてどうでもよくなる。

C や C++ の歴史の長さ故の物量に対抗するのは難しいけど
Rust は利用しやすさではかなり上回ってると思うので時間の問題だろ。
713 名前：デフォルトの名無しさん mailto:sage [2023/06/16(金) 23:38:46.36 ID:KXgq6I38.net]: >>696
単に5chがオワコンなだけだぞ
714 名前：デフォルトの名無しさん mailto:sage [2023/06/17(土) 20:33:46.40 ID:pjy0GOzk.net]: >>684
ときにアセンブラで書必要に迫られる組込でRustあ日の目をみることなんてない
715 名前：デフォルトの名無しさん mailto:sage [2023/06/17(土) 21:26:17.31 ID:iUJ74AnJ.net]: >>695
その人は本を出していたのか。今度都内へ行ったときに見てみるか
716 名前：デフォルトの名無しさん mailto:sage [2023/06/17(土) 23:07:17.38 ID:H9lc23A5.net]: 今日たまたま本屋で見かけた
売れるんかこれと思ったけど買う人がいる
717 名前：デフォルトの名無しさん [2023/06/18(日) 01:17:21.64 ID:PsNivFBp.net]: Rustでlinuxに機能を追加するならどんな機能が欲しい？みんな自由に言ってみて。
718 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 09:07:15.46 ID:JHhjqwBk.net]: >>696
ほんそれ
719 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 09:08:49.10 ID:JHhjqwBk.net]: >>699
crates.io はゴミだらけのイメージ(もちろんゴミじゃないのもあるがSN比が絶望的に悪い)
720 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 09:13:33.05 ID:JHhjqwBk.net]: >>704
これと言って無いし今のlinuxで満足(不満もあるけどそれがRustで解決するとも思わない)
カーネルもシェルもAPIもRust化しないと意味無くね？
どうせ unsafe! unsafe!! unsafe!!!
721 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 09:15:13.52 ID:QTU736PH.net]: >>706
まぁそれは何を比較するかじゃない？
ディストリビューション配布のCライブラリだと厳選されてるから当然クォリティ高いけど
GitHub上から探すとC系の方がS/N悪い（そもそもビルドできないとか）と感じるし
722 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 10:10:46.67 ID:dnSpWVpE.net]: rustは他の言語からの移植性が著しく悪い
移植と言うより最初から作ってるのと変わらない
723 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 10:29:41.24 ID:dnSpWVpE.net]: c　→　rustの移植が楽ならほおっておいても全部rustになる
その視点が欠けてる

ライナスがLinuxやGit作ったときのようにその他の勢力がおバカさんで実質アシストしてる時と同じような状況
Cust作るためのおぜん立てをしてるようにも見える
724 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 10:37:34.85 ID:dnSpWVpE.net]: 後世から見たらライナスはlinuxとgitとcustを作った偉人ですと言うことになるんだろう
725 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 12:12:13.93 ID:kd/h5bzN.net]: 仮にkernelや主要コマンドが全部rustに移植されたらその部分は安全にはなるわな
しかし現状そこまで行くかはわからん
なんせffiで別言語で書かれたライブラリ呼び出す時は全部unsafeやからな
つまり主要なlibも全部rustで書き変えないとunsafeからは逃れられないけどものすごい作業量になりそう
いけるのかな？
726 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 13:00:20.06 ID:TBj+uqoQ.net]: >>699
>Rust は利用しやすさではかなり上回ってると思うので
一部の需要に対してのみは、そういう傾向があるかもしれないとは思うが、
全般に対しては違う。
727 名前：デフォルトの名無しさん [2023/06/18(日) 13:12:59.30 ID:aPOK9VRV.net]: >>701
Rustはインラインアセンブリが書けてRustの変数と連動できるため困ることはない
叩く前に勉強しよう
728 名前：デフォルトの名無しさん [2023/06/18(日) 13:26:34.81 ID:PsNivFBp.net]: >>713
個人的にRustはあれだけの実行速度、安全性の割にはかなり文法がシンプルで好きだけどね。
729 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 14:02:54.81 ID:TBj+uqoQ.net]: >>715
蓼食う虫も好き好きだね。
730 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 16:08:38.91 ID:aKqZwOD/.net]: >>706
それ他の言語も同じだ
そういう宿命

>>709
だから安全なんだよ
731 名前：デフォルトの名無しさん mailto:sage [2023/06/18(日) 23:54:05.72 ID:V79KPNHt.net]: >>704
その発想からしてRustのパラダイムから逸脱しており反Rust
732 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 17:00:50.46 ID:Dvlv0UV+.net]: >712
>なんせffiで別言語で書かれたライブラリ呼び出す時は全部unsafeやからな
これ知るとRust安全神話なんて嘘八百八町なんよね
金儲けのために保守気取ってましたーに通じる
733 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 19:31:43.67 ID:WU95hkUv.net]: >>719
こういう言説聞くと甘えにもほどがあるって思うけど、
そういう不満から Pure Java みたいに Pure Rust なライブラリが発展していけばいいね。
734 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 19:54:19.85 ID:kXFGlrCh.net]: unsafe=危険=意味なしみたいな人はRustを使うことが目的だと思っているんだろうね
安全なソフトウェアやシステムを開発することが目的ならそういう発想にはならないはずだ
735 名前：デフォルトの名無しさん [2023/06/20(火) 20:03:45.82 ID:2T4Y6uqL.net]: 純粋なRustのライブラリはまだ完成度が微妙なんだよな。PythonとかC,C++と比べると。勿論、他言語のバインディングのライブラリは結構豊富なんだけど、それだとRustを使う意義がないからな。
736 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 20:20:14.97 ID:IIzrqfbq.net]: >>719
部分的にでもマシになるなら意味あるやん。
論理的な破綻がないように定理証明器をベースにした言語とかもあるけど、
そのために既存のライブラリが使えないようだとそれこそ使い物にならんだろ。

結局はバランスおじさん「結局はバランス」
737 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 20:41:02.57 ID:7CvaHT3W.net]: >>719
それはunsafeとは何かを理解できていなくて初心者なのかも知れないけどかなりヤバイよ
ffiなんて例を出す必要はなくメモリ空間へのアクセスは最終的に生ポインタとなって当然unsafeになる

例えばslice[index]やslice.iter()の内部は当然unsafeな生ポインタを使って実装されている
ではunsafeで実装されているslice[index]やslice.iter()は危険か？となるがもちろん完全に安全だ
なぜならunsafeを内部に閉じ込めて安全なインタフェースを提供しているからである
これがRustの基本原理

ffiについても同様で例えばファイルのオープンや読み書きは通常OSへのシステムコールとなり通常ffiとなるため当然unsafe
しかしRustの標準ライブラリではそのunsafeを内部に閉じ込めて安全なインターフェイスとして提供している

このようにメモリアクセスもOS呼び出しもそれ自体は当然unsafeだがそれはモジュールの内部に閉じ込められている
そしてそれらを利用する側のプログラマーは安全なインターフェースのみを用いてsafeにプログラミングすることができる
そしてsafeな部分なコンパイラにより様々な安全性が自動的に保証されるという至上の恩恵をもたらすのがRust
738 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 20:48:07.86 ID:FDgZeyem.net]: 話の流れとは直接関係無いが、豆知識:
バグと言うものは、64BIT 整数を 32BIT 整数で受けたり、符号付きを符合なし
で受けたり(その逆でも)するだけでも起きるし、メモリ関連バグだけでは無い。
739 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 20:50:12.42 ID:FDgZeyem.net]: 例えば、OSの一度に行なえるファイル読み書きが10MBに制限
されている場合に、それを知らずにバイト数に20MBを指定して
しまったら、バグとなる。
テストでは10MBを超えるファイルを扱っていなかったら気付かない。
740 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 21:06:06.55 ID:wgbzrV/N.net]: >>726
テスト仕様が10MB超えるファイルを扱うパターン記載されてないなら仕様じゃん

その場合仕様ミスではあるがバグとは呼ばない
バグってのは仕様通りに動いてない事を指すんやで
741 名前：デフォルトの名無しさん mailto:sage [2023/06/20(火) 21:17:59.27 ID:7CvaHT3W.net]: >>725
Rustは強い型安全性が保証されるためそれらのバグも起きない

>>726
それはプログラミング言語とは独立した無関係な話
制限があるのにエラーを返さないOSがあるならそれ自体の問題でありプログラミング言語は関係ない
エラーを返すならそのエラーの対処を正しくしていればバグは起きない
742 名前：デフォルトの名無しさん [2023/06/21(水) 20:47:56.17 ID:DnSmyfOL.net]: Rustで最初に出したバグはデッドロックだったな
コンパイルエラーにしてくれるもんだと油断していた
743 名前：デフォルトの名無しさん mailto:sage [2023/06/21(水) 21:05:00.78 ID:W7d/0xn7.net]: 静的解析でデッドロックを検出するのは不可能
もちろんRustでも無理
744 名前：デフォルトの名無しさん mailto:sage [2023/06/26(月) 18:26:13.57 ID:H3+gGIMJ.net]: すいません、くだらない質問かもしれませんけど割り込ませて下さい
Haskellとかだと二項演算子(+)はNum classに属する型なら適用できます
自分が作った型でもその型において(+)をどう実装するか定義すれば(+)が利用できるようになります
例えば5元体の計算を行うF5 型を定義してそこで足し算とかをするには

data F5 = F5 Int deriving (Eq,Show) -- 型F5を作成
instance Num F5 where -- F5がNum classに属する宣言
　(F5 x ) + ( F5 y) = F5 $ mod (x+y) 5
...略...

のようなものを作れば例えば

print $ ( F5 3 )^4

でF5 1を得る事ができます
同じような事はRustでできますか？
自分でこのような5元体の計算を行うための型を自作しそれの計算を二項演算子(+),(*)を用いた表記を可能にする方法とかありますか？
745 名前：デフォルトの名無しさん mailto:sage [2023/06/26(月) 18:32:46.35 ID:DZPgqn/v.net]: >>731
std::ops::Add を実装すれば + が使えるし
std::ops::Mul を実装すれば * が使えるよ。
https://doc.rust-lang.org/std/ops/trait.Add.html
https://doc.rust-lang.org/std/ops/trait.Mul.html
746 名前：デフォルトの名無しさん mailto:sage [2023/06/26(月) 19:00:39.37 ID:PhkZx7XR.net]: >>732
ありがとうございます
やってみます
747 名前：デフォルトの名無しさん mailto:sage [2023/07/04(火) 01:09:18.95 ID:2CEMaM2m.net]: 神クラス的なArcMutexのstructをごっそり差し替えし始めたらrust analyzerが糞遅くなって書くのが辛い
コード戻したくなる
助けて
748 名前：デフォルトの名無しさん mailto:sage [2023/07/08(土) 03:39:28.67 ID:kPVzZee0.net]: キー�
749 名前：{ードの何かのキーが入力されてるか調べるけど 何もない場合は止まらずにそのまま次の処理を続けるはどうすればいいの？ []: [ここ壊れてます]
750 名前：デフォルトの名無しさん mailto:sage [2023/07/08(土) 04:25:29.10 ID:hz58RfSC.net]: >>735
C言語の時と同じ
ノンブロッキング指定するだけでなく
cooked modeではなくraw modeをICANONに指定
これでバッファリングされることなくブロックされることなく読み出せる
libc叩かなくてもtermioなど好みのクレートを使う
751 名前：デフォルトの名無しさん mailto:sage [2023/07/08(土) 07:46:14.85 ID:kPVzZee0.net]: なるほど
752 名前：デフォルトの名無しさん mailto:sage [2023/07/08(土) 08:39:38.42 ID:kPVzZee0.net]: 窓だからGetAsyncKeyState呼び出すのが楽っぽい
753 名前：デフォルトの名無しさん [2023/07/13(木) 13:31:51.91 ID:B+tQlcfl.net]: Rust言語で開発したWindowsカーネル、Canaryチャネルで展開開始
https://news.yahoo.co.jp/articles/de16ce55a291d59f7364096690fd601c5ee2ece2
754 名前：デフォルトの名無しさん [2023/07/14(金) 11:16:58.08 ID:tzjfWmow.net]: 値をコピーせずに参照を切り替えてFibonacci数列を計算したい

https://ideone.com/lnMyvH

はいけるんだけど

https://ideone.com/VerTGV

は

error[E0658]: destructuring assignments are unstable

と怒られます
どなたか対処法わかりますか？
755 名前：デフォルトの名無しさん mailto:sage [2023/07/14(金) 11:27:16.72 ID:Jafjy1es.net]: >>740
これでどう？
https://doc.rust-lang.org/std/mem/fn.swap.html
756 名前：デフォルトの名無しさん [2023/07/14(金) 12:09:03.76 ID:8J2hXx2d.net]: >>741
おお、素晴らしい
あざっす
757 名前：デフォルトの名無しさん [2023/07/14(金) 12:17:12.18 ID:8J2hXx2d.net]: ちなみにコレxとyの参照してる値を保持してる内容を入れ替えてませんよね？
xとyの参照してるアドレスの入れ替えをしたいんですけど
それどうやって確かめたらいいんでしょう？
758 名前：デフォルトの名無しさん [2023/07/14(金) 12:25:35.09 ID:8J2hXx2d.net]: そもそもうまく行ってると思ってたほうもうまくいってなかったorz

https://ideone.com/rny4y8

xとyの参照が切り替わってるんではなくて値そのものこくかんしてやがる
xとyの値に触らずxとyの参照先アドレスだけ切り替えるのってできないんでしょうか？
759 名前：デフォルトの名無しさん [2023/07/14(金) 12:36:55.78 ID:8J2hXx2d.net]: ちょっと長くなるけどやりたい事書きます
例えばFという処理があってそれを初期値a0に何度も適用したいとします
Fの値を計算する関数を入力バッファと出力バッファのアドレスをとって入力バッファ側のデータを読んで出力バッファに書き出す関数を作ったとします
それを何度も繰り返す場合、出てきた出力バッファの内容をもう一度入力バッファにコピーする作業はあまりにも無駄なので出てきた出力バッファを今度はそのまま出力バッファとして使用したいんです
でもx,yは参照型でy=xとしたら何故かxの内容をyの内容に置き換えてしまってるみたいですけどコレ何故なんでしょう？
なんとかならないんですか？
760 名前：デフォルトの名無しさん [2023/07/14(金) 12:57:26.91 ID:KGL+WmuV.net]: 自己レス

わかりました
こうですね

https://ideone.com/sl7Q9v

ここまではうまく行った
761 名前：デフォルトの名無しさん [2023/07/14(金) 13:20:43.04 ID:bUq24laG.net]: そして教えていただいたsys::mem::swapで確認
うまく行ってる感じです
素晴らしい
あざっす

https://ideone.com/1pWNZ7
762 名前：デフォルトの名無しさん mailto:sage [2023/07/14(金) 13:21:19.50 ID:i4/iEcAZ.net]: そもそもE0658がideoneのrustcのバージョンが古すぎるせいだから>>1のPlayground使ってろ
763 名前：デフォルトの名無しさん mailto:sage [2023/07/14(金) 19:05:41.95 ID:qocfo89A.net]: 亀だが
>>695
>基礎から学ぶ組み込みRust
見てきた。あの内容じゃWebの記事読んでおけば十分な感じだった
肝心の低レイヤー(CPUやペリフェラルとのインターフェイス)の解説がペラい
特に現状ではメーカーのサポートが得られない以上HALやBSPに相当する部分を
自前で用意せざるを得ないケースは少なくないと思うけど
その辺が十分に解説されているようには見えなかった
764 名前：デフォルトの名無しさん mailto:sage [2023/07/14(金) 21:27:06.52 ID:+dZRH6iE.net]: そりゃマイナーなチップのHALを自分で作るなんて
マニアックすぎる内容で商業出版は無理だろ
そこまでやるならもう既存の実装見に行ったほうが早いよ
765 名前：デフォルトの名無しさん mailto:sage [2023/07/17(月) 14:57:59.69 ID:ckC6D+AP.net]: 期待してたけどめちゃくちゃ頼りないスタイルガイドが出てきたな
「こういう場合はこうフォーマットしましょう」だけじゃなくもう少し踏み込んで欲しかった
https://doc.rust-lang.org/nightly/style-guide/statements.html
766 名前：デフォルトの名無しさん mailto:sage [2023/07/17(月) 15:40:03.84 ID:qDsaxMYb.net]: スタイルガイドの目的はrustfmtの挙動を文書化して開発を進めやすくするってことだから
まさに「こういう場合はこうフォーマットしましょう」のための文書だよ
767 名前：デフォルトの名無しさん [2023/07/17(月) 17:17:17.76 ID:WT/Een/k.net]: もう少し踏み込んで欲しかった、と言ってる人にそれを言ってもどうもならないわな
別にスタイルガイドの定義の話あなたが勝手に始めただけですよね
論破ですよね
768 名前：デフォルトの名無しさん mailto:sage [2023/07/17(月) 17:39:41.44 ID:Lx49eL3d.net]: なにいってだこいつ
769 名前：デフォルトの名無しさん mailto:sage [2023/07/18(火) 03:22:09.12 ID:wb1VWGHJ.net]: >>745
ポインタとポインタのポインタの違いだな

>>747
そう
ポインタのポインタをswapに渡せばポインタが書き換わる
770 名前：デフォルトの名無しさん mailto:sage [2023/07/18(火) 03:37:10.43 ID:wb1VWGHJ.net]: >>751
従来の言語のスタイルローカルルールの乱立やルール解釈の違いなどの反省から
Rustの標準ではrustfmtを使うことに尽きるわけだがそれ以上にどんな記述を求めているのだろうか
771 名前：デフォルトの名無しさん [2023/07/18(火) 09:14:53.67 ID:nuoH1aU3.net]: 一般的なスタイルガイドを知ってる人と知らない人の違いだね
常識だと思ってた
772 名前：デフォルトの名無しさん [2023/07/18(火) 13:02:43.58 ID:W9LkQalw.net]: 公式のスタイルガイドはrustfmtに実装するフォーマッティング以外はスコープ外
フォーマッティングガイドラインと改名したほうがいいわな
773 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 11:14:31.27 ID:HXkvqxP4.net]: 関数呼び出しの質問です
私の認識では
「rustは関数呼び出しは基本call by valueで呼び出され、呼び出し時の“値”は基本コピーして渡される、ただしimmutatibleな呼び出しでは関数側が値を変更しないのにコピーするのは無駄なのでコピーされない」
であってますか？
それでお聞きしたいのはrust compilerって呼び出した関数側が実際引数を変更するかしないか判定して“immutatibleな変数を変更しようとした、なめとんかボケ”って怒ってくることがあります
コレ逆に言えば例えプログラマが変更しない変数をmutableで呼び出しを指定してもcompilerはどうせ変更されないんだからコピーもしないでいいよねと気を利かせてコピーしないとかしてくれると考えて大丈夫ですか？、
774 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 11:21:25.92 ID:yw4UHEnD.net]: >>759
言ってることが意味不明なので回答できない。
何か根本的に勘違いしていると思う。
コードで説明してみて。
775 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 11:41:04.52 ID:HXkvqxP4.net]: すいません
具体的なコーどはちょっと用意します
別件なんですけど

let mut i : u64;
let p : u64 = 2u64.pow(32)-2u64.pow(10)+1;
for i in 2..100000 {
if i.pow(524288)%p != 1 && i.pow(1048576)%p == 1 {
println!("{}",i);
}
}
と書いたところ
error[E0689]: can't call method `pow` on ambiguous numeric type `{integer}`
--> compiler.rs:136:8
と怒られます
u64って指定するだけではダメなんでしょうか？
どう書いたら通してもらえますか？
よろしくお願いします
776 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 11:47:10.22 ID:x9es5cRL.net]: unsafe { 引数のポインタ拾って描き替えたら }
呼び出し側も描き換わってたでござる
777 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 11:49:41.95 ID:x9es5cRL.net]: >>761
for i in 2..100000u64 {
778 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 11:51:21.32 ID:x9es5cRL.net]: >>763
あと mut i: u64 の i は for では使われてないし警告出てない？
779 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 12:00:23.67 ID:HXkvqxP4.net]: ダメでした

error[E0308]: mismatched types
--> compiler.rs:136:12
|
136 | if i.pow(524288u64)%p != 1 && i.pow(1048576u64)%p == 1 {
| --- ^^^^^^^^^ expected `u32`, found `u64`
| |
| arguments to this function are incorrect
|
note: associated function defined here
= note: this error originates in the macro `uint_impl` (in Nightly builds, run with -Z macro-backtrace for more info)
help: change the type of the numeric literal from `u64` to `u32`
|
136 | if i.pow(524288u32)%p != 1 && i.pow(1048576u64)%p == 1 {
| ~~~

となります
powってu64はダメなんでしょうか？
780 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 12:07:25.53 ID:HXkvqxP4.net]: ideoneでもダメです
https://ideone.com/FaBKXh
781 名前：デフォルトの名無しさん [2023/07/19(水) 12:11:42.11 ID:a/a2TjKK.net]: エラーメッセージから「ダメ」かどうかの１ビットしか読み取らない人にプログラミングは難しい。
782 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 12:12:42.07 ID:HXkvqxP4.net]: あ、そもそもコレダメですね
仮にu64受け付けてくれてもダメやん
powは自作します
しかしu64版のpowってないんでしょうか？
783 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 12:14:10.94 ID:x9es5cRL.net]: overflowは知らん自己責任でやれ
https://ideone.com/JR2FhX
784 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 12:17:18.80 ID:x9es5cRL.net]: >>768
https://crates.io/crates/rust-gmp
785 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 12:25:20.07 ID:YST94QZy.net]: いろいろキッツいなぁー

loop-variableはfor-loopのブロックスコープ
u64::powはfn pow(self, exp: u32) -> u64
(u32以上の値をとってもオーバーフローするから)

>「rustは関数呼び出しは基本call by valueで呼び出され、呼び出し時の“値”は基本コピーして渡される、ただしimmutatibleな呼び出しでは関数側が値を変更しないのにコピーするのは無駄なのでコピーされない」
>であってますか？
もちろん間違ってます
786 名前：デフォルトの名無しさん [2023/07/19(水) 12:29:53.08 ID:hsqLjzEB.net]: 余りをとっているから繰り返し自乗法を適当に実装すればオーバーフローは回避できる
787 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 12:30:35.45 ID:HXkvqxP4.net]: >>771
間違ってるんですか？
どこが違いますか？
788 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 12:41:14.04 ID:HXkvqxP4.net]: >>772
そうなんですよ
毎回あまり取らないとダメですよね
pの値も間違ってたし
やりたかったのはバッファサイズが1048576の有限体のフーリエ変換のための素数と位数1048576の元zetaを見つける作業でpはすぐ見つけてたんですけどzetaで手こずりました
まだrust慣れてないもので
これで行けました
https://ideone.com/haw9t8
見つけたzetaの候補３つ
4293918721
1557
7183
8874
789 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 15:49:39.29 ID:HXkvqxP4.net]: やはりダメです
型の指定の書き方がわかりません
次のコードです
https://ideone.com/QLw12c
有限体上のFourier変換を書きたいんですけどmutの書き方がらみで怒られます
どうすれば通せますか？
790 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 16:22:53.10 ID:HXkvqxP4.net]: とりあえずmutを全部につけまくったら通りました
https://ideone.com/EF9EEJ
791 名前：デフォルトの名無しさん [2023/07/19(水) 17:34:17.58 ID:g8hXxOtp.net]: >>775
>どうすれば通せますか？
The Bookを読んで基本を身につければ通せます。
https://doc.rust-lang.org/book/
まずはplygroundとエラーメッセージの読み方から学ぶことをお勧めいたします。
792 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 17:52:11.79 ID:HXkvqxP4.net]: ありがとうございます
コンパイルは無事通ったんですけどstack overflowで実行できませんでしたw
どうせならどでかいのでやってみようと欲張ったらダメでしたw
まぁ縮める分には見つけたpやzetaはそのまま使えるのでまた時間ある日に続きやります
やっぱり新しい言語挑戦するのは時間かかりますね
ついでにひとつお聞きしたいんですけど、今回は「Rustの売りのなるべくstuckでやる」でやってみたんですけど流石にこのサイズはstackにとれないようです
コレ同じ事ヒープでやってもRustコンパイラはフラグメンテーションが怒らないように良きにはからってくれますよね？
コードは>>776です、まだ作りかけですけど
Fourier変換でO(n log n)で掛け算するプログラムの実装の演習の自習中です
793 名前：デフォルトの名無しさん mailto:sage [2023/07/19(水) 23:54:55.34 ID:6nPpRSza.net]: >>759
>> rustは関数呼び出しは基本call by valueで呼び出され、呼び出し時の“値”は基本コピーして渡される

Rustは常にcall by valueでvalueをコピーする
大きなものをコピーされたくないならば
渡すvalueとしてその参照を指定する
すると参照すなわちポインタ値のみがコピーされて渡される

>> ただしimmutatibleな呼び出しでは関数側が値を変更しないのにコピーするのは無駄なのでコピーされない

immutatibleな呼び出しなんて概念はない
immutableな参照を渡すかmutableな参照を渡すかの選択肢はある
そのポインタ値は常にコピーされる

ポインタ値のコピーはどんな速い言語を作っても避けられずそれが最速
ただし例えば数値単体を渡すなら参照(ポインタ値)を渡すよりも速い

>>778
数MBのデータはスタック領域に入らないのでヒープ領域に開始時に確保すればよい
794 名前：デフォルトの名無しさん mailto:sage [2023/07/20(木) 15:25:39.14 ID:6BSTmMYa.net]: >>779
>Rustは常にcall by valueでvalueをコピーする

何でもかんでも #[derive(Copy, Clone)] 描く習慣は良くないな
795 名前：デフォルトの名無しさん [2023/07/20(木) 16:14:28.16 ID:zz9s86Uo.net]: 古典的なcall by valueの定義におけるコピーと
そのCopyとはまた違う話

ついでに言うとRustにおけるcall by valueの定義と
古典的call by valueの定義は違うので要注意
現代では古典的定義でcall by valueかどうかを考えるのはあまり意味がない
796 名前：デフォルトの名無しさん mailto:sage [2023/07/20(木) 19:56:50.64 ID:neDY19sM.net]: >>780
そのコピーはビットコピーの話でCopy実装型の話とは別
Copy非実装型でもムーブするとビットコピーされる
そもそもCPUやメモリにムーブなんてものは存在しなくてMOV (MOVE)命令ですらビットコピーが行われる

ただしビットコピーは最適化で消えうる
例えば別の変数にムーブしても最適化でビットコピーは消えうる
サイズの大きな値を関数でムーブ返ししてもRTO (Return Value Optimization)により呼び出し元スタックフレームに直接生成できるならビットコピーは消えうる
サイズの小さい値を関数でムーブ返しするとレジスタ返しとなる等
797 名前：デフォルトの名無しさん [2023/07/20(木) 22:07:49.98 ID:YJW86g9/.net]: call by valueのコピーはビットコピーなんて定義はない
ビットコピーかどうかはimplementation detail
798 名前：デフォルトの名無しさん mailto:sage [2023/07/20(木) 22:17:52.36 ID:mzA35L2k.net]: レジスタかメモリへのビットコピー以外に渡す手段はない
現行のコンピューターでは
799 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 01:08:25.26 ID:9fslOp72.net]: メモリ管理について質問です
Rustは「GCをしない言語」を謳っています
一応「GCを心配する必要はない、フラグメンテーションなも起きない、メモリ不足になったらそれはフラグメンテーションではなくて元々のメモリ不足」と言い切れればいいんですけど、実際にはそうではなく、下手なデータ管理をすればフラメンテーションは発生するようです
まぁそりゃそうなんですけど
https://hackernoon.com/ja/Rust%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%A7%E3%83%92%E3%83%BC%E3%83%97%E3%81%AE%E6%96%AD%E7%89%87%E5%8C%96%E3%82%92%E8%A6%8B%E3%81%A4%E3%81%91%E3%81%A6%E5%9B%9E%E9%81%BF%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95
ということはプログラマ極力フラグメンテーションが発生しないように注意したいところですが、しかしRustのアロケータはどういう状況でフラグメンテーションを発生させるか、どうやれば防げるかの資料が見つかりません、なので先のリンクの人は自分で調べてたみたいです
これ誰かご存知の方いますか？
具体的には同じ型のSizedのデータA,を作成して先にAを消し、その後同じ型のCを作った場合、Rustシステムはその時点で開いてる穴のAの抜け穴を利用してそこにCを割り当ててくれるんでしょうか、
それともBが消えるまではAのあった場所も“欠番扱い”になるんでしょうか？
800 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 02:40:42.91 ID:htX2UcZa.net]: >>785
アロケーションやフラグメンテーションはRustの言語システムの範囲外
例えばOSがない環境も含めてアロケータを自作もできるようになっている
普通にOSなどある環境を使うとRustはそこでの標準のアロケータをそのままグローバルアロケータとして用いる
つまり環境毎に異なるものが使われていてRustとは全く関係がない問題であることがわかる

もちろんRustでは自分でアロケータを変えることもできる
グローバルアロケータを丸ごと変える方法とBoxやVecなどで個別にアロケータを指定する方法がある
使用環境の標準のアロケータで何か問題が起きていると感じたらその例のように別のものと交換して比較してベストなアロケータを選べばよい

もう一つ全く別のアプローチとしてそれらアロケータに頼るのではなくプログラムのレベルでまとまったメモリの割り当て管理する方法もある
この方法は全て自分の制御下におけるため様々な特性のあるクレートがありもちろん自作もできる
801 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 02:50:52.30 ID:htX2UcZa.net]: >>785
後半の質問はもちろん再割り当てしてくれる
どの環境の標準アロケータでもそのような普通のことは当然している
だからアロケータの変更などは何か問題が起きてから考えればいい
質問の挙動ならばアドレスを表示させればわかる

fn main() {
// aを割り当て
let a = foo(123);
println!("a: {:p}", &*a);
// bを割り当て
let b = foo(456);
println!("b: {:p}", &*b);
// aを解放
std::mem::drop(a);
// cを割り当て
let c = foo(789);
println!("c: {:p}", &*c);
// aとcは同じアドレスになっている
}

fn foo(init: i32) -> Box<[i32; 1000]> {
std::boxed::Box::new([init; 1000])
}
802 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 08:56:00.85 ID:40PxJ+ku.net]: やはりそうですね
Rustはヒープエリアのメモリ管理は言語システムでは提供しない、その性能については規定しない立場なんですね
なので先の質問のような場合「Rustでは必ずうまいことやってくれる」とは言えず「コンパイラ××、実行環境××で実測したらうまく行った」程度しか言えず、同じソースを別の環境に持ってやったらダメだったもありうるんですね
結局ヒープを使わざるを得ない場合には「自分でメモリ割り当てをうまいことやる」しかないんですね
今やってる例だとスタックには入らないって怒られるし、ヒープ使うなら、うまくいくかはやってみるまでわからないというのはちょっと面白くないなぁ
803 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 09:24:29.44 ID:htX2UcZa.net]: >>788
OS環境などが提供するアロケータ(＝Rustのデフォルトのアロケータ)をそのまま使う時だけ環境依存になる
これはRustに限らずそれをそのまま使う全てのプログラミング言語で起こるためRustの問題ではない
しかもRustは次のように解決策がある言語だ

アロケータ含めて同じソースを持っていってそれを使うならば動作も同じになるので大丈夫
例えば先ほどのケースのようにjemallocをアロケータとして指定して使えば環境依存ではなくなる
よほど特殊なケースでの特殊な効率化を目指さない限り自分でアロケータを書く必要はない
804 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 09:54:09.20 ID:JFG0S3Tm.net]: まぁそうですね
Rustにしたら今までのプログラミング言語で常に問題視されてたアロケーション問題が魔法のように解決するなどという事があるはずはないですね
805 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 09:59:59.87 ID:htX2UcZa.net]: 何を問題にしているのか明確にせよ
Rustはアロケータすら自由に入れ替えられる
つまり理論上可能なことはRustならば解決できる
806 名前：デフォルトの名無しさん [2023/07/22(土) 10:40:08.11 ID:S6pKsqQS.net]: 複オジーww
807 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 10:45:39.31 ID:xU//sEEH.net]: 問題は普通のプログラミング言語の“メモリ割り当て問題”です
別にRust特有の問題ではなく、どんなプログラミング言語でも発生する問題ですよ
Rustではどういう戦略で当たってるのかなと
もちろんこの戦略に関して“どんな場合でもうまくいくまほうのような解決策”などありません、そして多くの場合この処理は大変重たい処理でとても重大な問題を引き起こします
画像処理、動画処理、AIの機械学習の処理などで大きなデータの割り当て、更新、消去は処理中かなり頻繁に起こり、データサイズによってはフラグメンテーションが大きな問題になる事などしょっちゅうです
結局プログラマはほとんどの場合自前でアロケーション問題を解決させられるわけでそこにもはや“言語のデフォルトに任せておけばいける”幻想は抱いてません
しかしRustはどうしてるんだろうと、もしRustでやれといわれた場合があったと妄想して自分にそれができるようにしときたいなと思って自習中なんです、まぁ絶対なさそうですが
今まで色々資料読んだ範囲内だと感覚的には「Rustはメモリ管理に関しては言語内部的には頑張らない、外部環境で処理するか、可読性を犠牲にガチャガチャしろ」というスタンスで提供されてる感じはしてます
808 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 11:31:54.16 ID:l0FUWY0y.net]: >>793
Rustは可読性を一切犠牲にすることなく、ソースコードそのままで、グローバルアロケータ指定だけを追加すればアロケータを変更できる
この件に関してRustは最も融通が効く優れた言語の一つ
809 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 11:35:08.26 ID:nQhdUCcc.net]: この人はそういう人なので適当に切り上げることをおすすめします
810 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 11:38:03.03 ID:xU//sEEH.net]: まぁ無理です
できないことをできると言い張るのはもはや学問ではなく信仰です
811 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 11:49:43.86 ID:YLqzZrt5.net]: A造る
B造る
A消す
C造る
AのサイズよりCのサイズが小さいとき
A-Cのサイズ分のフラグメントが発生
812 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 12:06:07.26 ID:24bvSiNd.net]: >>793
>> 今まで色々資料読んだ範囲内だと感覚的には「Rustはメモリ管理に関しては言語内部的には頑張らない、外部環境で処理するか、可読性を犠牲にガチャガチャしろ」というスタンスで提供されてる感じはしてます

メモリ管理の階層の違いを理解できていなさそうだが
メモリアロケータの話ならばRustはC++と同様に交換自由でライブラリ選択可能
可読性を犠牲にガチャガチャする必要はなくRustでは#[global_allocator]で指定するだけで交換可能
813 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 13:41:17.13 ID:7Mz5wCRP.net]: 理解できてなかったらしい
もういいや
814 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 13:57:51.76 ID:u4m8T///.net]: >>793はC言語でたとえるとmallocを使ったメモリ管理とmallocの中のメモリ管理の違いをわかっていない初心者かな
815 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 13:58:55.74 ID:NWfMWzFP.net]: そうです
初心者でした
お騒がせして申し訳ありませんでした
816 名前：デフォルトの名無しさん [2023/07/22(土) 14:25:05.31 ID:AxAuiZIS.net]: >>797
AのサイズよりCのサイズが大きいときは
フラグメントは発生しないのかな？
817 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 14:42:32.24 ID:QLIAp4G5.net]: >>802
そんなに単純じゃないよ。
確保しようとする大きさによって違う領域から割り当てるような実装も普通。
順序良く割り当てるわけではなく、
そのときの状況によって効率的になるように采配する。

仮に断片化を意図的に起こしてでも総合的に断片化の確率を減らすような
戦略を持っているのかもしれないし、
よほど深刻な場合を除いて使う側はアロケータの中なんぞ忘れておくのが吉。
818 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 14:54:17.36 ID:NWfMWzFP.net]: もちろん発生しますよ
どんな場合でも最高次数にうまくいく魔法のような戦略なんてありません
なのでケースバイケースで場合に応じて戦略を使い分けなければならない
しかしOSの実行環境なんかのアロケーターはプログラムの内部情報を何一つ持ってないから「開きメモリのリストを持っておいて最初に見つかったスキマにアサインする、足りなくなったらGC」以外に戦略の採りようがない、だから従来のプログラミング言語は自分でGCするわけです、少なくともコンパイラはコンパイルする時点でどれくらいの頻度でどれくらいのサイズのアロケーション要求が発生するかある程度情報が得られるからそれを利用してよりよい割り当て戦略をとれるチャンスがあるからです、なんならその情報をコンパイラに教えるnotificationをつけられるように設計する事もできる
しかしそれとて限界がある、だからRustはもうそれすらやらない、アロケーションは自分でやれ、そのためのツールはある程度は言語内部で用意する、ダメなら言語外部のツール使え、という「無理してやってもどうせ“最適”には程遠いからやらない」んでしょう
逆に言えばRustでプログラム組むとき、特にでかいデータの作成、廃棄を繰り返すような場合はプログラマはかなり練度が必要になるんでしょう
立ち位置としてそれくらいの事がこなせるユーザーをプログラマとして想定してるという事です
学習コストが高いんじゃなくてそもそもプログラマに要求されてる水準が高めなんですね
819 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 16:19:13.40 ID:2BLjTz4O.net]: >>804
間違い多いな
まず一般的にGCはフラグメンテーションを解決しない
特にマークアンドスイープ方式のGCや参照カウント方式のGCはフラグメンテーションは放置で関与しない

Rustについての記述は間違いだらけでなんとも言いようがない
言語外部のツール使えとはトンデモすぎて何を言ってるのかもわからない

フラグメンテーションを起こし得るメモリアロケーターについてRustはC/C++と同じ立場で同じものを使う
C/C++/Rust共通の話として同じようにjemallocなど別のメモリアロケーターを使うことができる
Rustだけ特別な方法をとったり特別な性質をもったりはしておらずフラグメンテーションについてもC/C++と同じ
820 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 16:41:16.06 ID:NWfMWzFP.net]: 素人なものですいません
スレ汚しすいませんでした
821 名前：デフォルトの名無しさん [2023/07/22(土) 17:02:30.53 ID:NRmzieuj.net]: >まず一般的にGCはフラグメンテーションを解決しない
マーク&スウィープ方式は一般的にコンパクションもやってるぞ
822 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 17:07:41.36 ID:2BLjTz4O.net]: >>807
コンパクションをするかしないかは独立した問題
マークアンドスイープ自体はコンパクションを伴わない
823 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 17:59:22.96 ID:QLIAp4G5.net]: >>808
再配置できないならそもそも論外なんだから
無関係ではないだろ。
824 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 18:05:22.75 ID:YLqzZrt5.net]: そういえば君らのメモリ管理の会話でLinkedListの使い道思い出したわ
Rustやその他の言語側じゃなくてOS側のメモリ管理にLinkedList使われてるわ
825 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 18:42:28.71 ID:2BLjTz4O.net]: >>809
再配置するのはコピーGCで使用中データ全移動と全ポインタ書き換えとなる
マークアンドスイープGCはその名の通り使用中を辿りマーク付けしてマークされなかったものを再び未使用領域とする
826 名前：デフォルトの名無しさん [2023/07/22(土) 19:01:55.55 ID:TsQs+vXV.net]: >>808
論点は”一般的”にやってるかどうかだろ
君は一般的にやってないと言ってるわけで
JavaもC#もJavaScriptもみんなGCでcompactionやってる
827 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 19:18:33.46 ID:2BLjTz4O.net]: >>812
compactionをする前にマークアンドスイープGC自体は既に終わっていて独立した別の行為
実際にそれら言語では世代別GCが行われていていて新入り若手のオブジェクトはコピーGCを行なうが古いオブジェクトはマークアンドスイープのみで再配置しない方法が一般的
828 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 19:31:27.25 ID:nB6v7J6K.net]: 隔離スレ行けアスペジジー
829 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 20:04:44.58 ID:2BLjTz4O.net]: 再配置はデータコピーとそこへのポインタ全て書き換えでコストが大きすぎるから可能な限り避けるのが正しい
世代別GCで若手オブジェクトだけに限ってコピーGCの対象にするのも若手の大半は一時的利用でコピーしなくて済むため

Rustではそんなコストをかけないだけでなくヒープ確保解放のコストすら減らすことと一石二鳥で解決する方法も取られている
例えばbumpalo crateはまとまった領域を持って追記していくだけで個別の解放コストゼロ(＝何もしない)と個別の確保コストも最小(＝追記のみor足りないとまとまったお代わり)のアリーナアロケータ
つまり未使用領域の再利用をしないことで管理不要となり最高速になるとともにまとめて一気に最高速で返す
具体的にはサーバーまたはバッチ処理で各対象固有データのみそこから確保してその対象を終える時に破棄
これはフラグメンテーションを防ぐのに非常に効果的な方法
830 名前：デフォルトの名無しさん [2023/07/22(土) 21:33:49.24 ID:kHWj4RWJ.net]: まーた複オジが知ったかぶりして無知晒してるw
初心者かなww
831 名前：デフォルトの名無しさん [2023/07/22(土) 22:04:25.70 ID:kdu4dn9d.net]: Rust使うくらいならJavaかC#で良いのでは？
832 名前：デフォルトの名無しさん mailto:sage [2023/07/22(土) 22:08:51.83 ID:wR/xGD2g.net]: RustとC#だとどっちがいいの？
833 名前：デフォルトの名無しさん mailto:sage [2023/07/23(日) 02:44:41.28 ID:lmJrnSr9.net]: >>815
GCのないRustが速いわけだ
834 名前：デフォルトの名無しさん mailto:sage [2023/07/23(日) 11:09:10.60 ID:kMNWXVHy.net]: >>815
C/C++でも同じアルゴリズムのアロケータあるで
835 名前：デフォルトの名無しさん mailto:sage [2023/07/23(日) 11:10:16.97 ID:dOw1chPf.net]: >>817
🤮
836 名前：デフォルトの名無しさん mailto:sage [2023/07/25(火) 06:32:45.09 ID:7X7HwnNv.net]: >>820
言語に関係なくそこへ行き着くんだよな
もちろん通常はフラグメンテーションなんか気にせずに普通にコードを書けばよく
稼働時間の長いプロセスでフラグメンテーションが実際に起きた時の解決策の一つ
837 名前：デフォルトの名無しさん mailto:sage [2023/07/27(木) 13:16:19.02 ID:/bGsBsBb.net]: play-rustのコードのコピペのやり方教えて下さい
具体的にはお題スレの

https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=f627f3a5de4a0c467f015a8b1527c141 <
838 名前：br> のコードコピペする方法がわかりません よろしくお願いします []: [ここ壊れてます]
839 名前：デフォルトの名無しさん mailto:sage [2023/07/27(木) 14:04:04.46 ID:90/I2Z5n.net]: rustは型推論をしてくれると聞いたのですけど、結果どういう型になったか調べる方法はありますか？
Haskellのghciの:tに当たるやつです
例えはghci内で
prelude> let f n = sum [ x^n | x<- [1..5] ]
として
prelude> :t f
とすれば
( Num a, Integral b ) => b -> a
のように返してくれます
rustでコンパイラの型推論の結果どういう型に決定したのか調べる方法はありますか？
840 名前：デフォルトの名無しさん mailto:sage [2023/07/27(木) 14:28:57.60 ID:p+3LvAw4.net]: >>824
LSP 対応のエディタ (VSCode など) を使ってるならそのへんにカーソルを合わせるだけで型は見れるよ。
841 名前：デフォルトの名無しさん mailto:sage [2023/07/27(木) 21:59:53.82 ID:x4QyUuiY.net]: >>824
安直な方法としては関数の戻り型なら -> i32と嘘の型宣言を指定すれば型不一致で正しい具体型をコンパイルエラーに表示してくれる
プログラムで表示したいならこれ
fn get_type<T>(_: T) -> &'static str {
std::any::type_name::<T>()
}
842 名前：デフォルトの名無しさん mailto:sage [2023/07/27(木) 23:11:30.70 ID:sTDTKxns.net]: >>825
>>826
あざっす
843 名前：デフォルトの名無しさん mailto:sage [2023/07/27(木) 23:12:33.60 ID:paov2RlH.net]: rustの型推論って曖昧なことを許容したっけ？
すべて一意にならないとならないと思ってたけど
844 名前：デフォルトの名無しさん mailto:sage [2023/07/28(金) 19:39:32.86 ID:4cjf/6GX.net]: >>828
正しい
ジェネリックであってもパラメタは各々で必ず一意に静的に確定せねばならず
impl Traitで型宣言しても各々で一意に具体的な型に静的に確定する
特にそれが関数の引数ならば生成コードは単相化される

ただしdyn Traitはそれらが静的ではなく実行時のオブジェクト生成毎に個別に一意の具体的な型に確定する点で異なる
コンパイル時の静的な生成コードは複数の型で共有となるためvtableを持って対処している
845 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 16:54:29.41 ID:Nh9kevR9.net]: なるほど
Rustは最終的にコンパイルが終わって型が完全に推論が終わって単相型が決定した状態でしかわからないのかな
当然get_typeで得られるstrは推論終わって単相型が割り当てられた後の型しかわからないんやな
846 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 18:53:43.03 ID:nTghkNr5.net]: コードを書いた時点で型は決まるし書いた人は型を把握できる
ジェネリックな関数だとしても型パラメタ以外の部分は確定している
その関数を呼び出す側が最後のピースとして型パラメタを指定して完全確定する
847 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 19:01:27.37 ID:mkN3FcGi.net]: そうなんよねぇ
ML型型理論ならexpression毎に最も一般的な型が決まる
Haskellは型を指定しない場合自動的にその最も一般的な型を確定させてghciとかで調べられる
今のところ上がってる方法ではRustではそれに該当する方法はなさそう
848 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 19:02:57.30 ID:mkN3FcGi.net]: イヤまだvscideとかのやつは試してないな
これならできるんかな？
849 名前：デフォルトの名無しさん [2023/07/29(土) 20:36:12.76 ID:JeVM9tS2.net]: こいつダメだわ
ある意味複オジ2世
850 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 21:40:33.16 ID:EPaDIYai.net]: >>830
> Rustは最終的にコンパイルが終わって型が完全に推論が終わって単相型が決定した状態でしかわからないのかな
いやもうrustは変数宣言時に定義した型の変更を許さないのよ（基本的に）
だから型推論は変数宣言時のものを利用したり、関数の場合は返値、手打ちの数字の場合はデフォルトの型に決め打ちされて型推論されるわけ
いちいち型を調べる必要がない
ジェネリックに関しても基本的に場合分け
851 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 21:44:15.48 ID:EPaDIYai.net]: pythonとかjavascriptとか勝手に型を変更する（ような振る舞いをする→変更するとは言ってない）
言語なんてサイテーだと個人的には思う
852 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 22:05:07.65 ID:2dUASh9D.net]: >>835
どゆこと？
rustの型システムはしゃないの？
853 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 22:10:13.37 ID:2dUASh9D.net]: ごめん、誤字った
rustの型システムはMLじゃないの？
いわゆる型の全体と命題論理の全体を一対一に対応させる
で、その命題論理の目モデルを探す事＝単相型を決定する事がMLの型推論システムで、Rustもそれ採用してるんだと思ってるんだけど
で単相型が割り当てられる“命題”に対応してるものが多相型と呼ぶんだと教えてもらった事あるけど
854 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 22:19:51.45 ID:381IW7f/.net]: も少し書くなら基本的にrustもhaskellも型システムは基本的な原理は同じじゃないのって話
それを説明する用語としてRust特定の説明の仕方をしてるのかもしれないけど説明の仕方や用語の使い方を変えたところでどっちもカリーハワード理論に基づく型システムじゃない？
855 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 22:51:50.32 ID:381IW7f/.net]: もし同じならHaskellと同じく例えば

mysum [] = 0
mysum (a:as) = a + ( mysum as )

なら　Haskell ならmysumの型は

( Num a ) => [ a ] -> a

と推論されます
RustでもML型システムである限り少なくとも内部的には同じような型が割り当てられてるはずだと思うんですけど
もちろんこれら推論された型を全部総合して実装時には特定の単相型が割り当てられます
この辺のメカニズムはHaskellもRustも同じじゃないんでしょうか？
856 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 23:06:20.41 ID:MBm8IaU2.net]: まずRustの数値リテラルはHaskellと違って多相な型を持たないです
857 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 23:25:14.79 ID:I6XWshKt.net]: >>840
分かってる気になっておかしなことを書く癖を直したほうがいいと思うが…
858 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 23:36:28.14 ID:I6XWshKt.net]: 人間としての推論機構が間違っている

基礎を勉強してルールとしてそれを覚えてから
それを基に推論を行わないと意味がないと知るべき
859 名前：デフォルトの名無しさん mailto:sage [2023/07/29(土) 23:51:52.56 ID:nTghkNr5.net]: >>832
最も一般的な型ではダメでRustは唯一に確定しなければならない
Rustは関数(メソッド)の引数も返り値も型宣言が必須だけど
そこでの型はジェネリックで型パラメータを持つものも多く
その型パラメータのトレイト境界などによる制約とそのトレイト実装をする型が複数あることから複数解も生じる
複数解がありうるならばコンパイルエラーとなり明示的な型指定を求められる
唯一の例外が数値リテラルの利用により数値型までは確定している時でそれが整数ならば自動的にi32型に解決される
860 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:16:28.33 ID:psEFm3Dt.net]: >>841
その説明はよくrustの解説本にあるけど多分字面通りの意味にとってはいけないんじゃないかと
だってプログラム全体を見なければ型なんか決められるはずない
ML型の型システムである限りHaskellのexpressionから定まる最も一般的な多相型持ってると思う、でなければML型型システムと呼べない
さっきあげたmysumなんかその典型、あのmusumはnum classに属するすべての型で使うことができる、もしこのような多相型を持たない理論ならすべての足し算を持つクラス全てにほとんど同じsumを定義させられることになる、それを避けられるのがML型システムの1番の売りなんだから
てか上の例のmysumに相当する書き方Rustでもできるんでしょ？
無理なん？
861 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:18:56.60 ID:psEFm3Dt.net]: ML型システムと呼べないは言い過ぎかな？
まぁ型宣言省略しても型推論してくれるならML型型システムと呼べなくはないけど、でも流石にさっきのmysumみたいな記述は許されてるんじゃないの？
862 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:19:43.44 ID:dT6HJfPv.net]: ハスケル！
ハスケル！
ハスケル！

その毎度のハスケルおじさんに構うのは止めとけよ
Rubyおじさんと変わらないんだからさあ
自覚のない荒らしだよ
863 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:19:47.09 ID:psEFm3Dt.net]: >>844
そうなん？
じゃあさっきのmysumみたいな書き方はRustではできないのあ？
864 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:21:02.70 ID:dT6HJfPv.net]: Haskellおじさんは自分の思いをここに書かないと死んじゃうの？
なんでRustをRustとして扱いたくないの？
865 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:21:05.69 ID:psEFm3Dt.net]: >>847
目障りなら無視してくれていいけど純粋に新しいプログラミング言語に挑戦してるだけだから邪魔しないでくれる？
君は一生ひRustに捧げればいいやん
866 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:22:04.96 ID:dT6HJfPv.net]: ハスケルおじさんは壁に向かってハスケルハスケル行ってればいいのに
867 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:24:01.50 ID:dT6HJfPv.net]: マクロしらんの？
868 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:24:09.72 ID:psEFm3Dt.net]: >>849
すでに習得した言語の対比して新しい言語に挑戦するのは当たり前やろ？
Haskellの型システム理解するのにどれだけの時間をかけて教科書を読み、論文を読み、プログラミングを組んでみたか、その資産を使いたいとおもうのがそんなに悪いんか？
黙っといてくれよ
869 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:24:40.66 ID:dT6HJfPv.net]: >>853
悪いに決まってるだろ？
そんなこともわからんの？
870 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:26:23.01 ID:dT6HJfPv.net]: 論文読まないとプログラム言語が理解できないんだから困ったやつだろ
推論システムが変
871 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:29:41.31 ID:dT6HJfPv.net]: まずは"真面目にRust学習"しろ
そして習得しろ
そして疑問を解決しろ
872 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:32:06.97 ID:psEFm3Dt.net]: >>855
すまんけどオレは論文なんか読まなくても理解できるような天才じゃないんだよ
君は論文なんぞ読まなくても何もかもわかる天才なのかもしれんけど世の中そんな天才ばかりじゃないんだよ
オレみたいに寝食忘れて努力に努力を重ねてやっと話しが分かる鈍才もいるんだよ
鈍才が悪あがきするの邪魔せんでくれ
873 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 00:33:26.30 ID:psEFm3Dt.net]: >>856
もうオレに関わらないで
その方が双方幸せじゃないか？
874 名前：デフォルトの名無しさん [2023/07/30(日) 02:16:35.97 ID:ArPWIRVu.net]: 大先生3人に共通するのは
自分は分かってるという根拠のない思い込みと
何度指摘されても全く反省せず同じことを繰り返す傍迷惑な行動
875 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 02:39:34.14 ID:g1ghpAt+.net]: >>848
consセルを使った簡易なリスト操作表記をRustは言語仕様レベルではサポートしていない
だからそのHaskellのmysumをその表現のまま移植するのは本質的ではないため
意味だけを重視してリストをイテレータで表現し再帰定義している点を尊重すると

use std::ops::Add;
use num::Zero;

fn mysum<T>(mut iter: impl Iterator<Item = T>) -> T
where
T: Zero + Add<Output = T>,
{
match iter.next() {
Some(n) => n + mysum(iter),
None => T::zero(),
}
}

一例としてこのようにmysumはジェネリックに書ける
mysumに最低限必要なトレイト境界(Zero + Add)のみを課している
もちろんこの関数だけで以下のように機能して計算結果も合う
assert_eq!(15, mysum([1, 2, 3, 4, 5].into_iter()));
876 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 02:43:03.72 ID:g1ghpAt+.net]: >>860のmysumでトレイト境界はZeroとAddさえ満たしていれば通常の数値でなくても構わないので
例えば以下のようなHoge型を定義して必要なトレイト境界(ZeroとAdd)を実装すると

#[derive(PartialEq, Debug)]
struct Hoge(usize);
impl Zero for Hoge {
fn zero() -> Self { Hoge(0) }
fn is_zero(&self) -> bool { self.0 == 0 }
}
impl Add for Hoge {
type Output = Self;
fn add(self, rhs: Self) -> Self {
Hoge((1 << (self.0.trailing_ones() + rhs.0.trailing_ones())) - 1)
}
}

先程と同じように「15 = 1 + 2 + 3 + 4 + 5」をHoge型で表現することで
Hogeについてもmysum()は以下のようにきちんと計算できていることがわかる
assert_eq!(Hoge(0b111111111111111), mysum([Hoge(0b1), Hoge(0b11), Hoge(0b111), Hoge(0b1111), Hoge(0b11111)].into_iter()));

Haskellに全く詳しくないので逆に質問というか教えてほしい
このHoge型をHaskellで定義(実装)するにはどのようなコードになるのか？
そしてこのHoge型に対してもHaskell版>>840のmysumで使えるようにするにはどうするのか？
たぶん型クラスNumの代わりに型クラスZeroとAddを指定するだけで済むのだろうけど
もしHaskellに型クラスZeroやAddがなければそれを定義する形になるのだろうか？
よろしくお願いします
877 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 10:57:59.43 ID:TSIasAnA.net]: >>861
Haskellではこうなります
https://ideone.com/PKy694

mysum [] = 0
mysum ( a : as ) = a + ( mysum as )

hogePlus a 0 = a
hogePlus a b | even b = 2 * (hogePlus a ( div b 2 ) )
hogePlus a b = 1 + 2 * (hogePlus a ( div b 2 ) )

data Hoge = H Integer deriving Show

instance Num Hoge where
( H x ) + ( H y ) = H ( hogePlus x y )
fromInteger = H

main = do
print $ mysum [ 1..5 ]
print $ hogePlus 3 7
print $ mysum [ H 1, H 3, H 7, H 15, H 31 ]
878 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 10:58:19.77 ID:TSIasAnA.net]: この例だとmysumの型は
mysum :: ( Num a ) => [ a ] -> a
と推論されます
すなわちmysumは

　aがNum class に属する型aに対して[a]型の値に対してa型の値を返す関数の型

です
よってmysumをある型Hogeで利用するにはHogeにNumインスタンスを導入しなければなりません、すなわちRustでは
impl Num for Hoge { ... }
のように書く部分です( >> 860 のAdd,Zeroを実装してる部分に該当します)
本来はNumのminimal complete definition全部実装するべきでHaskell1990までは“定義が揃ってない”とおこられましたが。2010以降は必要な分だけ実装すれば良い、ただし実行時エラーは覚悟しろという風に変更されてるようです(未確認、コンパイラがエラー吐かなくなったので)
879 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 12:33:59.93 ID:g1ghpAt+.net]: >>862
RustのAddトレイト実装によって足し算(a + b)のみを他の型でも自由に使えるようにできる機能をHaskellは持っていないということ？
そのためHaskellではやむを得ない代替処置としてHoge型を型クラスNumへ入れてしまうことで解決したということ？

例えばRustではStringについてもAddトレイト実装があり
let s = String::from("abc");
assert_eq!(s + "xyz", String::from("abcxyz"));
といったこともできます
同様に自作の型に対しても足し算のみの実装が可能です
Haskellではこのようなケースでもオーバースペック気味にNumを使うしかないのでしょうか？
880 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 12:37:15.22 ID:g1ghpAt+.net]: >>863
Haskellでは実行時エラーを覚悟しろという点は非常に困りますね
今回のケースも無理やりにNumへ入れてしまったのに足し算しか実装していないから引き算や掛け算などで実行時エラーとなるわけですよね

ちなみにRustのnumクレートでは
trait Num: Zero + One + NumOps + PartialEq とトレイト境界があり
impl NumOps for T where T: Add + Sub + Mul + Div + Rem {} の実装があります
つまり自作の型で使う場合は全ての演算を実装した上で更に加えて
impl Num for Foo とするとようやくNumになれます
したがってRustでは不備があればコンパイル時エラーとなり安心して安全に使うことができます
881 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 12:47:58.55 ID:wjjxPYUe.net]: そろそろ隔離スレ行ってろカスども
882 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 14:02:34.57 ID:iwDEPHME.net]: Haskell 的には演算子オーバーロードを目的として型クラスを使うことはしない。
Num な性質を持つ値の操作として + という名前の演算子もあるというだけで、
演算子として + を使いたいから型クラスの実装を定義するということはしないってこと。
それに、 Num はいくつかの演算子を使えるというだけではなく
それらの演算子の関係で満たさなければいけない性質があるので個々の演算子 (に結び付く型クラス) として分解できない。
https://hackage.haskell.org/package/base-4.18.0.0/docs/Prelude.html#t:Num

価値観が違う。

なんせ Haskell では記号を組み合わせていくらでも演算子を作ることが出来て
たとえば <$> とか >>= とかいう変な演算子を必要なだけ作れるので少ない演算子を取り合う必要がない。

Num の性質の中で + を使うってのと、
なんらかの足し算っぽい操作は別の名前で定義されているべきだし、
Haskell ではそれで困らない。

価値観が違う。
883 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 18:06:30.12 ID:mgfeU+D6.net]: 新設の見慣れぬ演算子の種類を勝手に増やして各々が異なる意味付けすることは可読性を下げるのみで百害あって一利無し

>>863
コンパイラがエラーを吐かずに実行時エラーとなるのはマズいな
Haskellの価値観はよくない
884 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 19:58:32.75 ID:Llc746TG.net]: すいません、筆が滑りました
もちろんコンパイル時にエラー吐きます
以前のHaskellだと例えそのプログラムで使われてない場合でも実装しないとエラー吐いてました
しょうがないのでwhere句に使いもしないのに
_ * _ = undefined
signum _ = undefined
....
を書いてました
流石に無意味すぎて使わないのは書かなくて良いことになったようです
使ってるのに未実装はもちろんコンパイラが見つけてくれます
885 名前：デフォルトの名無しさん mailto:sage [2023/07/30(日) 20:06:02.24 ID:iwDEPHME.net]: どうでもいいけど signum という名前を見るとヴォルケンリッターを連想してしまう……
886 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 08:16:09.72 ID:G+nEO2Oo.net]: どうでもいいなら・・・煽りたくなるな
887 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 10:23:47.98 ID:8wbRk2dY.net]: use Hoge::prelude::*; って良く観るがダサいなー
888 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 10:35:07.69 ID:i3Lje9zm.net]: でもまあ機能ごとにモジュールを整理しても
それとは別によく使う集合があるのも現実だし。
889 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 11:07:00.50 ID:sgBBFIN2.net]: global 禁止(キリっ
890 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 12:25:28.59 ID:lZja90Kc.net]: >>872
preludeは邪道で非推奨
自動適用される標準ライブラリのprelude以外は使わない＆設けない
例えばtokio::preludeも廃止された
891 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 12:34:21.81 ID:eCR2qI4e.net]: Rustで、Vecに要素を追加したとき、メモリ不足で
メモリ確保に失敗した場合、どうなるんですか？
C++の場合は「例外」がthrowされますが。
892 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 14:38:56.18 ID:uDpaCeqo.net]: pqnic
893 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 16:40:54.67 ID:cE0Z6rmj.net]: ﾋﾟｸﾆｯｸ?
894 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 17:53:43.20 ID:1dCFbVL1.net]: fn っていちいち略さなくても function でよくない？

書き込める変数の宣言に mut ってつけるのもダサい
895 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 18:05:43.81 ID:+bjI2PCn.net]: mutはガチでダサい
何かいい記号はなかったのかとｗ
896 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 18:13:53.64 ID:+bjI2PCn.net]: 英語圏の人たちはmut見てcoolに感じるとか日本人と感性が違う可能性がある
897 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 18:38:57.32 ID:9nT3Yxeb.net]: >>879
感性が古いよ
898 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 18:48:05.02 ID:STr6yd2M.net]: 今までミュートと読んでいた
899 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 18:49:54.52 ID:A3cMstwB.net]: unicode解禁にして変にすればいい
900 名前：デフォルトの名無しさん [2023/07/31(月) 20:49:15.69 ID:X0OEUfKN.net]: >>882
短い略語を使いたがるのはメモリ容量が少なかった昔の習性・感性だろ。
昔に作られた言語のFortranとPascalですらfunctionは略さなかったのに、
今になって変な略語を採用したRust開発者は工学的センスも美的センスもない。

比較的新しい言語のF#はmutと略さずにmutableと書く。
901 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 21:15:27.96 ID:+bjI2PCn.net]: BASICの頃はDEF FNと言うので関数を定義してた
902 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 21:25:40.03 ID:4/4p/Sxt.net]: 様々なプログラミング言語があって千差万別な中
大した問題ではないキーワード名やその多少の長さに文句をつける人はダメな仕事できないやつ
仕事できる人は文法とその意味論を比べる
903 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 21:34:38.41 ID:+bjI2PCn.net]: ダサいのはダサい

今後何があってもbegin end区切りの言語は使わないと思う
delphiやってた時もimplementationと言うのを見てクソダサいなと感じた
Objective-Cも二度と接することはないだろう
904 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 22:59:44.59 ID:i3Lje9zm.net]: kotlin や swift の前で同じこと言えるの？
905 名前：デフォルトの名無しさん mailto:sage [2023/07/31(月) 23:19:46.93 ID:+bjI2PCn.net]: implementation　Point　{
public function ...
｝
906 名前：デフォルトの名無しさん [2023/08/01(火) 03:00:40.65 ID:8wU+ches.net]: >>881
constより2文字も短い！かっけええぇぇぇ！！！
かもな
同意しないけど
907 名前：デフォルトの名無しさん mailto:sage [2023/08/01(火) 03:53:49.10 ID:enF/Vqu1.net]: constは定数だからコンパイル時に静的に確定する
immutableかmutableかというのはconstとは無関係な概念で実行時の変数の値が書き換わるかどうか
つまりRustの非mut (immutable)は定数ではなく実行時に値が決まる変数
908 名前：デフォルトの名無しさん mailto:sage [2023/08/01(火) 11:16:59.87 ID:AvEKEx5a.net]: let x : u32 = 1234;
と
const x : u32 = 1234;
は違うんですか？
909 名前：デフォルトの名無しさん mailto:sage [2023/08/01(火) 11:22:28.49 ID:AvEKEx5a.net]: なるほど、const = の右辺値はconst 文脈で書かれていてコンパイル時に決定できないといけないけど let = の右辺はその制約がないのか
910 名前：デフォルトの名無しさん mailto:sage [2023/08/01(火) 17:52:49.94 ID:3uGNwlqu.net]: constはコンパイル時に値が決まる定数となり定数名は大文字で書く
letは(mutの有無に関係なく)実行時に値が決まる変数となり変数名は小文字で書く
mutの有無はその変数の値が書き換えられるかどうかだけの違い
911 名前：デフォルトの名無しさん mailto:sage [2023/08/01(火) 18:49:11.32 ID:Nt/KTAzO.net]: 自分は素人だけどそれじゃあ型に対する言及が抜けてないですか？
912 名前：デフォルトの名無しさん mailto:sage [2023/08/01(火) 20:27:35.06 ID:3uGNwlqu.net]: 型とは直交する概念なので型とは無関係
任意の型で成り立つ
913 名前：デフォルトの名無しさん mailto:sage [2023/08/01(火) 22:08:28.57 ID:YdsBZTXH.net]: 'static
914 名前：デフォルトの名無しさん mailto:sage [2023/08/01(火) 22:38:58.55 ID:Nt/KTAzO.net]: constはシャドーイングは行われない
変数と違い型を必ず明示しなくてはならない
915 名前：デフォルトの名無しさん mailto:sage [2023/08/02(水) 00:09:43.49 ID:IOFZl0B3.net]: >>899
なんでですか？
constシャドーイングしてなんか不都合あります？
916 名前：デフォルトの名無しさん [2023/08/02(水) 00:12:43.58 ID:/ED8qpF1.net]: >>893
constならROM領域に置ける
917 名前：デフォルトの名無しさん mailto:sage [2023/08/02(水) 00:12:59.71 ID:IOFZl0B3.net]: あ、わかった
そりゃそうだ
918 名前：デフォルトの名無しさん [2023/08/02(水) 09:00:43.40 ID:4pI1Wfnv.net]: 関数名というか関数を格納した変数？にもmut付けるときあるけど
動作中に関数を変えるのが目的？って表明以外の意味ある？
919 名前：デフォルトの名無しさん mailto:sage [2023/08/02(水) 13:19:46.95 ID:MBDISWVo.net]: 関数ポインタかラムダ式（クロージャ）かで意味が変わりそうだな

関数ポインタの場合は途中で別の同型の関数に差し替えるときにmutが必要
クロージャの場合は途中で内部の変数が変更される（FnMutになる）ときにmutが必要
（クロージャは型の関係で別の関数に差し替えることはできないはず）

下の例だとf,gのどちらもmutがないと怒られる

fn print_foo() { println!("foo"); }
fn print_bar() { println!("bar"); }

fn main() {
let mut f: fn();
f = print_foo;
f();
f = print_bar;
f();

let mut i = 0u32;
let mut g = move || { println!("{i}"); i += 1; };

for _ in 0..5 { g(); }
}
920 名前：デフォルトの名無しさん mailto:sage [2023/08/02(水) 13:23:57.98 ID:MBDISWVo.net]: そこに置かれてる値（関数ポインタ or クロージャ）が変更されるという意味では同じか
921 名前：デフォルトの名無しさん mailto:sage [2023/08/02(水) 18:24:39.32 ID:SI51iZ7R.net]: let mut hoge; じゃなくて

むしろ let hoge = 3; と mut hoge = 3; の二種類に分ければ美しくてよ
922 名前：デフォルトの名無しさん mailto:sage [2023/08/02(水) 19:02:02.79 ID:F3jAz55G.net]: static mut もあるし
letはパターンマッチ文だからlet (mut a, b) もあるし
if let Some((ref mut p, ref q)) もあるし
923 名前：デフォルトの名無しさん [2023/08/02(水) 20:18:56.34 ID:/ED8qpF1.net]: >>906
それは無い
924 名前：デフォルトの名無しさん mailto:sage [2023/08/03(木) 07:43:41.06 ID:9tsUh6Bs.net]: 速い！安全！ださい！
925 名前：デフォルトの名無しさん mailto:sage [2023/08/03(木) 08:17:38.34 ID:8npqW66R.net]: >>907
mutを単独キーワードに分離したRustの設計方針の勝利だな
926 名前：デフォルトの名無しさん mailto:sage [2023/08/03(木) 10:00:57.61 ID:W+hOnHrE.net]: かわいい
北朝鮮みたい
927 名前：デフォルトの名無しさん mailto:sage [2023/08/03(木) 21:15:21.47 ID:j7849mpF.net]: こんなスレ見てるなんてダサいぞ！
928 名前：デフォルトの名無しさん [2023/08/04(金) 09:07:52.99 ID:XLfSEGlw.net]: かわいい
埼玉県みたい
929 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 17:59:34.17 ID:xBSreVT+.net]: 任意長整数型演算の実装の演習してるんですけど

・和の時には下の桁から、大小の比較の時は上の桁から順次比較するので双方からのアクセスをO(1)で行いたい
・任意長なので加法のときにover flowしたときitemの追加ができないとダメ

この場合どのcollection型が有利ですか？
ソースが難しすぎてわかりません
情報お願いいたします
930 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 19:27:39.64 ID:3wcIZOky.net]: 自分ならVec使う
931 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 19:29:40.12 ID:lVXXe/mp.net]: >>914
何を問題にしているのかわからない
言語に関係なく連続体のデータ型(配列やベクタなど)の順次アクセスは
前から後ろから関係なくサイズNに対して総コストO(N)で1つあたりO(1)
それらのうち固定長ではなくサイズを伸ばせるデータ型(ベクタ)なら要素を追加できる
RustならVec
932 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 20:21:24.84 ID:xBSreVT+.net]: >>916
各collectionの内部構造がよくわからないんですよ
ソース全部読めてなくて
vecってLinkedLustみたいな数珠繋ぎじゃないですよね？
933 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 20:24:19.56 ID:xBSreVT+.net]: >>915
ありがとう
確かに片方だけ伸ばすならbecで良さそうなんですよね
しかし後でよくよく考えたら掛け算の時に一の位の方向にも伸ばせた方が便利な気もしてきて
でもそっちは絶対じゃないんですよね
なんせvecのソースがむずい
934 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 20:32:19.03 ID:Mgx3ApDu.net]: ソースよりドキュメントを見なよ。
図つきで解説されてるから。
Vec は必要に応じて自動で再配置する配列ってかんじ。
要素は連続して配置される。
935 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 20:50:29.31 ID:WEauDaB9.net]: >>919
https://doc.rust-lang.org/std/collections/index.html
とか読んだんですけどよくわからないんですよ
rust専用スレならstd::vec全部目を通せてる人いるかなと
連続して確保される領域の幅とかは指定できます？
936 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 20:51:36.50 ID:lVXXe/mp.net]: >>917
性質が重要なのであってよほどのことがないかぎり実装内部のソースを知る必要はない
LinkedListは極一部の用途を除きほとんどの用途で遅く不利になり今回も考える必要はない
これらは言語と関係なく一般的な話
937 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 21:11:21.94 ID:kGEgc8zj.net]: >>921
とりあえず今はガロアの連分数使って円周率の計算でもやってみようと思ってるんですけど、その場合計算する項のlog orderで桁数が増大していきます
でも例えばbinary splittingとかにすれば桁数の上昇具合が変わってきます
そういう用途に応じて適切なcollection型の使い分けできるようにしたいんですよ
あくまで練習なので
ソース読みはまぁ趣味みたいなもんなんですけどそもそもRustの自習が趣味なので
938 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 21:11:35.12 ID:Mgx3ApDu.net]: >>920
だからドキュメント読めってば。
Vec はポインタとキャパシティと長さを管理する仕組みだと書いてある。
https://doc.rust-lang.org/std/vec/struct.Vec.html#guarantees
実体が配列だからスライスの形で扱うことも出来る。
もし C++ を知ってるなら設計理念的には vectorと同じ感じとおもっていいと思う。
939 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 21:16:41.06 ID:kGEgc8zj.net]: >>923
まぁ実はちょっと立場上普通の人より深く知ってる事を要求されることが多いんですよ
もちろんRustを並の人より知ってると言えるには後何年か修行しないといけないんでしょうけど、そもそもRustについては趣味なのでそこまで深く理解しなくてもいいとは思ってます
まぁ趣味なのでボチボチ読みます
ありがとうございます
940 名前：デフォルトの名無しさん [2023/08/06(日) 21:39:48.28 ID:+jzrd7Vj.net]: Haskell君と同じ臭いがしますね～w
941 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 22:09:28.45 ID:lVXXe/mp.net]: >>922
何度も書いて伝わっていると思うが各データ型の性質や各用途への向き不向きは使用言語と関係ない話
その適切なcollection型の使い分けというのが仮に必要だとしても各言語と関係なく抽象的なレベルで考えて可否を判断すべきこと
その上でベクタ型のデータ構造では何がいけないのかの問題点も見えてこない
942 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 22:29:25.87 ID:jEjmg3Hf.net]: やっぱり>>914のようにサイズが不定である場合にはダメですね

The capacity of a vector is the amount of space allocated for any future elements that will be added onto the vector. This is not to be confused with the length of a vector, which specifies the number of actual elements within the vector. If a vector’s length exceeds its capacity, its capacity will automatically be increased, but its elements will have to be reallocated.

まぁ一般論ではなくて××桁まで計算するとか決めうちして使います
どのみち掛け算最終的にはFourier変換でやってみるつもりなのでその場合不定長だとメチャクチャ難しいし []; [ここ壊れてます]
944 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 22:59:01.67 ID:lVXXe/mp.net]: >>927
不定長なら再配置を含めてもVecが有利
再配置コストは例えば2^nから2^(n+1)へ広げる度にしか発生せず誤差となる
それよりも連続領域に配置されることによるメモリキャッシュ効果が絶対に効く
945 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 23:14:54.40 ID:vwDBawzd.net]: >>928
そうなんですか？
でもドキュメントには続いて

For example, a vector with capacity 10 and length 0 would be an empty vector with space for 10 more elements. Pushing 10 or fewer elements onto the vector will not change its capacity or cause reallocation to occur. However, if the vector’s length is increased to 11, it will have to reallocate, which can be slow. For this reason, it is recommended to use Vec::with_capacity whenever possible to specify how big the vector is expected to get.

とありますよ？
946 名前：デフォルトの名無しさん mailto:sage [2023/08/06(日) 23:50:23.90 ID:lVXXe/mp.net]: それを読んで再配置があった場合でも1回あたりO(1)で済んでいることが理解できないならば
Rustの勉強でもなくプログラミングの勉強でもなくCSなどの基礎から学ぶことをおすすめする
そういう基礎を理解しないままO(1)で行ないたいと最初の質問で書いていたのもヤバい
何度も伝えているが各言語と関係なく成り立つ話なのだから各言語に立ち入る前に理解を済ませておくべき
947 名前：デフォルトの名無しさん mailto:sage [2023/08/07(月) 00:14:34.21 ID:KoOATDug.net]: >>930
>CSなどの基礎から学ぶことをおすすめする
任意長整数型演算の実装の演習をするような人ならCSで学ぶ程度の知識はあるんじゃなのか
当然、データ構造についても一通りの知識はあると思うが
948 名前：デフォルトの名無しさん [2023/08/07(月) 00:41:08.66 ID:Sa+WohTx.net]: “amortized O(N)”を”1回あたりO(1)”に変換するあたりは流石オジ
でもCS基礎を学べというオジの主張に今回ばかりは同意するよ
949 名前：デフォルトの名無しさん mailto:sage [2023/08/07(月) 00:47:42.86 ID:uTLlh+jk.net]: >>930なんでO(1)で済むんですか？
そもそもデータ全体を連続領域に確保するんでしょ？
その延長する部分のヒープがもう埋まってたらデータ全部丸写しするしかないんじゃないですか？
大体そもそもデータを連続領域に確保して前からも後ろからも関係なくアドレス1発でアクセスもできて、その上データの追加もO(1)でできるとかなら無敵じゃないですか？
そんな魔法のよなメモリ管理できるハズないのでは？
950 名前：デフォルトの名無しさん mailto:sage [2023/08/07(月) 00:48:41.30 ID:Lr/s88yL.net]: Vecって単純過ぎてデータ構造では扱わなかったりするのかな
ならし解析では最初に出てきそうなネタだけど
951 名前：デフォルトの名無しさん mailto:sage [2023/08/07(月) 00:50:22.19 ID:uTLlh+jk.net]: ああ、データの読み書きが一回あたりI(1)ですか
でも今データの追加は整数の桁数が一上がるごとに発生するんですよ？
あらかじめデータの桁数が不明でそれが難しいと言ってるじゃないですか
足し算のたびにコピー発生しますよ？
952 名前：デフォルトの名無しさん [2023/08/07(月) 00:53:46.05 ID:O5oF7I6f.net]: こいつぅ
絶対わかってないやんw
953 名前：デフォルトの名無しさん mailto:sage [2023/08/07(月) 00:53:52.95 ID:++BmxY1A.net]: 実際バイナリスプリッティングでマクローリン級数で足し算する場合とかどうやってあらかじめ必要桁数予言するの
954 名前：デフォルトの名無しさん mailto:sage [2023/08/07(月) 00:54:45.54 ID:eXrQj8ZH.net]: 実際どんな用途かも具体的に書いてるのに
955 名前：デフォルトの名無しさん mailto:sage [2023/08/07(月) 02:21:35.00 ID:pearvhja.net]: 2年くらい前の過去スレと今の状況見比べて泣いちゃった
956 名前：デフォルトの名無しさん [2023/08/07(月) 10:50:23.98 ID:wl/Lx6N5.net]: ここまでvecdeq無しとは
957 名前：デフォルトの名無しさん mailto:sage [2023/08/07(月) 18:18:54.25 ID:UTlzilSe.net]: VecDequeもその名の通りVec(正確にはどちらもRawVec)で作られていて
確保されている連続領域に対して未使用領域が末端か途中かの違いしかない

>>933は確保されている連続領域が埋まった時のコストを気にしているようだが
サイズNが埋まるまでの再配置の総コストは最悪ケースでもわずかN-1回の読み書きコストで済む

例えばサイズN/2が埋まった時にその倍のサイズNの新たな連続領域へ再配置するためにはN/2回の読み書きが発生
仮に最悪ケースでサイズ1からスタートしてもそれまでの累積の再配置コストはN/2+N/4+N/8+...+1 ＝ N-1が上限値となる
つまりサイズNが埋まるまでの再配置の総コストは最悪のケースで読み書きN-1回でありO(N)で済む

一方でサイズNが埋まるまでの再配置以外の読み書きが何回行われるかを今回のケースで考えると
次々とサイズが倍々に増えていく計算の場合は最小でも合計O(N)回の読み書きが起こり
次々とサイズがリニアに増えていく計算の場合は最小でも合計O(N^2)回の読み書きが起こり
もっと緩やかにサイズが増える場合や上述の増え方の場合でも普通に読み書きが多い計算なら合計O(N^2)を超える
現実のほとんどの計算においてVecの再配置コストO(N)は誤差となる
958 名前：デフォルトの名無しさん [2023/08/09(水) 00:49:09.66 ID:52BV6d5f.net]: >>931
＞当然、データ構造についても一通りの知識はあると思うが

今までのレス読んでそう思う？
959 名前：デフォルトの名無しさん mailto:sage [2023/08/09(水) 18:58:03.94 ID:2XWtgL1F.net]: でも競プロでvec.insert(0, value)でタイムアウトしたけどvecdeque.pushfront(value)ではタイムアウトしなかった経験があるな
960 名前：デフォルトの名無しさん mailto:sage [2023/08/09(水) 19:31:59.29 ID:X5pmvNGk.net]: VecDequeはring bufferだから連続性は保証されないね
VecみたいなDerefがないから&[T]に渡せない
slice未実装かと思ったら2つのsliceで返すas_slices()が実装されてて思ったより芸が細かかった
961 名前：デフォルトの名無しさん mailto:sage [2023/08/09(水) 22:17:02.23 ID:5oPtG5Gl.net]: >>943
そのinsertはずらすコピーが毎回O(N)かかるからサイズNになるまでの累計はO(N^2)になってしまう
一方で満杯になったときの自動再配置コピーコストの方は累計でO(N)だからさほど気にしなくていい

>>944
その時の状態配置に応じて最小コピーで連続領域にしてくれるmake_contiguous()で
連続1本になった&mut [T]を得られるのでVecDeque内でのsort()なんかもできちゃうね
962 名前：デフォルトの名無しさん [2023/08/10(木) 04:07:06.41 ID:GpbD/XFE.net]: >slice未実装かと思ったら2つのsliceで返すas_slices()が実装されてて

He-
963 名前：デフォルトの名無しさん [2023/08/10(木) 04:08:51.37 ID:GpbD/XFE.net]: vecdequeはlinkedlistじゃね
964 名前：デフォルトの名無しさん mailto:sage [2023/08/10(木) 06:08:17.32 ID:74A6gUuN.net]: vecdequeはもちろんvecで構成
linkedlistは他のデータ構造(vector, binary tree, hash table)と比較してほとんどの用途で遅く不利なため極限られた用途でしか用いられない
linkedlistが用いられる限られた用途でもlinkedlistの欠点を補うため同時にhash tableやbinary treeなどと組み合わせて用いられることも多い
965 名前：デフォルトの名無しさん mailto:sage [2023/08/11(金) 08:01:08.13 ID:4oMIZBsG.net]: >>931
データ構造なんて知らなくてもできる
中学生の頃やってた

大学入った1年の前期でプログラム実習があってそこでも多倍長整数演算の計算をやった
配列で計算すんの
何も難しいことはない
966 名前：デフォルトの名無しさん mailto:sage [2023/08/11(金) 08:22:37.37 ID:6e7vDYNE.net]: RustやるならCSでもまず計算モデル(特にスタックフレームモデル周辺)だろ。
967 名前：デフォルトの名無しさん mailto:sage [2023/08/11(金) 08:37:22.11 ID:/t3LBfIN.net]: >>949
その配列というのが長さと場所を固定した連続領域を取るデータ構造なのよ
Vecは同じ連続領域だけど長さと場所は可変なデータ構造
VecDequeはVecを用いたリングバッファで連続領域を確保して使っているけど使用データ自体は最大二つの領域に分かれるデータ構造
LinkedListは連続領域を使わない連結リストといったようにいろいろあるデータ構造の中で質問者はどれを使うべきか悩んでるみたい
968 名前：デフォルトの名無しさん mailto:sage [2023/08/11(金) 11:19:59.50 ID:4oMIZBsG.net]: 最近おかしな議論が複数のスレにまたがって続いてるけど
多倍長整数というワードすら出てこないんだからなあ
969 名前：デフォルトの名無しさん mailto:sage [2023/08/11(金) 12:40:08.98 ID:v1edpQDw.net]: 複オジと厨房と二人いるのか？
それとも厨2病をこじらせた複オジか？
970 名前：デフォルトの名無しさん mailto:sage [2023/08/11(金) 13:08:17.16 ID:1cDd+Y+T.net]: >>952
ユーザーは多倍長整数ライブラリを使えばいい
しかし彼は作る側でどのデータ構造を使って実装するとよいかの相談
Rustの話ではなく普遍的な基礎知識の話だけどな

>>914
>>任意長整数型演算の実装の演習してるんですけど
>>(略)
>>この場合どのcollection型が有利ですか？
971 名前：デフォルトの名無しさん [2023/08/11(金) 14:32:24.16 ID:8y9raxy5.net]: >>953
最近はこじらせてる人が3～4人いるよ
複オジは>>954
972 名前：デフォルトの名無しさん mailto:sage [2023/08/11(金) 14:38:02.18 ID:WGGkjKOg.net]: 複オジ認定される人は複数いると思われ
973 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 06:55:54.99 ID:H/leygs+.net]: 誰かに雇われてるのかもな
974 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 17:12:05.53 ID:uYfXOEbY.net]: 詳しい人がいたらアドバイスをもらえると嬉しいです
やりたいこと
　入力系イベントの変換及び送出
　例えば所定のウインドウがアクティブ時にピンチインが入力されたらCtrl+「-」を送出とか
OS
　WindowsとLinux。同じコードで両OSに対応する必要はない
UI
　とりあえずCLIでも構わない
技術要素
　入力系イベントのグローバルフック。Rustではどうやる？
というか言語を問わずグローバルフックを使った新しい記事ってめっちゃ減っている気がする
現行の環境でどのような実装が良いのかよくわからない
975 名前：デフォルトの名無しさん [2023/08/12(土) 18:35:08.55 ID:Vg3fIeNP.net]: XY問題の上にRust関係ないな
976 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 20:05:24.91 ID:uYfXOEbY.net]: 今でもピンチイン/ピンチアウトで縮小拡大できないデスクトップアプリは珍しくないからね
特にエンジニアリング系アプリは有名どころでもタッチやペンに対応していなかったりするし
あと今から作るならRustを使いたいけどフックなどの実装は処理系依存になりやすく
システム言語を自称するRustでどこまでできるのかという点も興味ある
977 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 21:12:06.35 ID:ufIhf+ig.net]: 言語と関係なくね？
978 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 22:08:53.37 ID:ysM/YNb0.net]: >>961
言語の話ではないが、まぁ、RustでWinやLinuxのアプリを作るときには(激システム依存だろうが)関係するからな
WinならWinのapiを使うためのクレート
https://learn.microsoft.com/ja-jp/windows/dev-environment/rust/rust-for-windows
で頑張るとかになるだろうが。
979 名前：デフォルトの名無しさん [2023/08/12(土) 22:11:27.89 ID:ecBv/yaX.net]: アタオカがまた別のアタオカを呼ぶ
980 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 22:58:19.87 ID:SnIoCjjg.net]: >>958
今風のやり方は知らないが大昔にCでxlib使ってx11のイベント通知もらって何でもできた

>>960
CでできることはRustでできる
各分野についてRustだけで書かれたクレートもあれば
Cのライブラリを呼んでほぼ生で提供するクレートから
それをRustなインタフェースで提供するクレートもある
レアな分野で誰もクレート作ってなければ自分で作るのも難しいことではない
まずはcrates.ioでクレート探しからスタート
もし何を探すべきかがわからないのならばそれはRust以前の問題
981 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 23:35:32.02 ID:pSdIUbms.net]: まぁ仕事でRust使う人は皆無だろうからな
そして仕事でなければコンソールアプリで十分やし
家でサンデープログラミングするのにわざわざwindows sdk引っ張り出さないし
982 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 23:49:38.13 ID:SnIoCjjg.net]: むしろ仕事でWindowsを使わない
人それぞれだろう
983 名前：デフォルトの名無しさん mailto:sage [2023/08/12(土) 23:52:35.31 ID:3Gp8Ilch.net]: システムプログラミング向けの言語だからデスクトップアプリでは活況ではないんじゃないかな
984 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 00:01:39.02 ID:lcT7JkgH.net]: そうか、サーバサイドの人は使わんわな
985 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 00:04:16.66 ID:RW198XaM.net]: 好きにプロセス消失してもいい系のWebサーバ向けアプリには
あんまメリットないわな。
986 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 01:00:38.38 ID:IKXyPV6w.net]: >>968
>>969
WebサーバーサイドはRustが最も適している
そしてRustが毎年調査しているAnnual Survey ReportでもRustの業務利用目的の調査トップがWebサーバーサイド＆バックエンド
https://gihyo.jp/assets/images/article/2022/09/rust-monthly-topics/in_what_technology_domain_is_Rust_used_at_your_company.png
987 名前：デフォルトの名無しさん [2023/08/13(日) 11:45:17.49 ID:mxfdwtiA.net]: また現状認識ズレた人が不況に熱心なこと
988 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 12:47:43.44 ID:tlLZmbuO.net]: クラウドはリソース(演算能力やストレージ)を使った分だけ金がかかるという話は何度も言及されているやで
989 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 13:12:36.18 ID:1wlKIUZg.net]: ずっとそれ勘違いして言い続けてるよね
急になんJ民の振りしてもバレバレ
990 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 13:31:43.04 ID:4YjHceGO.net]: >>972
オンプレミスも同じ
遅い言語を用いていると無駄にサーバー数が必要となりその電気代が固定費となってしまう
C/C++にはtokioのような非同期並行並列でCPUマルチコアを使い切れるスケジューリング環境もないため
現状Rust一択
991 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 16:16:11.90 ID:QszCfK1u.net]: オンプレでも最終的にはそうなんだけど、クラウドの力でリソースの割り当てが柔軟に出来る状況になったので
「(開発初期は) まだ余っているリソースのチューニングは後回しにする」ということが出来なくなった。
余りなど存在しないので。
992 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 20:12:32.36 ID:NbQv8fjv.net]: 費用ならjavaやc#の方が安い
利用者が多くエンジニアを集めるコストが低いので
993 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 21:37:06.42 ID:lTJXvUOS.net]: Webサービス分野だと小規模なサービスは人件費 > サーバー費用だからRustは早すぎる最適化になりがち。
とはいえ開発体験もかなり優秀な部類になってきたから初手でRust選ぶのが開発者のオナニーとは言い切れなくなってきてるよな。
994 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 22:11:07.62 ID:QszCfK1u.net]: ウェブサービスというものが根本的に手探りだった時代は
素早く変更してサービスに反映させられる言語が重要だったけど
今は部品が確立してそれを組み合わせる形に変わっているから
部品が充分に揃っていると仮定できるなら言語 (処理系) の性能差で差がつく。
995 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 22:21:31.33 ID:26EPBWum.net]: でも実際問題としてRustで組んだ人いる？
996 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 22:35:27.66 ID:4YjHceGO.net]: 世界のウェブインフラもRust製

【CDN世界トップシェアCloudflare】
https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html
CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、
同社自身がRust製のHTTPプロキシである「Pingora」を開発し利用していることを明らかにしました。

【クラウド世界トップシェアAWS】
https://japan.zdnet.com/article/35183866/
Rustで構築されたAWSサービスの例としては、
コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
「Amazon Simple Storage Service（S3）」、
「Amazon Elastic Compute Cloud（EC2）」、
コンテンツ配信ネットワーク「Amazon CloudFront」、
LinuxベースのコンテナーOS「Bottlerocket」などがある。
997 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 22:57:04.72 ID:otTwfC5P.net]: >>980
イヤ、そうじゃなくてこういうとこで雑談するレベルの話で実際に仕事でRust使うような実例を持ってる人いるかって質問
別に煽ってるわけじゃないよ
まずそこまで流行ってないと思うしかない、仕事で実際使った人いるならどういう経緯で使うことになったのかなぁと
998 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 23:15:24.43 ID:QyDGXVub.net]: 自分は仕事で書いてるし、直接の知り合いで仕事で使ってる人10人くらいはいるかな
なんで国内でも数十社くらいは使ってるんじゃないかと思う
999 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 23:48:35.51 ID:iO5PvBbd.net]: そうなんや
それは言語はなんでもいいから好きなので書いていいん？
それともRustで書くように指示された案件？
1000 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 23:48:42.00 ID:427/I8XL.net]: > 自分は仕事で書いてる

開発の仕事じゃなさそう
くだらないウェブ記事書いてお小遣いもらってそう
1001 名前：デフォルトの名無しさん mailto:sage [2023/08/13(日) 23:51:53.47 ID:6khxmh9H.net]: うちはバックエンドの一部をRust製にした
最終的には全てRust製へ置き換えるが着実に一つずつ
1002 名前：デフォルトの名無しさん mailto:sage [2023/08/14(月) 00:03:15.79 ID:SMR2domD.net]: へぇ、意外にRust導入されてるんやな
1003 名前：デフォルトの名無しさん [2023/08/14(月) 02:41:34.96 ID:QUiVDENJ.net]: 蝦出んす
1004 名前：デフォルトの名無しさん mailto:sage [2023/08/14(月) 06:54:36.10 ID:BvDmcvEg.net]: >>983
うちの場合はC++で書かれた部分をRustに移行した感じ
開発言語は実担当者に任されてるから自分のチームの数人で話して決定
皆C++書けるからRustも結構すぐ書けるようになってた
1005 名前：デフォルトの名無しさん mailto:sage [2023/08/14(月) 08:31:01.38 ID:YSmL6IQ6.net]: こちらはNode.jsからRustへ移行だったけど
どちらもasync/awaitによる軽量タスクコードだから意外に簡単だった
1006 名前：デフォルトの名無しさん mailto:sage [2023/08/14(月) 22:05:11.92 ID:VoYfevle.net]: どれも具体性が薄すぎてニートが妄想で書いてるんかってレベルやな

何の目的があってRustが選択されたのか
他の候補として何が検討されたか
最終的に目的はどの程度達成されたのか
大きな課題としてどんなものが現れたか
その課題はどう解決したか（しなかったか）

一般論じゃなく各論で、そういう特筆すべきことはなんにもなかったんか？
1007 名前：デフォルトの名無しさん mailto:sage [2023/08/14(月) 22:08:35.90 ID:NTZtQKzP.net]: そうやって情報収集しようとするクセよくないぞ
自分でしらべろや
1008 名前：デフォルトの名無しさん mailto:sage [2023/08/14(月) 22:13:54.79 ID:sy90BXR1.net]: このスレにいる以上は Rust に関心を持っているのは当たり前なんだから
実務で使ってる事例もそれなりにあるのは全く自然なことだと思うんだが、
そう思えない理由がなんかあるか？

LISP スレですら実務の採用例がそこそこあるのに Rust で無いってこたぁない。
1009 名前：デフォルトの名無しさん mailto:sage [2023/08/14(月) 23:40:20.02 ID:GBb0r4Vn.net]: 思う思わないレベルの話はいらない
1010 名前：デフォルトの名無しさん mailto:sage [2023/08/14(月) 23:49:03.15 ID:h0ddCJfE.net]: アンチの相手しなくていいんじゃないかしら
お盆に入ってからの書き込み原文ママ

「仕事でRust使う人は皆無だろう」
「サーバサイドの人は使わん」
「Webサーバ向けアプリにはあんまメリットない」
「開発の仕事じゃなさそう」
「くだらないウェブ記事書いてお小遣いもらってそう」
「どれも具体性が薄すぎてニートが妄想で書いてる」
1011 名前：デフォルトの名無しさん mailto:sage [2023/08/15(火) 00:22:56.61 ID:0OuVStUx.net]: 無理やで
1012 名前：デフォルトの名無しさん mailto:sage [2023/08/15(火) 01:10:11.11 ID:eHfmSxwe.net]: >>994
君のとこでは採用してるん？
1013 名前：デフォルトの名無しさん mailto:sage [2023/08/15(火) 02:40:39.04 ID:ozj7JwYA.net]: 確かにこんなところで調査しても意味ねえわ
1014 名前：デフォルトの名無しさん mailto:sage [2023/08/15(火) 03:17:19.17 ID:W84SzS8v.net]: NoSQLなデータ扱うマイクロサービス改修を機会にそこをRustにしたよ
1015 名前：デフォルトの名無しさん mailto:sage [2023/08/15(火) 08:51:26.28 ID:ca01mENm.net]: ウクライナが勝ってるよっていう情報を流すのと同じw
1016 名前：過去ログ ★ [[過去ログ]]: ■ このスレッドは過去ログ倉庫に格納されています

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef