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/08(火) 00:43:17.33

ウィンドーズホンだとC#からC++/CXを経由してネイティブなC++が呼べたお

**デフォルトの名無しさん** · 2019/10/08(火) 00:45:06.10

なるほど。開発環境が決まっててABI決めうちできるならいけるのか。

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

Dがあるじゃん

**デフォルトの名無しさん** · 2019/10/09(水) 11:04:16.03

ここの住民の低レベルさが確定した

**デフォルトの名無しさん** · 2019/10/09(水) 11:15:47.99

レベルの高い話題くれ

**デフォルトの名無しさん** · 2019/10/09(水) 17:58:10.09

Cは社交界のオキテを知らない村娘だから
不用意に呼ぶとズッキュウウウンしちゃったりするのよ
だから簡単に呼べなかったりするけど呼べるときはシャワーも浴びずにすっ飛んでくる、そんな子

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

C++のライブラリへのバインディングでほとんどのAPIがunsafe&unsafeって書いて無い奴もunsafeかもしれんから自分で気をつけてね☆
みたいのがあるんやが

これってRustで書く意味無くね…？

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

貴方がRustで書き直せば喜ぶ人もいるんじゃない？

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

ま～つもと
いけいけまつもと
がんばれまつもと

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

>>448
C++のライブラリ使うからだろ。
Rustで書かれたもの使うか、Rustで書き直せ。

**デフォルトの名無しさん** · 2019/10/10(木) 13:45:05.68

Box<T>のTを初期化せずに返すunsafe fn box_t() -> Box<T> があったとして
let mut t;
unsafe {
t = box_t();
// Tの初期化
}
にするのと
let mut t = unsafe { box_t() };
// Tの初期化
ですますのとどっちが良いRust?

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

Rustプログラミング入門
https://www.ohmsha.co.jp/book/9784274224355/

**デフォルトの名無しさん** · 2019/10/10(木) 14:59:57.87

>>452
unsafeで囲む範囲はどの言語でも最小限にしろよ
初期化にunsafe要らんのなら囲むな

**デフォルトの名無しさん** · 2019/10/10(木) 19:40:43.29

なんでＵｎｓａｆｅメモリ領域にしなかったんだ…

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

ﾑﾝｯ

**デフォルトの名無しさん** · 2019/10/11(金) 09:08:20.83

>>448
unsafeなAPIに対してrustで安全なラッパーを被せてやれれば意味がある

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

unsafe fn vec_t_n(n: usize) -> Vec<T> {
let mut v: Vec<T> = Vec::with_capacity(n);
v.set_len(n);
v
}

fn vec_t_n(n: usize) -> Vec<T> {
let mut v: Vec<T> = Vec::with_capacity(n);
unsafe { v.set_len(n); }
v
}

unsafe fnにするかfnにするか
例えばutf-8を保証するStringのようにTがなにかを保証する型だとして
Vec<T>の中身がTでないかもしれないからunsafe fnが良いRustでOK?

**デフォルトの名無しさん** · 2019/10/11(金) 11:00:26.28

>>455
1文字ずつ文字間開いてるとucs2で書かれてるように見える

**デフォルトの名無しさん** · 2019/10/11(金) 15:38:54.43

>>458
そのコードだけで言えばset_len()を使うことで保証されなくなるlengthの正しさを
呼び出し側が保証する必要があるのかどうか

from_utf8_uncheckedみたいな別のunsafe fn使ってればそれによって壊される安全性があるなら
その安全性を呼び出し側が保証する必要があるのかどうか

**デフォルトの名無しさん** · 2019/10/15(火) 20:37:26.43

https://keens.github.io/blog/2015/09/23/rustwokakutokinochiken/
move semanticsのお陰でGCがないので本当に小さい。hello, worldが277KBだった。

Javaででかいのが当たり前で大昔の感覚を忘れてしまったんだが
ちいさい？

**デフォルトの名無しさん** · 2019/10/15(火) 21:56:51.61

その千分の一でもまだでかい

**デフォルトの名無しさん** · 2019/10/15(火) 22:12:04.54

バイナリゴルフが流行ってんの？

**デフォルトの名無しさん** · 2019/10/15(火) 22:36:57.07

たった13バイトの文字列をコンソールに出力するだけで283648バイトを浪費ｗｗｗｗｗ

**デフォルトの名無しさん** · 2019/10/15(火) 22:39:45.49

minimal runtimeってタイトルなんだからランタイムが小さいって話だろ。比較対象はGoとかHaskellとかであって、Cが小さいなんてのは当たり前。

**デフォルトの名無しさん** · 2019/10/16(水) 08:58:56.22

270kBは何が入ってるの

**デフォルトの名無しさん** · 2019/10/16(水) 13:15:16.66

>>465
nim
https://mevius.5ch.net/test/read.cgi/tech/1519896738/

**デフォルトの名無しさん** · 2019/10/16(水) 13:29:20.87

ファミコン版のスターフォースのROMは16KBやったんやで

**デフォルトの名無しさん** · 2019/10/16(水) 13:39:20.98

一方ルーストはhello, worldとコンソールに表示させるだけで277KBｗｗｗ

**デフォルトの名無しさん** · 2019/10/16(水) 18:54:57.62

ファミコンのドラクエ3が256KBだっけ

**デフォルトの名無しさん** · 2019/10/16(水) 19:33:59.18

Kbitじゃない？

**デフォルトの名無しさん** · 2019/10/16(水) 21:08:46.19

エミュROMでぐぐったら出てきた
ドラクエ3が256KByte
ドラクエ3が128KByte
ドラクエ1が64KByte
どれもKbitではない

**デフォルトの名無しさん** · 2019/10/17(木) 00:23:19.63

N88-BASICとかディスク拡張命令とか考えなければ32 KBに収まってた
数十KBというのは広大な情報量
人間の遺伝子もジャンクDNAを除けば10 KB強ぐらいなのではないか

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

https://www.tel.co.jp/museum/magazine/news/042.html
だってさ
ジャンク含めてもＣＤ一枚分の模様

**デフォルトの名無しさん** · 2019/10/17(木) 17:16:51.68

go だと Hello, work! だけで 2MB でした本当にありがとうございました

**デフォルトの名無しさん** · 2019/10/17(木) 18:57:57.40

日本は欧米と比べてココがダメ！
↓
韓国のほうがもっとダメなのでセーフ！

**デフォルトの名無しさん** · 2019/10/17(木) 20:26:17.00

>>475
デバッグ情報をストリップしてください

**デフォルトの名無しさん** · 2019/10/17(木) 20:41:23.80

https://www.atmarkit.co.jp/ait/articles/1910/17/news088.html
「Rust」言語を採用したAWS、Rustプロジェクト支援を開始

Amazon Web Services（AWS）は2019年10月14日（米国時間）、オープンソースのシステムプログラミング言語「Rust」について、開発プロジェクトをスポンサーとして支援することを発表した。

　Rustは、高速で信頼性が高く、効率的なコードを作成、保守できるように設計されている。2015年に最初の安定版がリリースされて以来、実システムへの導入が大きく進んでおり、GoogleやMicrosoft、Mozillaのような企業がいずれもRustを使用している。

　例えばMicrosoftは自社製品の脆弱（ぜいじゃく）性の約7割を占めるメモリ安全性の問題を解決するためにRustが役立つと指摘している（関連記事）。

　AWSでもRustの利用は大幅に拡大しており、「Lambda」「EC2」「S3」のようなサービスにおいて、パフォーマンスに敏感なコンポーネント用の言語として採用している。

　AWSは先ごろ、軽量のマイクロ仮想マシン（microVM）を数秒で起動できる安全な仮想化技術「Firecracker」をオープンソースとして公開したが、ここでもRustが採用されている（関連記事）。

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

それでも数秒かかるんか…
コールドスタートの悪夢未だ醒めず

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

＞例えばMicrosoftは自社製品の脆弱（ぜいじゃく）性の約7割を占めるメモリ安全性の問題を解決するためにRustが役立つと指摘している（関連記事）。

これWindowsの脆弱性の話だろうけど、
静的解析ツールでは解決しないってことなのか？

**デフォルトの名無しさん** · 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

モナド早くきてくれー