Rust part22

**デフォルトの名無しさん** · 2024/01/20(土) 23:21:40.08

公式
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 part21
https://mevius.5ch.net/test/read.cgi/tech/1692105879/

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

**デフォルトの名無しさん** · 2024/01/20(土) 23:30:24.59

**デフォルトの名無しさん** · 2024/01/20(土) 23:30:59.71

Rust Reference Book
https://doc.rust-lang.org/reference/
Rust Standard Library
https://doc.rust-lang.org/std/
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
Rust serde Book
https://serde.rs/

**デフォルトの名無しさん** · 2024/01/21(日) 19:52:38.28

Rustを理解していく順序　(文法以外)
ownership　
↓
lifetime　(これ以前でも参照を持ち越さない範囲で可)
↓
trait　(これ以前でもライブラリ既存traitメソッド使用は可)
generic　(これ以前でもライブラリ既存genericメソッド使用は可)
↓
macro　(これ以前でも既存macro使用は可)
async　(これ以前でも同期で使用可)
↓
unsafe　(ほとんどのことはunsafeを使わずに可能)

もしunsafeを使わないと効率よく実装できない安全なパターンを見つけて、
かつ、それが既存ライブラリに存在しない新たなパターンならば、
それは大発見だから皆のためにそのcrateを公開すべし

**デフォルトの名無しさん** · 2024/01/21(日) 20:27:09.29

今、refと&で混乱してるとこ！

**デフォルトの名無しさん** · 2024/01/21(日) 20:58:34.51

オーナーシップとかAIにやらせればOK
意識して時間割く必要なし

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

>>5
パターンマッチングはCopy実装型はcopyされてそれ以外はmoveされる

copyやmoveを避けるには
マッチング対象を参照にすれば
全て参照として受け取れる

しかしある部分はcopyである部分は参照で受け取りたいことがよくある
(例えば数値とStringで構成されてる場合)
その時は参照で受け取りたい部分のみrefを付けるとそこは参照で受け取れる

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

>>5
refはbind by reference
左辺(相当)でのみ使う(binding生成時のみ)
右辺で&を使うのと同じだけど右辺で&を指定できない場面で使う

&を左辺で使うとパターンマッチでデリファレンス
右辺で*を使うのと基本同じ

**デフォルトの名無しさん** · 2024/01/21(日) 22:36:05.82

>>https://mevius.5ch.net/test/read.cgi/tech/1692105879/990
一応知らない人のために書いておくけど

「Rustがunsafeコード一切なしでメモリアンセーフ」な事が判明してから半年近く経ってる
特定の機能導入のタイミングでコードが発見されたけど、
「Rustの仕様バグ」だと認識されていて直せない

>>4
そんな事並べて理解したつもりでも、分からないと言っている人の側の主張が正当なんだよ

最近はここでも保証って言われなくなっただろ、当たり前だよRustの仕様に健全性が無いのだから
たぶん知っていて話を逸らしているのか、過去スレでスルーしたかで、この指摘も無理やり矮小化してくるからな
(githubの議論でも矮小化して放置)
気を付けろよ

https://github.com/rust-lang/rust/issues/114936

**デフォルトの名無しさん** · 2024/01/21(日) 22:51:42.90

>>9
無意味な揚げ足取りをしてRustを叩きたい人はアンチスレへ
棲み分けしてください

Rustアンチスレ
https://mevius.5ch.net/test/read.cgi/tech/1509028624/

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

仕様バグだから直せないじゃなくて
厳密なチェックをする実装は0から作ったほうが早いから
今使ってる確率的(笑)な実装は変更しないんだよね？

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

これマジ？　どれくらいの確率で踏むんけ？　コンパイルのバクはケアしたくないなあ

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

>>12
意図的にvarianceの穴を突く無意味なコードを書かないと発生しないため>>9は無害

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

>>9
こんなコンパイラの脆弱性を突くようなコードを普通なら書かない定期

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

>>9は9年前の2015年から既知の有名なパターン
意味のあるプログラミングで絶対に踏むことはないため害はない
その特殊ケースに対応するデメリットの方が大きいため対策されていない
それらを踏まえたうえでIT大手が揃ってRustを採用しRust Foundationも設立された

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

9のコードの意味が理解できないんだが何が問題なのか説明してくれ

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

c++のテンプレートはチューリングマシンだから
無限ループを起こせるのは仕様の欠陥がどうか聞きたい

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

f: impl for<'s> FnOnce(&'s str) -> (&'static str, [&'static &'s (); 0])　の説明だけ。
ライフタイム 's の str を引数にして、&'static str 型と、[&'static &'s (); 0] 型のタプルを返すクロージャが f ということ。
[&'static &'s (); 0] は &'static &'s () 型の長さ 0 の配列。
&'static &'s () は、ユニット型() のライフタイム 's の参照のライフタイム 'static の参照。

この &'static &'s () の部分で変なことが起きてそうと言っとるな。

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

>>17
C++ の仕様ではテンプレートの展開深度に上限を設定することを認めているのでチューリングマシンではない。
非現実的な回数のループが起こるのならそれは処理系の欠陥。

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

>>15
1.65.0で新しく導入された回帰バグですって書いてあるし
2015年の#25860とも別だねってコメントも付いてますやん

**デフォルトの名無しさん** · 2024/01/23(火) 00:35:34.27

>>18
文脈無視してその引用だけで言えそうなことは
&'static &'s T 型が存在するならば 's も 'static でなければならない
このルールに反しない限り &'s str を &'static str に変換してよい

**デフォルトの名無しさん** · 2024/01/25(木) 23:09:32.35

安全にこれで&'staticへ変換できる

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

**デフォルトの名無しさん** · 2024/01/26(金) 23:31:43.19

最後までずっと使うものやあるいは
あるメモリ限度内に収まる使い方ならば
リークさせて扱いが楽になるメリット享受を選ぶのもありかもな

**デフォルトの名無しさん** · 2024/01/27(土) 23:34:17.17

>>22
それ&'static strではなく&'static mut strを返してもええねんで

**デフォルトの名無しさん** · 2024/01/28(日) 02:18:12.19

>>22
leakって安全なの？

**デフォルトの名無しさん** · 2024/01/28(日) 04:27:59.88

leakは安全
そのプログラム終了まではその部分のメモリを解放しないだけ

**デフォルトの名無しさん** · 2024/01/28(日) 08:32:52.16

>>25
Rust の定義ではメモリリークは安全性を損なわないことになってる。
言語の機能として積極的に阻止しなければならないような動作ではないが、
だからといってむやみにリークさせていいわけでもないのは当然なので
そこらへんはロジック上の必要性を鑑みて「正しく」運用するのはプログラマの責任だよ。

**デフォルトの名無しさん** · 2024/01/28(日) 12:34:08.20

leakは参照を削除するとメモリリークになると書いてあった（機械翻訳）けど参照って削除できるの

**デフォルトの名無しさん** · 2024/01/28(日) 13:17:17.43

>>28
原文は何て書いてるのさ

**デフォルトの名無しさん** · 2024/01/28(日) 14:30:03.90

期待した通りの結果になるのは危険ではないという知見は合理的だ
期待や願望よりも地獄のような厳しい現実にこだわるバイアスがかかってない

**デフォルトの名無しさん** · 2024/01/28(日) 15:17:37.40

>>28
leak()は所有者がいなくなるだけ
つまりそのメモリ領域が解放されなくなるだけで安全な行為
そこを指す参照だけになる

一般的に参照は指しているだけ
その参照を表す変数もしくは一時的な値が消えればその参照は消えたことになる
参照が消えても実体には何ら影響なく解放なども生じない

**デフォルトの名無しさん** · 2024/01/28(日) 18:26:28.82

メモリリークにならない＝参照がデストラクタを呼び出せる
ではなく
参照はデストラクタを呼べないが、参照が永久に残ればメモリリークにならない

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

メモリリークは多義なので
GC言語でも、今後は使わないオブジェクト等をどこが参照しているため解放されない、これもメモリリークと言う
つまり参照が残っているからメモリリークじゃないとは言えない
逆にRustの場合は、leak()を適用した時点でそこは永久に解放されないのだから、既にメモリリークとも言える
もちろんそれで困らない時に意図的にリークを可能とするものなので、その機能や行為自体に問題はなく、そのプログラムの性質や環境や方針次第

**デフォルトの名無しさん** · 2024/01/30(火) 02:10:08.22

多義である事実に人間が従うのではなく、定義を変えたいので変えまくった人間に事実が従う
利己主義の結果を予想するのではなく結果を予想できる範囲内で利己的になる

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

きちんとメモリ確保・解放する
ただそれだけのことだけどうまく行かないものだね

**デフォルトの名無しさん** · 2024/01/30(火) 07:11:49.27

>>35
Rustならそれができるし保証される
ただしその基本に加えて融通を利かせることもできる
意図的にリークさせる(解放しない)こともできるしそれを使わないこともできる
意図的に循環参照を作ってリークさせることもできるしそれを避けるための手段も用意している

**デフォルトの名無しさん** · 2024/01/30(火) 11:19:29.95

それくらいできてくれないと習得に対して割に合わない

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

>>35
二回以上解放しない保証は大成功した
一回以上解放する保証をやる気がない
与えられた問題を勝手に分割してやりたい部分だけやってる

**デフォルトの名無しさん** · 2024/01/31(水) 05:41:08.45

Rustでは意図的にリークもしくは意図的に循環参照作成の場合を除いて必ず解放される

**デフォルトの名無しさん** · 2024/01/31(水) 22:24:17.87

スポーツでも五輪だけが目的のプロがいたら割に合わないが
なんか目的をあやふやにすれば五輪に出ても破産しないよね

**デフォルトの名無しさん** · 2024/02/01(木) 16:48:45.42

Microsoft seeks Rust developers to rewrite core C# code
https://www.theregister.com/2024/01/31/microsoft_seeks_rust_developers/

でかいところのバックエンドRust化が増えてきたな

**デフォルトの名無しさん** · 2024/02/01(木) 17:28:29.31

しかしRust流行らんな

**デフォルトの名無しさん** · 2024/02/01(木) 19:27:48.94

Pythonやkotlinみたいな手軽さで堅牢で高いパフォーマンスが出れば最高なんだけどなかなかね

**デフォルトの名無しさん** · 2024/02/01(木) 20:38:04.52

from C to Rust へのマイグレーションは時間がかかるからしゃあない

**デフォルトの名無しさん** · 2024/02/01(木) 21:16:53.56

>>43
Pythonはスクリプトを書く程度ならいいけどプログラミングには不向き

**デフォルトの名無しさん** · 2024/02/01(木) 21:44:37.29

きちんとガベコレしてるのに見下されてるなあPythonは
きちんとしても割に合わない

**デフォルトの名無しさん** · 2024/02/01(木) 21:53:27.11

動的型は堅牢とかきちんとやるみたいなのと相反するんだよな
書き捨てならいいけど長期的にメンテするやつには向いてない

**デフォルトの名無しさん** · 2024/02/01(木) 21:55:25.71

Rust、言うほどPythonと比べて手軽でないか？

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

プログラマの意図を書かないと、意図を表せる言語じゃないと「正しい」かどうかは検証しようがない。
だから意図の表現方法として型やライフタイム注釈やらの形を確立したのであって、お手軽に柔軟に動かす言語では実行時に不都合があれば止まるという形にならざるを得ない。
静的型があれば全部が解決ってわけではないけどごく基本的な整合性検査すらせずに実行するまでわからんというのはメンタル的にきつい。動的型はきつい。
自分で把握できる程度の小さな規模なら動的型のほうが楽ってこともあるといえばあるけど、人類は駄目なのでちゃんと把握できる規模は自分で思っているよりだいぶん小さい。

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

Pythonはやっぱり行列を扱うのに長けてる気がするな
ただ静的には何の変数を見ても(Variable)xxx: Anyみたいな型推定しかされていなくて、自分の書いたコードですら訳がわからなくなる
他人の書いたライブラリを使うときはまるで魔法を使ってるかのようだ

**デフォルトの名無しさん** · 2024/02/01(木) 22:40:37.81

Pythonというかインタプリタは部分的にCを使うことを認めざるをえない
それを大多数に納得させるコストが激安

**デフォルトの名無しさん** · 2024/02/01(木) 22:42:10.75

>Pythonはやっぱり行列を扱うのに長けてる気がするな

pythonのどこが？numpyがあるだけじゃね。

**デフォルトの名無しさん** · 2024/02/01(木) 22:45:58.52

PythonはC/C++/Rustで書いたライブラリを呼び出すスクリプト言語として使っている限りは問題ない
プログラミング言語としては不向きで使うべきではない

**デフォルトの名無しさん** · 2024/02/01(木) 22:54:05.96

OSのカーネルにはPythonは不向きだからクソどうでもいい生存競争をしなくてすむ

**デフォルトの名無しさん** · 2024/02/01(木) 23:06:17.91

使い分けが出来ない人はスキルが低いだけ
言語に限らずどの技術でも同じこと

**デフォルトの名無しさん** · 2024/02/01(木) 23:13:02.07

各種カーネルのRust移植に時間かかってるけどC/C++からRustへの書き直しってそんなに大変なの？

**デフォルトの名無しさん** · 2024/02/01(木) 23:14:24.05

Pythonもプログラミング言語だしシェルスクリプトも立派なプログラミング言語だよ

**デフォルトの名無しさん** · 2024/02/01(木) 23:23:51.23

プログラミング言語はそれに付随するフレームワークの質で需要が変わってくるけど、
C/C++/Rust/アセンブラなど低水準言語はガべコレのランタイムが不要というアドバンテージがある
だからカーネル用途での需要が高い