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/10/27(水) 08:48:37.83

Boehmってカタカナ的には何て読むの？

**デフォルトの名無しさん** · 2021/10/27(水) 09:08:54.86

ボエヒムじゃないの？

**デフォルトの名無しさん** · 2021/10/27(水) 10:46:43.20

ベームかボームだろ、ボエヒムとかワロタw

**デフォルトの名無しさん** · 2021/10/27(水) 11:14:08.33

ドラクエの呪文みたいだな

**デフォルトの名無しさん** · 2021/10/27(水) 11:35:17.90

ドイツ語のoeは日本語ではエって転写される

**デフォルトの名無しさん** · 2021/10/27(水) 12:01:22.63

Phoenix

**デフォルトの名無しさん** · 2021/10/27(水) 12:11:52.89

412 名前：以下、名無しにかわりましてVIPがお送りします投稿日： 2013/01/19(土) 21:03:25.42 ID:a2pD/tlo0

FランのFはフェニックスのFや！
例えこんなところで落ちぶれても不死鳥のごとく上流階級に返り咲くんや！！

414 名前：以下、名無しにかわりましてVIPがお送りします投稿日： 2013/01/19(土) 21:04:02.87 ID:dT9mn0sK0

>>412
フェニックスは「phoenix」

**デフォルトの名無しさん** · 2021/10/27(水) 14:01:22.92

cafe la boheme

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

>>887
スレチだが、Boehmなので本来はSTWだけなのでUnityにGCラグが発生していたことは有名ですが、2018/12頃に
インクリメンタルGCが出来て改善された。
https://blog.unity.com/technology/feature-preview-incremental-garbage-collection
またUnityでゲームなどを作るときに良くやるのがGCを動かさないこと（＝オブジェクトを破棄しない）で
オブジェクトプールを使用して1度作ったオブジェクトをプールして置き破棄させない方法など、Unityにある
文字列比較などを使用しないなど細かい事をやる。本末転倒といえばその通り

**デフォルトの名無しさん** · 2021/10/29(金) 02:30:41.55

典型的なバッドノウハウだな
とはいえ日本でUnityが一番つかわれているであろう現場のモバイルゲーム開発は
昔はケータイJavaのゲーム開発やってた場合が多いのでその辺のGCバッドノウハウに慣れちゃってるという
Boehmはボエーンて読んでるわ

**デフォルトの名無しさん** · 2021/10/29(金) 02:58:27.64

oe はドイツ語の o の代替綴りとしてあてられることが多い。
つまり boehm の本来の綴りは bohm ってことね。
o はオの口の音でエという感じなので音としては中途半端で、カタカナに当てはめにくい。

ドイツ語の発音通りをあえてカタカナにするならボェーンに聞こえるんだけど、
bohm という人名は通例ではベームと表記してるね。

**デフォルトの名無しさん** · 2021/10/29(金) 02:58:48.47

あれ？ 2ch に投稿したらウムラウトが消えてる……。

**デフォルトの名無しさん** · 2021/10/29(金) 03:36:42.46

appleをアップルと記載するような文化やからね。カタカナにしてしまったら本来の発音との差異なんて気にしたらキリがない

**デフォルトの名無しさん** · 2021/10/29(金) 04:15:21.99

名女優のオードリー・ヘップバーンと
ローマ字表記のヘボン式で有名なヘボン氏が実は同じ綴り同じ発音の同じ姓みたいなもんか

**デフォルトの名無しさん** · 2021/10/29(金) 05:16:40.74

ドイチュ語と描いてない >>898 は失格

**デフォルトの名無しさん** · 2021/10/29(金) 21:33:27.38

まじかあ、これが可能だったのかあ

let v = vec![1, 2, 3];
println!("{}", v[if true { 1 } else { 2 }]);

**デフォルトの名無しさん** · 2021/10/29(金) 23:53:13.86

>>901

ヘボンさんは自分でも気に入って「平文」なんてハンコ
持ってたくらいだから定着しちゃったんだよなｗ

**デフォルトの名無しさん** · 2021/10/30(土) 00:22:25.21

音韻と音声は異なる。ある言語で同じ音だと認められる音が音韻で、
たとえば日本語だとシンブンシという言葉に表れる二個のンは実際には違う音
なのに同じ音として処理している。
(だからヘボン式ローマ字では書き分けるルールになっている。)

音韻として同じでも音声として幅はあり、そして音韻は言語に依存するもんだから、
外国語の音を転写してくるとどう頑張ったって辻褄の合わない部分は出てくる。

**デフォルトの名無しさん** · 2021/10/30(土) 01:29:07.34

>>901
唐鳳は上手いよな

**デフォルトの名無しさん** · 2021/10/30(土) 02:41:12.91

いつの間にか[T; N]にIntoIteratorがimplされてるな
しかも興味深いことにVec等と異なり消費されないようだ
借用ルール的にはどういう扱い？

**デフォルトの名無しさん** · 2021/10/30(土) 08:30:57.45

イテレータが理解できないやつ定期的に湧くな

**デフォルトの名無しさん** · 2021/10/30(土) 09:56:39.69

常駐

**デフォルトの名無しさん** · 2021/10/30(土) 11:34:48.67

>>902
ドイちェン

**デフォルトの名無しさん** · 2021/10/30(土) 20:52:05.52

>>907
Rust 1.53.0で配列にIntoIteratorが実装された
あと識別子に日本語も使えるようになった
配列は要素がCopyを実装しているかどうかで所有権の扱いが変わる

#[derive(Debug,Clone,Copy)]
struct 構造体 {
　値: isize,
}
fn main() {
　let 配列 = [構造体{値:1}, 構造体{値:2}, 構造体{値:3}];
　for 変数 in 配列 {
　　println!("{:?}", 変数);
　}
　println!("{:?}", 配列[0]);
}

例えばこれはコンパイルが通って動くけど
構造体のderiveのCopyを外すと
配列の所有権はfor in内部のinto_iter()で移動してしまいコンパイルが通らなくなる

**デフォルトの名無しさん** · 2021/10/30(土) 21:00:13.45

>>911
ぶっちゃけ日本語の識別子わかりやすいって思ってしまった

**デフォルトの名無しさん** · 2021/10/30(土) 22:32:29.50

日本語識別子わかりやすいんだけど入力に手間がかかるのがつらい

**デフォルトの名無しさん** · 2021/10/30(土) 23:29:17.10

let v0 = vec![1, 2, 3];
let mut v1 = v0;
v1.push(120);

let mut v0 = vec![1, 2, 3];
let v1 = &mut v0;
v1.push(120);

所有権関連で試してみてるんだけど、この二つの違いってなんなん？
いまいちよくわからん
上のはmutでないvecをlet mutの変数に入れるとpushできてまうし
下のはlet mutでない変数なのに&mutでいれるとpushできてまう

**デフォルトの名無しさん** · 2021/10/30(土) 23:56:55.99

https://doc.rust-lang.org/rust-by-example/scope/move/mut.html

**デフォルトの名無しさん** · 2021/10/31(日) 00:40:09.42

>>914
それぞれpushした後にv0とv1がどうなってるか確認してみるとわかる

**デフォルトの名無しさん** · 2021/10/31(日) 01:41:05.72

うんこ荒らすな！

**デフォルトの名無しさん** · 2021/10/31(日) 02:16:55.91

すまんがVSCode + Rust-Analyzerで勉強中なんだけどさ
数ヶ月前は変数の型が表示されていたのに、今じゃ全然表示されなくなっちゃったんだけど・・・・どうすればいいんだぜ？

**デフォルトの名無しさん** · 2021/10/31(日) 03:00:17.77

int * constみたいなもん

参照先のアドレスは変更不可だけどそのアドレスが指してるvectorは&mutだから変更可能

**デフォルトの名無しさん** · 2021/10/31(日) 03:02:55.52

>>914
他の言語での余計な知識を捨て去ってゼロから考えるとわかりやすかったよ
今回の件で関係するルールは単純でこれだけかな？

【所有権】
・所有権を持てるのは一人だけ
・使う(＝代入や関数引数も含まれる)と所有権は移動する
・ただしCopyトレイト実装型は使う時にCopyされるので所有権は移動しない

【所有権を持つ可変と非可変】
・その変数の中身を書き換える予定があるなら変数を可変(mut)に宣言しておく
・他の変数に代入しなおせば可変か非可変か変更可能(つまりその変数を使う時の制限ヒント)

【参照(＝貸出＝借用)】
・所有権が移動されたくなければ参照で貸し出す
・可変参照(&mut)の貸し出しは1人のみに参照独占で元も可変変数であること
・非可変参照(&)の貸し出しは同時に何人でも可能
・まとめるとsingle writer or multi readers

所有権を明確にするのはメモリ自動解放のため
可変を明確にするのは並行(concurrent)/並列(parallel)での競合回避のため

**デフォルトの名無しさん** · 2021/10/31(日) 07:46:34.10

>>918

inlayHints

**デフォルトの名無しさん** · 2021/10/31(日) 09:44:05.10

所有権を伸ばして発音すると昇龍拳みたいに聞こえる
出掛かりが無敵なところも似てる

**デフォルトの名無しさん** · 2021/10/31(日) 09:51:39.37

ヒカヘンサンショウ

**デフォルトの名無しさん** · 2021/10/31(日) 13:37:02.02

丁寧で優しい920を弄りたくないけど、これを読める人は914のような質問はしないね

**デフォルトの名無しさん** · 2021/10/31(日) 13:58:11.88

以下の関数をジェネリックにする方法ありますか？
fn is_one_two_three<A: AsRef<[isize]>>(a: A) {
　assert_eq!(&[1, 2, 3], a.as_ref());
}
fn main() {
　let a = [1, 2, 3];
　is_one_two_three(a);
　let a = vec![1, 2, 3];
　is_one_two_three(a);
}
配列もVecも受け取る関数でこれはコンパイルも通り動いているのですが
isizeと型が決め打ちのところをジェネリックにTとしたいです
どうするとよいでしょうか？

**デフォルトの名無しさん** · 2021/10/31(日) 14:34:45.61

>>925
数値型を一般化する trait を使うのが普通かな。
自分で定義しても良いが num_traits::FromPrimitive を使うならこんな感じ
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=1fbd536dd6c9ea76beb20a666b085190

**デフォルトの名無しさん** · 2021/10/31(日) 16:04:00.70

>>914
気持ちの上では他の言語と対応付けるのではなく Rust のルールで理解すべきという点で >>920 に
同意ではあるんだが、そうは言っても知っていると引っ張られるのも仕方のない話で、
入門初期では多少はしょうがないとも思う。

あえて C++ で同等のものに置き換えるとするとこんな感じかな。

#include <vector>

int main(void) {
{
const std::vector<int> v0 = {1, 2, 3};
std::vector<int> v1 = v0;
v1.push_back(120);
}
{
std::vector<int> v0 = {1, 2, 3};
std::vector<int>* const v1 = &v0;
v1->push_back(120);
}
}

この場合は所有権の概念はあまり関係なくて
メソッド呼出しの演算子が参照を自動で調整してしまうのも混乱の原因になってる気がする。
mut が何にかかっているのか見えにくい。

**デフォルトの名無しさん** · 2021/10/31(日) 16:25:11.82

>>927
少なくとも上は全く同等じゃない
C++では表現出来ない

**デフォルトの名無しさん** · 2021/10/31(日) 16:52:46.17

>>928
ムーブの仕組みが違うのはしょうがない。
この場合は const 性の話だと思ったから……

**デフォルトの名無しさん** · 2021/10/31(日) 17:14:21.91

C++で考えるのは弊害しかないじゃん
何がしょうがないだよ

**デフォルトの名無しさん** · 2021/10/31(日) 17:47:23.34

弊害しかないは言いすぎ
この場合mutをどこに付けると何が可変になるかの話だから
C++でconstをどこに付けると何が不変になるのかを例に出すのは自然なたとえだと思いますよ

**デフォルトの名無しさん** · 2021/10/31(日) 21:58:15.04

let mut vec0 = vec![vec![0, 2, 3]; 3];

for mut i in vec0.iter_mut() {
　i.push(9);
}

for mut i in &mut vec0 {
　i.push(9);
}

この二つのループの意味は同じ？
こういう二つの書き方があるのでちょっとわかりにくい気がする

**デフォルトの名無しさん** · 2021/10/31(日) 22:14:30.87

へー、これが通るんだ
ちょっと笑った

let vec0 = vec![0, 2, 3];
let mut vec0 = vec0;
vec0.push(99);

**デフォルトの名無しさん** · 2021/10/31(日) 22:21:16.21

>>933
シャドーイングだから当たり前でしょ

**デフォルトの名無しさん** · 2021/10/31(日) 22:22:32.67

シャドーイングOKな言語でもlintが禁止してきてイラっとする

**デフォルトの名無しさん** · 2021/10/31(日) 22:31:01.48

>>934
状態まで置き換え可能なのはおかしいような気がする
せっかく不変変数にしてるのに事実上代入可能にしてることに何の意味があるんだろう

**デフォルトの名無しさん** · 2021/10/31(日) 22:44:51.38

クソみたいな名前が増えないようにだよ

**デフォルトの名無しさん** · 2021/10/31(日) 22:57:25.82

>>924
「関係するルールは単純でこれだけ」と言って関係ないものも含めて8個もルールを羅列するやつが丁寧で優しいわけがないよ

**デフォルトの名無しさん** · 2021/10/31(日) 23:04:28.74

>>937
変数名の再利用と状態変更はちがくね？
そもそも変更しないと宣言して変数をシャドーイングして変更可能にするのも疑問だけど、
まあそれは仕様だとして、それが変数名の再利用とは無関係じゃんね　再利用しない前提なんだから

**デフォルトの名無しさん** · 2021/10/31(日) 23:09:50.30

もはや何言ってるかわからないレベル

**デフォルトの名無しさん** · 2021/11/01(月) 00:28:06.90

>>936
状態置き換えてない
新しい方の変数を参照するようにしているだけ

**デフォルトの名無しさん** · 2021/11/01(月) 00:30:02.23

>>932
mut i ってmut必要だっけ

**デフォルトの名無しさん** · 2021/11/01(月) 01:16:30.92

>>932
> for mut i in vec0.iter_mut() {
> for mut i in &mut vec0 {

どちらもiは&mutになるので同じfor文になる
そしてlet mut i = &mut ... と書いている時と同じく左側のmutは不要(warning)

**デフォルトの名無しさん** · 2021/11/01(月) 01:31:09.18

>>925
配列もVecも受け取る関数ならば
as_ref()でスライスに揃える方法だけでなく
配列もVecもそのままの型で使う方法もあり
どちらもa[i]の形はIndexトレイトで使えるので例えば

fn get_second_item<A: std::ops::Index<usize, Output=T>, T: Copy>(a: A) -> T {
　a[1]
}

fn main() {
　let a = [1.1, 2.2, 3.3];
　assert_eq!(2.2, get_second_item(a));

　let a = vec!["a", "b", "c"];
　assert_eq!("b", get_second_item(a));
}

と配列/Vec側も中身のf64/&str側もジェネリックに書ける

**デフォルトの名無しさん** · 2021/11/01(月) 08:15:24.70

背後にある考え方を説明せずにルールだけ教えても理解できないよ。

まあ、ルールに一貫したコンセプトがないんだったら「こういうものだ」と押し付けるしかないけど。

**デフォルトの名無しさん** · 2021/11/01(月) 23:13:41.76

可変の場合は面倒でもmutが必要ってしたほうがわかりやすいような気がするなあ

**デフォルトの名無しさん** · 2021/11/01(月) 23:57:09.03

let mut p = &mut q;　の左辺mutを書くとwarningが出る理由は、pはmutではなく、あくまでも&mutであるためだろう。
つまり、そこに左辺mutを書いてしまう人はきちんと理解していないという意味ではなかろうか。

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

let mut ~~はそこで定義される変数が可変（再代入可能）になるもので、
&mut ~~はそこで作成される参照が可変になる、という理解なんだけど、
どうもしっくり来てない。引数の宣言で&mutとつけるとどうなるの、とかすぐ出てこない。

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

let mutのmutはコード生成には不要だけど&mutのmutは必要だと言う話を聞いた

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

950

**デフォルトの名無しさん** · 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のお陰でハゲが治りました！