[過去ﾛｸﾞ] Go language part 5 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
979: デフォルトの名無しさん [sage] 2025/05/20(火) 22:34:48.64 ID:vbQ41r/k(1/3) AAS
>>967
単純に、「重い」と認識できてない馬鹿と、分かってても変更しない意識高い系馬鹿の合わせ技でしょ
1995時点で「お前らのマルチスレッドはスイッチングが重すぎてまるで機能していない」と看破できたのはJSだけ
大半の言語はこれを認め、JSと同様に「手動」で軽量化も可能なよう、async文法を導入した
ただし実際、手間が増えてるのと、将来的にOSレベルでのスイッチングが軽くなった場合に、asyncで書かれたコードはゴミになる
だから「抽象度が高い状態で書きたいのだ！！！」「OSで『自動』的にやらせたほうがコード資産の価値は高いのだ！！！」という言い訳はできる
(問題は軽くなる予定が全く無いことだが)
この意味では、「asyncが必要なのではなく、OSがポンコツすぎるのだ！！！」と責任転嫁することも出来るはずだが、
誰もやらないところを見ると、OSは限界までは軽いんだろうな
そして逆に、アプリ側でasync必須でスケジューラも持ってれば、OS側で持ってるのは無駄なので削除して軽量化することは出来る
chromiumOSが奇妙に軽いのはこの辺かもな(＝JS専用OS)
980: デフォルトの名無しさん [sage] 2025/05/20(火) 22:35:11.14 ID:vbQ41r/k(2/3) AAS
> プリエンプティブ
> 協調スケジューリング
改めて考えてみたが、「同期APIを使える」くらいしか利点を思いつかない
協調スケジューリングの場合は「非同期API強制」となるからね
JSは2013年頃でも「SLEEPは？」とか言われてたし、889のような馬鹿げたブログ(2015)を書くやつも居るしで、
非同期アレルギーはそうならなかったやつの想定以上に激しいのかもしれん
(俺に言わせれば、SLEEPは別の書き方があるからそれでいい、Promiseはゴミ、コールバック地獄になるのは腕前の問題、
この辺JSは全関数がクロージャなのだから適当に関数ぶった切って書き、コールグラフを整理すれば回避出来る、となるが)
そして出自がJSというのも当たりは悪い
フニャフニャ文法、階層が関数、専用構文とprivateのないオブジェクト指向、
ダックタイピング、動的に変化するthis、他型のメソッドも使える、で、
正統派オブジェクト指向のC++/Java/C#勢からすれば十分異端すぎるのに、更に、非同期、イベントドリブン、だからね
JSモデルが想定以上に速かったから、他言語開発者はJSを研究せざるを得ず、
何じゃあこれはーーー！！！となるのは分かる(＝JSアレルギーの発症
俺の場合は、え？こんなので大丈夫なのか？→あれ？意外と問題ねえな→実は他言語が無駄に冗長過ぎただけでは…、となったが)
まあブレンダン・アイクは本当に上手く攻略したな、とは思うよ
とはいえ、『同速なら』同期APIのコードの方がマシなのは事実だから、
同期API派はさっさと同速になる方向の努力をすべきだと思うがな
981(1): デフォルトの名無しさん [sage] 2025/05/20(火) 22:36:05.33 ID:vbQ41r/k(3/3) AAS
>>976
> skipping TCP and TLS handshakes required on a new connection.
いやこれってありなんか？とは思ったが、GETならどうせ同じ(はず)だからいいのか？
となると、リバースプロキシって、誰かの操作を横から盗み見してる感じになるのか？
> 原文はRust最強みたいな変な誤解をされないように注意深く書かれている
信者が発狂するからといってオブラートに包みすぎ。原文は以下
> This is not because we run code faster.
まあCと比べればRustも遅いから、これはどうにもならんが
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.041s