Rust part26

**デフォルトの名無しさん** · 2024/09/20(金) 22:18:38.38

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

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

**デフォルトの名無しさん** · 2024/09/20(金) 22:19:18.10

**デフォルトの名無しさん** · 2024/09/20(金) 22:22:15.11

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/
Rust Performance Book
https://nnethercote.github.io/perf-book/

**sage** · 2024/09/21(土) 06:46:43.45

>>1
O2

**デフォルトの名無しさん** · 2024/09/21(土) 10:38:37.60

アンチの人はRustスレの邪魔をせずに
こちらへどうぞ

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

**デフォルトの名無しさん** · 2024/09/21(土) 11:45:15.28

変な質問かもしれないけどRustでもUMLのクラス図みたいなものって有効？
必要なケースとしては、プログラムの設計を他者と共有する必要があり、かつ相手は時間をとってコードを詳細に読むわけでなないという場合

今どきUMLという感じかもしれないけど、社内の他のプロジェクトではUMLを (常にではなく、必要に応じて時々) 使っている
Rustのプロジェクトでもこれを求められた場合にどう対応すれば良いのか
型同士の関係 (1対多などの数量関係や呼び出し関係) を説明するくらいはできるけど、継承などオブジェクト指向を意識したところがあるから、Rustのコードの設計を説明するのに必ずしも向かない気もする
こういう、設計を共有するのってみんなどうしてる？

**デフォルトの名無しさん** · 2024/09/21(土) 12:11:46.71

>>6
トレイトをインターフェイスとみなせば (わかりやすいかどうかは置いといて) 一応は成立すると思う。
だけどそういう図を見るくらいなら cargo doc を読んでいくほうがわかりやすいんじゃないかなぁ。
UML が有用なのはシーケンス図とか、抽象度の高い用途のほうでしょ。

**デフォルトの名無しさん** · 2024/09/21(土) 12:37:38.28

開発者が相手ならCargo docは有効だと思う
だけど、説明したいのは構造体やメソッドの使い方じゃなくて、ドメイン側のロジックが適切な型として表現されてるか、それに抜け漏れがないかといった点
それを視覚的に示せるということでクラス図を例に出した
相手はRustのコードに直接触れるわけではないけど、ドメイン側の知識を持ってて、そういう観点からのレビューをしたいという場面

書いてて思ったけど、Rustのenumで表現されてる型がやや表現しづらい？
OOPだとICommandのようなインタフェースを継承させてたけど、その代わりにenum Command にしてるケース
UMLに合うようにRust側のコードをトレイトを使って書き直すのも本末転倒な感じがする

**デフォルトの名無しさん** · 2024/09/21(土) 12:53:36.90

>>8
プログラムとしての合理性とドメイン側のロジックがそれほど一致しないのは普通のことなのでそういう形でレビューする事例は全然聞いたことないな。
特に専門的でプログラマの理解が追っつかないレベルだとドメイン側のロジックに忠実にやるしかないのだろうけど……。

**デフォルトの名無しさん** · 2024/09/21(土) 13:19:40.34

経験的にRustの構造体はデータベース設計のER図が合いそう
ライフタイムの関係で
・構造体のDrop≒レコードのdelete
・参照≒行ロック
みたいなイメージがしやすくて実装とのギャップを減らせると思う
enumはER図だとsubtypeに相当する

**デフォルトの名無しさん** · 2024/09/21(土) 13:46:07.48

テンプレートメタプログラミングに対応してないなら、C++ですら使えないと思う

**デフォルトの名無しさん** · 2024/09/21(土) 14:16:16.53

メタコードでも最終的に具現化されるから大丈夫でしょ
メタの部分はメタのままモデル化しとけばいい

**デフォルトの名無しさん** · 2024/09/21(土) 15:26:24.58

>>6
自分も相手もUMLに慣れてるのならUML使えばいいと思う
リバースエンジニアリングで図を書くのでなければ別に困らない

>>8
>Rustのenumで表現されてる型がやや表現しづらい？
<<enum>>や<<enumeration>>のマーカーをつけるだけ

**デフォルトの名無しさん** · 2024/09/21(土) 16:07:13.97

VS CODEとrust-anlayzerでrustを書いてるんだけど、
if文を1行でこう書きたいんだけど、自動整形で改行されちゃうんだけど、↓を許容する設定の仕方知っている人いたら教えて～
if 1 == 1 { true } else { false }

**デフォルトの名無しさん** · 2024/09/21(土) 16:47:05.18

rustfmtを使って整形しているのならば
#[rustfmt::skip]

**デフォルトの名無しさん** · 2024/09/21(土) 16:52:58.13

(if 1 == 1 { true } else { false })
let foo = if 1 == 1 { true } else { false };
みたいにカッコで囲むかletで値を受けるならrustfmtのsingle_line_if_else_max_widthが効きそうだけど
裸のifだと設定では無理かも

#[rustfmt::skip]
if 1 == 1 { true } else { false };
でskipするしかない

rustfmtの設定はrustfmt.toml（Cargo.tomlと同じ場所）で
single_line_if_else_max_width = 80
とか書けばいい
参考：github.com/rust-lang/rustfmt/blob/master/Configurations.md

**デフォルトの名無しさん** · 2024/09/21(土) 17:16:34.53

設計図と実物のギャップに比べたら改行がちょっと多い程度の差は
人体に無害だ
だが科学的に無害だとしても人の機嫌を損ねることは許されない

**デフォルトの名無しさん** · 2024/09/21(土) 18:16:59.29

>>14
短絡評価込みだとこれと同一になるはず。
1==1 && true || false;

この形でも長くなりすぎると改行されちゃうけどね。

**デフォルトの名無しさん** · 2024/09/21(土) 18:24:23.07

>>18
それ結果がboolのとき限定だし流石に……

(1 == 1).then(|| true).unwrap_or_else(|| false)

うーん、ないな

**デフォルトの名無しさん** · 2024/09/21(土) 19:05:43.59

boolならif else必要ないやろ

**デフォルトの名無しさん** · 2024/09/21(土) 19:52:13.10

trueのときの値，falseのときの値って意味で書いてんじゃねえかな

**デフォルトの名無しさん** · 2024/09/21(土) 20:44:43.28

>>15
>>16
ありがとう。やっぱり無理かー
InteliJ Ideaではできたのにな。RustRoverはまだ発展途上だし
Zedに期待したいけど、どこまでできるのか

>>21
そういうことです。とはいえbool限定で別の1行書き方があるとしても↓の書き方を1行に整形してほしいということで

> if 1 == 1 { true } else { false }

**デフォルトの名無しさん** · 2024/09/21(土) 22:18:19.38

>>9
それを一致させるように努力するのが本来のDDDよ
それを放棄したプロジェクトはいわゆる軽量DDDというアンチパターン

**デフォルトの名無しさん** · 2024/09/21(土) 22:31:50.56

>>21
マジかよ
そんな書き方したらあかんやろw

**デフォルトの名無しさん** · 2024/09/21(土) 22:52:39.16

逆に、一致しないように努力させられるのが特許とか知財か
どっちも嫌な努力

**デフォルトの名無しさん** · 2024/09/22(日) 11:14:51.14

どちらの書き方が簡潔に分かりやすいですか？

let result = match () {
_ if 場合1 => 値1,
_ if 場合2 => 値2,
_ if 場合3 => 値3,
_ if 場合4 => 値4,
_ if 場合5 => 値5,
_ => 値その他,
};

let result = if 場合1 {
値1
} else if 場合2 {
値2
} else if 場合3 {
値3
} else if 場合4 {
値4
} else if 場合5 {
値5
} else {
値その他
};

**デフォルトの名無しさん** · 2024/09/22(日) 11:48:01.54

そのifの判定内容はマッチで扱えないものという認識で良い？
例えば値の範囲なら以下のように書く
let b = match(a) {
　// x if x < 0 とも書けるけど冗長
　..0 => "nagative",
　0..10 => "small",
　_ => "many",
}

ifが必要なら、個人的には「その分岐が変数の値に応じて決まる」という意味合いが強ければmatchを、そうでないならifを使う
元のレスだとmatchに渡すものが空だけど、これが単にレスする際に省略したものでなく本当に () をmatchさせようとしてるなら、ifの方が分かりやすいと思う

**デフォルトの名無しさん** · 2024/09/22(日) 12:58:59.11

だね
条件の中身次第

**デフォルトの名無しさん** · 2024/09/22(日) 13:05:19.87

>>26
matchが短く見やすく可読性も良いかな
並んで順に判定することもわかりやすい

**デフォルトの名無しさん** · 2024/09/22(日) 13:13:51.09

内容次第では条件と値のセットを辞書的なもの(BtreeMapやArray)で管理する形にすることもよくある

**デフォルトの名無しさん** · 2024/09/22(日) 15:11:30.55

複おじ君 Rust を 2 年かそこらやっててまだこんなことにこだわってるの

**デフォルトの名無しさん** · 2024/09/22(日) 15:20:32.79

たとえば、動的にメソッドを定義するコードが
どこにも書かれていないことを確認するためにソースコード全体を読む必要はほとんど無いが
妙な書き方をすればそれが必要になる

**デフォルトの名無しさん** · 2024/09/22(日) 15:36:11.10

でその妙な書き方かどうかはどうやって判定すんの

**デフォルトの名無しさん** · 2024/09/22(日) 16:08:33.07

正しくないかもしれない値段で物を売り買いする自由があるんだから
うっかり正しくない判定をしても大して問題ないよね

**デフォルトの名無しさん** · 2024/09/22(日) 16:16:50.01

こう簡単に矛盾すること書けるやつのソースコード見てみたいわ

**デフォルトの名無しさん** · 2024/09/22(日) 19:42:13.27

矛盾したコードを書いた時、Rustなら検知してくれる

**デフォルトの名無しさん** · 2024/09/22(日) 20:01:27.84

コンパイラのレイヤーしか頭に無いバカ

**デフォルトの名無しさん** · 2024/09/22(日) 22:58:14.23

コスプレイヤーのケツしか頭に無い

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

リスクを取るとか失敗を恐れないことと、矛盾を限りなくゼロに近づけることって
相性悪いよな

**デフォルトの名無しさん** · 2024/09/23(月) 00:43:24.10

ポエ味が過ぎる

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

そのレベルの判定基準で売ったり買ったりキャンセルする自由がある

**デフォルトの名無しさん** · 2024/09/29(日) 17:53:03.81

全然普及してないね
誰が使ってんの？

**デフォルトの名無しさん** · 2024/09/29(日) 18:08:13.96

https://response.jp/article/2024/08/08/385006.html
ドイツのVectorとHighTec EDV-Systemeは、RustアプリケーションとCベースのAUTOSAR Classic基本ソフトウェアの統合に成功した、と発表した。
これにより、自動車業界でのプログラミング言語「Rust」使用における最後の障害が取り除かれたという。

**デフォルトの名無しさん** · 2024/09/29(日) 18:13:50.86

トヨタもRust技術者を募集してるね

**デフォルトの名無しさん** · 2024/09/29(日) 22:22:20.01

「The Rust Foundation」は、人命や財産に関わるような安全性が決定的に重要になるシステムのために、
Rust言語を責任を持ってサポートするためのコンソーシアム「Safety-Critical Rust Consortium」の設立を発表しました。
設立には日本からWoven by Toyotaが参加

**デフォルトの名無しさん** · 2024/09/30(月) 04:31:41.35

Rustは良い言語だと思うけど
> 人命や財産に関わるような安全性が決定的に重要になるシステム
に効果的なのかはやや疑問

自動運転は詳しくないから財産の方で書くけど、例えばみずほ銀行のシステム障害や仮想通貨取引所からのコインの流出といった問題はRustだと防げてたか？というとそんなことはないと思う
プログラム上のバグは防ぎやすくなるけど、仕様策定時の想定不足や運用の問題までは防げない

**デフォルトの名無しさん** · 2024/09/30(月) 07:15:29.93

プログラム上のバグを防ぎたいと思うからこそ
MISRA C みたいなルール作ってチェックしてるわけで
それを言語仕様で防げるRustを使いたいというのは当然だと思うけど
仕様バグが防げないからといって他のバグも入ってよいわけではない

**デフォルトの名無しさん** · 2024/09/30(月) 07:34:00.91

>>46
プログラミング言語がカバーしない領域の問題を持ち出して来て「Rustはこの問題を防げない！」と主張するバカがときどき現れる
頭が弱いんだろうな

**デフォルトの名無しさん** · 2024/09/30(月) 08:45:28.66

>>48
そういう領域をわざと曖昧にして騙す詐欺師もいるからなんとも。

**デフォルトの名無しさん** · 2024/09/30(月) 09:16:22.72

ああ、>>42みたいなのって定期的に現れてたけどこれも例のネタ振りだったのか
終わりやなあ

**デフォルトの名無しさん** · 2024/09/30(月) 10:02:54.61

>>49
プログラミング言語ではカバーできない領域の問題をわざわざ出して来て
「Rustはこの問題を防げない！」と主張するのが詐欺師
他の言語でも防げないのだからRustにおける問題ではない

**デフォルトの名無しさん** · 2024/09/30(月) 10:32:26.16

>>46
言語機能からくるバグと仕様のバグを区別できてなさそう

**デフォルトの名無しさん** · 2024/09/30(月) 10:54:40.07

Rustで他国の技術者を疲弊させる作戦なのかもな

**デフォルトの名無しさん** · 2024/09/30(月) 11:04:51.09

たしかにTesla/SpaceXが言語選択を前面に出して安全性アピールしたこと無いな

**デフォルトの名無しさん** · 2024/09/30(月) 11:30:05.30

言語を全面に出してアピールするのは使える言語しかアピールするものがないカスだけ
他にアピールするものがある人はそっちをアピールする
言語は乗り換える時はしれっと乗り換える