Rust part21

**デフォルトの名無しさん** · 2023/08/15(火) 22:24:39.45

公式
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 part20
https://mevius.2ch.net/test/read.cgi/tech/1677771928/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.2ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2023/12/30(土) 05:19:08.00

>>761
「出してください」な

**デフォルトの名無しさん** · 2023/12/30(土) 05:21:27.73

まあちゃんと「出してください」って言われても俺の分野がバレない奴があったか悩ましいが

**デフォルトの名無しさん** · 2023/12/30(土) 05:28:06.55

こういうのは具体的を出すということ自体が結構難しいんだよな
>>761が使っているライブラリでバージョンが1未満のものを上げるとかしてくれたら話が早い

**デフォルトの名無しさん** · 2023/12/30(土) 06:29:39.39

Rust勉強中。アノテーション注釈が出てきたところで流行らない理由をなんとなく察する
ヌルポとメモリーリークを防げるから個人開発で使う分にはいいけど。会社で広める気にはならない
学習コスト高いわ

**デフォルトの名無しさん** · 2023/12/30(土) 10:07:43.55

async traitが安定化されてる！！！
https://blog.rust-lang.org/2023/12/28/Rust-1.75.0.html

**デフォルトの名無しさん** · 2023/12/30(土) 10:32:04.21

>>765
アノテーション注釈ってなんやねん
無駄にラーニング学習コスト費用高い資料読んでね？

**デフォルトの名無しさん** · 2023/12/30(土) 11:16:50.31

>>765
ライフタイム注釈ってタイプしたつもりで全然ちがう文字を打ち込んでた
the bookを読んでるだけだよ。疲れてたんだ…

**デフォルトの名無しさん** · 2023/12/30(土) 11:33:27.15

the book はきついよね

**デフォルトの名無しさん** · 2023/12/30(土) 11:41:42.24

staticを自粛する言語はみんな高コスト
チェリーピッキングみたいに最高値の近辺だけが高いという指摘はうさんくさい

**デフォルトの名無しさん** · 2023/12/30(土) 12:22:34.64

>>768
非公式翻訳版を読んでるだろ
あれで学習したやつは例外なく使えないのが出来上がるからやめとけよ

**デフォルトの名無しさん** · 2023/12/30(土) 18:18:48.80

>>759
自分が具体的なことを書いていないという指摘は否定しないw

**デフォルトの名無しさん** · 2023/12/31(日) 05:11:31.11

>>765
ライフタイム注釈はたいてい一意に定まりその時は省略できるから面倒にならないよ
省略できず明示的にライフタイム注釈を指定しないといけない場合は
例えば複数の参照を受け取り参照を返す関数などでそれら参照間の関係を指定する

**デフォルトの名無しさん** · 2023/12/31(日) 10:19:28.53

>>765
>ヌルポとメモリーリークを防げるから
メモリリークは防げない
ヌルポとメモリリークが防げればいいだけならNull Safetyを備えたGC言語で十分

**デフォルトの名無しさん** · 2023/12/31(日) 10:35:21.39

なまじライフタイムを省略できるせいでライフタイム未修得でも書けてしまう言語なので、いざライフタイム省略出来ない時が来た時に脳がバグる

**デフォルトの名無しさん** · 2023/12/31(日) 11:15:14.55

ライフタイムの記述は省略できることはあっても常にライフタイムを意識しながら書かなきゃいけない
それに省略できない場面にも日々遭遇するから「省略できるから面倒にならない」みたいな初心者釣りはやめた方がいい

暗黙的に意識しなきゃいけないC++に比べればある意味面倒ではないという程度

**デフォルトの名無しさん** · 2023/12/31(日) 11:24:54.37

マクロやFFIのようなやや高度な機能を除いた基本機能の中ではライフタイムが一番難しくて一番面倒
性能と引き換えに受け入れなければいけない面倒臭さ

**デフォルトの名無しさん** · 2023/12/31(日) 12:07:26.58

ライフタイム意識しなくても良いと騙されて書き始めた人間のがライフタイムに恐れを抱いて迂回しながら書いた至る所でcloneして値渡するコード

**デフォルトの名無しさん** · 2023/12/31(日) 13:31:13.38

まあ C++ と比較するとおおよそ良くなってると思うが C++ で不都合なく寿命管理できる能力があるなら Rust でライフタイムを明記するのを面倒と感じることはあるだろうな。
人類は駄目なので実際には頻繁に問題を起こすという現実があるんだけどさ。　わかってても間違うのが人類。

**デフォルトの名無しさん** · 2023/12/31(日) 13:50:46.98

お金を賭ければ失敗することもあるけど賭けなければどうということはない
どっちも現実なんだけどリスク回避＝現実逃避だと思ってるのが人類あるある

**デフォルトの名無しさん** · 2023/12/31(日) 14:00:16.32

C++で不都合なく寿命管理出来る能力があったらライフタイム管理なんて数文字タイプが増えるだけになのでは

**デフォルトの名無しさん** · 2023/12/31(日) 14:02:49.07

>>779
Rustで性能&安全性優位になるのは積極的にスタックに積んで参照使いまくった場合だろうけど、c++だとスマートポインタとアロケータで最適化しとけという話になるからなぁ。

どんくらい性能差あるのかわからん。

**デフォルトの名無しさん** · 2023/12/31(日) 14:05:38.66

>>781
出来ると思ってるが実際には出来てないって話さ

**デフォルトの名無しさん** · 2023/12/31(日) 16:01:28.24

もうRustじゃ無理なんだよ

**デフォルトの名無しさん** · 2023/12/31(日) 17:31:22.31

>>784
Rustが有利という話の流れの中で唐突にRustが何か無理なことある？

**デフォルトの名無しさん** · 2023/12/31(日) 18:02:32.92

プログラミング出来ない人は本当に出来ない。
C++ を使えているくらいの人なら Rust を (良いと思うかどうかは別として) 真面目に学べば使いこなせるだろうけど、初心者が最初に学び始めるには全く向いてないなぁと思うくらいのハードルの高さはあると思う。

**デフォルトの名無しさん** · 2023/12/31(日) 18:29:47.72

プログラミング出来ない人にRustはハードルが高いという主張か

**デフォルトの名無しさん** · 2023/12/31(日) 19:12:47.61

ゴミには何触らせてもゴミ

**デフォルトの名無しさん** · 2023/12/31(日) 20:25:01.01

>>786
単に最近のスクリプト言語が簡単過ぎるだけだと思うけどね
ブイブイ言わせてる()モダンなスクリプト言語使いが
俺たちRustも書けるっしょwみたいなノリで挑戦して
書けなくて諦めるというのを何度も見てきた
本来プログラミングってのはこの程度は難しいものよ

**デフォルトの名無しさん** · 2023/12/31(日) 20:41:56.95

Rustを書けず断念するような低レベルの人ならば
他の言語でもまともなプログラムは書けないと思うけどな

**デフォルトの名無しさん** · 2023/12/31(日) 22:03:37.75

バージョンおじさんの次はスクリプトコンプおじさんか

**デフォルトの名無しさん** · 2023/12/31(日) 22:07:53.39

ライフタイムは関数に渡すときborrowするだけなら何も難しいことはないんだが型に参照を含めていろんな操作をしたり持ち回ったりし始めると複雑度が急上昇する

**デフォルトの名無しさん** · 2023/12/31(日) 22:22:03.06

そこは同じ
型に含まれてる参照のライフタイムがその型にも付くだけ

**デフォルトの名無しさん** · 2024/01/01(月) 00:50:09.76

あけましておめでとうございます
ライフタイム面倒なので捨ててstaticにしたいそんな貴方へ魔法の関数プレゼント！

fn to_static_str(input: &str) -> &'static str {
　　input.to_owned().leak()
}

**デフォルトの名無しさん** · 2024/01/01(月) 19:58:44.82

the book で勉強中だけど覚えること多いなあ
構文を覚えるだけで70時間はかかりそう
デザインパターンの勉強は必要なさそうだけど
実践投入するには読経も20時間分ぐらい必要だろうな

**デフォルトの名無しさん** · 2024/01/01(月) 22:17:40.22

90時間でも約11日稼働ならオンボーディングで
極端に辛いというほどじゃなくね

**デフォルトの名無しさん** · 2024/01/01(月) 22:29:17.37

>>795
Rustの構文は諸言語のバリエーション範囲内でほとんど同じ
強力なパターンマッチングとその構文が新規なくらいですぐ習得できる

**デフォルトの名無しさん** · 2024/01/02(火) 00:14:27.39

Rustの勉強が大変なら勉強なんかせんでええ
Copilotに書かせてコンパイル通ればOKや！

**デフォルトの名無しさん** · 2024/01/02(火) 08:32:02.80

copilot は予測変換の賢いやつって感じ。
個々の場面では思ったよりも賢くて使い物になるが全体を構成するのに人の思考がいらないほど、全部丸投げ出来るほどではない。
出来る人が楽をするツールであって、できない人が使ってもまともなものは作れない。

**デフォルトの名無しさん** · 2024/01/02(火) 22:18:53.42

>>792
どっちかというとそういうもち回しによる複雑な操作するなってのがrustの思想だろ

**デフォルトの名無しさん** · 2024/01/03(水) 00:45:56.91

他の言語の習慣を捨てないとなかなか実践できないと思う
しばらく使ってるとRust特有のプラクティスが見えてくるけど

**デフォルトの名無しさん** · 2024/01/03(水) 00:58:25.14

全体を構成する部分が問題になってRustにノータイムで移行できない人間が書くスクリプト言語で書かれたプログラム、読みたくなさすぎる

**デフォルトの名無しさん** · 2024/01/03(水) 18:10:43.49

VSCodeとrust-analyzerでrustを書いている人にちょっとお聞きしたいんだけど、
rustのコード補完で、必ずabc順になっちゃうんだけど
直前に使用したメソッドを優先的に上位に表示させることってできないの？
VSCodeのエディタの設定でrecently usedを設定してもabc順でしか表示さない
InteliJIdeaでは学習した結果、使用頻度の高いものを上位に表示してくれてたのに・・

**デフォルトの名無しさん** · 2024/01/03(水) 23:00:13.67

質問の仕方が間違っているぞ
そういう時は「補完もまともに出来ないクソ言語」って言えば信者が頑張って探してくれる

**デフォルトの名無しさん** · 2024/01/04(木) 17:30:55.33

InteliJでは出来てたって書いてあるの読めない人なのかな？
こういう人がテストケースとか書いてると思うと怖くてたまらんね

**デフォルトの名無しさん** · 2024/01/04(木) 17:56:16.02

>>804は頭の弱いRustアンチの人だから無視しとけ

**デフォルトの名無しさん** · 2024/01/04(木) 18:21:30.81

ごめんよ
rustが難しくて理解できない可愛そうな人だったか

**デフォルトの名無しさん** · 2024/01/04(木) 19:32:15.16

誰も問題解決出来てなくて草
マジで糞言語なのか？
VSCodeでもPythonなら出来るぞこれ

**デフォルトの名無しさん** · 2024/01/04(木) 20:05:26.49

>>776
これはそう思うわ。
そこが面倒ならそもそもrust使うことが面倒だろって気にしかならん。

**デフォルトの名無しさん** · 2024/01/04(木) 20:44:14.40

普通にバグ報告すればいいのに

**デフォルトの名無しさん** · 2024/01/04(木) 20:47:26.53

>>808
あらためてVSCode再起動したら普通に直近に選択したメソッドや変数が上位に表示されるようになった
ごめんね　ぺこり

ちなPythonは入れ子のループの内側から外側のbreakができないから嫌い

**デフォルトの名無しさん** · 2024/01/04(木) 21:51:07.65

InteliJ は rust-analyzer 使ってないんじゃなかった？
開発支援機能の基盤が違えば細かい挙動が一致しないのなんて当たり前過ぎて何が言いたいのかわからない。

**デフォルトの名無しさん** · 2024/01/04(木) 22:28:32.21

>>795の読経って何？

**デフォルトの名無しさん** · 2024/01/05(金) 08:39:06.77

>>813
https://github.com/BurntSushi
この人のリポジトリひとつ読んだら実装に移るわ

**デフォルトの名無しさん** · 2024/01/05(金) 09:40:39.59

Rustで書かれたLinux互換OS「Maestro」が爆誕
https://softantenna.com/blog/rust-maestro/

**デフォルトの名無しさん** · 2024/01/05(金) 09:43:03.49

>>814
ああ、コードを読むのを読経と言ってるのか。ありがとう。

**デフォルトの名無しさん** · 2024/01/05(金) 13:58:06.60

読経なんかせんでええ
GPTに書かせろ

**デフォルトの名無しさん** · 2024/01/05(金) 14:50:07.45

ソースはお経じゃねえぞ

**デフォルトの名無しさん** · 2024/01/05(金) 16:26:15.51

写すと写経
読むと読経か

般若心経に波羅蜜多という単語が出て来る
修行の意味だが、修行を行った量という意味でもあり
英単語のparameterと同語源だという
引数か

ヤシの木palmとparameterも同語源って説がある
palmは手の平の意味だが手の指で文字を数えるとも繋がる
これがまた修行の量とか引数って概念に繋がる
またヤシの葉で分厚いパルミラヤシと呼ばれるものは経文を書くのに使われていた
経文を書いた量がまた修行のパラメーターとなった

ナツメヤシのことをdateというが日にちも数えるもの、デートも日にちを重ねて交流を深めるものとされた
ヤシの葉と修行と日にちと引数は常に数えるものとされた

一方で波羅蜜、パラミツというスイカの5倍くらいある果物もある
果実を輪切りにするとアナログ時計のように果肉が並び
時間を象徴するものだから？という話があるが、パラミツと波羅蜜多は特に関係がないという方が多い

インドにRust外注したら動くものは帰ってくるのかどうか

**デフォルトの名無しさん** · 2024/01/05(金) 17:09:23.62

parameterのpara-はギリシア語由来の「離れている」では
parallel（平行）のpara-

**デフォルトの名無しさん** · 2024/01/05(金) 19:03:58.53

>>815
爆誕出来てないじゃん。
仮に互換するにした場合、バグも再現するんかね？

**デフォルトの名無しさん** · 2024/01/06(土) 15:29:56.82

無理にひねくれたこと書かんでよろしい

**デフォルトの名無しさん** · 2024/01/07(日) 02:08:36.16

rustちょっと書いたけどなんかハマらんな
つまんない
刺激が少ない
俺は別に言語に安全性なんて求めてないんだ
刺激がほしいんだ

**デフォルトの名無しさん** · 2024/01/07(日) 02:15:40.93

>>823
お前のチームのバグ出しまくる同僚に使わせたら？

**デフォルトの名無しさん** · 2024/01/07(日) 02:41:23.33

プログラミングそのものに刺激を求めるんじゃない
刺激はプログラミングで実現したいものに求めろ

**デフォルトの名無しさん** · 2024/01/07(日) 09:36:48.73

rustはコンパイラにムチを打たれながらコーディングする性癖ドＭ言語だよ
自身の性癖と合う言語を使ってけ

**デフォルトの名無しさん** · 2024/01/07(日) 15:48:04.06

Rustがムチ打つかレビューでムチ打つかの違いでしかないんだよな
誰にも見せないコードなら関係ないけど

**デフォルトの名無しさん** · 2024/01/07(日) 16:53:56.32

男は黙ってSegmentation Fault

**デフォルトの名無しさん** · 2024/01/07(日) 21:59:04.51

>>827
レビューは体裁しか見ないやついるからな。内容読まないとかレビューになってねーから。
コンパイラにチェックさせたほうがマシ。

**デフォルトの名無しさん** · 2024/01/08(月) 12:20:12.43

刺激ってメモリリークでクラッシュとか、ストレージフォーマットとかか？

**デフォルトの名無しさん** · 2024/01/08(月) 20:41:35.20

スマートポインタについて勉強中。強い参照、弱い参照という概念が出てきて目が回る
RefCell……所有権の共有が発生する参照……参照？？？
言葉遊びが過ぎないか。。。

**デフォルトの名無しさん** · 2024/01/08(月) 21:50:36.68

何書いてるかによるけど、出来ればスマートポインタ使わずに書きたい

**デフォルトの名無しさん** · 2024/01/08(月) 21:56:10.69

>>831
強い参照、弱い参照はRustやC++だけでなくJavaやC#、PythonやJavaScriptでさえ出てくる一般的な概念だぞ

RefCellは所有権の共有じゃないぞ

スマートポインタや参照という言葉もRustの定義を理解した上で学ぶ必要があるんだけどちゃんとした資料で勉強してるか？

**デフォルトの名無しさん** · 2024/01/08(月) 22:02:17.92

>>833
目が回って頭が混乱してた。Rcのことです
the bookを読んでます。英語版と日本語版を読み比べならが進めてます

**デフォルトの名無しさん** · 2024/01/08(月) 22:04:58.02

>>832
FSTという決定木を呼び出す実装を書く予定なんだよね
どこまで既存のクレートを使えるか次第だけど。たぶんスマートポインタ必須だろうなあ……胃が重い

**デフォルトの名無しさん** · 2024/01/08(月) 22:45:23.91

>>831
説明するのには言葉を使うしかしょうがないだろう。
それとも小難しい記号だらけの操作的意味論を読み解くほうがマシとでもいうか？

**デフォルトの名無しさん** · 2024/01/08(月) 22:56:58.99

>>835
まず前提環境が重要になる
たとえば並行はあるのか？並列はあるのか？両方あるのか？
あるとしても共有が必要なそれらの範囲はどこまでなのか？
それとは別の話で参照の共有と所有権の共有についても前者だけで済むのか後者も必要なのか？
など

**デフォルトの名無しさん** · 2024/01/09(火) 00:03:40.70

>>835
木構造は普通にポインタ使うと地獄だよ
Nodeにポインタを持たせる実装ならRefCellとRcとOptionの組み合わせでゴニョゴニョやることになる

**デフォルトの名無しさん** · 2024/01/09(火) 00:15:41.68

配列にどんどん詰め込んでいって
ポインタのかわりにインデックスで管理するという方法も取れなくはない。
Rust で参照の取り扱いが面倒くさくなったときは割とよく使われる。

**デフォルトの名無しさん** · 2024/01/09(火) 00:41:55.42

Rustだから面倒になるのではなく
同じ方針ならばC/C++でも同じようになる
そしてどの言語でも同じく色んな方針を取ることができる
たとえばプログラム終了まであるメモリを解放しない＆しなくてよい状況と方針ならば
CだけでなくRustでもそのようにプログラミングすることで簡単になる

**デフォルトの名無しさん** · 2024/01/09(火) 00:48:52.81

Array/VecとMapでやる方が普通

てかスマートポインタで胃が重いとか言ってる人にFST実装させようとするのはどうなのか
学生さんの宿題ならいいんだけど

**デフォルトの名無しさん** · 2024/01/09(火) 13:46:52.23

>>815
windowsこそrustで書き直して欲しい

**デフォルトの名無しさん** · 2024/01/09(火) 14:29:03.17

いやWindowsは消滅してくれ
Windowsのパス区切り文字がバックスラッシュだと面倒くさいんだよ
いつになったら他のOSのようにスラッシュになるんだ

**デフォルトの名無しさん** · 2024/01/09(火) 14:42:13.51

そこでいまどき困るか？
ライブラリで吸収してくれるだろ

**デフォルトの名無しさん** · 2024/01/09(火) 15:03:46.95

困るのはそんなポイントではないわな

**デフォルトの名無しさん** · 2024/01/09(火) 15:51:14.16

UNIX
https://learn.microsoft.com/ja-jp/cpp/c-runtime-library/unix

プログラムを UNIX に移植する場合は、次のガイドラインに従ってください。

・引数としてパスとファイル名を表す文字列を実行するルーチンでは、UNIX と互換性のあるパス区切り記号を使用します。 UNIX は、この目的でスラッシュ (/) のみをサポートしますが、Win32 オペレーティングシステムでは、円記号 (\) とスラッシュ (/) の両方をサポートします。

**デフォルトの名無しさん** · 2024/01/09(火) 16:00:24.31

WindowsはWSL2のおかげで立ち位置を少し取り戻した感ある
Docker×WSL最強なんだ

**デフォルトの名無しさん** · 2024/01/09(火) 16:26:04.96

Rustを学習していてよくわかんないんだけど、なんで&mut演算子って=の右側に書くの？
演算子を分けて&を右でmutを左にすべきことじゃないのか

**デフォルトの名無しさん** · 2024/01/09(火) 16:31:10.75

>>848
変数がmutなのと参照がmutなのと意味が違うでしょ

**デフォルトの名無しさん** · 2024/01/09(火) 16:38:48.96

不変なT型　T
不変な不変参照　&T
不変な可変参照　&mut T

可変なT型　mut T
可変な不変参照　mut &T
可変な可変参照　mut &mut T

**デフォルトの名無しさん** · 2024/01/09(火) 16:51:10.28

それ複オジがよく書いてたやつだけど
そうやって書くと型の違いと変数のmutabilityの違いを混同しちゃうから良くないんだよね

**デフォルトの名無しさん** · 2024/01/09(火) 16:57:39.62

fn main() {
let mut foo = String::from("foo");
let mut bar = String::from("bar");

let a1 = &foo;
// a1の値も参照先（foo）も変更できない
// a1.push('o'); // 不可
// a1 = &bar; // 不可
println!("{a1}"); // foo

let a2 = &mut foo;
// a2の値は変更できないが参照先（foo）は変更できる
a2.push('o');
// a2 = &mut bar; // 不可
println!("{a2}"); // fooo

let mut a3 = &foo;
// a3の値は変更できるが参照先（foo）は変更できない
// a3.push('o'); // 不可
a3 = &bar;
println!("{a3}"); // bar

let mut a4 = &mut foo;
// a4の値も参照先（foo）も変更できる
a4.push('o');
a4 = &mut bar;
println!("{foo} {a4}"); // foooo bar
}

**デフォルトの名無しさん** · 2024/01/09(火) 17:54:54.96

>>815
先にfirefox互換のブラウザをRustで作れよ

**デフォルトの名無しさん** · 2024/01/09(火) 20:29:20.32

>>815
ついにRustで書き切ったカーネルが出たか
素晴らしい😎

**デフォルトの名無しさん** · 2024/01/09(火) 21:43:46.90

JythonみたいにRinuxとか呼ばれる様になるんかね

**デフォルトの名無しさん** · 2024/01/09(火) 23:30:54.91

>>847
わかる

**デフォルトの名無しさん** · 2024/01/09(火) 23:33:35.76

>>850
＞可変な不変参照　mut &T
＞可変な可変参照　mut &mut T

そこは
mut& T
mut& mut T
のほうが良くないか？

**デフォルトの名無しさん** · 2024/01/09(火) 23:44:10.92

>>857
なんでmut& Tやmut& mut Tのほうがいいと思うの？

**デフォルトの名無しさん** · 2024/01/10(水) 00:26:25.61

変数は不変　参照先も不変
【Rust】 let ptr: &i32 = ...
【C/C++】 const int* const ptr = ...

変数は可変　参照先は不変
【Rust】 let mut ptr: &i32 = ...
【C/C++】 const int* ptr = ...

変数は不変　参照先は可変
【Rust】 let ptr: &mut i32 = ...
【C/C++】 int* const ptr = ...

変数は可変　参照先も可変
【Rust】 let mut ptr: &mut i32 = ...
【C/C++】 int* ptr = ...

**デフォルトの名無しさん** · 2024/01/15(月) 07:32:23.77

プログラミングをしていて最も出現頻度が高いのがその4つのうちこのパターンだな

＞変数は不変　参照先も不変
＞【Rust】 let ptr: &i32 = ...
＞【C/C++】 const int* const ptr = ...

したがって可変部分のみmutを付加するRust方式が理に適っている

**デフォルトの名無しさん** · 2024/01/15(月) 09:26:21.36

C/C++のconstとRustのletを対比するなよ
コンパイル時の定数と変数は違うから