958(2): デフォルトの名無しさん [sage] 2022/02/26(土) 13:41:54 ID:CoGWNwI7(1) AAS
Goってぶっちゃけ言語機能とか割とどうでもよくて、
・ビルドやデプロイや運用がシンプル
・本家の開発体制が保守的で、長期的に安定したサポートが期待できる
という点がメリット
極力作りっぱなしで放置したい類のものに向いてると思うんだよね
Goしかできない奴やGo大好きで使ってる奴もまずいないだろうし、こんなもん執拗に叩いて何がしたいの

962(1): デフォルトの名無しさん [sage] 2022/02/26(土) 16:17:55 ID:kpnhrKVl(6/10) AAS
>>951
やってないのはやる必要がないから。
他言語も馬鹿ではないので、改善の努力はしてるし、いい点があったら平気でパクってる。

(Goはgreenthreadで全て解決！と謳っているわけではないけども、そうだとしたら）
そのアイデアは面白かったが、現実的ではなかった。
（ただしこれはランタイムの問題だから改善の余地はあるはず）

非同期はコードがうざくなるのは事実だが、async文法でほぼ払拭された。
だからみんなパクってる。

まあ完全にループだし、材料枯渇でここら辺で終わりかな。
そりゃ信者の念仏を何度聞いても翻意する事はないよ。俺は文系ではないし。
こちらの見解では説明出来ないデータが出て来たら、分析して、考えを修正するけど。

>>957
virtualの40MBを単純に合算したら、今は4倍軽くて、4k/goroutine時代は2.5倍軽かったという事か。
フットプリントだけの比較ではあるが。
だから極めて単純に言えば、他言語のスレッドでジョブを4つずつ束ねて処理する運用をすれば、
フットプリントでは並んで、速度は余分なスケジューラが入ってない分勝てる事になる。

963(1): デフォルトの名無しさん [sage] 2022/02/26(土) 17:32:36.09 ID:nY3OEggH(1) AAS
>>960
そりゃWebのフロントエンドに比べりゃなんだって放置したい系になるだろ
Webの場合はバックエンドでもWebフレームワークをサポートバージョンに維持する必要があるから
長くても3〜5年すればコードを変更することになる

967(1): デフォルトの名無しさん [sage] 2022/02/26(土) 18:16:48.89 ID:nWQ4XblH(2/2) AAS
>>966
SPAのすぐ裏でUIの要件に合わせて作るようなやつのことじゃね？
そういうのはそもそもGoを採用しないと>>960で書いた通りだ

974(2): デフォルトの名無しさん [sage] 2022/02/26(土) 21:20:48.95 ID:4mZJSMD8(1/4) AAS
>>943
>> それはN:M軽量スレッドだからなし得ることなので、他の言語ができてない以上何とも比べづらい。

RustもM:Nモデルだよ
Goと同じく複数の非同期タスクを複数のOSスレッドに割り当て
しかもGoとは異なりスタックレスなのでGoよりも軽量タスクを実現しているよ

>>951
>> スティーリングまでやるのは他の言語の言語標準機能にはErlangぐらいにしかない。

RustもGoと同じM:Nモデルでワークスティーリングもしているよ
Rustでは以下のランタイムを選ぶことができるよ
・1:1モデル (＝M:Mモデル、OSスレッドそのまま利用)
・M:1モデル (シングルOSスレッドで並行マルチタスク)
・M:Nモデル[スレッドプール方式]
・M:Nモデル[ワークスティーリング方式]

978(1): デフォルトの名無しさん [sage] 2022/02/26(土) 21:59:12.46 ID:4mZJSMD8(2/4) AAS
>>975
RustはGoと真逆で標準ライブラリとは最小限のものに限る位置付けなので
標準ライブラリには非同期ランタイムを作るための枠組みだけが存在していてランタイム自体は無しだよ
これは全ての分野について同じ方針でRustでは標準＋準標準(デファクトスタンダード)を使ってプログラミングをするよ