21/12/14 10:15:19.20 YU8H/oh/.net
結局Rustが一番いいよな
非同期をawaitという限られた同期パターンだけでなくfutureを直接扱うことも可能だし
Goのようにコルーチンをすぐ動かせるしそれに対して同様にchannel通信もいけるしfutureとして扱うことも可能
1005:デフォルトの名無しさん
21/12/14 10:55:30.64 9qJ+oS+1.net
アホか、Rustに厳密なcoroutineなんてデフォルトで無いやろ、Boost移植のcontext-rs/coroutine-rsとかあるけども…
実験的にRFC 2033: experimental coroutinesとかやってるけど、N:Mスレッドスケジューラーが標準搭載される未来はない。
1006:デフォルトの名無しさん
21/12/14 11:24:57.22 YU8H/oh/.net
>>984
Rustでは一昨年からasync blockが既にstackless symmetric coroutineとして動いています
zero costでlazyなのでasync blockを作るとそれだけだとfutureが出来るのみ
それをm:n含め好きなスケジューラがいくらでもあるのでそれに対してspawnするだけで起動します
そのasync block内では全てawaitしまくればgoroutineと同じ状況になります
もちろんチャネルも使えます
1007:デフォルトの名無しさん
21/12/14 12:31:40.21 cpUh/hIt.net
Rustの並行処理には未来を感じるけど、
tokioとasync-stdはどっちがデファクトスタンダードです？
1008:デフォルトの名無しさん
21/12/14 12:37:47.85 XjtTquHZ.net
不毛な議論にまたなるのでアホは相手したくないが、「厳密な」と書いていることが全くわかってない。
所詮spawnするということはasync/awaitがepollベースであり、更には「全てawaitしまくれば」なんてGoと同じ状況じゃないでしょｗ
標準搭載と書いてるのに「好きなスケジューラがいくらでもある」とほざく
ゼロコスト、ゼロコスト言うやつがいる限りウザがられるし、英文で書けば相手を丸め込む事ができると思い込んでると
ホントに爪弾きにされるぞ、Rust推しは分かるけどもう少し顔真っ赤にしてくる態度改めようぜ？
C++でもco_await、co_yieldはゼロコストでスタック消費しないし、コンパイラ型で非同期にコスト掛かる言語って何？
1009:デフォルトの名無しさん
21/12/14 14:43:42.13 ecGTY8hf.net
URLﾘﾝｸ(i.imgur.com)
2022年版が必要です
1010:デフォルトの名無しさん
21/12/14 14:53:55.31 nVZu9KeB.net
>>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の状況こそ、明らかに有利である。
1011:デフォルトの名無しさん
21/12/14 15:23:08.46 SmqbIrWZ.net
顔真っ赤マン。。。
1012:デフォルトの名無しさん
21/12/14 16:25:41.72 iFoIKYew.net
>>989
顔真っ赤で草
1013:デフォルトの名無しさん
21/12/14 17:27:33.19 YU8H/oh/.net
>>986 個人的には名の通りstdをasync化しているasync-stdが好みです >>987 よくわかっていらっしゃらないようなのでどの言語でもいいから実際にプログラミングしてみることをおすすめします epollでもselectでもいいからI/Oイベントループを自分で書いてみればそれがディスパッチャでありスケジューラの核心だとわかりますよ C言語で大丈夫ですから
1015:デフォルトの名無しさん
21/12/14 18:07:51.75 K0HBzsrc.net
顔真っ赤オジサン、スケジューラの核心ｗｗｗ
1016:デフォルトの名無しさん
21/12/14 20:36:31.90 oL+i1N1M.net
ここまでの議論でわかったことは、RustよりGoのほうが上。
1017:デフォルトの名無しさん
21/12/15 07:13:59.09 CevG0U/x.net
Goでできることが全てRustでもできるようになってしまったもんな
Goではできないこと辛いことが多すぎてGo2でRustの後追いしようとしているがGo2は期待外れで盛り下がっている
1018:デフォルトの名無しさん
21/12/15 08:58:39.57 3YmRd/Kz.net
それがディスパッチャでありスケジューラの核心
1019:デフォルトの名無しさん
21/12/15 11:21:17.73 TZwcTz32.net
Goは色んなレベルで簡素で手段に制限があるけど
そこをパズルのように組み合わせてある程度のことは出来る楽しさがいいのよ
ただしそれが飽きられてきていたり楽しいと思う人たちより外に広まらなかったり
自然じゃない組み合わせで実装や冗長な記述などせざるをえなかったり
だからGoはこのまま狭い適用範囲だけで使われる形になりそう
1020:デフォルトの名無しさん
21/12/15 11:41:54.42 z10T13Tn.net
このスレなくなったら名残惜しいから次スレ建てろ
完走しても建ってなかったらワイが建てるで
1021:デフォルトの名無しさん
21/12/15 12:34:06.40 t4BO72er.net
>>997
納得できない
じゃあきみはGoにGenericsとか実装されても使いたくないの？
Goの良いところはそういうとこじゃないでしょ
1022:デフォルトの名無しさん
21/12/15 12:34:55.45 z10T13Tn.net
1000ならC++の勝ち！！！！！
1023:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 235日 4時間 30分 6秒
1024:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています