Rust part12

**デフォルトの名無しさん** · 2021/08/24(火) 22:55:27.78

公式
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/

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

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

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

**デフォルトの名無しさん** · 2021/11/02(火) 11:55:17.95

let mutのmutはbindingがmutableかどうか
&mutは型が&mut Tなのかどうか

Cのconst pointerとpointer to constと同じ
Rustはデフォルトimmutableなのでmutableにしたい場合にのみmutで修飾

普通使わないけどパターンマッチと組み合わせると
let &mut mut x = &mut y;
みたいな書き方もありうる

**デフォルトの名無しさん** · 2021/11/03(水) 12:07:17.82

mutが必要ってより、for mutにfor let mutにならないことが不思議

**デフォルトの名無しさん** · 2021/11/03(水) 17:34:54.99

それは単にforの文法がlet不要なように設計されたってだけでは

**デフォルトの名無しさん** · 2021/11/03(水) 18:34:42.48

let パターン = ...
for パターン in iter
match パターン ...
fn hoge(パターン: TypeName, ...)
ってことやぞ

**デフォルトの名無しさん** · 2021/11/03(水) 19:26:40.94

Rustにはif let Some(3) = v {}とか、 while let Some(i) = a {}とかあり。letは不変のキーワードじゃなく
右辺に対するパターンマッチ展開で、for letがないのは、forはfor..inしかなく、Cのようなfor ;条件;の文が
存在しないためという考えらしいです。。。

**デフォルトの名無しさん** · 2021/11/04(木) 06:57:56.88

forで変数の初期化が要るみたいな発想になる時点でC由来の処理系に洗脳されているんじゃぁ・・・

**デフォルトの名無しさん** · 2021/11/04(木) 13:00:03.95

for p in v { … }　は
v.into_iter().for_each(|p| …)　と同じ機能たけど
長いメソッドチェーンな時など敢えてforでなくfor_each使ったりも

**デフォルトの名無しさん** · 2021/11/04(木) 20:16:49.18

ただしfor文は値を返せないのが弱点かな
イテレータならfor_eachの代わりにfoldしたりfindしたりあるいはmapやfilterなど色々処理して最後にcollectしたりと値を返せる

**デフォルトの名無しさん** · 2021/11/04(木) 20:24:42.58

>>958
forやwhileは、そもそもループが実行されないパターンがあるので、それは無理ってなったらしい
だからloopでは値を返すことができるので、loopを使うぺし

**デフォルトの名無しさん** · 2021/11/04(木) 21:17:21.49

>>959
for式やwhile式がOptionを返してループ0回ならNoneで済む話ではないのでしょうか？

**デフォルトの名無しさん** · 2021/11/04(木) 21:26:55.06

forで値を返したいとか言ってるやつまだいたのかw

**デフォルトの名無しさん** · 2021/11/04(木) 23:50:24.53

>>960
ループ内は実行されないからNoneも返せないってことよ
loopは明示的に自分でbreakするから許容

let test: = if true { 1 };
たとえば、これでtestにNoneが入るとかおかしいことになるってわかるっしょ？
それと同じこと。

**デフォルトの名無しさん** · 2021/11/04(木) 23:51:56.14

実際問題としてHITUYOU

**デフォルトの名無しさん** · 2021/11/04(木) 23:52:15.61

ごめん誤爆した。

実際問題として必要な場面がないだろ。

**デフォルトの名無しさん** · 2021/11/05(金) 08:00:41.30

forの話なら、これって今はどっちで書くのが一般的？ルールとして基本はHOFで書くのを
やっぱり強制したいのだけど
https://doc.rust-lang.org/stable/rust-by-example/fn/hof.html

**デフォルトの名無しさん** · 2021/11/05(金) 13:18:20.54

rust現場で使ってる人は何系のシステム作ってるん？

**デフォルトの名無しさん** · 2021/11/05(金) 14:22:06.73

現場で使ってる人なんていません

**デフォルトの名無しさん** · 2021/11/05(金) 14:42:52.35

求人検索をしてみても、Rust使ってるとこなんて指で数えられるぐらいしかなさそうかな

**デフォルトの名無しさん** · 2021/11/05(金) 15:22:01.85

とりあえずいつもの貼っておく
https://www.rust-lang.org/production

**デフォルトの名無しさん** · 2021/11/05(金) 15:29:07.01

試験的にGoからRustに切り替え中だよ。両方ともバックエンドとフロントエンドまでやってるのでそのまま移植出来て簡単…じゃなかった
インフラはサクッと終わったけど、フロントは素のWasmで実装するもGoより遥かに複雑で難解なRustでやる意味は？的な事になって
vDOM系フレームワークで実装するも、Non-vDOM系のが殆どの場面で速い事が分かったのでやり直し中

で、本番環境で運用できるのか？となると最初の印象に反して｢出来る｣と思うね。
動かし始めて不具合が出た時に、何処がヤバいのか分からない怖さがない。
過去の資産と経験則は捨ててRustのお作法に従うようにするのが大切、下手にアレを使いたいので使い回すとかやると余計苦労する。

**デフォルトの名無しさん** · 2021/11/05(金) 19:10:07.53

>>970
もしよろしければオススメのRustフレームワークを教えてください

**デフォルトの名無しさん** · 2021/11/05(金) 20:26:36.98

ちんちんぶらぶらRustすぱーと

**デフォルトの名無しさん** · 2021/11/05(金) 20:33:04.86

うちではバイトの女子大生も使ってるが
Rustを使うような企業はネット求人になんか頼らんだろうね、今のところ

**デフォルトの名無しさん** · 2021/11/05(金) 21:52:24.97

>>971
Dominator

**デフォルトの名無しさん** · 2021/11/05(金) 23:26:41.71

Dominatorってこれか
https://github.com/Pauan/rust-dominator
virtual DOM使わずゼロコストでリアクティブか

ベンチマーク見るとVue/React/Angularなどは非常に遅いんだな
https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html
Vanilla JSで頑張るのでなければRustでDominatorを使った方が良さそうってことか
ウェブフロントエンドまでRustの時代が来るとは驚き

**デフォルトの名無しさん** · 2021/11/05(金) 23:41:27.00

おもしろそうだけど、メンテが辛くなりそう。仕事でそんなん大丈夫かしら？

**デフォルトの名無しさん** · 2021/11/06(土) 01:14:13.09

ダメに決まってんじゃん。。無理やり使おうとしてるのが丸わかりだわ。

**デフォルトの名無しさん** · 2021/11/06(土) 01:50:27.76

>>975
少くともその表に載ってるsolidってのは非vDOM系のJSフレームワークだけど…
その表ではDominatorとどっちが速いですか？
そしてそれはなぜですか？
それを勘案しても、
Vanilla JSで頑張るのでなければRustでDominatorを使った方が良さそうってなりますか？

**デフォルトの名無しさん** · 2021/11/06(土) 01:55:12.94

フロントエンドのwasmでrustを使う意味が分からん、assemblyscriptなんかでts変換したほうがよっぽど
人材確保も容易で速度も出そうだけど、まあ全部１つの言語に統一したいという欲望は分かるが

**デフォルトの名無しさん** · 2021/11/06(土) 08:58:19.69

その種の願望はいつだって失敗してるのに何回でもこだわるバカが出てくる。
ビジュアルプログラミングとかノーコード並みに愚かだわ。

**デフォルトの名無しさん** · 2021/11/06(土) 09:42:55.78

夢は終わらねえ！

**デフォルトの名無しさん** · 2021/11/06(土) 10:40:16.97

htmlマクロが微妙だよな。yewもしかり
マクロの仕様理解して書かないといけないからwebpackみたいなコンパイラー挟んでreact,vueみたいなhtmlベースでかけたら普及進むと思う

**デフォルトの名無しさん** · 2021/11/06(土) 10:43:29.52

フロントエンドはElmで書いた方がいいと思う
Elmの設計をパクったRust用フレームワークよりElmそのもので書いた方がいい

**デフォルトの名無しさん** · 2021/11/06(土) 11:32:19.13

>>979
WasmはもともとC/C++をブラウザのフロントエンドで使いたい願望から
始まったものだ。
意外に思うかもしれないが、C/C++を使いたい人はRustの1000倍くらい多い。

**デフォルトの名無しさん** · 2021/11/06(土) 12:19:33.04

>>979
AssemblyScriptはメモリ管理GC問題があるし文法が単にTSの限定サブセットに過ぎないため色々と辛すぎる

そのためWebAssemblyでの使用言語調査結果もこんな状況でRustが圧勝
https://blog.scottlogic.com/ceberhardt/assets/state-of-wasm/desired-language.png

>>978
Wasm⇔JSのオーバーヘッドがあるので処理が少なくほとんどDOM操作になる時だけはJSのみで書いたほうが速い (当たり前)
そのためほぼDOM操作のそのベンチマークではRustフレームワークがわずか数％遅くなっているが現実には処理内容次第ですぐに逆転する

>>983
Elmは型クラス(Rustではtrait)がなく例えば抽象的なイテレータも持てず色々と辛い

このスレはRustにアンチな人がRustを貶めようと常駐して頑張ってるようだけど
Rustを用いるのがベストな方法な場合が非常に多いよ

**デフォルトの名無しさん** · 2021/11/06(土) 16:27:09.97

もはや人類の発展はRustにかかっていると言ってもいい

**デフォルトの名無しさん** · 2021/11/06(土) 16:30:35.71

Rustのお陰でハゲが治りました！

**デフォルトの名無しさん** · 2021/11/06(土) 16:45:26.77

C++ドロップアウターの掃き溜まり

**デフォルトの名無しさん** · 2021/11/06(土) 16:57:33.02

similar word exists: `掃き溜め`
similar word exists: `吹き溜まり`

**デフォルトの名無しさん** · 2021/11/06(土) 21:24:09.65

rustがベストな時が多いとかよくそういうデマを平気で流せるよね。。

**デフォルトの名無しさん** · 2021/11/06(土) 21:39:59.60

シャドーイングがよくわかりません。
変数名によって中身が一意に決まらなくなることによって、安全性も下がるし並列性？も確保できなくなる気がするのですが、変数が全mutableな言語より安全性マシだしRustは関数型言語じゃないから並列性そこまで重要視してないし書き味のが大事だぜってことですか？

**デフォルトの名無しさん** · 2021/11/06(土) 21:47:09.97

安全性も下がるし並列性？も確保できなくなる気がするのは気のせいではないでしょうか

**デフォルトの名無しさん** · 2021/11/06(土) 22:22:33.53

>>991
プログラミング初心者には難しいかもしれないけど
一般的にプログラミング言語ではスコープという概念があってスコープが異なれば同じ変数名でも全く別のものとして認識され格納場所は異なるし型が異なってもよい
その中でもブロックスコープは多くのプログラミング言語で採用されていてブロックが始まると新たなスコープが出来て同じ変数名でも全く別のものとして扱われる
今回のシャドーイングスコープも同様でシャドーイングの時点から新たなスコープが始まるため同じ変数名でも全く別の変数として扱われる
だから安全性は全く下がらないし並行でも並列でもシャドーイングで問題が生じることはない
むしろシャドーイングの利用で利便性が高まっていることがプログラミング経験を重ねると理解できる

**デフォルトの名無しさん** · 2021/11/06(土) 22:44:27.14

ダイナミックスコープはいらない子だった・・・？

**はちみつ餃子** ◆8X2XSCHEME · 2021/11/06(土) 23:40:03.82

ダイナミックスコープがデフォルトの言語なんて Emacs Lisp くらいしか見たことないわ。

**９９１** · 2021/11/07(日) 06:37:58.76

意図したシャドーイングならともかく、間違って同じ変数名つけたコード片突っ込んでしまった系だと他言語にあるらしい２重宣言エラーないの怖くないですか？

新たなスコープが生まれるので並列性に問題ないことはなんとなく理解できました

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

D言語の再来。

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

次スレは？
>>980が1時間待っても立てなかったら俺がやる

**デフォルトの名無しさん** · 2021/11/07(日) 08:48:10.79

質問いいですか

**デフォルトの名無しさん** · 2021/11/07(日) 10:09:41.36

くたばれ

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 74日 11時間 14分 14秒