Rustアンチスレ

1 ：デフォルトの名無しさん：2017/10/26(木) 23:37:04.08 ID:9syp6YaG.net

Hello World以上の事をやるとコンパイルが通らない()Rustのアンチスレです

2 ：デフォルトの名無しさん：2017/10/26(木) 23:40:36.83 ID:LSWABSRs.net

Getting startedでもHello World以上のことはやってるんだから
あなたの触ってる言語がRustじゃない可能性のが高そうだね

3 ：デフォルトの名無しさん：2017/10/27(金) 00:11:03.46 ID:8v9HsLU9.net

コンパイルさえ通してしまえばエラーが無いことを保証される。
自動的な並列化によりメニーコア時代に対応。
メモ化サポート、動的計画法が自動的に実装できる、AI時代に必須。
Rust使いというだけで尊敬される、自動的に彼女ゲット。
C/C++の20倍高速。

4 ：デフォルトの名無しさん：2017/10/27(金) 01:38:19.39 ID:HS++Psw6.net

ただし扱えるのはモジラに選ばれた人間のみ

5 ：デフォルトの名無しさん：2017/10/27(金) 01:59:27.69 ID:zibA1NJ/.net

コンパイルすら通せない馬鹿が劣等感を爆発させた結果が>>1

6 ：デフォルトの名無しさん：2017/10/27(金) 02:21:16.33 ID:8v9HsLU9.net

Rustによって未来志向の意識世界に目覚めました。
いま核ミサイルの集中制御システムに携わっています。
Rustが世界を変える、Rustで世界を変える。
アッラーアクバール。

7 ：デフォルトの名無しさん：2017/10/27(金) 09:45:57.32 ID:T+eCoUsJ.net

Cは自分の頭や足を撃ち抜く危ない言語ってよく言うが、つまり銃レベルで強力ってことだよな

Rustはなんだ？ぼうっ切れか？たしかに銃と違って暴発したりはしないな

8 ：デフォルトの名無しさん：2017/10/27(金) 18:02:33.63 ID:cUZom3KZ.net

http://ha10.net/talk/1503389313.html

9 ：デフォルトの名無しさん：2017/10/27(金) 18:02:45.00 ID:697iydar.net

>>5
>>1だけどこのスレ建てたのは離隔目的だぞ

10 ：デフォルトの名無しさん：2017/10/27(金) 19:54:56.14 ID:Ql9mpjN/.net

どんな木っ端言語にもアンチがいるもんだなぁ(しみじみ)

11 ：デフォルトの名無しさん：2017/10/29(日) 18:15:04.59 ID:COmwxbJI.net

アンチを隔離するつもりが信者が捕獲されちゃったとかrustyなコードにありがちな本末転倒っぷり

12 ：デフォルトの名無しさん：2017/10/30(月) 15:46:08.82 ID:a0o0t6OO.net

>>10
本当に木っ端だったらなんも言わねえよ
モジラが言語自体をゴミクズのままにしておきながら
ステマに工数と金をぶっこんで自社ブランドの肥やしにして
それに騙されてゴミクズ掴まされる被害者がでてることに文句つけてるんだよ

13 ：デフォルトの名無しさん：2017/10/30(月) 17:28:53.44 ID:ExtYgMew.net

>>12をそっくりそのままGoを作ったGoogleに送りつけたい

14 ：デフォルトの名無しさん：2017/11/05(日) 09:42:11.34 ID:/OpyHVwj.net

>>12
え、go ぐらいシンプルな文法でも満足に使えんの？
馬鹿なんじゃないの？

15 ：デフォルトの名無しさん：2018/02/10(土) 22:35:12.01 ID:gZwa/8Tz.net

>>12をそっくりそのままSwiftを作ったAppleに送りつけたい

16 ：デフォルトの名無しさん：2018/02/11(日) 09:24:51.51 ID:YryqqCkE.net

>>11
Rustに傷つけられたアンチと戯れるスレだからね、仕方ないね

Swiftは騙されるアポー信者が多くてめっちゃウハウハだったな、Swiftやってますだけでクッソ仕事多かったのwww
Rustは、、、上流工程には知名度がなく、下流工程には難易度が高く、どこ行っても誰も騙せNEEEEEEEE
どこの業界(分野)に行けば騙されてくれる被害者がいますか？マジで教えてください

17 ：デフォルトの名無しさん：2018/02/11(日) 20:02:48.65 ID:JG+HYHMD.net

整数型からC-like enumに変換するのにtransmuteとかしないといけないのがクソ
enumをforループするだけのことが面倒なのもクソ
ボローチェッカーとの戦い(笑)以前に生産性低すぎるわこんなもん
C++を置き換えるとか言ってるやつは頭お花畑やろな

18 ：デフォルトの名無しさん：2018/02/11(日) 20:26:21.53 ID:PouFYKRN.net

>整数型からC-like enumに変換するのにtransmuteとかしないといけないのがクソ
だって実現方法はともかく意味的に整数はenumではないもの

>enumをforループするだけのことが面倒なのもクソ
forループしようと思う時点でそれはenumを使うべき場所でないのでは……

19 ：デフォルトの名無しさん：2018/02/11(日) 21:47:14.09 ID:YryqqCkE.net

unsafeなtransmuteなんて使う地雷に自ら突っ込んで行ったら生産性も落ちる罠

何をしようとしてenumメンバをforで回す機会があるのかサッパリ分からんが
生産性悪い書き方して生産性悪いと言ってるのはよく分かった
ちょっとオモロイから、生産性悪いと思った事例をもっと教えてくれよ

20 ：デフォルトの名無しさん：2018/02/11(日) 23:22:44.25 ID:18bG+VQL.net

アンチアンチ

21 ：デフォルトの名無しさん：2018/02/12(月) 11:06:57.76 ID:+5PXSpLD.net

俺は賢いからunsafeだって使いこなせるぜ、transmute使うぜ
結果、メモリ非安全で生産性悪いRustクソ!!!!

俺はアホだから危ないunsafe使うのやめよ、整数型からenumにするのはfn new使おう
結果、メモリ安全で生産性良いなー

Rustはアホ向けの学習難易度の低い言語だった可能性が微レ存？

22 ：デフォルトの名無しさん：2018/02/12(月) 13:03:15.96 ID:JDol8IEk.net

普通の人間はアホか賢人に分類すると、だいたいアホ側がふさわしいからな。
無理する奴がバグを生む。俺はアホで良い。

23 ：デフォルトの名無しさん：2018/02/12(月) 19:04:43.26 ID:1V20MNhs.net

ちょっと検索すればenumのvariantsをループで回す方法でてくる
enumの定義時にマクロを使って全メンバーを含む配列も同時に定義するなどがある
これだけをやってくれるcrateも作れそうだ

24 ：デフォルトの名無しさん：2018/02/14(水) 22:58:26.65 ID:0r3oW/nt.net

C++が車だとしたらRustはせいぜいゴーカートだなぁ

25 ：デフォルトの名無しさん：2018/02/16(金) 06:49:37.38 ID:W1XJdyx1.net

☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

26 ：デフォルトの名無しさん：2018/02/22(木) 15:21:57.27 ID:H839Tp+8.net

C++がカーチスだとしたらRustはフォルゴーレな印象

27 ：デフォルトの名無しさん：2018/02/23(金) 17:07:47.78 ID:ZuaVfjvd.net

つまり、どっかの豚しか乗りこなせないのか…

28 ：デフォルトの名無しさん：2018/05/23(水) 20:21:30.55 ID:Au5e7VGg.net

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

P5EA8

29 ：デフォルトの名無しさん：2018/07/05(木) 01:24:10.02 ID:RfoszcD2.net

6YB

30 ：デフォルトの名無しさん：2018/07/16(月) 21:36:50.20 ID:LulkQD8r.net

なんで所有権の移動という一度しか起こらない元値を破壊するものが印なしで
参照の借用渡しが＆にしたんだろう

ねえ

31 ：デフォルトの名無しさん：2018/07/18(水) 21:34:09.40 ID:uzHZzsnA.net

moveは安全なのに何が問題だと感じるの？

32 ：デフォルトの名無しさん：2018/07/19(木) 20:56:32.22 ID:zpCf8yuT.net

次世代言語スレのつづきか
安全なだけでめっちゃわかりづらいだろ
ふつうの=でコピーと動きが違いすぎる

33 ：デフォルトの名無しさん：2018/07/21(土) 00:47:19.79 ID:mSZJjtkc.net

コピーはコストかかるから暗黙的なコピーは意図せぬ性能劣化を引き起こす可能性がある

34 ：デフォルトの名無しさん：2018/07/21(土) 04:00:07.64 ID:PpAF+dgy.net

暗黙のコピーと暗黙の参照渡しが区別つかないJavaで困らないんだから困らないのかもしれない

35 ：デフォルトの名無しさん：2018/07/21(土) 23:33:24.37 ID:SCDZUWz8.net

javaで暗黙にコピーされるのは基本データ型だけでは

36 ：デフォルトの名無しさん：2018/07/23(月) 21:30:42.22 ID:2ez6F7EW.net

C#でも困んないし

37 ：デフォルトの名無しさん：2019/07/28(日) 18:59:39.61 ID:5UHV96py.net

JavaとC#にはGCがあるからな

38 ：デフォルトの名無しさん：2019/07/28(日) 19:00:55.44 ID:5UHV96py.net

ていうかJavaやC#は暗黙のdeep copyをしない件について：

39 ：デフォルトの名無しさん：2019/07/29(月) 21:44:34.57 ID:CSar0obt.net

https://i.imgur.com/QvQTuqJ.jpg

40 ：デフォルトの名無しさん：2019/07/30(火) 00:56:59.74 ID:ZDjzCSg/.net

>>39
グロ

41 ：デフォルトの名無しさん：2019/10/30(水) 14:37:39.93 ID:4EQH++wv.net

クソの中のクソ
キング・オブ・クソ
作ったゴミも使うカスも肥溜めで溺死すればいい

42 ：デフォルトの名無しさん：2020/03/21(土) 17:46:30.14 ID:vJ0Lurek.net

無能がほざいてて気分いいわ

43 ：デフォルトの名無しさん：2020/03/21(土) 17:51:42.22 ID:20ZHUxLS.net

haskellと同じ道をたどるだけだな。
馬鹿がなぜか選民思想やり出して終了。

44 ：デフォルトの名無しさん：2020/03/21(土) 18:38:21.24 ID:txJMIm7g.net

>>3
>コンパイルさえ通してしまえばエラーが無いことを保証される。
そんなわけない。

45 ：デフォルトの名無しさん：2020/03/25(水) 01:29:02 ID:COJzGufp.net

Rustは、コンパイラ時エラーに悩まされる反面、実行時エラーに悩まされるのを減らす
などと言われる。
しかし、コンパイル時エラーが出ると言うことは、裏を返せば、書けないアルゴリズムが存在するということだ。
直感的ではない回りくどい書き方が必要となり記述量が多くなる。
他の言語では好きな書き方が出来て、それはどれも正解だが、Rustでは正解が非常に狭くなる。
正解が狭いことがエラーを減らすなどという人がいるが、実際には、Rustは
書けるアルゴリズムが狭い、と言うことなのである。
これは言語設計の問題である。

なお、ここで言っているアルゴリズムは、全体的なものではなく、細かいミクロ的なものである。
通常の言語では、1つの仕事を細かい変数の使い方まで含めれば数万通り以上に書けるだろう。
そして、そのどれもが正解であり、結果が正しくバグも無いのだから、内のどれかが悪い書き方という
ことは特にない。
ところが、Rustでは、その大部分の書き方が出来ないのである。
駄目だから敢えてできなくしているのではなく、Rustが設計上、書けないアルゴリズムがあるということに他ならない。
つまり、Rustは書けるアルゴリズムが、本来コンピュータが書けるアルゴリズムの内の、非常に狭いサブセットに限られてしまうということである。
これは、Rustの大きな欠陥である。

46 ：デフォルトの名無しさん：2020/03/25(水) 01:29:24 ID:COJzGufp.net

>>45
「駄目な書き方だからエラーにしている」
と言うのは間違いで、正しくは、
「Rustコンパイラの静的解析能力では、書き方を非常に限定しないと
　正しいことを保障できなかったり、自動化できなかったりするため、
　しょうがなく狭い書き方しか出来なくしている」
と言うことに他ならない。
人間には脳内の静的解析で明らかに正しいことが分かる書き方でも、
Rustコンパイラではでは同じことができないため、敢えて
変数束縛、借用、単一参照など、コンパイラでも解析できる程度の
範囲に書き方を限定して無理やり人間のプログラミングの可能性を
狭めているに過ぎない。

47 ：デフォルトの名無しさん：2020/03/25(水) 01:31:01 ID:COJzGufp.net

>>43
Rustは、Haskellから多くを借りてきているらしいから、Haskellと同じ
道をたどると言う予想はあながち間違ってない。

48 ：デフォルトの名無しさん：2020/03/25(水) 01:41:15 ID:COJzGufp.net

Rustは表面的に使うだけなら、まあ、C++が使えるプログラマなら、大体使えなくは無いだろう。

しかし、自分で独自にリンクリストを作ろうと思うと事態は一変する。

そこまで深く入った人ほど、Rustは難しい言語だと感じるはずで、
RustがC++程度で理解できると思ってる人は、99%、浅い所までしか使ってない
と言えよう。

49 ：デフォルトの名無しさん：2020/03/25(水) 08:33:39.98 ID:atIoOIeM.net

道具として正しい在り方だな

50 ：デフォルトの名無しさん：2020/03/25(水) 12:40:37 ID:COJzGufp.net

>>49
RAD言語ならそれで良いが、システム言語では駄目。

51 ：デフォルトの名無しさん：2020/08/09(日) 13:48:40.83 ID:cPfQFxYQ8

>>48
愚直に実装すると複数ヶ所で同一のミュータブルな参照を保持する必要に迫られるけど，
それはRustではコンパイルエラー
じゃあどうするか？ → 内部でUnsafeな生ポインタを使う
みたいな話か

52 ：デフォルトの名無しさん：2020/08/28(金) 02:41:24.81 ID:BFWbiW8H.net

Rustは、コンテナは、配列(長さがコンパイル段階で静的に決まる固定長)、
ベクター(動的配列)が主で、LinkedList<T>は、せっかくのリンクトリストの
特徴である末尾以外の「途中」への追加は出来ない。
これではリンクリストの意味が無い。
また、公式ドキュメントに
「ベクターの方がLinkedList<T>より速い」
などと書いてあるが、それはとんでもない間違い。

53 ：デフォルトの名無しさん：2020/08/28(金) 17:13:22 ID:BFWbiW8H.net

リンクリストを実装するのはこんなに難しく、
nextメンバの型は、Option<Rc<RefCell<Node<T>>>>
となる :
type Link<T> = Rc<RefCell<Node<T>>>;
#[derive(Debug)]
struct Node<T> {
　　value: T,
　　prev: Option<Link<T>>,
　　next: Option<Link<T>>,
}
impl<T> LinkedList<T> {
　　pub fn append(&mut self, v: T) {
　　　　let node = Node::new(v);
　　　　match self.tail.take() {
　　　　　　Some(old_tail) => {
　　　　　　　　old_tail.borrow_mut().next = Some(Rc::clone(&node));
　　　　　　　　node.borrow_mut().prev = Some(old_tail);
　　　　　　}
　　　　　　None => {
　　　　　　　　// first element
　　　　　　　　debug_assert_eq!(self.len(), 0);
　　　　　　　　self.head = Some(Rc::clone(&node));
　　　　　　}
　　　　}

　　　　self.tail = Some(node);
　　　　self.length += 1;
　　}
}

54 ：デフォルトの名無しさん：2021/01/08(金) 10:57:50.09 ID:4h6DBvmg.net

00年代半ばごろのゴミサイトがアクセス数を稼ぐのを思い出した


ゴミ

55 ：デフォルトの名無しさん：2021/05/05(水) 10:12:10.05 ID:Icux/Qfe.net

可読性低いな

56 ：デフォルトの名無しさん：2021/06/18(金) 18:36:38.41 ID:GgPo8kME.net

Ｒｕｓｔを含めた新手の言語の仕様が固まるまで、２０年ぐらい掛かるからなぁ

今２０代の連中がＲｕｓｔを使いこなせる様になっても、

システム開発に使える頃には、４０過ぎの中年だけど、まだプログラマー続けてるの？

57 ：デフォルトの名無しさん：2021/06/30(水) 12:11:47.40 ID:TGFkopCB.net

レッツ！ｍｕｔ　＆ｍｕｔ　もっと　＝　したい：ダメな日本語；

58 ：デフォルトの名無しさん：2021/07/07(水) 23:28:03.78 ID:3EDdhBYW.net

error[E0382]: use of moved value: `vector`

59 ：デフォルトの名無しさん：2021/07/16(金) 02:31:03.20 ID:UUn46lBk.net

もうお前のRustコード直すの嫌だわ

60 ：デフォルトの名無しさん：2021/07/21(水) 02:06:52.85 ID:DO3wSfvm.net

意識高い系が自己満足でめちゃくちゃなコードを他人に押し付ける言語

61 ：デフォルトの名無しさん：2021/08/10(火) 09:03:54.83 ID:fPg8NGNP.net

>>45
何かいいやり方があるはずだ。誰が見ても明らかな、たったひとつのやり方が。
そのやり方は一目見ただけではわかりにくいかもしれない。オランダ人にだけわかりやすいなんてこともあるかもしれない。

The Zen of Pythonの一節だけどRustの設計思想もこういうことなんじゃないか？
何通りもある書き方を統一することによってコードを読む人にも分かりやすくするってことだと思う。
もうそこは好みの問題だから気に入らなければやらないでいいんじゃないか？

62 ：デフォルトの名無しさん：2021/08/10(火) 09:10:56.61 ID:UUhRSoFC.net

Rustは組み込みシステムでも非常に多く使われているように何でも書ける
Cと同様に低レベルな部分でも記述可能でさらにインラインアセンブリも可

63 ：デフォルトの名無しさん：2021/08/10(火) 14:11:34.30 ID:mSeKT5En.net

raw pointer 使えるし C でできることはだいたい出来るのでは
できないのは variable length argument/array くらい？

64 ：デフォルトの名無しさん：2021/08/11(水) 07:11:51.41 ID:KlEtC9pi.net

そりゃunsafeすればなんでもかけるわ

65 ：デフォルトの名無しさん：2021/08/11(水) 07:16:15.10 ID:N49Uco17.net

>>64
C/C++/Rust以外の言語ではどうやっても無理

66 ：デフォルトの名無しさん：2021/08/12(木) 10:28:40.81 ID:whMOJJYX.net

なんかRustアンチは必要以上にunsafeを忌避してる気がする

unsafeは注意が必要な部分を限定するために用意された言語機能なのに
「unsafe使うならC/C++でいいじゃん」
とか考えてそうな雰囲気

67 ：デフォルトの名無しさん：2021/08/12(木) 10:57:49.37 ID:tXISMw6z.net

unsafeブロック内でもボローチェッカは仕事するって知らん人多そう

68 ：デフォルトの名無しさん：2021/09/04(土) 03:57:00.95 ID:kn1l/Q+t.net

>>24
いや、自走車椅子だろ

69 ：デフォルトの名無しさん：2021/09/04(土) 04:05:22.28 ID:iqtSb51S.net

>>24
C++より便利で安全だから
例えると醤油とソースかな

70 ：デフォルトの名無しさん：2021/09/06(月) 13:53:51.27 ID:kq9rR1L5.net

Rustスレでは場違いなので、イテレータというか高階関数の話にもう一度食いつくとする。

Juliaなんかだと並列・分散処理するために@distributed forなんて書くが、Erlangだとループ中に
spawnをして、Goもgoroutineを起動する。map/reduceなんかだと明らかにメニ―コアを使った方が
速いが、標準ではそうなっていなくて、外部ライブラリのrayonなどを使用する。
GoでもRustでもこれをさらに分散処理させるにはgRPCなど規格化されたインターフェースを通すが
やりたい事はJuliaの@distributed forなのに手間を感じさせる。
Rustにライトウェイトスレッドが言語仕様として入るとは思えないが、やはり言語には向き不向きが
存在する。近年のjavascriptを発端とするasync/awaitにも疑問が生じる。あまりにも多くの言語が
同期実行のライブラリと整合性が無さすぎる

71 ：デフォルトの名無しさん：2021/09/06(月) 14:51:17.48 ID:6RpN+EMp.net

DSLと同等の使い勝手を汎用的な言語に求めるのはつらいのでは

72 ：デフォルトの名無しさん：2021/09/06(月) 16:49:04.49 ID:7r7RF488.net

>>70
たしかにJavaScriptのasync/awaitとRustのは最も対照的ですがどちらも良い特徴があると思います
JavaScriptはブラウザも外部のNode.jsもその言語実行環境として非同期ランタイムが組み込まれasync/await導入以前から非同期関数が標準として装備
そのため非同期関数が呼ばれたら次のスケジュールで即座に実行が始まりますね

一方でRustは標準の非同期ランタイムがなく用途に合わせて自由に非同期ランタイムを用意することが出来ます
さらにRustのasync/await自体はゼロコストで設計されており非同期関数が呼ばれても自動的にスケジューリングされない特徴があります

Rustはこれらに関して「何ができない」のではなく「何でもできる」わけなので
あとは記法の簡易性を求めるのならばその呼び出し関数等の設計とマクロでお好みの方面へ寄せることも可能です

73 ：デフォルトの名無しさん：2021/09/11(土) 00:36:45.81 ID:YO3o85Uj.net

>>72
これは良い書き方をしているが非同期ランタイムを自由に選べるのではなく、適切に選ばないと
インターフェースをサポートしない場合があるため、互換性が保てないでしょう。Rusterは
ゼロコストという話を良くしますが、Rustの非同期はタスクごとにステートマシンを作るために
確かにNode.jsなどと比べるjavascriptと比べれば、全体で非同期をスケジューリング管理する
ものと比べアロケーションや実行コストなどは小さいですが、それほど喧伝すべきことでもありません。
いずれにせよ多くの非同期はI/Oバウンドでありepollベースなどで管理されます。当然ながら
(Cに代わるようなハードウエア近い）システム言語なので出来ない事があってはイケていません。
私が言っているのは、Rustに限りませんがasync/awaitの記述が普通に考慮されてない設計の悪い
ライブラリが沢山あるという事です。Rustのマクロは最低だと思います、なぜわざわざ学習コストを
引き上げるのか理解できません

74 ：デフォルトの名無しさん：2021/09/11(土) 01:17:56.12 ID:PRM8i6LA.net

>>73
あなたの主張は意味がわからない
まず「互換性が保てないでしょう」は何との何の互換性が保てないのか？意味不明
次に「それほど喧伝すべきことでもありません。」は結局のところあなたは反論すら出来ずに同意してしまっている
さらに「Rustに限りませんが(略)設計の悪いライブラリが沢山あるという事です。」はRust言語に対する批判にすらなっていない
それぞれ具体的に問題点を述べましょう

75 ：デフォルトの名無しさん：2021/09/11(土) 01:24:36.44 ID:Q/hQI3Xf.net

唐突にマクロが登場するのも分かりませんね
async-awaitがマクロだった頃の話をしているのですか？

76 ：デフォルトの名無しさん：2021/09/11(土) 01:41:58.05 ID:YO3o85Uj.net

あんたの方が意味不明だけど（笑）
まず文書の書き方にケチを付けてロンパーする癖を直しましょう。

最初から非同期ランタイムの互換性と書いているでしょう。例えばasync-stdと
tokioは互換性がありません。今は互換性がほぼあるようになってきていますが
それでも完全ではありません。

ゼロコストFeatureという話は、VS Javascriptという言語のランタイムではその
通り認めていますが、コンパイル型の言語でコストが高い非同期は稀です。

Rust言語に対する批判しか書かないわけではありません。あなたは攻撃されたと
思い込む癖が強すぎる。「近年のjavascriptを発端とするasync/awaitにも疑問が
生じる。あまりにも多くの言語が同期実行のライブラリと整合性が無さすぎる」
という大本も読めない。まあそういう人間が増えすぎて居る訳で、こんな雑談で
怒り心頭になり、それぞれの具体的な問題点はあなたの性格でしょう。
言語的な反論をせずに文書の読解も出来ず、条件反射で相手を貶す。とてもでは
ないですが近寄りがたいですね

またマクロについても「マクロでお好みの方面へ寄せることも可能です」という
返答に関して感想を述べてるのに過ぎないのに、全く話を辿れていません。

77 ：デフォルトの名無しさん：2021/09/11(土) 02:11:46.06 ID:w5S7rLqj.net

>>76
具体的な問題点を述べましょう
例えばtokioの上に構築されたhttpモジュールであるhyperも互換レイヤーによりasync-std 上でも動作します

RustアンチスレでなぜJavaScriptを問題にしているのかも謎ですが
JavaScriptのasync/await/Promiseもあの環境で非常に優れて設計されています
この件についても具体的な問題点を述べておられないですね

78 ：デフォルトの名無しさん：2021/09/11(土) 11:03:00.32 ID:LLoV+Okg.net

>>76の勝ち
以上

79 ：デフォルトの名無しさん：2021/09/11(土) 13:53:10.45 ID:zUj2TAiQ.net

>>76
＞「近年のjavascriptを発端とするasync/awaitにも疑問が生じる。
＞あまりにも多くの言語が同期実行のライブラリと整合性が無さすぎる」

意味がちょっと不明です。
JavaScriptでそれらが用いられうる通信分野では、基本的に同期実行のライブラリは存在しません。
例えばhttpなどで取得してくるfetch()も非同期ですし、もっと低水準のモジュールも非同期です。
同期実行のライブラリと整合性が無さすぎるとは、何を意味しているのでしょうか？

80 ：デフォルトの名無しさん：2021/09/11(土) 13:59:42.94 ID:QGVH5OH8.net

発端と言ったらC#の方が古くね

81 ：デフォルトの名無しさん：2021/09/12(日) 14:45:35.48 ID:dsndgRWH.net

Rustって組み込み開発向いて無くね？
どう考えてもLinuxなりBSDなりある程度高度なOSがある事前提だ、OSのメモリーコンパクションが
無いとGCが無い故にメモリーの断片化が起こり、長時間稼働するタイプの小さな組み込みには向かない。
マイクロコントローラのメモリー付きSoCでブーストラップローダーがあるだけの組み込みには使えない
ま、サポートプラットフォームにTier1/Tier2でも、そういうのに使えるとは書いてないけど

82 ：デフォルトの名無しさん：2021/09/12(日) 15:02:08.52 ID:raaoGYn7.net

>>81
その文章だけならCにいれかえてもあってそうなんだが？

83 ：デフォルトの名無しさん：2021/09/12(日) 15:22:52.56 ID:lBuMyCBZ.net

>>81
つまりC/C++/Rustは組み込みやOSに向いていないとｗ

84 ：デフォルトの名無しさん：2021/09/12(日) 15:26:04.82 ID:Cf6Jz1Ay.net

そこで組み込みのために開発されたJavaですよｗ

85 ：デフォルトの名無しさん：2021/09/12(日) 21:57:41.77 ID:UrK9UNLE.net

それはリソースがたっぷりある組み込みのケースで感覚としてはアプリ開発に近い
組み込みはピンキリだからスクリプト言語が動く環境まである
一方でC/C++/Rustじゃないと厳しい環境もある

86 ：デフォルトの名無しさん：2021/09/12(日) 22:17:14.89 ID:Zjk1d74X.net

>>76
同期実行ライブラリと整合性が無いというのはウソです
Rustでstd利用の同期とasync-std利用の非同期のプログラムはほとんど同じように書けます

例えば複数のファイルのチェックサム計算を同期と非同期の2通りに書いた以下の記事を参考にすると
https://qiita.com/osanshouo/items/671c45072a79c7b27aba
メイン部分の両者のdiffを取ると以下のような感じです

　 for entry in entries {
　 　let entry = entry.unwrap();
　 　if entry.file_type().unwrap().is_file() {
　+　　let handle = async_std::task::spawn(async move {
　 　　 　let filepath = entry.path();
　-　　 　let mut file = fs::File::open(&filepath).unwrap();
　+　　 　let mut file = fs::File::open(&filepath).await.unwrap();
　 　　 　let bytes = {
　 　　 　　let mut bytes = Vec::new();
　-　　 　　file.read_to_end(&mut bytes).unwrap();
　+　　 　　file.read_to_end(&mut bytes).await.unwrap();
　 　　 　　bytes
　 　　 　};
　 　　 　let checksum = bytes.iter().fold(0u8, |acc, b| acc.wrapping_add(*b));
　 　　 　println!("{:?}: {}", filepath.file_name().unwrap(), checksum);
　+　　});
　+　　handles.push(handle);
　 　}
　 }

つまり差は2点のみ
非同期実行では不可欠なspawnがが入ることと
非同期を同期風に書けるようにするためのawaitが入ることだけです
おっしゃる『同期実行のライブラリと整合性が無さすぎる』との主張は間違っています

87 ：デフォルトの名無しさん：2021/09/12(日) 22:19:55.41 ID:s09Gb+ph.net

設計にバカが関わってなければC++で十分

88 ：デフォルトの名無しさん：2021/09/12(日) 22:44:56.06 ID:Q5FBinyU.net

コードの規模が大きくなると複雑さが増して相対的に知性下がるからバカが開発することを前提にした方が良い

89 ：デフォルトの名無しさん：2021/09/13(月) 20:47:01.12 ID:dBMpD8or.net

>>88
それは自覚症状が無いだけで自分が馬鹿なだけかも知れんが。

90 ：デフォルトの名無しさん：2021/09/13(月) 20:51:25.89 ID:9PNw/wOW.net

>>89
自分は馬鹿と思ってコード書いた方が良いよ本当に
これはバカにしてるとかじゃなくて心構えとして

91 ：デフォルトの名無しさん：2021/09/14(火) 19:27:55.83 ID:kyozNdb6.net

>>90は賢いお人

本来馬鹿は馬鹿を自覚できないから
平気でウンコを顔面につけたまま歩き回り
いろんなものを糞まみれにしてケロっとしてる

92 ：デフォルトの名無しさん：2021/09/14(火) 20:13:08.96 ID:Wng5bteL.net

>>90
お前と俺を一緒にスンナよ。
人間の頭脳は画一敵意ではなく差が大きい。

93 ：デフォルトの名無しさん：2021/09/14(火) 23:33:28.66 ID:9cp1Eg6y.net

微笑ましい

94 ：デフォルトの名無しさん：2021/09/14(火) 23:52:38.24 ID:BSh8VTqx.net

少なくともある程度以上の大きさの開発したことある人や
複数案件を同時進行した人なら
いくら完璧にしていても確率的にミスが入り込むとわかるはず
そしてC++とRustとの比較ならどちらが良いかも冷静に判断できる

95 ：デフォルトの名無しさん：2021/09/15(水) 02:02:19.36 ID:x4RgVtnC.net

>>86
そんな事を言ってるんじゃないと思いますよ、「複数のファイルのチェックサム計算」なんて単純な事なら
当然ながら同期と非同期でそれほど違いは出ないでしょうし互換性があるように見えるでしょう。なぜなら
チェックサム計算は一瞬で終わり非同期はファイル毎に区切っているから。チェックサム計算は同期コードで
いずれも書かれていて１つも違いがありません。
これをいくつかのファイルは巨大でファイル長が不明（無限では無い）が大きいファイルのチェックサム計算や
より複雑で時間のかかる計算を非同期で行いたいとすればどうしますか？チェックサム計算で、read_to_endは
使えずストリームを非同期に読み続けて計算することになるでしょう。という事はbytes.iter().foldも使えません

「同期実行ライブラリと整合性が無いというのはウソです」このように言い切ること自体に"気持ち悪い信仰"を
持っているのは良く分かりますが、元が「整合性が無さすぎる」と言っているのは、整合性がある１パターンを
示しても意味が全く無いという事です。多くの問題は「ウソです」と言い切れる浅はかさが問題です
http://qiita.comの記事なんて初心者のサンプルに過ぎません

96 ：デフォルトの名無しさん：2021/09/15(水) 11:47:44.97 ID:PYzW5a+n.net

>>94
確率的な話をするならコンパイラの塾制度考えた場合の確率を下回るくらいのメリットしかrustにはないよ。

97 ：デフォルトの名無しさん：2021/09/15(水) 20:26:11.48 ID:77IP/X5S.net

>>96
rustcで検出できるバグを仕込む確率よりもrustcのバグを踏む確率の方が高いということ？

98 ：デフォルトの名無しさん：2021/09/15(水) 21:21:02.30 ID:PYzW5a+n.net

rustcで検出できるバグよりcとのバインディングでの勘違いで生じるバグのが多いわな

99 ：デフォルトの名無しさん：2021/09/16(木) 00:37:37.41 ID:Efcezeu+.net

まあ静的チェックに過剰な期待してる奴は大抵クソだよ

100 ：デフォルトの名無しさん：2021/09/18(土) 06:51:34.59 ID:pceSJQ2d.net

>>94
そのうち上位層はビジュアルプログラミングに取って代わられて行ったりしてね