Rust part11

**デフォルトの名無しさん** · 2021/06/17(木) 00:24:12.56

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

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

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

前スレ
Rust part10
https://mevius.5ch.net/test/read.cgi/tech/1617367084/

**デフォルトの名無しさん** · 2021/07/23(金) 02:10:09.02

asyncは途中I/Oウェイトで待たされるような処理じゃないと意味がない

**デフォルトの名無しさん** · 2021/07/23(金) 10:52:29.51

スレッド、プロセス、タスクなどの定義は分野やプラットフォーム等によって異なる

**デフォルトの名無しさん** · 2021/07/23(金) 12:55:46.87

VSCode+Rust Analyzerの環境で、ミュータブル変数にアンダーラインが付されるのをやめたいのですがどうすればよいですか？

**デフォルトの名無しさん** · 2021/07/23(金) 13:55:17.59

awaitの前後でスレッドは変わる可能性があるものの、タスクは変わらないんだと思ってたわ

**デフォルトの名無しさん** · 2021/07/23(金) 13:58:58.67

>>357の言う「タスク」って1つのasync関数のように読めるんだが、そういう理解で合ってるのか？

**デフォルトの名無しさん** · 2021/07/23(金) 14:46:14.22

>>362
tokio::spawnなどの引数に渡すものがタスク
async関数やブロックの場合もあるし、それらをコンビネーターでしたものの場合もある

**デフォルトの名無しさん** · 2021/07/23(金) 15:12:50.36

だとすると「スレッドよりさらに小さい」ってのは変だな。大きい小さいあるいは包含関係が決められるものじゃない。

**デフォルトの名無しさん** · 2021/07/23(金) 15:14:21.60

そもそも直交する概念だし用途によって使い分けるものでもあるし

**デフォルトの名無しさん** · 2021/07/23(金) 16:49:32.73

スレッドより軽量という意味での小さいなら分かる

**デフォルトの名無しさん** · 2021/07/23(金) 19:17:06.47

Elixirのプロセスは、軽量プロセスと言われていて、
OSのプロセスやスレッドではなく、Greenスレッドです

カーネルではなく、VMでスケジューリングされるので軽量、
コンテキストスイッチが発生しない

1軽量プロセスで約300ワードです

**デフォルトの名無しさん** · 2021/07/23(金) 19:46:36.80

ここはRustスレ

**デフォルトの名無しさん** · 2021/07/23(金) 21:20:19.48

いつものRubyキチガイだろう
何言っても無駄だからスルーするしかない

**デフォルトの名無しさん** · 2021/07/23(金) 21:25:52.66

>>366
スレッドで動くんだから「スレッドより軽量」ってことはない。

**デフォルトの名無しさん** · 2021/07/23(金) 21:50:34.41

>>367
軽量プロセスでもコンテキストスイッチは発生するよ

**デフォルトの名無しさん** · 2021/07/23(金) 22:59:27.49

>>370
タスクと同じことをスレッドでやろうとした場合の比較ね
タスクと同じ数のスレッドを作った場合スタックだけで結構な量のメモリが必要になったりする
あとコンテキストスイッチのコストは少なく済んだりするんじゃないかな

**デフォルトの名無しさん** · 2021/07/23(金) 23:08:30.77

>>372
「タスク」の定義が>>363のようなものならそれはスレッドと直交する概念だと思うが？

**デフォルトの名無しさん** · 2021/07/24(土) 00:30:53.20

心臓のスイッチ切って死なねえかなこいつら

**デフォルトの名無しさん** · 2021/07/24(土) 01:45:40.45

>>370
async/awaitでのタスクはスレッドよりリソースを喰わず軽量
例えば1つのスレッドの上に1万個のタスクでも動作可能でいわゆるC10K問題も対応できる軽量さ

>>373
直交する概念ではなく重量順に
OSプロセス≧OSスレッド≧タスク
（それぞれ＝となるのは1プロセス1スレッドおよび1スレッド1タスクで用いる時）

**デフォルトの名無しさん** · 2021/07/24(土) 02:52:34.75

タスクって名前が良くないな
一般的にはタスクってプロセスのことじゃない？

**デフォルトの名無しさん** · 2021/07/24(土) 02:57:53.91

んなことないでしょ？？？

**デフォルトの名無しさん** · 2021/07/24(土) 04:00:31.27

タスクってのは内部実装的には非同期I/Oを使ったシングルスレッドでしょ。

**デフォルトの名無しさん** · 2021/07/24(土) 07:37:56.03

>>375
OSプロセスは複数のスレッドを持つ場合があるから≧でいいが、>>363の言うタスクなら
1スレッドで同時に実行できるのは1タスクしかないと思うが？

**デフォルトの名無しさん** · 2021/07/24(土) 09:29:01.55

Rustのasyncについて知りたければ「async-book」は必読なので
次からテンプレに入れよう
https://rust-lang.github.io/async-book/

>>980
よろしこ

**デフォルトの名無しさん** · 2021/07/24(土) 10:59:35.94

>>379
1スレッドで同時に実行されるタスクが1つというのは正しい

従来のスレッドでの並列化(1スレッド1タスク)の場合、IO処理を呼び出すと処理完了するまでの間はスレッドはsleep状態になってしまっていた
sleepしている間に他のタスクを実行させるためには、実行するタスクと同じ数だけのスレッドを生成する必要があるが
スレッド生成で消費するリソースが多いため数万タスクを同時に捌くことは難しかった

async-awaitではIO処理完了までの間スレッドをsleep状態にするのではなく別のタスクを実行する
これによりスレッドあたりの処理可能タスク数が増えるため、アプリケーション全体で同時に捌けるタスク数も増える

従来の手法でもスレッドをsleepさせないようなプログラミングは可能だけどプログラムの構造を大きく書き換えないといけなかった
普通のスレッド並列のプログラムと同じ書き味でより多くのタスクを捌けるプログラムが書けるというのがasync-awaitの一番のメリット

ただし常にasync-awaitが望ましいわけでもない
async-awaitで効率的に実行できるのはIO待ちが発生するタスクの場合で、CPUをぶんまわす処理には向いていない
適材適所で従来のスレッドによる並列化手法と組み合わせて使うことになる

**デフォルトの名無しさん** · 2021/07/24(土) 11:28:00.32

>>379
いいえ
1つのスレッド上で同時に複数のタスクを並行(concurrent)に実行できるのがasync/awaitのタスクです。
C10Kと言われるように1つのスレッド上で10000のタスクでも並行に実行できます。

ちなみに1つのスレッド上で並列(parallel)に実行されるのは1つのタスクのみなのは当たり前なので、わざわざ言うことはないです。
今回はasync/awaitの話なので、
『1つのスレッド上で同時に複数のタスクを並行(concurrent)に実行できる』が正解です。

**デフォルトの名無しさん** · 2021/07/24(土) 11:33:29.24

>>381
その1スレッドが時分割で複数タスクを実行できるということのちょうど裏返しで、1タスクは複数スレッドから実行され得る。
つまりそこに大小関係、包含関係などは無い直交した概念。
軽量云々てのはOSスレッドとグリーンスレッドの話とごっちゃになってんじゃないかねぇ。

**デフォルトの名無しさん** · 2021/07/24(土) 12:05:51.45

>>382
>C10Kと言われるように1つのスレッド上で10000のタスクでも並行に実行できます。

本当に並行に実行される？
キューイングされたコールバックを順に呼んでるだけじゃなくて？

**デフォルトの名無しさん** · 2021/07/24(土) 12:13:15.89

ねえこの引っ込みがつかなくなったゴミクズ共のメンチの切り合いっていつまで続くの？

**デフォルトの名無しさん** · 2021/07/24(土) 12:14:13.90

包丁刺し合って死んで終わらないからネットのマウント取り合いって性質が悪いんだよね

**デフォルトの名無しさん** · 2021/07/24(土) 12:17:43.31

5chに何も期待してるのか

**デフォルトの名無しさん** · 2021/07/24(土) 12:21:52.26

>>384
あなたは初心者のようだから
まずは基礎知識である並行(concurrent)と並列(parallel)の違いを理解してから
あらためて>>382を読み直して理解しましょう

**デフォルトの名無しさん** · 2021/07/24(土) 12:40:53.43

>>388
理解した
並列じゃないってことね

**デフォルトの名無しさん** · 2021/07/24(土) 12:41:30.17

間違った
並行じゃないってことね

**デフォルトの名無しさん** · 2021/07/24(土) 12:42:53.22

で、実際のところランタイムってlongjmpみたいなことしてるの？

**デフォルトの名無しさん** · 2021/07/24(土) 12:49:05.14

>>391
しない
Futureを実装したオブジェクトのメンバとして持ち回る
クロージャがFnMut/FnOnceを実装したオブジェクトのメンバとして状態を持ち回るのと同じ

**367** · 2021/07/24(土) 12:51:25.18

Elixir, Go の軽量プロセスと同じでしょ？

OS は関係ない。
言語(VM)内で切り替えているだけだから

**デフォルトの名無しさん** · 2021/07/24(土) 13:02:35.92

タスクの厳密な定義が気になるのってFutureを必要とする動機が無いんじゃないかね
別に新しいことができるわけじゃないし、必要無ければ知らなくていいよ

**デフォルトの名無しさん** · 2021/07/24(土) 13:54:25.17

C10k問題がまずあって、それをselect/epollで解決するってシナリオをまず理解しておかないと
何でめんどくさい事わざわざやってんの？としかならんでしょ
モチベーションが大事

**sage** · 2021/07/24(土) 14:51:29.52

まともにテストしてねーじゃん
https://lkml.org/lkml/2021/7/7/422

**デフォルトの名無しさん** · 2021/07/25(日) 01:04:24.12

オライリーのrustの本ってどう？
これから勉強するんだけど、これ使っても時代に遅れない？

**デフォルトの名無しさん** · 2021/07/25(日) 02:38:56.34

4年前の本だからおすすめはしないな

**デフォルトの名無しさん** · 2021/07/25(日) 02:43:00.77

>>383
マルチスレッドなランタイムを使えばスレッドとタスクはm:nだけど
シングルスレッドなランタイムを使えばスレッドとタスクは1:n
いずれの場合でもタスクはスレッドより軽量な存在であり直交する概念ではない

**デフォルトの名無しさん** · 2021/07/25(日) 09:01:27.23

>>397
原著の第2版がオススメ

といってもasyncの章が追加されたのを除くとコアなところは第1版と同じ
今のところオライリー本が圧倒的に良いので他の本で学ぶくらいなら第1版の訳書のほうがいい
古くなってるところはEdition Guideやasync-book、Rust Blogで補完

**デフォルトの名無しさん** · 2021/07/25(日) 09:12:18.43

俺もそう思う。古かろうがオライリー本が圧倒的に良い。

**デフォルトの名無しさん** · 2021/07/25(日) 09:59:11.23

>>397
言語仕様的なのが延々と書いてあっても辛くないタイプの人ならオススメ
自分はそういうのが好きだが、「サンプルアプリを作りながら学びましょう」ってタイプではないので合わない人はいると思う

**デフォルトの名無しさん** · 2021/07/25(日) 11:34:17.97

Rust はサンプルコードを見ながら真似ていれば雰囲気で書けるようになる……
なんていう言語ではないので基礎的な理屈を体系的に (それでいてわかりやすく)
説明してくれるオライリー本はとても良いよ。

確かに理屈っぽいが、 Rust がそういう言語なのでオライリーの本がつらいと思う人は
そもそも Rust がつらいタイプの人なんだと思う。

**デフォルトの名無しさん** · 2021/07/25(日) 19:04:19.16

Rustlingsのこれやっててよくわかんなかったんだけどさあ
https://github.com/rust-lang/rustlings/blob/main/exercises/if/if1.rs
自分の解答は
pub fn bigger(a: i32, b: i32) -> i32 {

if a > b{
return a;
}
b
}
これなんだけど、「return a;」のところってなんで「a」だけじゃダメなの？

**デフォルトの名無しさん** · 2021/07/25(日) 19:46:35.31

elseがあればいいんじゃない？

**デフォルトの名無しさん** · 2021/07/25(日) 19:49:48.51

>>404
関数の最後じゃにゃいから

**デフォルトの名無しさん** · 2021/07/25(日) 21:25:46.69

オライリー買ってくる

**デフォルトの名無しさん** · 2021/07/25(日) 21:31:05.59

ありがとう
最後の式だ特別なのか

**デフォルトの名無しさん** · 2021/07/26(月) 20:33:20.42

文と式を区別しましょう

**デフォルトの名無しさん** · 2021/07/26(月) 21:31:17.41

ブロック式が値を持つなら式文も値を持たせればよかったと思うんだけど、それだと何か都合が悪いのかな。

**デフォルトの名無しさん** · 2021/07/26(月) 21:53:51.50

それは式文を構成する式と何が違うのか

**デフォルトの名無しさん** · 2021/07/26(月) 22:05:31.99

最後だけセミコロンを外すとかしなくて済む。

**デフォルトの名無しさん** · 2021/07/26(月) 22:09:46.01

セミコロンあるなしで意味が変わるのって、バグを産む原因になりそう

**デフォルトの名無しさん** · 2021/07/26(月) 22:26:28.18

その流れ前スレでも見た気がする

**デフォルトの名無しさん** · 2021/07/27(火) 00:03:59.51

どちらかというと;の有無で()を返すかどうか制御できる方がいい気がするけどな
式文も値を持つならわざわざ();って書かないといけない
（まぁわざわざ書かせるのもRustらしい気もするが）

>>413
間違えたら型エラーになるからバグにはならんと思うよ

**デフォルトの名無しさん** · 2021/07/27(火) 03:17:46.37

() を返す場合は関数省略だからreturn必須でよかったな

**デフォルトの名無しさん** · 2021/07/27(火) 05:41:20.63

if-elseとかmatchとかでひたすら();書くのさすがにやばくない？

**デフォルトの名無しさん** · 2021/07/27(火) 08:21:13.66

どうしても () を返さなきゃならない場面ってそんなに多いんだっけ？

**デフォルトの名無しさん** · 2021/07/27(火) 08:35:39.46

コード例がないから全然わからん

**デフォルトの名無しさん** · 2021/07/27(火) 08:54:31.16

Ok(())とか？

**デフォルトの名無しさん** · 2021/07/27(火) 09:50:38.86

最初アホみたいにReturn合った方が…とか思ってたけど慣れると全く要らん境地になるから不思議

**デフォルトの名無しさん** · 2021/07/27(火) 10:35:08.16

>>418
少なくともletは値を返すわけにはいかないので()だね
まぁCopyなら返せなくもないけど、Copyかどうかで挙動が変わるのはさすがに…
();を明示する、みたいにするとletだけ特別扱いになるし、結局今のルールでいいんじゃないかと

**デフォルトの名無しさん** · 2021/07/27(火) 11:00:19.20

elseのないif式で偽の時の値の話だと思ってた

**デフォルトの名無しさん** · 2021/07/27(火) 11:03:48.76

>>417
書き方が悪かった
returnは値を返す時は必須だけどreturnがない場合は省略する。関数の返り値と同じ法則で

**デフォルトの名無しさん** · 2021/07/27(火) 19:22:36.90

でも、関数の最後じゃなくてもさあ
文があったら、そこでリターンしてくれたらいいのにな
まあ、ミスってても気づき辛くなるからダメなんかな？

**デフォルトの名無しさん** · 2021/07/27(火) 19:47:32.00

2文目以降は一切評価されないってことか
斬新だね

**デフォルトの名無しさん** · 2021/07/27(火) 21:44:05.27

>>422
特別扱いってのがよくわからないなぁ。
let x が () なら let x; も () でいいし (); を明示する必要もないと思うんだけど。

**デフォルトの名無しさん** · 2021/07/27(火) 21:53:09.04

そもそもletは式じゃないし

**デフォルトの名無しさん** · 2021/07/27(火) 22:40:27.72

XXXがstatementだとか、XXXはexpressionだとか
そういう議論が出る時点でダメ言語のオーラが
言語オタクには楽しいかもしれないけど

**デフォルトの名無しさん** · 2021/07/27(火) 22:47:11.69

だから式文じゃない文は () でいいんじゃね？特に特別扱いとは思わんが。

**デフォルトの名無しさん** · 2021/07/27(火) 23:18:47.62

文は()という単純なルールを崩してまで式文から値を得たいモチベーションがよくわからん
単に;を取って式にすればいいだけなのに

**デフォルトの名無しさん** · 2021/07/27(火) 23:20:35.98

Rust書いてて式と文を意識して区別しないといけないことなんて無いよ
CやPythonならあるけど

**デフォルトの名無しさん** · 2021/07/27(火) 23:30:43.54

関数末尾だけセミコロン外すのが気に入らないなら、C/C++でやってたようにreturn x;とすればいい
それで不都合を生むことはない

**デフォルトの名無しさん** · 2021/07/28(水) 00:01:15.04

clippy先生に注意される

**デフォルトの名無しさん** · 2021/07/28(水) 01:30:00.88

全てはclippy先生の仰せのままに

**デフォルトの名無しさん** · 2021/07/28(水) 01:47:51.35

#![allow(clippy::foo)] を書けばいいじゃん

**デフォルトの名無しさん** · 2021/07/28(水) 04:09:34.57

なるほど

＞Rustのセミコロンは意味と構文からそれぞれ説明できる。
＞意味論的には、以下の原則を覚えておけば十分である。
＞
＞・セミコロンで終端された文は強制的に () 型となる。
＞・ブロックの途中の文は () 型でなければならない。
＞・ブロックの型はブロックの最後の文の型と等しい。(文がひとつもない場合は ())

**デフォルトの名無しさん** · 2021/07/28(水) 07:29:31.85

＞・ブロックの途中の文は () 型でなければならない。

これがあるから1行目の仕様なんだろうけど、これの理由ってなんなのかな。

**デフォルトの名無しさん** · 2021/07/28(水) 08:03:12.35

文に型なんてないよ

**デフォルトの名無しさん** · 2021/07/28(水) 08:14:26.64

文って値を返さないのかと思ってたけれど、
()を返してるって事？

**デフォルトの名無しさん** · 2021/07/28(水) 08:37:40.51

ブロックの型はブロックの最後の「式」の型と等しい。(「ブロックの最後に式がない」場合は())

ここの間違いが他のすべての説明によく分からない辻褄合わせを持ち込んでいるだけだと思う

**デフォルトの名無しさん** · 2021/07/28(水) 09:58:43.22

>>437
＞・ブロックの途中の文は () 型でなければならない。

そもそもブロックの途中の文を()以外にすることってできるの？
{ foo; bar } みたいなブロックを{ foo bar }とは書けないし

**デフォルトの名無しさん** · 2021/07/28(水) 10:29:08.57

>>442
それは型の問題以前に文法の問題

型だけの問題だというなら、{ let foo = (); foo bar }と書けばコンパイルできるはずだが、
もちろんそんなことはない

**デフォルトの名無しさん** · 2021/07/28(水) 11:58:08.16

Facebook、次期ビルドシステムの開発でRust言語の採用を明らかに
https://www.publickey1.jp/blog/21/facebookrust.html

**デフォルトの名無しさん** · 2021/07/28(水) 11:59:44.89

>>443
文法の問題を解決しつつブロックの途中の文を（）以外にする方法がわからんってことよ

**デフォルトの名無しさん** · 2021/07/28(水) 12:46:01.08

>>445
何度でも言う
文に型はない

**デフォルトの名無しさん** · 2021/07/28(水) 12:58:11.75

「文を()にする/()以外にする」の正確な意味を言語化してほしい
「文が評価されて結果として()/()以外が得られる」という意味で言っているのなら、文は評価されて結果を返すものではない
評価されて結果を返すものは式と呼ばれる
文は式ではない

**デフォルトの名無しさん** · 2021/07/28(水) 13:10:10.87

>>447
俺もそのへんはよくわからんが、
式文は「文が評価されて結果として()が得られる」って認識で使ってた
これが誤りならまあすまん

ここにこだわるつもりは全然なくて、
ようするに>>437の「ブロックの途中の文は () 型でなければならない。」ってのがどういうこっちゃってこと
この表現だと() 型じゃなくする方法があるように読めるからさ

**デフォルトの名無しさん** · 2021/07/28(水) 13:12:38.58

この一連の議論の評価値は ()

**デフォルトの名無しさん** · 2021/07/28(水) 13:27:20.45

>>448
自分は>>441で書いた通りその部分は辻褄合わせだと思ってるよ

まあでも、自分もRust入門したころは似たようなことでこんがらがってたような気はする
ブロックが式だなんて思ってなかったからかな

**デフォルトの名無しさん** · 2021/07/28(水) 14:29:43.24

>>449
コンパイルエラーだよ

**デフォルトの名無しさん** · 2021/07/28(水) 14:52:26.31

セミコロン省略できる式文(?)の型が()ではない場合は型エラーになるね
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=85e09ac464b7f9fb07b6aa1e2d08e8c9

セミコロンをつけたり、型を()にしたりするとエラーにならない
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=4e4152ae35e8fd2821060f44ed9a2fda
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=86429babc54c38b515dfe1f9de85f127

**デフォルトの名無しさん** · 2021/07/28(水) 17:33:51.84

最も単純化してこれはコンパイル通るけど
fn main() {
　if true {
　　1
　} else {
　　0
　};
　()
}
しかし上記のifの尻のセミコロン無しだとコンパイルエラー【値が()ではない】となる
セミコロン無しでも数字1と0を()へ変えればコンパイルが通る

つまり
>>437
＞・ブロックの途中の文は () 型でなければならない。

ifをセミコロン無しで値が数字だと上記の条項を満たせないためエラー
ifをセミコロン無しで値が()だと上記の条項を満たせる

あるいは
＞・セミコロンで終端された文は強制的に () 型となる。

値が数字でもifをセミコロン終端させれば上記の条項を満たせる

**デフォルトの名無しさん** · 2021/07/28(水) 17:46:15.09

で？って感じだけど
とりあえずリファレンス見てくれば？
https://doc.rust-lang.org/reference/expressions/block-expr.html

**デフォルトの名無しさん** · 2021/07/28(水) 18:03:06.43

>>454
そのリファレンスの説明だけだと
以下はコンパイル通るけど、関数内の3つの()のうち任意の1つでも数値に変えるとコンパイルエラーとなる説明はどの部分になる？

fn main() {
　if true {
　　()
　} else {
　　()
　}
　()
}

**デフォルトの名無しさん** · 2021/07/28(水) 18:13:09.38

今問題になってるのはこっちだね
最後の方に「;省略した式文は()でないといけない」となっている
https://doc.rust-lang.org/reference/statements.html

**デフォルトの名無しさん** · 2021/07/28(水) 18:38:39.95

>>455
Note: As a control flow expression, if a block expression is the outer expression of an expression statement, the expected type is () unless it is followed immediately by a semicolon.
https://doc.rust-lang.org/reference/expressions/block-expr.html

An expression that consists of only a block expression or control flow expression, if used in a context where a statement is permitted, can omit the trailing semicolon. This can cause an ambiguity between it being parsed as a standalone statement and as a part of another expression; in this case, it is parsed as a statement. The type of ExpressionWithBlock expressions when used as statements must be the unit type.

When the trailing semicolon is omitted, the result must be type ().
https://doc.rust-lang.org/reference/statements.html#expression-statements

あとif式はifのブロックとelseのブロックで型が揃ってないとだめだよ