Rust Part7

**デフォルトの名無しさん** · 2019/07/14(日) 23:31:47.54

Mozilla発のRust言語のスレ

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

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

前スレ
Rust Part6
http://mevius.5ch.net/test/read.cgi/tech/1532714678/

**デフォルトの名無しさん** · 2019/10/18(金) 15:26:11.27

>>480
その関連記事は>>27。そのソースは>>190
静的解析ツール等を併用してもC/C++では無理があると指摘している

**デフォルトの名無しさん** · 2019/10/18(金) 17:46:16.42

mut をマットって読んでる人いる？

コアチーム含めミュート派が大勢なのは知ってるけど
eがないとミュートって読むのは不自然だし、時々eをタイプしそうになるから
マット派になろうかと思ってるんだが

**デフォルトの名無しさん** · 2019/10/18(金) 17:52:26.42

おれはミューツ派

**デフォルトの名無しさん** · 2019/10/18(金) 17:55:14.75

>>482
マット派
レットマットって発音が気持ちいい

**デフォルトの名無しさん** · 2019/10/18(金) 17:59:19.15

どう見てもムッと

**デフォルトの名無しさん** · 2019/10/18(金) 18:12:40.01

むーと

**デフォルトの名無しさん** · 2019/10/18(金) 18:29:52.38

結構いろんな読み方してんのね
マット派いたから安心して転向するわ

ちなみにドイツ語ではムートって読んで勇気って意味らしい

**デフォルトの名無しさん** · 2019/10/18(金) 20:27:28.69

Rustの単語のセンスだけはどうも好きになれん

**デフォルトの名無しさん** · 2019/10/18(金) 20:30:24.39

わかる
fnとかpubとかunwrapとか普通にわかりにくい

**デフォルトの名無しさん** · 2019/10/18(金) 21:57:09.28

pubはまあわかるけど
fnとunwrapは他言語でもあるし普通にわかりやすいと思ってたわ

IntoIteratorとかは素直にIterableでいいのにとは思う

**デフォルトの名無しさん** · 2019/10/19(土) 00:46:14.72

しかしRustでOS作ったらCより性能悪かったという記事があったはず
新しくOS用のプログラミング言語を作った方が良いのでは
RustはOS開発を主眼にしてるわけじゃないだろう

**デフォルトの名無しさん** · 2019/10/19(土) 01:22:54.66

OSの性能って曖昧過ぎて何測ってるのかわからん

**デフォルトの名無しさん** · 2019/10/19(土) 04:43:06.59

Redoxめっちゃマッハやった

**デフォルトの名無しさん** · 2019/10/19(土) 07:34:16.56

Rustは配列の境界値チェックがあるから普通に使うとCよりちょっと遅いよ

**デフォルトの名無しさん** · 2019/10/19(土) 13:01:40.81

>>494
分岐予測があるので理由はそこじゃない

**デフォルトの名無しさん** · 2019/10/19(土) 13:28:05.60

は？

**デフォルトの名無しさん** · 2019/10/19(土) 13:43:06.95

OS組もうとするとRustの言語概念を無視するような書き方をしなきゃいけない
みたいに書いてあったんだけど

**デフォルトの名無しさん** · 2019/10/19(土) 13:44:39.15

「Rust」言語はCよりも遅いのか、研究者がベンチマーク結果を解説
ttps://www.atmarkit.co.jp/ait/articles/1909/13/news133.html
このソースは
A high-speed network driver written in C, Rust, Go, C#, Java, OCaml, Haskell, Swift, Javascript, and Python
ttps://github.com/ixy-languages/ixy-languages
これかな

**デフォルトの名無しさん** · 2019/10/19(土) 17:05:59.60

>>497
ケースバイケースだろ。
なんでも杓子定規にとらえるなって言ってやれ。

**デフォルトの名無しさん** · 2019/10/19(土) 18:07:21.38

いや普通にOSソース見ればそらrust向いてねーわってなるよ。
杓子定規にrust使おうってほうが気が狂ってるわ。

**デフォルトの名無しさん** · 2019/10/19(土) 18:16:31.77

Rustを使わないからそうなっているのかもしれんぞ
どこでＲｕｓｔだと不利なのか説明してくれ

**デフォルトの名無しさん** · 2019/10/19(土) 18:58:13.46

ストレージからプロセスを読んで起動する、とか
そもそもコンテキストスイッチングの処理とかは所有権の概念（データの寿命が入れ子）から外れてくる
気がするが、別にunsafeにせねばならないほどでもないｷﾓｽ
他に何かある？

**デフォルトの名無しさん** · 2019/10/19(土) 19:38:38.55

その昔はlispやforthでもos書いたりしたんだからrustで書けないことないだろう。

**デフォルトの名無しさん** · 2019/10/20(日) 00:31:55.71

redoxがあるけど。

**デフォルトの名無しさん** · 2019/10/20(日) 11:39:50.17

それで実際Rustはバグ発生率低いの？

**デフォルトの名無しさん** · 2019/10/20(日) 12:22:34.24

バグ発生率ってどうやってカウントするのが一般的なんやろか？

完全にただの思いつきで無意味な比較だけどgithubのgoとrustで総issue数/contributor数だと1人あたり2倍ぐらいgoのが多いね

**デフォルトの名無しさん** · 2019/10/20(日) 13:14:08.41

issueってバグじゃないだろ。
機能要望とか議論とかあるじゃん。

**デフォルトの名無しさん** · 2019/10/20(日) 23:15:26.37

小さめのサイズの本で、初心者向けの本が出た！

Rustプログラミング入門、酒井和哉、2019/10/13

**デフォルトの名無しさん** · 2019/10/20(日) 23:22:23.45

>>506
バグ発生率は、バスタブ曲線だろ。
初期によくバグる

土方をやってると、バグを多く出さないと、客に提出できないw

漏れは、平均的なIQ レベルより、間違いが少ないから、
いつも、アホみたいなバグを、わざと自分で作って、バグ発生数を増やしていたw

あらかじめ勉強している人は、滅多に間違わないから、バグ発生数基準だと困るw
一方、全く勉強していない香具師は、バグが多い

**デフォルトの名無しさん** · 2019/10/21(月) 03:46:22.99

俺は世界で一番この本を待ってた！！！！！

**デフォルトの名無しさん** · 2019/10/21(月) 13:21:09.04

仕様書にバグが多いのはあれわざと仕込んでるのかなるほど

**デフォルトの名無しさん** · 2019/10/22(火) 20:56:02.71

ネストした構造体のコンストラクトパターンみたいなやつはもっとチュートリアルで
説明した方がいいんでないのとは思う。
多分めんどくさい書き方にしかならんからやらんのだろうけれど。

**デフォルトの名無しさん** · 2019/10/23(水) 15:46:33.91

?の便利さに感動している

**デフォルトの名無しさん** · 2019/10/23(水) 16:06:56.63

え、なに？
文字化けしてますよ

**デフォルトの名無しさん** · 2019/10/23(水) 17:55:49.61

三項演算子は便利だったなぁ、と他言語を思い出して感動してるってことかな

**デフォルトの名無しさん** · 2019/10/23(水) 18:12:17.77

普通にResultの話じゃなくて？

**デフォルトの名無しさん** · 2019/10/23(水) 20:07:35.94

組み込みもネットワークツールもほとんどc以上の生産性を出すことないしな。。
一番有効な領域ってデバッガーじゃねーの？とは思う。

**デフォルトの名無しさん** · 2019/10/23(水) 20:47:39.59

Bookを6章まで読んだ俺が >>224 で書いたのが

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=dc60559b7af47298d305be80b340ee98

?の便利さに気づいた俺が書いたのが

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=308e7fe634f1e539c1f936c3989022f0

**デフォルトの名無しさん** · 2019/10/23(水) 21:06:25.79

.file_name()?.to_str()?.to_string()
Ｒｕｓｔだっさ

**デフォルトの名無しさん** · 2019/10/23(水) 21:12:36.43

公式に呼びやすい名前をつけないのがよくない
question mark operatorじゃわかりにくいから
error propagating operatorかerror handling operatorで

**デフォルトの名無しさん** · 2019/10/23(水) 21:26:40.40

ダサいかどうかとかどうでもよすぎる
性能、書きやすさ、読みやすさ、安全性がすべて

**デフォルトの名無しさん** · 2019/10/23(水) 21:31:02.23

性能　境界チェックのせいでだいぶおそい
書きやすさ　地獄
読みやすさ　悪夢
安全性　噂ではあるらしい

？まみれになるぐらいだったらヌルポで落ちても変わらんやん
どうせ無理に回復とかしないほうがいい類のだろ

**デフォルトの名無しさん** · 2019/10/23(水) 22:05:27.50

ぬるぽで落ちるのは運が良かっただけで何でも起きうるし最悪ｽｰﾊﾟｰﾊｶｰの餌食になる
?はちゃんとエラーで終了してくれる

って理解でおk?

**デフォルトの名無しさん** · 2019/10/23(水) 22:31:31.88

ヌルポって、javaのあれのこと？
シンタックスだけ比較して意味あんのかな

**デフォルトの名無しさん** · 2019/10/23(水) 23:02:51.06

>>523
ちがう
ぬるぽだとまず間違いなくぬるぽエラーで落ちる

NullSafeのありがたさはnullにならないこと
場合分けを考えずに常に変数を確実なひとつの値として扱える

**デフォルトの名無しさん** · 2019/10/23(水) 23:10:47.86

モナドだろうがなんだろうがNullはNullだ
へたに回復してしまうとほかに影響が波及して大惨事につながりやすい
むしろ最初からNullにならないことを保証してくれる方がうれしい

なのになんでOKで帰ってきた結果からfileNaeme取るのまで？つけさせられとんじゃ

**デフォルトの名無しさん** · 2019/10/24(木) 00:25:03.31

まあNULLで潔く死んでくれた方がってのは確かにあるわな。

**デフォルトの名無しさん** · 2019/10/24(木) 00:39:21.69

エラーかどうかのチェックは、NULLかどうかのチェックとは違う
ここ大事なところなので間違えちゃダメ

**デフォルトの名無しさん** · 2019/10/24(木) 01:03:58.72

潔く死んで欲しいなら明示的にunwrapなりexceptなりすればよい
バグなのか想定されたエラーなのかを区別して明示的にコーディングできるのがrustの利点では

**デフォルトの名無しさん** · 2019/10/24(木) 05:35:47.09

OptionとかResultにケチつけてるのは加齢臭キツすぎる

**デフォルトの名無しさん** · 2019/10/24(木) 06:50:04.06

下手に回復して大惨事になるのは、下手だからでしょ

file_nameに?付けてるのはディレクトリの場合無いからでしょ
なんでそんなことが疑問になるのか分からない

**デフォルトの名無しさん** · 2019/10/24(木) 09:03:26.66

Optionとか中途半端でたちわりーわ。
てかrustみたいにライフタイム意識する言語の場合、あんまり役割ない気がするけどね。

**デフォルトの名無しさん** · 2019/10/24(木) 12:28:38.87

メソッドチェーンの中で「owned -> borrowed -> owned」するのはアンチパターンだと思うんだよね
不必要な処理が入るし可読性も下がるのでいいことない

fn main() -> Result<(), std::io::Error> {
let path = std::env::current_exe()?;
let file = path.file_name().unwrap();
println!("{:?}", file);
Ok(())
}

**デフォルトの名無しさん** · 2019/10/24(木) 12:51:50.95

そもそものお題がこちら

＞187 デフォルトの名無しさん2019/08/26(月) 20:55:57.18 ID:hNXwMePN >>206>>214>>224
＞https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=8c44bed658726ada0deff031799664b7
＞1. std::env::current_exe()で実行ファイルのフルパスを得る
＞2. file_name()でファイル名だけにする
＞3. to_str()で&strにする
＞4. 途中でErrやNoneが返ってきた場合はデフォルトの値"foo"を使う
＞
＞ということをやりたいのですが、エラーでビルドできません。
＞どのように書けばいいでしょうか？

**デフォルトの名無しさん** · 2019/10/24(木) 20:32:12.47

>>534
お題があったのね
referenceを受け取ってreferenceを返す関数に抽出すればto_ownedやto_stringは不要

use std::path::PathBuf;

fn main() {
let path = std::env::current_exe().ok();
let file = file_name(path.as_ref()).unwrap_or("foo");
println!("{}", file);
}

fn file_name(path: Option<&PathBuf>) -> Option<&str> {
path?.file_name()?.to_str()
}

**デフォルトの名無しさん** · 2019/10/24(木) 21:22:39.45

勉強になりました

let file = {|| Some(path.as_ref()?.file_name()?.to_str()?)}()
.unwrap_or("foo");

でも動くようですけど関数に抽出した方が良いですか?

**デフォルトの名無しさん** · 2019/10/24(木) 21:41:02.37

それ関数作って呼んでるのとほぼ同じだし名前がついてるかどうかの違いだから好きにせえ

**デフォルトの名無しさん** · 2019/10/24(木) 21:55:47.24

Someで囲ったOptionalチェーンを返すクロージャってのが
Rustのイディオムとして認知されて来ればそういうやり方も有りかもだけど
俺は関数に抽出したほうが型が見えて読みやすいので良いんじゃないかと思う

**デフォルトの名無しさん** · 2019/10/24(木) 22:25:03.94

try blockを待て

**デフォルトの名無しさん** · 2019/10/25(金) 20:57:15.75

これまではto_string()がチェーン末尾だったからSomeに入れてたけど
末尾がto_str()になってOption返すから必要なかった

let file = {|| path.as_ref()?.file_name()?.to_str()}().unwrap_or("foo");

なぜ昨日は気が付かなかったんだろう……

**デフォルトの名無しさん** · 2019/10/25(金) 21:01:12.42

try block
ずっと待ってるあなたのことを
意味もなくクロージャで囲む日々

**デフォルトの名無しさん** · 2019/10/25(金) 21:29:24.66

モナド早くきてくれー

**デフォルトの名無しさん** · 2019/10/25(金) 21:51:56.35

モナドられると、ややこしい人が顔出してくるんでノーセンキュー

**デフォルトの名無しさん** · 2019/10/26(土) 06:18:18.43

関数型信者がうるさくなった言語は衰退する

**デフォルトの名無しさん** · 2019/10/26(土) 09:43:29.54

関数型ことごとくすたれてない？

**デフォルトの名無しさん** · 2019/10/26(土) 10:13:18.36

モナド（高階型）来てもいいんじゃない？OptionとResultで同じようなことやってるし

**デフォルトの名無しさん** · 2019/10/26(土) 13:48:16.66

オプショナルチェーンを矛盾なく繋げるモナドが入れば覇権だと思う
正直それだけできれば小難しい理論はいらないし

**デフォルトの名無しさん** · 2019/10/26(土) 14:36:55.83

チェーンは滅んでほしい

**デフォルトの名無しさん** · 2019/10/26(土) 14:53:14.83

チェーンってひとくくりにするなよ。メソッドチェーンは糞だが。

**デフォルトの名無しさん** · 2019/10/26(土) 15:11:41.74

チェーン評価ってのも聞いたことがあるな

**デフォルトの名無しさん** · 2019/10/26(土) 16:45:06.90

>>547
矛盾ってのがよくわからないんだけど
今のオプショナルチェーンだと何が問題なの？

**デフォルトの名無しさん** · 2019/10/26(土) 19:08:07.88

この板で否定的な言い分を魔に受けないほうがいい
冗談で言ってるか、冗談みたいな馬鹿の言い分だから

**デフォルトの名無しさん** · 2019/10/26(土) 23:02:43.13

おっぱい好きだけど爆乳は好きじゃない。

**デフォルトの名無しさん** · 2019/10/26(土) 23:16:28.89

奇乳きらい

◆QZaw55cn4c · 2019/10/27(日) 15:39:15.22

貧乳こそ正義

**デフォルトの名無しさん** · 2019/10/27(日) 20:10:25.95

**デフォルトの名無しさん** · 2019/10/27(日) 21:47:29.52

雄π

**デフォルトの名無しさん** · 2019/10/28(月) 07:30:15.50

ちっぱいだいすき

**デフォルトの名無しさん** · 2019/10/28(月) 11:04:07.07

たかが乳ですら意見割れてるのに関数型の話がまとまるわけないな

**デフォルトの名無しさん** · 2019/10/29(火) 22:37:06.24

うまいことドメイン駆動設計をオブジェクト指向から切り離せないかな？
Javaでアーキテクチャを考えると、「このコードはどこに書くべきか」がずっと分からなくなる
関数のシグネチャ読めばそれがMなのかCなのか業務ロジックなのか入出力なのか、全部分かるように書けないものか

**デフォルトの名無しさん** · 2019/10/29(火) 23:45:32.33

スレチ？それどもRustで考えてるのかな
JavaでもC#でもシグニチャ読めばMなのかCなのかくらいはわかるように書けると思うが

それはいいとしてDDDの本質はOOとは関係ないよ
Functional DDDの本がScalaとF#を例にしたのがそれぞれ出てるから読んでみるといいかも
F#のほうの著者のサイトみればRustのEnumでも同じような事できるのがわかるはず
https://fsharpforfunandprofit.com/ddd/

**デフォルトの名無しさん** · 2019/10/30(水) 00:09:30.97

はえ～

**デフォルトの名無しさん** · 2019/11/01(金) 14:20:55.93

Vulkanが公式でRustをサポートしてくれればRust製のゲームとかもっと出てくるのかなぁ

**デフォルトの名無しさん** · 2019/11/01(金) 15:16:52.33

enumの配列はメモリやばい？
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=0eeab60af9f7385db00275b2d168ac2c

**デフォルトの名無しさん** · 2019/11/01(金) 15:49:15.26

>>564
enum MyEnum {
Foo,
Bar(i32),
Baz(i32, i32, i32, i32, i32),
}

今のRustはEnumの一番大きいvariantに合わせてメモリを確保する
Baz(i32, i32, i32, i32, i32)が、4バイト x 5 = 20バイト
どのvariantかを示すTagバイトで+1バイトとパディングで+3バイト=24バイト
配列の要素数が3なら24 x 3 = 72バイト

**デフォルトの名無しさん** · 2019/11/01(金) 19:25:13.98

現職エントリ（）のドワンゴや
タイ全裸Wantedlyの推してる言語って時点で使う気起きなくなるよね

**デフォルトの名無しさん** · 2019/11/01(金) 19:29:17.10

タイ全裸って？

**デフォルトの名無しさん** · 2019/11/01(金) 21:28:00.41

>>567
タイ全裸Wantedlyでググろう
Wantedlyがタイで全裸になったわけではないが
企業としては全く信用できん

**デフォルトの名無しさん** · 2019/11/01(金) 21:55:41.28

どんなに「こんなに素晴らしい機能がある言語！」とか言われても
「でもあの個人情報お漏らし泥箱や現職エントリ（）ドワンゴとかDMCA乱用のWantedlyとかが推してる時点で……」ってなるのが
正しい社会人としてのあり方

**デフォルトの名無しさん** · 2019/11/01(金) 22:09:13.26

>>565
つまりどんなenum作るでもたくさん値を持たせないほうが余計なメモリ使わずベストってことか

**デフォルトの名無しさん** · 2019/11/01(金) 22:57:41.39

アンチドワンゴがみんなC言語使ってると思うと抜ける

**デフォルトの名無しさん** · 2019/11/01(金) 22:57:51.68

↑思うとワロタ

**デフォルトの名無しさん** · 2019/11/02(土) 02:27:34.58

まあ正直、いまだにえんじにゃーのファッションって部分がでかいわな。

**デフォルトの名無しさん** · 2019/11/02(土) 07:38:49.45

他人がなに使ってのかチラチラ伺いながら自分の使うもの決めるのか
小物すぎるだろ

**デフォルトの名無しさん** · 2019/11/02(土) 13:57:08.64

>>574
つっても現職エントリ様やタイ全裸と一緒にされたくはねえしなあ

**デフォルトの名無しさん** · 2019/11/02(土) 14:20:09.97

同じ言語使ってるだけで同一視すんのはお前だけだよ

**デフォルトの名無しさん** · 2019/11/02(土) 14:32:51.71

それらの企業はRustなんか採用する前からボロボロだっただろ。

**デフォルトの名無しさん** · 2019/11/02(土) 15:40:16.76

んでもって一発逆転をねらって水物のに飛びつくっていうアンチパターンね。

**デフォルトの名無しさん** · 2019/11/02(土) 20:44:05.92

あそこは一人が有名なだけだと思うがな

**デフォルトの名無しさん** · 2019/11/02(土) 22:56:34.85

https://github.com/woboq/qmetaobject-rs
このcrateの中で"rust!"というマクロが使われてるんですがクレート内や依存するクレートの中を探してみても定義してる箇所が見つかりません
どこで定義してるのかわかる方いませんか？

**デフォルトの名無しさん** · 2019/11/02(土) 23:31:33.69

>>580
Rustのマクロとして定義されてるものではないみたいね
↓ここら辺に説明がある
https://docs.rs/cpp/0.5.4/src/cpp/lib.rs.html#209-241