Rust part24

**デフォルトの名無しさん** · 2024/05/27(月) 06:41:26.82

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

**デフォルトの名無しさん** · 2024/05/27(月) 06:42:29.23

**デフォルトの名無しさん** · 2024/05/27(月) 06:43:12.56

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/05/27(月) 08:12:23.89

Cloudflare、HTTPプロキシ開発用RustフレームワークPingoraをオープンソース化
ttps://www.infoq.com/jp/news/2024/03/cloudflare-open-sources-pingora/

**デフォルトの名無しさん** · 2024/05/27(月) 19:41:54.75

>>1 乙

**デフォルトの名無しさん** · 2024/05/27(月) 21:05:50.42

なんで黙ってﾜｯﾁｮｲスレのリンク消したの？

**デフォルトの名無しさん** · 2024/05/27(月) 21:10:59.53

>>1乙ust

**デフォルトの名無しさん** · 2024/05/27(月) 23:31:45.00

rust-lldって魔法？

**デフォルトの名無しさん** · 2024/05/28(火) 23:01:09.87

「Sudo for Windows」はRustで開発されている！
メモリ安全が重視される分野で採用が広がるRust言語
ttps://forest.watch.impress.co.jp/docs/serial/yajiuma/1594981.html
次期大型更新「Windows 11 バージョン 24H2」に
搭載されることが確定した「Sudo for Windows」が、
Rust言語で開発されていることがわかった。

**デフォルトの名無しさん** · 2024/05/29(水) 09:39:32.15

完全にRustは残る言語になってしまったね

**デフォルトの名無しさん** · 2024/05/29(水) 11:05:17.42

言語の生き残るか否かもWindows次第かな

**デフォルトの名無しさん** · 2024/05/29(水) 13:45:30.43

この言語を支持してるやつは総じてデバッグ能力が低い

**デフォルトの名無しさん** · 2024/05/29(水) 13:56:47.79

なるほどそれはもうやるしかないね

**デフォルトの名無しさん** · 2024/05/29(水) 14:07:58.08

今更こんなのだけで一喜一憂するの？

ちなみにAzureCLIもRustだぞ
MacでHomebrewでインスコする時にRustのコンパイル始まって凄く時間掛かる

**デフォルトの名無しさん** · 2024/05/29(水) 14:55:30.35

ʕ◔ϖ◔ʔ

**デフォルトの名無しさん** · 2024/05/29(水) 16:53:17.15

>>12
テスト走らせるんじゃあかんの？

**デフォルトの名無しさん** · 2024/05/29(水) 17:06:12.76

>>9
これ仕組み上、console APIやTUIは動作しない
(それと肝心なところのほとんどがunsafeなのは見なかったことに)

**デフォルトの名無しさん** · 2024/05/29(水) 19:19:21.66

そういや、sudoとかの引数のバッファオーバーフローとかって、std::env::args_os使っていれば安全なのかな？

**デフォルトの名無しさん** · 2024/05/29(水) 22:46:32.28

unsafeはRust外のFFI/API境界でのやむを得ない出現か
unsafeを使うことで効率的かつ安全なパターンになる時のいすれかだが
後者のパターンは特定のプログラムから切り離してsafeなインターフェースを提供する汎用ライブラリに閉じ込めるのが好ましく
標準ライブラリはそのようにして出来ている

**デフォルトの名無しさん** · 2024/05/30(木) 12:31:47.54

つまりwindowsクレートはsafe interfaceの提供をサボってるということ？

**デフォルトの名無しさん** · 2024/05/30(木) 12:33:13.48

Rustと外側との境界はunsafeにせざるを得ないのは当たり前なのに肝心なところはunsafeと言われてもなぁ。
レビューすべき箇所が局所化されるだけでも十分なメリットだろ。

**デフォルトの名無しさん** · 2024/05/30(木) 14:46:49.26

>>20
>>21
どちらも正しい
Rustとその外側の境界部分で必ずunsafeが生じるからそこを問題にすることはない
ただしその部分は安全なインタフェースを提供するモジュールかできればクレートとして分離するのが好ましい

**デフォルトの名無しさん** ころころ · 2024/05/30(木) 16:38:16.78

Rust製Webサーバーで一番使われてるフレームワークって何だろ
MySQLと親和性高いなら使ってみたい

**デフォルトの名無しさん** · 2024/05/30(木) 18:56:43.74

>>23
axumとsqlx

**デフォルトの名無しさん** · 2024/05/30(木) 21:16:17.01

>>24
ありがと、試してみよう

**デフォルトの名無しさん** · 2024/05/31(金) 21:36:08.12

コンパイル前にcargo sqlx prepareでDBサーバからデータの型を得ておくことで静的型チェックできる仕組みなんだね

**デフォルトの名無しさん** · 2024/06/01(土) 10:39:11.44

へー、便利そう。
だけどこういう仕組みってカラム追加時のDBのマイグレーション辺りが入ってくるととたんに難しくなるんだよなぁ。

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

>>27
そういうDBテーブル構成変更するとどんなプログラミング言語でも何らかの対応が必要となるよ
Rustでsqlx利用ならばDB構成変更した時にcargo sqlx prepareで型をDBから入手し直せばコンパイル時に静的に型チェックされるから楽で安全だね

**デフォルトの名無しさん** · 2024/06/01(土) 22:32:36.24

DBの構成管理をどこで行うかという話
その辺の道具類は他言語に比べてRustはまだまだなので
DB側のツールで管理しておくという昔ながらのやり方が現状のベスト

**デフォルトの名無しさん** · 2024/06/01(土) 22:35:04.27

スクラッチのPHPみたいにSQL直書きからのexecuteはナシ？

**デフォルトの名無しさん** · 2024/06/01(土) 22:44:45.41

>>30
Rustのコード内にSQL直書き文字列を書ける
その上でデータベースとの静的な型チェックもされるのがsqlxのメリット

警備員[Lv.6][新芽] · 2024/06/01(土) 22:51:53.44

それで実行計画も取れるの？

**デフォルトの名無しさん** · 2024/06/01(土) 23:58:30.16

実行計画はDBのデータではないから型チェックは意味ないような

**デフォルトの名無しさん** · 2024/06/02(日) 09:14:40.51

>>21
機械語に近い部分がunsafeなのは当たり前だけど
それを手書きしていることを納得させるのが難しいんだろう
一番自動化されてるフレームワークを使ってみたいんだろ

**デフォルトの名無しさん** · 2024/06/02(日) 12:55:11.71

接続相手の仕様が形式化されたデータとして存在すれば
Rust 上の関数との対応付けを自動化できることもあると思うけど
形式化されたデータは誰かが準備しないといけないことには変わりないからなぁ。

Windows では API の仕様記述を WinMD と呼ばれる形で標準化してるけど
それだって WinRT (ちょっと高級な API) が前提になっているのでそんなに万能ではない。

あらゆる仕様を記述できるほど自由度 (複雑さ) のあるフォーマットにしたら結局は
プログラムを書くのとそんなに変わらんようになるので自動化できる部分は自動化して
ややこしい場合は手書きするという割り切りしないと仕方ない。

**デフォルトの名無しさん** · 2024/06/02(日) 23:32:50.95

Unix系システムコールとの共通部分は
ファイルシステムなど標準ライブラリとして安全なインターフェイスを提供できてるね
Windows特有部分も同じようにMicrosoftがsafeなライブラリを公式に用意することが望ましいのかな

**デフォルトの名無しさん** · 2024/06/03(月) 08:58:28.03

>>35,36
なるほど。結構時間経ったと思うが厳しい。

Microsoftがsafeなライブラリを公式に用意するまで、
プロダクションでのRust採用は様子見するのが良さそうだ。

Linux特有の機能が必要な場合も同様に様子見するのが良さそうだ。

**デフォルトの名無しさん** · 2024/06/03(月) 09:53:26.77

>>37
Windows クレートはもうかなり充実してるよ。
メタデータからの自動生成なので網羅的だし、 safe でいけるメソッドは safe になってる。
unsafe なのは本質的に unsafe なのでどうしようもないし。

Readme に書いてある例が古い Win32 API を使うスタイルの書き方だから印象が悪いのかなぁ……。

**デフォルトの名無しさん** · 2024/06/03(月) 12:15:09.36

>>37
LinuxでRustで困ってることないよ
様子見しなきゃいけないことがあるのならば具体的に挙げてみたら？

**デフォルトの名無しさん** · 2024/06/03(月) 15:47:20.28

>>38
>本質的に unsafe
良いキーワード出た、深掘りしてくれ

これとか
github.com/tokio-rs/io-uring

io_uringが本質的にunsafeだとでも思ってるのかな？

**デフォルトの名無しさん** · 2024/06/03(月) 16:27:42.41

本質的にC++な機能といえば多重継承
多重継承は他の言語に移植できない
万一できたとしたらそれは自動生成ではなく手作業で工夫されたコードだろうね

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

Win32APIを素で提供しようと思ったらunsafeなのは仕方ないので、もう一枚ハイレベルなラッパーかませてsafeにしてほしいところではある。

**デフォルトの名無しさん** · 2024/06/03(月) 19:27:13.29

だからモダンな WinRT に移行しようね！

**デフォルトの名無しさん** · 2024/06/03(月) 20:11:34.31

WinRTってWin32のAPI網羅できてるの？
モダンなAPIが古いのを機能的に網羅できてないから仕方なく使ってる気持ちなんだけど。

**デフォルトの名無しさん** · 2024/06/03(月) 20:49:12.70

WinRT は「おおよそ」には Win32 API の機能を網羅しているが
根本的なパラダイムが違っていて単純には置き換えられない場合はある。
最初から WinRT を前提として作っていれば Win32 API 抜きで行けることは多いよ。
ゼロではないところがイライラするかもしれんけど。

**デフォルトの名無しさん** · 2024/06/03(月) 21:57:04.03

>>41
クラス多重継承は問題多すぎなダメな機能なので多くの言語で禁止している
クラス継承そのものが問題を多く抱えているため各機能のインターフェースなどを実装するのが望ましい
Rustならば複数のトレイト境界を指定することでそれら複数のトレイト機能を実装した任意の型を対象に抽象的なプログラミングができる

**デフォルトの名無しさん** · 2024/06/04(火) 07:49:08.27

かきを最新AIに重箱の隅をつつく用意尋ねましょう
全ての電磁波は強い低周波も高周波も被爆する?
電磁かいが強い場所は20Hzと55Hzは磁気閃光これも被爆している.?
音波も強い場合は被爆する?
※自然界の化学科学の観測結果論文と人間の人工物で可能な化学と科学論文を読み込ませておく
是者と校舎を別々で回答する用意する
さらに制度を挙げるなら
グレーゾーンの論文をできるともいえるしできないともいえる用意認識させる

現在の科学が正しいのならなら電磁波攻撃はこのグレーゾーンの論文を使用しているので逃亡できている?

統合失調症電磁は音波なら周囲の者被爆している!?
寿命が短いのと免疫力低下起きて当然

**デフォルトの名無しさん** · 2024/06/04(火) 20:02:17.33

GPT4-Vの100分の1のサイズで同等の性能を誇るマルチモーダルモデル「Llama 3-V」が登場、トレーニング費用はたった8万円
2024年05月29日 14時00分
OpenAIがサム・アルトマンCEOを含む「安全・セキュリティ委員会」を設置、さらにGPT-4後継モデルのトレーニングを開始
2024年05月29日
「毒杯飲む直前どんな気持ちだった？」ソクラテスと対話できるAIを開発！
2024.06.04
※対象者【被害者】そっくりの返答が可能
たった数秒の音声データから音声合成が可能な「VoiceCraft」
2024年04月16日 07時00分
OpenAIがわずか15秒の音声からクローン音声を生成できるAIモデル「Voice Engine」をリリース
2024年04月01日
会話相手を数秒見つめて声を登録するだけでその人の声だけを聞くことができるAIヘッドホンシステムが開発される
2024年05月30日
※対象者の声を個別に録音

**デフォルトの名無しさん** · 2024/06/04(火) 21:25:19.75

std::ptr::addr_eqでdyn同士やdynと通常参照を比較してもいいんだよね

**デフォルトの名無しさん** · 2024/06/05(水) 02:32:30.56

比較の方法が複数あるとして
最も優秀な方法に依存するのではなく抽象に依存するのが定石だよな

**デフォルトの名無しさん** · 2024/06/05(水) 13:57:39.45

>>17
>肝心なところのほとんどがunsafe

当たり前やん
そもそも観なかったことにするための機能なんだし

**デフォルトの名無しさん** · 2024/06/05(水) 14:16:34.14

言語のパラダイムでどれだけ頑張っても言語の外はその規則に従ってくれないよ。
そこらへんの境界線でおおよそどこでも信頼できるインターフェイスは ABI だけ。
根本の部分が C の影響下にある状況のほうは変えようがない。

一応 unsafe rust という選択肢が登場した分だけだいぶんマシになってんだよ。

**デフォルトの名無しさん** · 2024/06/05(水) 14:19:53.54

>>38,52
>本質的に unsafe

本質的にunsafeの定義、早う

**デフォルトの名無しさん** · 2024/06/05(水) 14:28:05.14

C/C++のコード全体が常にunsafeすなわち自動的な安全保障なしなのに対して
Rustはsafe部分のコードが自動的に安全保障されるという明確な違いがある

**デフォルトの名無しさん** · 2024/06/05(水) 14:33:58.97

>>38,54

定義するとは何かすら知らないレベルでRustやってるのかよw

**デフォルトの名無しさん** · 2024/06/05(水) 15:41:52.55

定義するとは何かも知らなくても書けるのがRustの良いところ

**デフォルトの名無しさん** · 2024/06/05(水) 18:13:30.31

なぜ定義なんだ
喩え話では駄目な理由を考えるとすぐ思いつくのは、喩え話は非○○的だから駄目なんだよね

**デフォルトの名無しさん** · 2024/06/05(水) 19:11:15.28

>>49
dynはアドレスとvtableの対なので使える

use std::fmt::Display;
let i = 12345;
let r = &i;
let d: &dyn Display = &i;
// assert!(eq(r, d)); // 型が不一致でコンパイルエラー
assert!(addr_eq(r, d)); // アドレスが一致

文字列strはアドレスと長さの対なのでこのように比較できる

use std::ptr::{addr_eq, eq};
let s1 = "abcdef";
let s2 = &s1[..3];
let s3 = &s1[3..];
assert!(!eq(s1, s2)); // 長さが異なるので不一致
assert!(addr_eq(s1, s2)); // アドレスが一致
assert!(!addr_eq(s1, s3)); // アドレスが不一致

文字列をバイト列に読み替えたときにも使える

let b1 = s1.as_bytes();
// assert!(eq(s1, b1)); // 型が不一致でコンパイルエラー
assert!(addr_eq(s1, b1)); // アドレスが一致

**デフォルトの名無しさん** · 2024/06/05(水) 19:38:28.12

>>53
safe にするのが不可能(少なくともそれ単体は)というシンプルな意味で使ってるつもりだが

**デフォルトの名無しさん** · 2024/06/06(木) 22:14:32.57

fn 単純にこの比較も<T>(slice: &[T], index: usize) {
　let p = &slice[index];
　let q = &slice[index..];
　// assert!(eq(p, q)); // 型不一致
　assert!(addr_eq(p, q));
}

**デフォルトの名無しさん** · 2024/06/07(金) 12:52:26.48

グーグル、資料のわからないところを最新AIに質問できる「NotebookLM」日本版公開
https://ascii.jp/elem/000/004/202/4202481/

**デフォルトの名無しさん** · 2024/06/07(金) 23:50:20.38

as *const ()でupcastして比較しているだけなのか

**デフォルトの名無しさん** · 2024/06/08(土) 04:40:43.01

Option<String>型のxがある時に
x.as_ref()とするとOption<&String>が得られ
x.as_deref()とするとOption<&str>が得られることがわかりました

Option<&String>型のyがある時に
y.as_deref()としてもOption<&String>のままになりました
yからOption<&str>を得るにはどうすればいいのでしょうか？

**デフォルトの名無しさん** · 2024/06/08(土) 09:07:24.88

let tmp = Some(y.unwrap().clone());
let hoge = tmp.as_deref();

**デフォルトの名無しさん** · 2024/06/08(土) 09:09:50.82

cloneしたくなかったら
let hoge = Some(y.unwrap().as_str());

**デフォルトの名無しさん** · 2024/06/08(土) 10:33:13.95

unwrap()は基本的には使ってはいけない。

使ってもよい場合は論理的にNoneが絶対に来ないことが保証されてる場合で、
直前にNoneではないことをチェックしていて明白な場合と、
構造的にそこにNoneが来ないことをコメントで明記している場合のどちらか。

**デフォルトの名無しさん** · 2024/06/08(土) 10:34:38.61

もう一つは簡易プログラミングをする場合で、
そこにNoneが来た時に処理続行の意味がなく、
パニックという形でプログラムを終わらせても構わない場合。
これは本来はきちんとエラー処理対応するのが好ましい。

**デフォルトの名無しさん** · 2024/06/08(土) 10:39:31.95

ドキュメントのサンプルでは、
エラー処理は邪魔なので簡易的にunwrарが多用されているが、
それをそのまま用いるのがマズい理由は上述のため。

**デフォルトの名無しさん** · 2024/06/08(土) 10:45:50.57

「毒杯飲む直前どんな気持ちだった？」ソクラテスと対話できるAIを開発！
2024.06.04
リコーと理研、技術の実用化の“兆し”を察知するアルゴリズムを開発
2024/06/05
グーグル、資料のわからないところを最新AIに質問できる「NotebookLM」日本版公開
2024年06月06日

**デフォルトの名無しさん** · 2024/06/08(土) 11:07:47.98

>構造的にそこにNoneが来ないことをコメントで明記している場合

これはexpectのことを言ってるのかな？
panic!することには変わりないが

警備員[Lv.1][新芽] · 2024/06/08(土) 11:13:56.61

truckに手をだす勇者はいないのか？
https://github.com/ricosjp/truck

**デフォルトの名無しさん** · 2024/06/08(土) 11:35:42.10

>>63
y.map(|s| s.as_str())
or
y.map(String::as_str)

**デフォルトの名無しさん** · 2024/06/08(土) 11:44:51.45

>>70
単にunwrapでpanicさせるんじゃなくて
unwrap_orやunwrap_or_elseなどを使ってfallback valueを返す

>構造的にそこにNoneが来ないことをコメントで明記している場合
個人的に↑これには賛同しかねる
コードが脆弱になるから

**デフォルトの名無しさん** · 2024/06/08(土) 12:33:54.09

構造的にNoneでないことを期待しているロジックならチェックしたところでどうせリカバリできないんだし
単にパニックでいいと思うけどな

**デフォルトの名無しさん** · 2024/06/08(土) 12:53:40.15

事前条件・事後条件に反するときは panic するのが推奨されてなかったっけ？
要するにそういうことが一度でも起きたらバグが含まれているプログラムということだから修正するという前提がついてる。
あらゆるルートを想定するのも無意味だし、想定しないルートに入ったまま続けてもろくなもんじゃないので変なところがあったら止まったほうがいい。

ライブラリとして提供するなら expect にするに越したことは無いが
ただの panic でもスタックトレースは出せるし、
発見するのが自分 (またはチーム内などの身内) で修正するのも自分なら多少は雑でもよかろ。

**デフォルトの名無しさん** · 2024/06/08(土) 13:02:44.03

>>68
サンプルでrust unwrар好きだなと思っていたんだが、そんな理由で多用だったのか

**デフォルトの名無しさん** · 2024/06/08(土) 13:06:19.28

パニックさせるということはNoneかどうかをチェックしているということ
そしてパニック用のコードもそこに含まれるということ
そのため高速化がシビアなケースではunwrap_unchecked()が使われている
unsafeなので確実な監視対象となる点でむしろ好ましいケースもありうる
とはいえ特殊な場合を除き非推奨です

**デフォルトの名無しさん** · 2024/06/08(土) 14:06:17.67

ロジック的に None でありえないことをコンパイラが見抜ける状況でなら最適化で余計なチェックが消えることもあるし、分岐予測で速度的ペナルティはどうでもよくなることもある。
チェックするにしたって単発ではナノ秒単位の処理なので速度的に足を引っ張ることはまずない。
動画処理とか機械学習とかいった計算量が大きいものならチューニングが必要になることはあるかもね。

**デフォルトの名無しさん** · 2024/06/09(日) 00:14:30.88

例えばここにある`self.front.as_mut().unwrap()`や`front.next_kv().ok().unwrap()`のunwrapの使い方は妥当？
https://github.com/rust-lang/rust/blob/master/library/alloc/src/collections/btree/navigate.rs#L79-L80

**デフォルトの名無しさん** · 2024/06/09(日) 00:37:45.34

>>79
if self.is_empty() {
　None
} else {
　以降にあるから内部構造ロジックにより問題なし