C++ vs Rust

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

競え

**デフォルトの名無しさん** · 2021/12/08(水) 01:40:32.51

1次関数の試験で100点取れそうな説明

**デフォルトの名無しさん** · 2021/12/08(水) 01:51:55.62

数学100点君は数学用語の定義を誤解釈しまくって理解してしまっている感じ
説明の内容からしても多分中高生か啓蒙書を読みかじったおじさんなんだろ

**デフォルトの名無しさん** · 2021/12/08(水) 03:16:15.50

なんでここは、数学が理解できない人ばっかりなんだ。
だから、プログラマが馬鹿にされる。

**デフォルトの名無しさん** · 2021/12/08(水) 03:18:58.91

C++ vs Rust を語る前に、せめて、数学的に明らかに正しいことを理解できるから
でないとどうにもならん。
それ以前の問題。

**デフォルトの名無しさん** · 2021/12/08(水) 03:20:41.94

それと、科学者にとって最も大事なことは、頭の良さでも知識でもなく、
正直さだ。
自説を主張するために正しい主張を否定してはいけない。

**デフォルトの名無しさん** · 2021/12/08(水) 03:21:17.48

「ランダムアクセス」って任意の要素にアクセスすることを指すんだけど、乱択的に与えられた要素にアクセスすることをそう呼ぶんだと思い込んでる奴が複数いてクソワロ

**デフォルトの名無しさん** · 2021/12/08(水) 03:25:58.49

>>894
結果は一時式でも、それを求めるには確率論以前に、イマジネーションが必要。
どこかに書いてある知識の組み合わせでは導出できない。
確率論は、自分の想像力が重要に成るので、計算力だけでは無理な分野。
書いてある定理を組合すだけでも導けない。
数学は、基礎の部分はイマジネーションで作られているから、頭の良い
人以外には作れない。
いくら勉強しても無駄。

**デフォルトの名無しさん** · 2021/12/08(水) 04:31:15.37

ハッシュに格納するまでの過程は確率論でも格納された後はただのリニア検索だけの話にすり替わってないか？

**デフォルトの名無しさん** · 2021/12/08(水) 08:47:15.25

>>900
誰でも後から客観的に検証できる性質が数学含む科学の特徴ですよ
イマジネーションって言い換えればあなたの妄想ってことですよね

**デフォルトの名無しさん** · 2021/12/08(水) 12:57:52.28

データ追加の話をするのであれば、どのようなアルゴリズムでも無限個数を追加するなら無限時間かかるわw

**デフォルトの名無しさん** · 2021/12/08(水) 13:53:27.51

chaining使ってる場合でスロット数(M)が固定値かつ要素数(N)に対して小さければO(n)になるのは当然だよね

それで100点君は何を主張したいんだっけ？

**デフォルトの名無しさん** · 2021/12/08(水) 14:37:30.67

これか >>813

>また、N個のデータを持っているハッシュ構造は、1回の検索は、数学的に厳密にはO(N)
>だが、実験的(実際的)にはO(1)のように振舞うと言われており、厳密に扱うには、
>オーダーの記号だけでは表現しきれない。

「1回の検索は、数学的に厳密にはO(N)」になるのは
一般的なハッシュテーブルの実装とは関係ない架空の条件下の話だね

つかBig O記法が何の目的で使われるのか把握してなかったのか・・・
長々とお疲れさんでした

**デフォルトの名無しさん** · 2021/12/08(水) 17:48:45.17

何の目的で使われるの？せっかくだから聞いておきたい

**デフォルトの名無しさん** · 2021/12/08(水) 18:48:01.53

なにを言いたいのかさっぱりわからないんだが、さかのぼって読んでみると

>>861
> 最大M個の振り分け能力があるハッシュ構造にN個の(key, value)ペアを
> 書き込んでいる場合を考える。
> ただし、Mは定数とし、N が大きくなっても拡張していかないものとする。
> このとき、一回の検索に掛かる平均時間をg(N,M)とすると、
> ほぼ、
> g(N,M)=b・(ceil(N/(2M))

いや、全然違うし
一体何をあらわしてる式なんだ？

**デフォルトの名無しさん** · 2021/12/08(水) 18:55:15.30

c++: cほど性能はいらないけど、コーティングでcより楽したい
Rust: c++くらいの性能はほしいけど、間抜けがメモリリークをエンバグするのを防ぎたい

Rustの狙いはc++＆コーティング規約＆lintでけっこうカバーできるけど、Rustは言語仕様としてコーダー全員に規約遵守を強制しているのが強み。
Rustが本当に普及してきたら、Rust対抗としてC++と連携できるSmartC++が出てくるんじゃないのかね。

**デフォルトの名無しさん** · 2021/12/08(水) 19:27:33.65

>>908
＞Rust: c++くらいの性能はほしいけど、間抜けがメモリリークをエンバグするのを防ぎたい

これが重要だな。

**デフォルトの名無しさん** · 2021/12/08(水) 20:11:11.64

C++はCと同じ性能が出る
楽をしなければ

**デフォルトの名無しさん** · 2021/12/08(水) 21:56:00.76

間抜けがミスをするというと十分に訓練を受けたパログラマーならミスをしないと読めるが
実際にはコードベースが大きくなると間抜けなミスをする確率が高まるので
自分はミスをしないと思い込むのではなくミスした場合も検出できるようにすべき
静的解析やrustの真価はそういうところにあると思う

**デフォルトの名無しさん** · 2021/12/08(水) 22:28:44.41

>>902
ここの人には理解できないようだがな。

**デフォルトの名無しさん** · 2021/12/08(水) 23:45:42.27

>>911
そのためのコーディング規約＆lintだろ。
極端な話、Rustみたいに
基本unique_ptrにして共有する部分だけshared_ptrを使用＆生ポインタ禁止、
3rdパーティライブラリはunsafeなラッパークラスで閉じ込めた使用のみ可、
といったコーディング規約にして設計すりゃポカミスぐらいは防げる。

**デフォルトの名無しさん** · 2021/12/09(木) 01:07:49.62

>>913
何もrustに限った話ではないというのはその通りで
静的解析やrustと書いたのはそういう規約やlintで補うことも可能という意図

ただrustのshared mutabilityを原則禁じるルールなど、lintで同等のチェックするのは難しい気がする

**デフォルトの名無しさん** · 2021/12/09(木) 08:41:44.98

>>913
その規約を遵守させる工数がバカにならないんだよなぁ
人数が増えるとさらに倍になるし

**デフォルトの名無しさん** · 2021/12/09(木) 08:48:29.40

ポカミスってのは規約守り忘れとかも含むんだよな
lintやコンパイラみたいな機械的なチェック以外は基本信用できない

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

lint、コンパイラを無駄に信用しすぎだな。

**デフォルトの名無しさん** · 2021/12/09(木) 12:41:39.28

コンパイラに強制させたいのならnext c++待ちかね。

Rustの問題点が顕在化してきたくらいのタイミングで、RustアンチテーゼとしてSmartC++とか出てくるんじゃない？

c++のバットノウハウを禁止できればRust使う必要性はずいぶん薄れるな。
「SmartC++のスコープ内では生ポインタ変数禁止」「nullのスマートポインタの生成禁止」くらいでも十分な気がしてきた。

**デフォルトの名無しさん** · 2021/12/09(木) 14:23:33.22

Lifetime ProfilerでRustのborrow checkerに近いものを実装しようとしてるけど
機能的にも未熟だし標準的に使われるレベルになるかどうかも現段階では怪しい

そんな夢見てるくらいならRust使ったほうが堅いし現実的

**デフォルトの名無しさん** · 2021/12/09(木) 14:58:02.48

>>918
Rustの問題点てなんですか？
揶揄してるわけじゃなくてまだ入門の勉強中なのでいろいろ興味あります

**デフォルトの名無しさん** · 2021/12/09(木) 17:02:43.74

>>920
よく言われるのが学習コストの高さ。
c++もいいかげん複雑すぎる言語と言われているけど、Rustはそれに輪をかけて難しい。
特に他の言語を勉強した初級・中級者は変数の挙動から何から違う(＆他の言語のようにやるときのためのガイドラインも無い)ので地獄を見るかと。

**デフォルトの名無しさん** · 2021/12/09(木) 18:08:02.53

んなアホな

**デフォルトの名無しさん** · 2021/12/09(木) 18:22:55.56

>>921
そんなことはないと思う
Rustはわかりやすかったぜ
しかも他より書きやすく便利になった

**デフォルトの名無しさん** · 2021/12/09(木) 18:25:55.97

さすがのとほほさんも、Rust入門は書けてもC++入門は言語使用がでかすぎて書けなかった模様w
https://www.tohoho-web.com/www.htm

**デフォルトの名無しさん** · 2021/12/09(木) 18:47:57.46

>>923
ちょっとは「何がわかりやすかったか」ぐらいは書こうぜ。

**デフォルトの名無しさん** · 2021/12/09(木) 18:52:37.90

素直に公式のチュートリアルを流す分にはそんなに詰まるところはないと思うけどな
変に他言語の流儀を持ち込もうとするとハマりやすいというのはありそう
あといきなりWebアプリ作りたいとか思うとasyncで死ぬってのは多分ある

**デフォルトの名無しさん** · 2021/12/09(木) 19:14:20.34

>>29
https://lkml.org/lkml/2021/12/6/461
ついに正式に第二言語としてとりこまれましたとさ
完璧にお前の負けやな
いいか？自分の間違えを完璧に認めて
土下座するんだぞ？
写真上げろよガイジ

**デフォルトの名無しさん** · 2021/12/09(木) 20:04:08.95

Mac　　 Objective-C
Windows C++
Linux　 Rust

**デフォルトの名無しさん** · 2021/12/09(木) 20:26:40.72

MacはSwiftじゃないの？

**デフォルトの名無しさん** · 2021/12/09(木) 20:57:13.15

>>925
structとenumだけでナンでもできてわかりやすかったです
クラスや継承ピラミッドがないのも嬉しかったです
あと&selfやらderefやらその他のimpl&のおかげらしくポインタか否かを気にせず使えるのも便利ですね

**デフォルトの名無しさん** · 2021/12/09(木) 21:00:28.65

>>927
ArmとGoogleとMicrosoftとRed Hatの後押しのおかげで
RustがLinuxの第二言語の地位を確立したのね

**デフォルトの名無しさん** · 2021/12/09(木) 21:02:44.54

自動参照外しって絶対ただの馬鹿やろ

**デフォルトの名無しさん** · 2021/12/09(木) 21:27:55.05

auto derefが害になるRc::cloneしか思いつかなかった
他にどういう問題があるの？

**デフォルトの名無しさん** · 2021/12/09(木) 21:30:18.05

循環参照

**デフォルトの名無しさん** · 2021/12/09(木) 21:31:04.21

>>931
少し前進したな。このまま着実に進めて行って欲しい。

**デフォルトの名無しさん** · 2021/12/10(金) 00:10:47.49

個人開発の範囲内だとC++では困るかつRustなら上手くやれるっていうことがないから勉強する意欲があまりなかったんだが、ここまで来ると覚えとかなきゃ損なのかもな

**デフォルトの名無しさん** · 2021/12/10(金) 00:43:14.95

損かどうかはともかく一度触ってみるのはいいんじゃないかな
C++書いてる時点でライフタイム周りは分かってるわけだし、結構複雑な言語機能もバリバリ使いこなせるタイプなんだからRustが合う可能性は比較的高いと思う

**デフォルトの名無しさん** · 2021/12/10(金) 00:48:18.17

そうか…

**デフォルトの名無しさん** · 2021/12/10(金) 00:50:08.61

>>934
derefじゃ循環参照作れないと思うが

**デフォルトの名無しさん** · 2021/12/10(金) 05:45:51.32

記述量がどうしても Rust は多いイメージなんだよなあ

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

C++のテンプレートメタプログラミングよりも
高い効率と抽象性をRustでも実現できるの？
だったらRust使うが

**デフォルトの名無しさん** · 2021/12/10(金) 08:57:57.63

>>941
一般的に洗脳されていると難しいけれど色んなレベルでの意識改革ができると今後に役立つよ
例えばC++自体の限界のためにテンプレートメタプログラミングでやらざるを得なかったケースがRustでは使わずに出来てしまうケースもあるし
C++ではこうやるべきだと思えていたお決まりの手法が発想を転換するとRustでは別の手法によりもっと自然に出来てしまうケースもある
一方で失敗する人たちはそういった意識改革が出来ずにC++では当たり前に思えていた方法でそのまま突き進もうとしてしまい本来は簡単に出来ることを複雑にしてしまう
もちろん能力がある人たちならばこの意識改革が出来るため必要に応じて発想の転換など臨機応変に対応することが出来ますから大丈夫

**デフォルトの名無しさん** · 2021/12/10(金) 09:00:57.84

>>942
> 例えばC++自体の限界のためにテンプレートメタプログラミングでやらざるを得なかったケースがRustでは使わずに出来てしまうケースもある
> C++ではこうやるべきだと思えていたお決まりの手法が発想を転換するとRustでは別の手法によりもっと自然に出来てしまうケースもある

ふむふむ。例えばどういう具体例がありますか？

**デフォルトの名無しさん** · 2021/12/10(金) 09:49:59.85

そういう気付きや意識改革を自分で出来ない人たちはもっと基本的なところからスタートすると良いかな
例えばRustにはclassすらないしtry/catch/throwすらない
C++の視点から見るとそんなのでまともなプログラミングできるの？？となる
しかし現実にRustではそれらがなくとも普通に問題なく便利にプログラミングが出来ている
そして発想の転換が出来るようになるとclassやtry/catch/throwはプログラミングする上で必須なものではなかったんだなと真の理解が進む
まずはこういう基礎的なところからスタートするのがよいでしょう

**デフォルトの名無しさん** · 2021/12/10(金) 09:55:49.46

type traitに関してはまんまtraitで置き換えてコンパイル時に判定できる
type traitベースでenable_ifするのはtrait boundで

テンプレートメタプロそこまで詰めてやったことないから逆にRustでできなさそうなの挙げて欲しいかも
それか両方詳しいひとカモン

**デフォルトの名無しさん** · 2021/12/10(金) 09:58:50.45

>>943
典型的なのはSFINAEを駆使してた部分がtraitで解決できるとかかな
まぁconceptと同じようなもんだけど、conceptは正直まだ発展途上だと思う

**デフォルトの名無しさん** · 2021/12/10(金) 10:06:35.76

C++はSFINAEがあるから部分的に型エラーになっても大丈夫だけど
Rustのジェネリクスはそういうのは許容しないからちょっと表現範囲は狭いね
ジェネリクスの範囲外は手続きマクロでカバーする感じ
こっちは任意のコード生成だから、テンプレートより遥かに自由度が高い（が、当然乱用するとやばい）

**デフォルトの名無しさん** · 2021/12/10(金) 11:45:45.31

>>944
こういうの見るとどんどんRustが嫌いになっていく…

**デフォルトの名無しさん** · 2021/12/10(金) 12:09:04.41

>>948
Rustコミュニティーは若いからな。
説明ノウハウ無い＆自浄作用無いので、アホがクズみたいなレスでマウント取ろうとするのは仕方ないよ。

**デフォルトの名無しさん** · 2021/12/10(金) 12:51:44.86

>>942
テンプレート機能はC++の一部だしテンプレートメタプログラミングはその機能を使ったプログラミングに過ぎない
言語自体の限界とはまったく関係ないしやらざるを得ないという表現はなにを指しているのかわからない
>>944
そんなことを言ったらRustにもプログラミング上必須でない機能が無数にあるだろう
言語間に差があることは前提で言語ごとに設計の仕方が異なるからRustの話を聞いただけだ

**デフォルトの名無しさん** · 2021/12/10(金) 12:59:53.37

そういう何も分かってない系は放置してくれると助かります……

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

>>948
あなたのコンプレックスを刺激してしまってのならばごめんなさい
嫌いになるかどうかはあなたが損するだけなのでご自由にどうぞｗ

>>949
単なるアドバイスがマウントに見えてしまうのは一種の病気なので
普段の生活でもマウントがどうとかそんなくだらないとこは一切気にせずに穏やかに暮らしたほうが精神面にも良いでしょう

**デフォルトの名無しさん** · 2021/12/10(金) 13:40:16.69

>>950
> そんなことを言ったらRustにもプログラミング上必須でない機能が無数にあるだろう

無数？？
具体的にプログラミング上必須でない機能を挙げていただけますか？

> 言語間に差があることは前提で言語ごとに設計の仕方が異なるからRustの話を聞いただけだ

前提はおっしゃる通り同意です
具体的にどういうことをしたい時に設計の仕方でお困りですか？

**デフォルトの名無しさん** · 2021/12/10(金) 14:37:54.35

>>952
>>944がアドバイスに見えるとしたら、コーチング・ティーチング技術を勉強した方がいいよ。

>>941の「テンプレートメタプログラミング……」という問いかけには答えず、「そういう気付きや意識改革を自分で出来ない人たち」と相手を否定するだけのアホな言葉をアドバイスと言うのは無能すぎる。

こういうのはRustの害にしかならないから、>>952はアドバイスしないほうがいいよ。

**デフォルトの名無しさん** · 2021/12/10(金) 15:03:50.43

>>954
気付けない人たちへのアドバイスをしてはダメなのでしょうか？
アホな言葉とか無能とか言い出すあなたの人格を疑いますｗ

> こういうのはRustの害にしかならないから

こちらはRustに対して何の利害関係もなく中立なのでどうでもよいですｗ
むしろ害にしかならないと思い込みで決め付けることに呆れました

**デフォルトの名無しさん** · 2021/12/10(金) 20:08:53.17

いつもの二人
枯れ木も山の賑わい

**デフォルトの名無しさん** · 2021/12/10(金) 20:55:44.40

わりと>>954に同意

**デフォルトの名無しさん** · 2021/12/10(金) 22:02:18.09

>>941
健全なマクロはいいなぁと思った。

**デフォルトの名無しさん** · 2021/12/10(金) 23:43:39.24

>>955
>>954でアドバイス「技術」の話をしているのに、アドバイス「可否」の話をするのは無能の証。わかってやっているなら邪悪だし、どちらにしても>>955には他人にアドバイスする資格が無い。

やっぱりRustの害にしかならないから、>>955はアドバイスしないほうがいいよ。

**デフォルトの名無しさん** · 2021/12/11(土) 02:13:49.48

他人に資格がないとか言っちゃうお前も無能だよ

**デフォルトの名無しさん** · 2021/12/11(土) 02:53:22.45

次スレどうしますか
なんかテンプレに書くべきことある？

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

次スレ必要か？

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

馬鹿には理解できません、って書いておくか

**デフォルトの名無しさん** · 2021/12/11(土) 03:13:02.46

隔離スレ無いと本スレが荒れるかなって思ったけど
最近あっちは大人しいし、変なの湧き始めてからでもいいかね？

**デフォルトの名無しさん** · 2021/12/11(土) 03:13:38.27

C++もRustもそれぞれ別にスレがあるのだから次スレは要らないだろ
単発のネタスレだよここは

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

冗談抜きでランダムアクセスを「乱択的に生成した要素番号の要素にアクセスすること」だと思ってる人たちが700レスくらい消費したからな

**デフォルトの名無しさん** · 2021/12/11(土) 09:49:26.74

LinkedListをランダムアクセス可能とかいうバカのおかげでスレが伸びたな
LinkedList ランダムアクセスでググれば一発で分かるようなことを延々とやってたからな

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

お互い恥ずかしいこと書いちゃったからよっぽど悔しかったんだねwww

本スレがノイズだらけになるから隔離スレは継続すべき

**デフォルトの名無しさん** · 2021/12/11(土) 13:10:02.70

アドバイスしているつもりの有害をこちらに誘導できるから継続すべき。

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

優秀な人はレベルの高い学校に行かないと馬鹿になってしまうということが
証明されたスレだ。

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

どっちもウザいから無くていいよ

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

アルゴリズムの基本も知らないド素人

**デフォルトの名無しさん** · 2021/12/12(日) 14:18:54.35

C++の場合、std::prev()、std::next()等でランダムアクセス可能。

**デフォルトの名無しさん** · 2021/12/13(月) 04:01:27.37

それシーケンシャルアクセスや。

**デフォルトの名無しさん** · 2021/12/13(月) 04:06:48.16

std::next(v.begin(), 3)などが可能。

**デフォルトの名無しさん** · 2021/12/13(月) 09:51:08.61

そうなんだ、よかったね

**デフォルトの名無しさん** · 2021/12/13(月) 10:41:09.99

そうなんだ、よかったねで済む話を700レスも続けたスレだった

**デフォルトの名無しさん** · 2021/12/13(月) 10:55:12.57

ガイジ隔離できるから次スレ建てろ

**デフォルトの名無しさん** · 2021/12/13(月) 23:41:21.78

>>758
言ってることは全く正しいけど
promise/futureの存在によってasync/awaitが成立していることをもっと強調すべきかな
このまえGoスレでそれすら理解できないやつが延々と暴れていた
さらに「async/awaitがあればpromise/futureは不要！」とまで主張して暴れていた
非同期プログラミングをかじっただけの人にありがちなのかもしれない
例えば「複数のpromise/futureに対して任意の一つが解決されたら」とか「解決順に」とかawaitだけでは表現不可能なのにな

**デフォルトの名無しさん** · 2021/12/14(火) 01:57:04.15

あわしろ氏はガイジじゃないぞ。

**デフォルトの名無しさん** · 2021/12/14(火) 09:28:14.72

そうなんだ、よかったね

**デフォルトの名無しさん** · 2021/12/14(火) 09:42:41.73

golangにasync/awaitなんて無いし、promise/futureもchannel通信で作れば作れるけどそんな事しないし
むしろ暴れてるのはお前だろ、思想的に必要無い言語にそれを持ち込んで優位性を語るなんてアホちゃうか？

**デフォルトの名無しさん** · 2021/12/14(火) 10:15:19.20

結局Rustが一番いいよな
非同期をawaitという限られた同期パターンだけでなくfutureを直接扱うことも可能だし
Goのようにコルーチンをすぐ動かせるしそれに対して同様にchannel通信もいけるしfutureとして扱うことも可能

**デフォルトの名無しさん** · 2021/12/14(火) 10:55:30.64

アホか、Rustに厳密なcoroutineなんてデフォルトで無いやろ、Boost移植のcontext-rs/coroutine-rsとかあるけども…
実験的にRFC 2033: experimental coroutinesとかやってるけど、N:Mスレッドスケジューラーが標準搭載される未来はない。

**デフォルトの名無しさん** · 2021/12/14(火) 11:24:57.22

>>984
Rustでは一昨年からasync blockが既にstackless symmetric coroutineとして動いています
zero costでlazyなのでasync blockを作るとそれだけだとfutureが出来るのみ
それをm:n含め好きなスケジューラがいくらでもあるのでそれに対してspawnするだけで起動します
そのasync block内では全てawaitしまくればgoroutineと同じ状況になります
もちろんチャネルも使えます

**デフォルトの名無しさん** · 2021/12/14(火) 12:31:40.21

Rustの並行処理には未来を感じるけど、
tokioとasync-stdはどっちがデファクトスタンダードです？

**デフォルトの名無しさん** · 2021/12/14(火) 12:37:47.85

不毛な議論にまたなるのでアホは相手したくないが、「厳密な」と書いていることが全くわかってない。
所詮spawnするということはasync/awaitがepollベースであり、更には「全てawaitしまくれば」なんてGoと同じ状況じゃないでしょｗ
標準搭載と書いてるのに「好きなスケジューラがいくらでもある」とほざく
ゼロコスト、ゼロコスト言うやつがいる限りウザがられるし、英文で書けば相手を丸め込む事ができると思い込んでると
ホントに爪弾きにされるぞ、Rust推しは分かるけどもう少し顔真っ赤にしてくる態度改めようぜ？
C++でもco_await、co_yieldはゼロコストでスタック消費しないし、コンパイラ型で非同期にコスト掛かる言語って何？

**デフォルトの名無しさん** · 2021/12/14(火) 14:43:42.13

https://i.imgur.com/dB5gmZU.png
2022年版が必要です

**デフォルトの名無しさん** · 2021/12/14(火) 14:53:55.31

>>987
貴方のほうが色々とおかしい。

＞所詮spawnするということはasync/awaitがepollベースであり、Goと同じ状況じゃないでしょｗ

まずepollを貴方が理解できていない。epollはLinuxでのpoll/select系システムコールのAPI。
厳密にするのも的外れなので、仮にここではselect/poll等の意味合いで受け取っておく。
Goのgoroutineも当然ながらこのselect/poll等を用いて実現しているので全く同じ状況。
当然select/poll等を用いなければgoroutineのような軽量スレッド(グリーンスレッド)は実現できない。

＞所詮spawnするということはasync/awaitがepollベースであり、

引用再掲するが、貴方は更なる誤解もしている。
まず、awaitはfutureを解決する単なる一つの手段にすぎず、貴方が言及しているspawnする対象はfurureである。
そしてGoでの「go func」がRustでの「spawn(future)」に相当。
これらが為されないとどちらもスケジューラに登録されず両者は同じ状況であると言える。

＞更には「全てawaitしまくれば」なんてGoと同じ状況じゃないでしょ

Goroutineでは明記しなくても暗黙的にawaitを付けたのと同じ同期的な記述で非同期を記述できる。
したがって、Rustにおいては「全てawaitしまくれば」Goと同じ状況といっても過言ではないと言えよう。
いずれにしても「go func」と「spawn(future)」の場合と同じで記述面での些細な相違だけにすぎない。

＞標準搭載と書いてるのに「好きなスケジューラがいくらでもある」とほざく

Rustの標準には不可欠なものしか無いから標準搭載されていないのは当たり前。
よく例に出されるが、C言語でstdlibにあるrand()のような乱数ですらRustの標準ライブラリにはない。
貴方の無茶な理論だとRustは乱数もサポートしていない言語、となる。
OSや組み込みにも用いられる状況で、何か単一のスケジューラが標準搭載であればよい、わけがない。
むしろ様々なスケジューラを選ぶことができるRustの状況こそ、明らかに有利である。

**デフォルトの名無しさん** · 2021/12/14(火) 15:23:08.46

顔真っ赤マン。。。

**デフォルトの名無しさん** · 2021/12/14(火) 16:25:41.72

>>989
顔真っ赤で草

**デフォルトの名無しさん** · 2021/12/14(火) 17:27:33.19

>>986
個人的には名の通りstdをasync化しているasync-stdが好みです

>>987
よくわかっていらっしゃらないようなのでどの言語でもいいから実際にプログラミングしてみることをおすすめします
epollでもselectでもいいからI/Oイベントループを自分で書いてみればそれがディスパッチャでありスケジューラの核心だとわかりますよ
C言語で大丈夫ですから

**デフォルトの名無しさん** · 2021/12/14(火) 18:07:51.75

顔真っ赤オジサン、スケジューラの核心ｗｗｗ

**デフォルトの名無しさん** · 2021/12/14(火) 20:36:31.90

ここまでの議論でわかったことは、RustよりGoのほうが上。