[過去ﾛｸﾞ]
Go language part 5 (1002ﾚｽ)
Go language part 5 http://mevius.5ch.net/test/read.cgi/tech/1645915400/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
1: デフォルトの名無しさん [sage] 2022/02/27(日) 07:43:20.04 ID:uWHjNeVw Goについて扱うスレッドです。 GoはGoogleによって開発された言語です。 公式 https://golang.org 公式ドキュメント https://golang.org/doc/ 公式外パッケージドキュメント https://godoc.org ブラウザ上で試し書き https://play.golang.org ※前スレ Go language part 4 https://mevius.5ch.net/test/read.cgi/tech/1605467680/ http://mevius.5ch.net/test/read.cgi/tech/1645915400/1
903: デフォルトの名無しさん [] 2025/05/18(日) 15:31:42.85 ID:/UZONODy >>902 その awaitってやった関数は必ずasyncにする必要がありコンパイラはこれをgeneratorベースのステートマシンに変換するからｗ C# だって Task をそのまま返す関数を そのまま await できるだろ？一体何が違うんだ？ ほんとお前みたいな無知って困るわ そもそも俺が話していたのはJSで標準ライブラリをいちいち promise でラップするのは面倒だって話だよね？ それは sleepの例だったり fs/promises の存在だったり、httpクライアントで誰も標準ライブラリを使わない点の3つで完全論破したはずだけど ちなみに俺はC#でgithub star 2000ぐらいのOSS作ってるけどお前はそれぐらいの実績はあるんか？プログラミングしたことないエアプだの煽ってきてるけど http://mevius.5ch.net/test/read.cgi/tech/1645915400/903
904: デフォルトの名無しさん [] 2025/05/18(日) 15:39:51.60 ID:/UZONODy 何が違うの？そもそもお前が何を言いたいのかわからん JS ``` async function main() { console.log(await HelloAsync()) } function HelloAsync() { return Promise.resolve("hello"); } main() ``` C# ``` public class HelloWorld { public static async Task Main(string[] args) { Console.WriteLine (await HelloAsync()); } public static Task<string> HelloAsync() { return Task.FromResult("Hello"); } } ``` http://mevius.5ch.net/test/read.cgi/tech/1645915400/904
905: デフォルトの名無しさん [sage] 2025/05/18(日) 15:47:15.22 ID:eaOArS/2 >>903 C#やRustなどの言語はステートマシンにする必要があるがJavaScriptはそのまま行けるところが最大の特徴 asyncもPromiseもないコールバックだけの時代からなぜコールバック待ちの間に無関係な他の関数が実行できるのかを理解できなかったのか？ その枠組があるから多数の非同期イベントが飛び交うブラウザ内でも並行処理ができる 知らないなら基礎だから勉強しろ http://mevius.5ch.net/test/read.cgi/tech/1645915400/905
906: デフォルトの名無しさん [] 2025/05/18(日) 15:55:47.79 ID:/UZONODy >>905 だから このJSの例だと main() 関数で await使うためにコンパイラが main関数を generatorベースの ステートマシンに変換してるからｗ そのまま行けるってのが意味わからんのだけど説明できないだろお前ｗ 別にこれはC#だろうだRustだろうが何も変わらないからｗ C# も この例だとMain関数がステートマシンに変換されていて、HelloAsyncはTaskを返すだけで何もしてない 一体JSと何が違うんだ？？？説明できないだろasync/awaitをそもそも理解できていないみたいだから > asyncもPromiseもないコールバックだけの時代からなぜコールバック待ちの間に無関係な他の関数が実行できるのかを理解できなかったのか？ 何言ってるのかわからん、コールバックだのTaskだのPromiseだのそれはコードの書き方の違いであって最終的にepoll や IOCPで非同期で処理されていることは何も変わらない 無知はお前だ、お前が勉強しろ OSSスターで2000ぐらい獲得してから勉強しろだのマウントとってこいゴミ http://mevius.5ch.net/test/read.cgi/tech/1645915400/906
907: デフォルトの名無しさん [sage] 2025/05/18(日) 16:10:19.90 ID:eaOArS/2 >>906 なんだ少しは理解してるじゃないか 言語の中でepollなどでイベントループを抱え込んでいてそれがPromiseもasyncも無い大昔からJavaScriptは同じ つまりasync/awaitなんか関係なく初めからイベントループを内蔵している これはWebブラウザという無数に非同期タスクが飛び交う必要性からその仕様となった そのためC#などより早く非同期タスクが実現されてきた そのためC#などようなステートマシン変換なんか必要とせずに単なるシンタックスシュガーだけでasync/awaitも導入できている http://mevius.5ch.net/test/read.cgi/tech/1645915400/907
908: デフォルトの名無しさん [sage] 2025/05/18(日) 16:32:11.94 ID:5+cNmsjt WPFスレにもわいてるgithubでスターxxxx個君じゃん http://mevius.5ch.net/test/read.cgi/tech/1645915400/908
909: デフォルトの名無しさん [] 2025/05/18(日) 16:33:35.47 ID:/UZONODy JSはC# みたいにILから逆コンパイルできないから内部でどうなってるかは簡単にわからないけどJSだってステートマシン相当のものに変換してるからｗ async/await をコンパイラレベルで Promise, Task に変換し実装されていること自体はC#もJSも何も変わらない お前そもそもステートマシンの理解何もしてないだろ これを見ろ無知野郎 これがC#のステートマシンの実装だ、単なるシンタックスシュガーにすぎないことがわかる https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA+B6DACA8gOwBsBLfGbAYQGJsBRAE2IBdpsAzVt2GAWACgs2AOpRmMADR1GTbAEN89bACUArvmwBPCCqiUakeuQACABj14ipchQgBbAA7FCMKP35GATAEZ3Zo14BWAG53AGZsT2wACRhCQgghaEJ6fgBvMIivJAiADgjsgFlZUgAKfxMAbQBdOSgAcwBnAEo09y8ATmwyzpi4iABBBo18MBKmppC+AF83PiNw/2yjJAAecoA+aNj4weHRlr50uYB2fIA6ADEoOyUYBpVCJhKAIl7454n+GensIA= > そのためC#などより早く非同期タスクが実現されてきた また嘘ついてるよこいつ そもそもJSの Promiseも 他言語からパクってるにすぎない C# の Task は2010年実装 (.NET Framework 4.0) だ、JavaScriptはES2015 だから 2015 年だ Node.js は コールバック地獄 に2015まで悩まされてたけど C# はそんな問題とっくに解決してたんだわ だからpromiseもasync/awaitと同様C#のパクリといってもいいな Promise/Task以外の非同期実装なら C# だって前からあるわ ブラウザ側の言語だけ触ってるのが技術マウントとってくるのは滑稽だからやめたほうがいいよ > つまりasync/awaitなんか関係なく初めからイベントループを内蔵している C# はシングルスレッドのイベントループなどのゴミじゃなくてTaskはスレッドプールで実行されるからそのままマルチコア使えるんだわｗ メインスレッドに戻す機能(SynchronizationContext, TaskScheduler) もあるからJSシングルスレッドにしたかったらそれもできてロックフリーにできるんだわ (マルチスレッド使った方が良いので普通やらないが) http://mevius.5ch.net/test/read.cgi/tech/1645915400/909
910: デフォルトの名無しさん [sage] 2025/05/18(日) 16:42:27.02 ID:eaOArS/2 >>909 おまえまだ別人と勘違いしてるのか 俺はシングルスレッドにすぎないJavaScriptの非同期が優れているとは一度も言ってないぞ CPUコアスレッドを透過的に使いこなせるN:Mモデルが一番優れていると伝えただろ http://mevius.5ch.net/test/read.cgi/tech/1645915400/910
911: デフォルトの名無しさん [] 2025/05/18(日) 16:46:23.38 ID:/UZONODy >>910 まともに会話できないアスペ死ねよ お前と同一視してないって言ってんだろ JSを持ち上げる馬鹿としては同一だから言ってるだけ 話題そらしてないでこれの意味について論理的に説明してみろよ > そのためC#などようなステートマシン変換なんか必要とせずに単なるシンタックスシュガーだけでasync/awaitも導入できている 上でC#コンパイラがどう async await を Taskベースのステートマシンに変換したかを教えたが JSも別に何も変わらないから。結局お前が何が言いたいのかを説明しろ無知のくせにマウントとってくる無能 http://mevius.5ch.net/test/read.cgi/tech/1645915400/911
912: デフォルトの名無しさん [sage] 2025/05/18(日) 16:54:47.55 ID:eaOArS/2 >>911 何度も説明しているのに理解できないのは呆れる async/awaitなんか導入する前からJavaScriptはPromiseで非同期に動いている シンタックスシュガーにすぎないasync/await記法の導入によってステートマシンの導入なんか必要ない http://mevius.5ch.net/test/read.cgi/tech/1645915400/912
913: デフォルトの名無しさん [] 2025/05/18(日) 17:36:48.91 ID:/UZONODy >>912 C# は Taskベースのスレッドプール実装が先にあり、その後async/awaitが導入され、コンパイラがTaskベースのステートマシンに変換する JS は callback, Promiseベースのイベントループ実装が先にあり、その後async/awaitが導入され、(JIT)コンパイラがPromiseベースのステートマシンに変換する この2つの一体何が違うのか説明しろ ChatGPTの回答 質問: JavaScript の async/await は内部でPromiseを使ったステートマシンに変換されますか？ 回答 ``` はい。JavaScript の async/await は構文糖衣であり、内部的には Promise を使ったステートマシンに変換されます。 AsyncFunction は常に Promise を返す ECMAScript2017 の仕様では、async function を呼び出すと新しい Promise が即座に返されます。本体は zero 個以上の await 式で分割され、各 await ごとに実行を一時停止・再開する必要があるため、概念的にはステートマシンとして動作します モダン JavaScript エンジンでの最適化 V8（Chrome）、SpiderMonkey（Firefox）、JavaScriptCore（Safari）などのエンジンでも同様のステートマシン原理を内部に持ちつつ、ネイティブの AsyncFunction オブジェクトとして最適化して実装しています en.wikipedia.org ``` そしてお前は最初の話題であった標準ライブラリでasync/awaitがそのまま使えない問題について何も反論できてない 以下の3つについて反論しろ - なぜ promiseラップのsleep関数を実装するユーザが多いのか - なぜ標準ライブラリのhttpクライアントではなく axios等を使うのか - なぜ fs/promises は導入されたのか http://mevius.5ch.net/test/read.cgi/tech/1645915400/913
914: デフォルトの名無しさん [] 2025/05/18(日) 17:40:07.52 ID:/UZONODy 理解してないなどと煽ってきたのはお前が先 Claude ``` 質問: JavaScript の async/await は内部でPromiseを使ったステートマシンに変換されますか？ はい、JavaScript の async/await は内部でPromiseを使ったステートマシンに変換されます。 async/await は構文的な糖衣（シンタックスシュガー）であり、基本的にはPromiseベースのコードを書きやすくするための機能です。JavaScriptエンジンがコードを実行する際、async関数は内部的に以下のような変換が行われます： async関数は常にPromiseを返すように変換されます await式は、Promiseの解決を待つためのステートマシンの一部となります 関数内の各await式の前後でコードが分割され、Promiseのチェーンとして再構築されます ``` http://mevius.5ch.net/test/read.cgi/tech/1645915400/914
915: デフォルトの名無しさん [] 2025/05/18(日) 17:50:18.44 ID:/UZONODy >> 893デフォルトの名無しさんsage2025/05/18(日) 14:00:53.82ID:eaOArS/2(2/10) 返信 (1) >> Promise作るのにどこに面倒があるんだ？ >> プログラミングしたことがないエアプかよ >> 自作できないならお子様向けのpromisifyもあるだろ 標準ライブラリをasync/awaitで扱うためにpromise作るのが面倒じゃないなら なんで setTimeoutをPromiseでラップしたsleep関数を多くの人が作っているの？ なんで 標準ライブラリのhttpクライアントじゃなくて axios 等を使うの？ なんで fs/promises など一部はpromiseベースのAPIが導入されてるの？ そして何でNode.jsは他の言語では当たり前に可能な非同期のキャンセル処理をまともにサポートしてないの？ ステートマシンとか async/awaitの内部実装はどうでもいいからこれについて反論してみろ、無知のくせにマウントとってくる無能屑 http://mevius.5ch.net/test/read.cgi/tech/1645915400/915
916: デフォルトの名無しさん [sage] 2025/05/18(日) 23:04:23.34 ID:vhS9Z2b5 たまたま開いたスレでC#の話題がと思ったら… Goの話しろよ http://mevius.5ch.net/test/read.cgi/tech/1645915400/916
917: デフォルトの名無しさん [sage] 2025/05/18(日) 23:23:54.26 ID:vhS9Z2b5 Promiseが不便ならawait/async用に専用Taskの仕様を作ってクリティカルな部分だけ徐々に移行していけばいいじゃないと 傍観者は思うのであった http://mevius.5ch.net/test/read.cgi/tech/1645915400/917
918: デフォルトの名無しさん [sage] 2025/05/18(日) 23:50:58.93 ID:eaOArS/2 >>915 帰ってきたがまだ理解できてないのか Promiseは何か秘密な仕組みや秘密なシステムや秘密なランタイムがあるわけではなく単なるデータだ Promiseを介することでステートマシンなんか使うことなくasync関数を通常関数に自動変換できる 例えばこんなasync関数がある時 async function delay(n) { await new Promise((resolve, reject) => setTimeout(resolve, n * 1000)); return n; } async function foo() { console.log("hello"); let a = await delay(1); let b = await delay(2); let c = a + b; console.log(`${a} + ${b} = ${c}`); return c; } http://mevius.5ch.net/test/read.cgi/tech/1645915400/918
919: デフォルトの名無しさん [sage] 2025/05/18(日) 23:54:17.15 ID:eaOArS/2 >>918のasync関数fooは以下のように機械的に通常関数fooへと自動変換できる ステートマシンを使う必要はない function foo() { return new Promise((resolve, reject) => { console.log("hello"); delay(1).then((_x1) => { let a = _x1; delay(2).then((_x2) => { let b = _x2; let c = a + b; console.log(`${a} + ${b} = ${c}`); resolve(c); }); }); }); } http://mevius.5ch.net/test/read.cgi/tech/1645915400/919
920: デフォルトの名無しさん [] 2025/05/19(月) 00:01:41.90 ID:M5liwQEO Goの話しろよ… 横から少し突っ込むと、 >>915 が言ってるのは>>912にある「シンタックスシュガー」について、その糖衣構文が実際には何を行っているのかが分かっているか？ということ C#でもRustでも、ユーザー側のコードにはステートマシンは出てこないけど、async関数はステートマシンに変換されてる (だから await の前にある変数をそのまま参照できる) これはJSでも同じ >>918 についていえば言語の仕様の違いなので仕方ない JSではsleepみたいにブロックする関数 (CPUを使うような仕事ではないのに待たされる関数) はどうしようも無い C#だとそれを逃がす方法 (Task.Run) もあるけど、これはスレッドプールと関係するから、シングルスレッドのJSだと使えない いずれにせよGoと関係なさすぎ http://mevius.5ch.net/test/read.cgi/tech/1645915400/920
921: デフォルトの名無しさん [sage] 2025/05/19(月) 00:18:33.88 ID:m1yBrNr9 >>920 C#やRustは、await時に一時的にスケジューラに戻すために、ステートマシンのコルーチンに変換しますね。 しかし、JavaScriptはそのコルーチン化が不要なため、ステートマシンへの変換が不要ではないでしょうか？ 実際にステートマシンを使わずに変換している>>919を使ってみたら、元のasync関数と全く同様に動作しました。 http://mevius.5ch.net/test/read.cgi/tech/1645915400/921
922: デフォルトの名無しさん [sage] 2025/05/19(月) 00:20:32.66 ID:/1mCvxff 長くて全部は読んでないがブロッキング処理を含んでるものを単純にPromisifyしたところでなんちゃって非同期になるだけだからちゃんとしたasync対応版が必要って話じゃねーの？ 本当にPromiseでくくるだけでasync対応できると思ってるの？ http://mevius.5ch.net/test/read.cgi/tech/1645915400/922
923: デフォルトの名無しさん [] 2025/05/19(月) 00:30:47.00 ID:M5liwQEO 結果としては同じだよ C#だって Task.ContinueWith (x => ...) と繋げて書くのと、async/awaitで書くのとで、タスクの実行結果として得られるものは変わらない C#の場合は中間言語 (IL) へのコンパイルを挟むから、ステートマシンへの変換というのが可視化されやすい JSだとこれは「JSのエンジン (V8) の中でどのように動作するか」という話で、これは普通は気にしない だからJS界隈ではステートマシンという表現は使わず、「コードを直列化できる」といった機能面からの説明が多いのだと思う 予防線を張るけど、自分はJS詳しくないから間違いだったらすまない http://mevius.5ch.net/test/read.cgi/tech/1645915400/923
924: デフォルトの名無しさん [sage] 2025/05/19(月) 00:31:26.37 ID:m1yBrNr9 >>922 JavaScriptの場合はそうですよ Promiseでくくれば本物の非同期で簡単に並行処理できます C#のTask.Runも不要です async関数の登場以前からasyncと同じ動作で動いていますよ async関数は>>919のような感じのsyntax sugarなんです http://mevius.5ch.net/test/read.cgi/tech/1645915400/924
925: デフォルトの名無しさん [] 2025/05/19(月) 00:50:33.56 ID:dbv2av4u >>913 ChatGPTの回答が説明してるが例で書いてるPromise化されたコードも概念的にはステートマシンだよ awaitの地点を基準に変換してるってのはどの言語も同じ 実際Node.jsはJSコードにトランスパイルしてるんじゃなくて内部表現で変換してるはずだが ステートマシンだの内部実装はどうでもいい話で、それで他人に分かってないだの知識マウント取りに行ってるのがよくわからん http://mevius.5ch.net/test/read.cgi/tech/1645915400/925
926: デフォルトの名無しさん [sage] 2025/05/19(月) 00:57:23.60 ID:+bXsb1rs >>920 それはたぶん君が誤解してるよ >>918のコードが3(=1+2)秒かかるのはC#でいうところのTask.Runしてないからだと思い込んでしまったのかな JSはもっと賢くて自動的にTask.Runされる点が言語の最大の特徴だよ だからそのコード例のように直接awaitせずに let a_promise = delay(1); let b_promise = delay(2); let a = await a_promise; let b = await b_promise; このように分けるだけで並行動作してしまう 実行速度は3(=1+2)秒から2(=max(1,2))秒となるよ これが他の言語とは異なる点で長所 Webブラウザの中で色んなイベントが自然に並行動作できるためだよ http://mevius.5ch.net/test/read.cgi/tech/1645915400/926
927: デフォルトの名無しさん [sage] 2025/05/19(月) 01:34:27.35 ID:T/ZTGVq5 >>924 async/awaitがPromiseのsyntax sugarという話と 同期関数をPromiseでくくれば本当の非同期にできるかどうかは別の話 919の例は内部でsetTimeoutというノンブロッキングな処理しかしてないから問題ないだけ http://mevius.5ch.net/test/read.cgi/tech/1645915400/927
928: デフォルトの名無しさん [sage] 2025/05/19(月) 01:38:06.32 ID:T/ZTGVq5 >>926 Task.Runについても他の言語についても勘違いしてるぞ めちゃくちゃ基本的なんことなのでChatGPT等でもう少し勉強してからまだおいで http://mevius.5ch.net/test/read.cgi/tech/1645915400/928
929: デフォルトの名無しさん [sage] 2025/05/19(月) 01:41:44.47 ID:CwlN/9w+ チャンネルの概念が普及しなくて悲しい http://mevius.5ch.net/test/read.cgi/tech/1645915400/929
930: デフォルトの名無しさん [sage] 2025/05/19(月) 02:23:58.81 ID:WZn5jbbp >>927 もしかしてJavaScriptを使ったことない人かな？ JavaScriptは昔からすべてノンブロッキングで一部の機能に「ブロッキングモードも」付いているだけだよ シングルスレッドなのにブロッキングしたらブラウザが止まっちゃうでしょ それからPromiseを使うと非同期になるのではなくてPromiseが導入される前の時代の最初から非同期なの ブラウザではすべての機能が非同期に並行して動かないと困るでしょ http://mevius.5ch.net/test/read.cgi/tech/1645915400/930
931: デフォルトの名無しさん [sage] 2025/05/19(月) 03:23:55.32 ID:CwlN/9w+ プロミス以前はコールバックやで～ http://mevius.5ch.net/test/read.cgi/tech/1645915400/931
932: デフォルトの名無しさん [sage] 2025/05/19(月) 03:52:20.75 ID:WZn5jbbp >>931 そうだよ その初期のJSの時点で非同期に並行に動いてる そしてコールバックがあれば必ずPromiseを作ることができるという基本原理をわかってるかな？ http://mevius.5ch.net/test/read.cgi/tech/1645915400/932
933: デフォルトの名無しさん [sage] 2025/05/19(月) 04:13:08.42 ID:SYizIHd9 setTimeoutみたいな勝手に非同期になるのがある言語は気持ち悪い 明確に分けようという流れがあった node.jsはシングルスレッドとマルチスレッドが分かれているのが良い シングルならグローバル変数で渡せる マルチにしたいならWorker Threadsを使う Goroutineはマルチスレッド前提だから普通はグローバル変数で渡さない http://mevius.5ch.net/test/read.cgi/tech/1645915400/933
934: デフォルトの名無しさん [sage] 2025/05/19(月) 04:18:06.87 ID:CwlN/9w+ どうでもいい。誰に言ってるんだね http://mevius.5ch.net/test/read.cgi/tech/1645915400/934
935: デフォルトの名無しさん [sage] 2025/05/19(月) 04:20:05.27 ID:CwlN/9w+ settimeoutでプロミス使ってとchatGPTに頼もう http://mevius.5ch.net/test/read.cgi/tech/1645915400/935
936: デフォルトの名無しさん [sage] 2025/05/19(月) 04:32:36.09 ID:dxTyNwiY >>933 勝手に非同期ではなく setTimeoutだけではなく 昔からJavaScriptではブロックして待たせるのではなく非同期前提 そうでなければブラウザがマウスクリックにすら反応できなくなってしまう 例えばXMLHttpRequestでサーバからデータを少しずつ受け取りつつ 並行して画面を書き換えつつ 並行してUI入力があれば反応しつつ すべてを非同期にシングルスレッドで行なうことさえも20年前に広まった いわゆるAjaxだね 何もかもが非同期に並行に動く仕様だからこそ実現できた http://mevius.5ch.net/test/read.cgi/tech/1645915400/936
937: デフォルトの名無しさん [sage] 2025/05/19(月) 09:24:27.09 ID:8khPYfEx 間違い訂正 >>885 ✕ 平行(coherency ○ 平行(concurrency まあ知ってりゃ分かる範囲だが http://mevius.5ch.net/test/read.cgi/tech/1645915400/937
938: デフォルトの名無しさん [sage] 2025/05/19(月) 09:25:09.06 ID:8khPYfEx asyncについてはお前らのほうが詳しいようだから任せるが、俺が言おうとしてたのは、 「キラーアプリ/キラーコンテンツ」と同様に、プログラミング言語にも「キラーコンセプト/キラー文法」があり、 これがJSは「I/Oの分離」で、Goは「Goroutine」という事 まあざっくり関係ある所だけ詰めておくと、 >>887 > Javascriptでフロントエンドプログラム初心者が簡単に使えるから流行っただけ (887) なるほどお前がJS大嫌いなのは分かったが、Rustの馬鹿信者共と同様、お前も何故JSが蔓延ったのかを考えるべきだ Rustとは違い、JSはガチで蔓延ってるからな > async/awaitの発祥はC# (F#)だけど (887) 『文法』についてはその通り。ただし非同期シングルスレッドの『コンセプト』を全面的に打ち出したメインストリーム言語はJSが初だ と言うより、2000年頃はJSはオモチャ扱いされてたが、 パフォーマンスや記述の容易さにおいて優れた言語であることを実証し、実力でメインストリームへと駆け上がってきた この原動力になったのが「非同期」で、実際、現時点のメインストリーム言語はだいたい非同期をサポート『するハメに』なっている (＝JSが非同期でなかったら、他言語がここまで早くasyncをサポートすることも、またC#がasyncを思いつくこともなかったと俺は見ている) 同様に、多言語で普遍的なコンセプトはオブジェクト指向やクロージャ位だろ 逆に言えば、asyncはこれらに並ぶ発明、とも言える > JSが勝ったのは、それがブラウザで動く事実上ただ一つの言語だから (889) 一応Javaも使えた(らしい)が…(誰も使わないので2016頃にブラウザから落とされた) まだDOMのAPIに痕跡も残ってたはず そしてお前にとっては実はこれはラッキーな話で、JSがブラウザ内に留められていた、と認識したほうが正しい もしJSが当初からコンソール等でも使えたら、多分Pythonが駆逐されてた (俺にとってはこうなってくれてたほうが良かったが) http://mevius.5ch.net/test/read.cgi/tech/1645915400/938
939: デフォルトの名無しさん [sage] 2025/05/19(月) 09:25:50.19 ID:8khPYfEx > 別にシングルスレッドでの並行処理が良いなんてことはない これはお前の認識が間違ってる 非同期で平行処理をさばいたほうが「同期/マルチスレッド」よりも性能が出るので各言語はasyncをサポート『するハメに』なった これはお前も(JS大嫌いなので認めたくないようだが)、以下のように認識できてる > 理想的にはasyncの方が効率的になり得ると思うけど (889) C#もそうだが、Thread->(何かあったと思ったが忘れた)->BackgroundWorker->Taskまでは、 それまで通常の同期型マルチスレッドでしか無い というのはまあ、言い方が悪いのは認める なんせマルチスレッドは元来非同期であって、つまりmutex等の同期機構が必要な「ガチの非同期」であり、 JSの「なんちゃって非同期」で「非同期」を極めたつもりになってる馬鹿JSer共は俺も全員殺したい位だ ただ一般的に、また特に初心者に対しては「文法」が目立つので、「非同期」「非同期」言われ、「非同期」がすごいのかと勘違いしがちだが、 JSのコンセプトは「I/Oの分離」で、その手段が「非同期」だっただけ(そして強制＝I/Oに同期APIがほぼ無い) ここをお前は勘違いしてて、すごいのは「非同期」自体ではなく、「I/Oの分離」だ (ただしJSではI/O===非同期の為、見た目わかりやすい「非同期」が用語として使われることが多い) 何が違うかというと、切り出しの粒度が違う Goroutine含めたマルチスレッドは、I/Oをスレッド内で何度でも処理出来る つまりかなり大きな単位で切り出してる。これは後述するがスイッチングコストの問題もあるから これに対し、JSが求めたI/O分離は、各I/O毎に一つとする最小粒度でasyncに切り出し、 ただこれだけで十分だ、これ以外は切り出す必要もない、というわけ (だから切り出し粒度の面でもそれまでのマルチスレッドからすると異端) http://mevius.5ch.net/test/read.cgi/tech/1645915400/939
940: デフォルトの名無しさん [sage] 2025/05/19(月) 09:26:28.98 ID:8khPYfEx もう一度整理すると、 他言語「全然処理能力が足りない！もっとCPUを寄越せ！！くらえマルチスレッド昇竜拳！！！」 JS「いや書き方変えてI/Oを分離すれば、実はCPUなんて一つで足りてる」で、 GreeJS「ボクはマルチスレッドの倒し方、知ってますよ？」てなところだ 実際JSの性能が良かったから、他言語はJSを参考にI/Oを非同期化するための文法を導入『せざるを得なく』なった というのを885で書いたつもり(まあどうしても「非同期」が目立つが) 駄目押しで言っておくと、 「非同期」で書いた方がパフォーマンスが出てしまったから、C#含め各言語は「非同期」文法を導入『せざるを得なく』なった そしてこれを世に知らしめたのがJSで、結果、JSはプログラミング言語全体をリードする形になり、蔓延る事になってる 逆に言えば、2000年頃にC#がasyncを導入してたら、今頃C#はJSを超えるシェアだっただろうし、 同様に、GoがJSと同時期(1995)に発表され、Goroutineで『I/Oを』分離する、というコンセプトだったら、GoもJS程度には普及してたはず つまりJSはその当時、誰も思っていなかった「金脈」を掘り当てた結果、報酬として蔓延る事になった、とも言える http://mevius.5ch.net/test/read.cgi/tech/1645915400/940
941: デフォルトの名無しさん [sage] 2025/05/19(月) 09:27:03.65 ID:8khPYfEx でまあ、889のリンク先読んだが、その筆者やお前がasync大嫌いなのは分かった そしてその中でも言及されてるが、実際の所、I/OはOS内でasyncになってるから、 同期APIしか使ってないマルチスレッドでも自動的にasyncになるのは事実だ ただ、OSレベルではなく、プログラミング言語レベルでasyncにしてしまえば、 パフォーマンスでぶち抜ける事をJSが発見してしまった 実際何が違うの？といわれれば、スタック含めたコンテキストスイッチングが最小に押さえられ、 スタックも浅く小さく抑えられるのでキャッシュヒット率が上がる、程度のはずだが、 結局の所はこれが無視出来ないからパフォーマンスが出てしまってる つまり、 他言語「OSでasyncになってるからヨシッ！」 JS「いやコンテキストスイッチングをゼロにしてキャッシュヒット率上げれば全然行けるで！！！お前らまるで見えてねえな」 でJSが正しかったから、JSモドキなコンセプトをasync文法として採用『せざるを得ない』状況になってるわけ ただしこれが良いか悪いかは確かに微妙である その筆者は「色が付いて(＝同期関数か非同期関数か分からないので)使いにくい」というわけだが、 これはその筆者がJSを知らないだけで、JSはI/Oが非同期になってるだけなので、関数名見れば分かる(ように作る) ただ、I/Oが全部非同期で強制なら、理屈的には、(プログラマによる明示的な記述無しで)全自動で非同期に出来るはず これに近い事をコンパイラにやらせているのがC#だし、generator(コルーチン)な実装にすりゃ出来るだろというのもその通り 明示的にプログラマにI/O分離させた結果、同期よりは見にくいソースコードとなるのは事実 自動化出来てればもっと上ではある (そして他言語はOSで十分に自動async化出来てると勘違いしてたのをJSが指摘した形になる) http://mevius.5ch.net/test/read.cgi/tech/1645915400/941
942: デフォルトの名無しさん [sage] 2025/05/19(月) 09:27:53.50 ID:8khPYfEx だからGoが普及する為には、JS同様に何かしら「金脈」を掘り当てる必要がある それが出来てないから今がある Goの場合の想定「金脈」はGoroutine、 Java流に言えば、"Write once, perform anywhere"(一度書けばどこでも最大性能)だが、 実際の所はGoroutineのスイッチングコスト(とチャネルの通信コスト？)が高すぎて、最小粒度ではパフォーマンスがまるで出ない 逆にこれが出来てるのはGPU/CUDAであり、同じゲームプログラム(シェーダープログラム)で、 それぞれのハードウェアでの最大性能が出る だからベンチでGPU毎のfpsがずらりと綺麗に並ぶ事になる 敗因は何か？と考えると、 ・JS以外の他言語と同様、スイッチングコストを甘く見すぎ ・スイッチングコストを下げる努力をしてない、というよりプログラマ側の努力で下げられない (当然だが同一/最小粒度のままで。粒度を上げてスイッチングコストを下げるのは本末転倒) かと。逆にJSは ・プログラマに強制的にI/O非同期化の努力をさせ、スイッチングコストゼロを目指す というコンセプトが当たったから今がある http://mevius.5ch.net/test/read.cgi/tech/1645915400/942
943: デフォルトの名無しさん [sage] 2025/05/19(月) 09:28:31.40 ID:8khPYfEx > Goは「普通の関数をそのまま並行に動かせる」感じなので、その手軽さが好まれてると思う (989) > CPUバウンドな計算には向かないけど、IO中心のタスクなら十分に良い性能にはなるので さらに駄目押ししておくと、I/OバウンドならPythonやPHPでも問題ない だから問題なのはCPUバウンドの場合だが、 JSは「お前らがCPUバウンドと勘違いしてるのは、実はスイッチングコストバウンドだ。本当のCPUバウンドはまだ先にある！！！」として 『手動で』I/Oを非同期分離する事をプログラマに要求し、 (実際ウザイのも確かだが)やってみると確かにパフォーマンスが出るので、 他言語も同様の仕組みを導入『せざるを得なく』なった もしGoroutineが本当に素晴らしければ、他言語も同様の仕組み、 つまりマルチスレッドをもっとお手軽に記述出来る文法を導入せざるを得なくなる ただ、そうではなかったので、そうなってない つまり、他言語から見て、Goroutineは真似る価値もない そしておそらく > 「普通の関数をそのまま並行に動かせる」 これが駄目なんだよ GPUはスイッチングコストがゼロになるようにハードウェアが作られているが、それでもプログラムにはだいぶ制限がある メチャメチャざっくり言うと、通常はとりあえず1024スレッドを目指すので、レジスタは64本に制限される なおスタックは元々無い。だからx86CPU(レジスタ8本)だとイメージとしては ・スレッド当たりのスタックは224Bytes(=56*4) となる。勿論、スタックを消費するタイプの再帰は出来ないし、コード上の変数の数も制限される(≒最大63変数、1本はPCなので) 対してGoroutineには何の制限も無いだろ そりゃスタックも大きくなるしスイッチングコストも結果的に上がる (＝キャッシュヒット率が下がる。まあGPUにはCPU的文脈のキャッシュもないが) http://mevius.5ch.net/test/read.cgi/tech/1645915400/943
944: デフォルトの名無しさん [sage] 2025/05/19(月) 09:29:12.15 ID:8khPYfEx だから今すぐ出来る対策は、Goroutineのスタックサイズ制限でのスイッチングコスト低減だろうよ コンパイラで各Goroutine毎の最大スタックサイズを静的に解析し、そのサイズに固定する 静的にスタックサイズを確定出来ないGoroutineのコードは、落とす(＝エラーとしてプログラマに書き直させる)、とかだね (GPUは既にこうなってる《はず》) とりあえずGPUでは"Write once, perform anywhere"出来てるのだから、 ・依存性がない最小単位でGoroutineに分離/分割し ・スイッチングコストをゼロに出来れば 行けるはず。ただ、Goはこのどちらもやろうとしてないよね これも駄目押ししとくと、 Go「グリーンスレッドだから軽い」 GPU/CUDA「Goroutineなんて贅肉多すぎのデブスレッド。本当のマルチスレッドを見せてやんよ」 てなところかと http://mevius.5ch.net/test/read.cgi/tech/1645915400/944
945: デフォルトの名無しさん [] 2025/05/19(月) 10:09:21.10 ID:JmTSINZF >>926 このC#コードを実行してみろ、無能屑 3秒じゃなくて2秒で終わるんだが Go でも go つけたらそうなる、Rustでも触ってないがそうだろう 平然とデマ広げてマウント取るの滑稽だからやめたほうがいいよ Stopwatch sw = new(); sw.Start(); var a = Task.Delay(1000); var b = Task.Delay(2000); await a; await b; sw.Stop(); // Elapsed: 00:00:02.0083451 Console.WriteLine($"Elapsed: {sw.Elapsed}"); http://mevius.5ch.net/test/read.cgi/tech/1645915400/945
946: デフォルトの名無しさん [] 2025/05/19(月) 10:23:40.26 ID:JmTSINZF 非同期APIを流行らしたのは JSじゃなくて nginx だから Node.jsが出たのは2009で、Go も2009、nginxは2004だ あたかもJSやNode.jsが非同期を発明したかのように語るのやめろ、流行らしたのは事実だが あとGoよりシングルスレッドの方のNode.jsの方がパフォーマンス出るとか言ってるのはお前だけだから、ソースを出せ GPU/CUDAで行われる並列処理は Webで行われる並行並列とか全く異なるし、無能が長文書くの誰も読まないからやめたほうがいいと思うよ http://mevius.5ch.net/test/read.cgi/tech/1645915400/946
947: デフォルトの名無しさん [] 2025/05/19(月) 11:22:21.24 ID:XkyvQnVv 非同期が流行ったのはWin32のIOCPからじゃないかな Windowsのマナーでは、1990年代から非同期が当たり前だったよ http://mevius.5ch.net/test/read.cgi/tech/1645915400/947
948: デフォルトの名無しさん [sage] 2025/05/19(月) 11:29:25.21 ID:SYizIHd9 Goroutineみたいなマルチスレッドをブラウザ上でJavascriptで使うにはWeb Workerを使う チャネルに相当するのはpostMessage http://mevius.5ch.net/test/read.cgi/tech/1645915400/948
949: デフォルトの名無しさん [sage] 2025/05/19(月) 12:25:32.76 ID:CwlN/9w+ Linuxのカーネル内では最初から非同期だよ。流行りもなにも非同期しかない http://mevius.5ch.net/test/read.cgi/tech/1645915400/949
950: デフォルトの名無しさん [sage] 2025/05/19(月) 14:06:50.34 ID:ePBLToOQ >>945 それは あんたの認識不足だな C#ではそのようにTaskを起動してようやく2秒を実現 Goでもgoでgoroutineを起動しでようやく2秒を実現 JavaScriptでは関数を呼び出すだけで2秒を実現できている この差が非同期が前提であるJavaScriptの実力だ http://mevius.5ch.net/test/read.cgi/tech/1645915400/950
951: デフォルトの名無しさん [] 2025/05/19(月) 14:11:01.04 ID:XkyvQnVv 非同期と並列実行は無関係だけどな http://mevius.5ch.net/test/read.cgi/tech/1645915400/951
952: デフォルトの名無しさん [sage] 2025/05/19(月) 14:13:24.79 ID:vceEd9JD 職場で浮いてるかブリリアントジャークとして大活躍しとるんか http://mevius.5ch.net/test/read.cgi/tech/1645915400/952
953: デフォルトの名無しさん [sage] 2025/05/19(月) 14:19:01.58 ID:ePBLToOQ >>946 JavaScriptは1995年からあり非同期で動いている 象徴的なXMLHttpRequestはIEで1999年からMozillaで翌年 念のため説明すると外部のサーバーからHTTPでデータを非同期に送受信できる シングルスレッドでユーザーインターフェースの処理などをしながらサーバー群と通信しデータを処理し表示することを非同期に行える http://mevius.5ch.net/test/read.cgi/tech/1645915400/953
954: デフォルトの名無しさん [sage] 2025/05/19(月) 14:21:16.24 ID:ePBLToOQ >>951 並列ではなく並行な この2つを区別できないのはヤバいぞ JavaScriptはシングルスレッドで非同期に並行処理が基本機能として備わっている http://mevius.5ch.net/test/read.cgi/tech/1645915400/954
955: デフォルトの名無しさん [sage] 2025/05/19(月) 14:33:46.83 ID:vceEd9JD ここは30代が50代園児に非同期を語るスレです http://mevius.5ch.net/test/read.cgi/tech/1645915400/955
956: デフォルトの名無しさん [sage] 2025/05/19(月) 15:00:01.58 ID:3L8OUWa4 >>950 お前底無しの馬鹿だろw http://mevius.5ch.net/test/read.cgi/tech/1645915400/956
957: デフォルトの名無しさん [sage] 2025/05/19(月) 15:19:35.67 ID:ePBLToOQ >>956 技術的に反論できないの？ 非同期並行が本質的に備わっているJavaScriptと他の言語との違いを理解しよう http://mevius.5ch.net/test/read.cgi/tech/1645915400/957
958: デフォルトの名無しさん [sage] 2025/05/19(月) 15:43:40.54 ID:SYizIHd9 node.jsはグローバル変数がリクエスト間で共有される 書き方として楽なのはもちろん同期コストもかからない http://mevius.5ch.net/test/read.cgi/tech/1645915400/958
959: デフォルトの名無しさん [] 2025/05/19(月) 15:57:08.17 ID:JmTSINZF >>953 webサーバとして流行ったのは 2009年の Node.js だボケ、かなり最近の話じゃねーか 非同期APIってのはクライアント側のブラウザを指してねーわボケ >>950 C#のTaskとJSのPromiseは同じ表現だボケ > JavaScriptでは関数を呼び出すだけで2秒を実現できている C# はTask.Delay 関数呼び出すだけだが、JSとかいうゴミは new Promise(resolve => setTimeout(resolve, ms) とかいうゴミコード書いてるじゃねーか どこが関数呼び出すだけなんだ？ C# は ネイティブスレッドモデルだから Task.Delay と Thread.Sleep の使い分けができるが JSはできないけど、これはデメリットでもあるぞ C#の方がネイティブスレッドを扱える分、汎用的に様々なアプリを作れるのに向いているということだ JSは前提としてIOが絡むものじゃないと向いていないゴミなわけだ よってデスクトップやらモバイルで使う言語じゃねーんだわ、頼むからブラウザ以外で使おうとするのやめろゴミども http://mevius.5ch.net/test/read.cgi/tech/1645915400/959
960: デフォルトの名無しさん [sage] 2025/05/19(月) 16:08:08.14 ID:uNJYr9YV >>958 それはJavaScriptの性質 node.jsはブラウザの外に出したことでようやく普通の言語と同様にローカルファイルアクセスやサーバー化ができるようになったことが本質 元々JavaScriptには非同期並行が前提の性質があるため node.jsとなったことでその効率と利便性の良さをサーバーサイドでも発揮した ただしシングルスレッドの限界があり別スレッドはWorkerという分離でダサい マルチコアをN:Mモデルで透過的に活かせるGoやRustに利がある http://mevius.5ch.net/test/read.cgi/tech/1645915400/960
961: デフォルトの名無しさん [sage] 2025/05/19(月) 16:35:28.76 ID:NvwVFQDL Goスレが糞言語の話題で埋まるのは偲び無い http://mevius.5ch.net/test/read.cgi/tech/1645915400/961
962: デフォルトの名無しさん [sage] 2025/05/19(月) 20:33:15.49 ID:60+8EMpP >>773を書いたのは自分だけど 別の言語の話題で盛り上がるスレになってしまったようだ http://mevius.5ch.net/test/read.cgi/tech/1645915400/962
963: デフォルトの名無しさん [sage] 2025/05/19(月) 20:41:50.05 ID:cWzC7L5F nodeなんてExceptionキャッチ出来てなくてクソアプリ量産だよ Goがいいいよ http://mevius.5ch.net/test/read.cgi/tech/1645915400/963
964: デフォルトの名無しさん [sage] 2025/05/19(月) 22:09:44.38 ID:ohfptUI9 >>961 まったくだ http://mevius.5ch.net/test/read.cgi/tech/1645915400/964
965: デフォルトの名無しさん [sage] 2025/05/19(月) 23:46:27.40 ID:8khPYfEx >>946 > あとGoよりシングルスレッドの方のNode.jsの方がパフォーマンス出るとか言ってるのはお前だけだから、ソースを出せ お前は現実を直視しろ (ちなみに俺が言ってるのは個々のフレームワークやバイナリの話ではなく、モデルの話だ) しつこいようだが纏めると、 従来型のマルチスレッド： スレッド間：シグナル、ロック、通信 スレット内：同期APIを使う。I/OはOSレベルで自動的に非同期 起動単位：JOB単位（＝JOB毎に1スレッド) アクティブスレッド数：CPUと同数以上 狙い：多数のスレッドで性能を上げる Go型のマルチスレッド：(＝従来型の発展型) スレッド間：通信 スレット内：同期APIを使う。I/OはOSレベルで自動的に非同期(なおGoroutineで非同期にも書けるからasync文法は必要ない) 起動単位：JOB単位、またはもっと小さく、データフロー単位（＝1つのJOBを多数のGoroutineに分割) アクティブスレッド数：CPUの数倍以上 狙い：かなり多数のスレッドでさらに性能を上げる JS型のマルチスレッド：(＝アンチマルチスレッド) (スレッド間：通信) スレッド内：非同期APIを使い、プログラマが手動でI/Oを非同期化 起動単位：全部(またはできるだけ多数)のJOBを一つのスレッドで処理する アクティブスレッド数：出来れば１、または最小 狙い：マルチスレッドにおけるオーバーヘッドを無くすため、「出来るだけ少ないスレッド」に集約する http://mevius.5ch.net/test/read.cgi/tech/1645915400/965
966: デフォルトの名無しさん [sage] 2025/05/19(月) 23:46:56.13 ID:8khPYfEx で、従来型よりJS型の方がパフォーマンスが出ることが分かってしまったから、あらゆる言語がasyncを慌てて導入することになってる だからasyncを導入した言語は、自ら敗北を認めてる ただまあ、確かにGoはこの意味では負けを認めていないな とはいえ、「出来るだけ少ないスレッド」という、マルチスレッドを根本から否定するJS型が勝ってしまった意味は大きい そしてGo型は従来型をさらに発展させたものなのだから、お前らに危機感がないのはだいぶ狂ってる この意味でなら、Goは負けを認めず、負け筋に乗り続けてるだけ (だから今後共負け続ける) Go型でJS型に勝つためには、スレッドスイッチのコストを最小化することが必要だが、Goはこれをやろうともしてない だから、Goに勝ち筋は今の所無い http://mevius.5ch.net/test/read.cgi/tech/1645915400/966
967: デフォルトの名無しさん [sage] 2025/05/19(月) 23:58:00.24 ID:+dWR/SKT Goroutineが重いプリエンプティブを選んだのはなぜだろうね マルチユーザのマルチタスクなら強制的にプリエンプションせざるを得ないけど自分たちでコードを書くのだから協調スケジューリングで十分なはず 結果多くのコンテキスト切り替えスイッチングも重くスタックレスにも出来ず http://mevius.5ch.net/test/read.cgi/tech/1645915400/967
968: デフォルトの名無しさん [] 2025/05/20(火) 00:21:14.96 ID:sg7u1BbS シングルスレッドのRedisに限界があるから Dragonfly や Garnet が出てきているのに何言ってんんだこいつ Goがそもそもグリーンスレッドモデルってことを全く理解してなさそうｗ Goが「スレット内：同期APIを使う」ってなに？ｗ Time.Sleepするとスレッドがブロックされるのか？同期APIじゃないからｗ JSだろうがGoだろうが非同期モデルを採用しているのだから最終的にepoll, kqueue, IOPCを使って処理されてるだけで、goroutineだのasync/awaitだのは単なるユーザコードの書き方の違いにすぎない Goのgoroutineのスイッチングコストなんて全く大したことがない、goroutineの切り替えはユーザモードで行われる & スタックポインタとg構造体のポインタを書き換えるだけで数命令で完了する非常に軽量な処理 その差よりマルチコア使えるかの要素の違いの方がパフォーマンス上よっぽど重要かつ支配的 JSが流行ったのは単なるブラウザで動く初心者言語なだけだし 非同期モデルを流行らせたのは Node.jsじゃなく apache -> nginxの10K問題解消の系譜だ 統合失調症に近いなお前、すべて「わかった」気になってるけどれはお前の脳内の中だけの話 C#にしかりGoにしかりGoogleやMicrosoft が全世界から優秀なエンジニアを集めて言語＆ランタイムを設計、開発させてるから お前みたいな糖質が問題提起する内容などそもそも問題がないように設計されてるのよ http://mevius.5ch.net/test/read.cgi/tech/1645915400/968
969: デフォルトの名無しさん [] 2025/05/20(火) 01:00:38.79 ID:8PwvoTt0 ユーザ多いJavaもGoと同じくグリーンスレッドモデルだけどw Kotlinもコルーチンでグリーンスレッドモデルだね どの言語もJSのやり方とは別のアプローチでC10K問題を解消してるだけですよねw Goのgoroutineだけ否定する理由を全く論理的に説明できてないですねw goroutineのスイッチングコストが高いと勘違いしているようだけど数個のレジスタを書き換えるだけで非常に高速に行われるはずだけどw 君のスイッチングコストが高いという主張を裏付ける記事やベンチマークを貼った方がいいんじゃない？ http://mevius.5ch.net/test/read.cgi/tech/1645915400/969
970: デフォルトの名無しさん [sage] 2025/05/20(火) 01:31:58.27 ID:ZTQVFMJe 50代園児達は厳しいのだ http://mevius.5ch.net/test/read.cgi/tech/1645915400/970
971: デフォルトの名無しさん [sage] 2025/05/20(火) 02:25:32.98 ID:q97OvMDE 大量の非同期タスクで最も性能が出るのはRustで決着がついている CDNシェア世界トップのCloudflareも従来のnginxを捨ててRust製に変更して性能を大幅に高めている 先日githubにRustソースコードも公開された 以下はそのまえの記事 Cloudflare、NGINXに代えて自社開発のRust製HTTPプロキシ「Pingora」をグローバルCDNに採用。性能向上しつつCPUとメモリ消費を3分の1に https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、 同社自身がRust製のHTTPプロキシである「Pingora」を開発し利用していることを明らかにしました。 Pingoraはすでに同社のCDNに採用され、毎日1兆回以上のリクエストを処理し、性能向上や数多くの新機能の提供を実現しつつ、従来と比較してCPUとメモリリソースの消費はいずれも3分の1程度に収まっているとのこと。 http://mevius.5ch.net/test/read.cgi/tech/1645915400/971
972: デフォルトの名無しさん [sage] 2025/05/20(火) 02:44:02.44 ID:Wybyn9P/ Perlに依存してるｗｗｗ http://mevius.5ch.net/test/read.cgi/tech/1645915400/972
973: デフォルトの名無しさん [sage] 2025/05/20(火) 08:09:09.31 ID:bVe5xETf >>971 それいつもの再設計で良くなったパターンじゃなくて？ http://mevius.5ch.net/test/read.cgi/tech/1645915400/973
974: デフォルトの名無しさん [sage] 2025/05/20(火) 08:14:17.18 ID:ZTQVFMJe 機能は絞ってるんだろうな http://mevius.5ch.net/test/read.cgi/tech/1645915400/974
975: デフォルトの名無しさん [sage] 2025/05/20(火) 08:22:55.01 ID:Gk4G5H2z >>971 最速と言われてきたNGINXの3倍速かよ http://mevius.5ch.net/test/read.cgi/tech/1645915400/975
976: デフォルトの名無しさん [sage] 2025/05/20(火) 10:42:26.74 ID:SbcnGbeK 原文読んだけど https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/ - コネクションプール戦略の改善により遅延を削減できた - NginxのLuaモジュールをRustに置き換えたことでCPUとメモリの使用量を削減できた Rustだからというよりアーキテクチャの改善と汎用性や柔軟性を犠牲にした最適化でパフォーマンスを改善したってことだ 全体として原文はRust最強みたいな変な誤解をされないように注意深く書かれているから、ちゃんとその辺りを理解してあげないと失礼 http://mevius.5ch.net/test/read.cgi/tech/1645915400/976
977: デフォルトの名無しさん [sage] 2025/05/20(火) 11:16:09.13 ID:Y8vT9Doa 遅いGoやC#などで作っても勝てないし C/C++で非同期プログラミングは未だに様々な問題を抱えていて不利なので 速さも環境も整っているRust一択になっている状況 http://mevius.5ch.net/test/read.cgi/tech/1645915400/977
978: デフォルトの名無しさん [] 2025/05/20(火) 17:31:30.72 ID:qgCJRvxW クラウドフレアはFPGAを使うべきでは？ LuaスクリプトよりRustのほうが速いという主張も良くわかりませんでした それは当たり前では？ http://mevius.5ch.net/test/read.cgi/tech/1645915400/978
979: デフォルトの名無しさん [sage] 2025/05/20(火) 22:34:48.64 ID:vbQ41r/k >>967 単純に、「重い」と認識できてない馬鹿と、分かってても変更しない意識高い系馬鹿の合わせ技でしょ 1995時点で「お前らのマルチスレッドはスイッチングが重すぎてまるで機能していない」と看破できたのはJSだけ 大半の言語はこれを認め、JSと同様に「手動」で軽量化も可能なよう、async文法を導入した ただし実際、手間が増えてるのと、将来的にOSレベルでのスイッチングが軽くなった場合に、asyncで書かれたコードはゴミになる だから「抽象度が高い状態で書きたいのだ！！！」「OSで『自動』的にやらせたほうがコード資産の価値は高いのだ！！！」という言い訳はできる (問題は軽くなる予定が全く無いことだが) この意味では、「asyncが必要なのではなく、OSがポンコツすぎるのだ！！！」と責任転嫁することも出来るはずだが、 誰もやらないところを見ると、OSは限界までは軽いんだろうな そして逆に、アプリ側でasync必須でスケジューラも持ってれば、OS側で持ってるのは無駄なので削除して軽量化することは出来る chromiumOSが奇妙に軽いのはこの辺かもな(＝JS専用OS) http://mevius.5ch.net/test/read.cgi/tech/1645915400/979
980: デフォルトの名無しさん [sage] 2025/05/20(火) 22:35:11.14 ID:vbQ41r/k > プリエンプティブ > 協調スケジューリング 改めて考えてみたが、「同期APIを使える」くらいしか利点を思いつかない 協調スケジューリングの場合は「非同期API強制」となるからね JSは2013年頃でも「SLEEPは？」とか言われてたし、889のような馬鹿げたブログ(2015)を書くやつも居るしで、 非同期アレルギーはそうならなかったやつの想定以上に激しいのかもしれん (俺に言わせれば、SLEEPは別の書き方があるからそれでいい、Promiseはゴミ、コールバック地獄になるのは腕前の問題、 この辺JSは全関数がクロージャなのだから適当に関数ぶった切って書き、コールグラフを整理すれば回避出来る、となるが) そして出自がJSというのも当たりは悪い フニャフニャ文法、階層が関数、専用構文とprivateのないオブジェクト指向、 ダックタイピング、動的に変化するthis、他型のメソッドも使える、で、 正統派オブジェクト指向のC++/Java/C#勢からすれば十分異端すぎるのに、更に、非同期、イベントドリブン、だからね JSモデルが想定以上に速かったから、他言語開発者はJSを研究せざるを得ず、 何じゃあこれはーーー！！！となるのは分かる(＝JSアレルギーの発症 俺の場合は、え？こんなので大丈夫なのか？→あれ？意外と問題ねえな→実は他言語が無駄に冗長過ぎただけでは…、となったが) まあブレンダン・アイクは本当に上手く攻略したな、とは思うよ とはいえ、『同速なら』同期APIのコードの方がマシなのは事実だから、 同期API派はさっさと同速になる方向の努力をすべきだと思うがな http://mevius.5ch.net/test/read.cgi/tech/1645915400/980
981: デフォルトの名無しさん [sage] 2025/05/20(火) 22:36:05.33 ID:vbQ41r/k >>976 > skipping TCP and TLS handshakes required on a new connection. いやこれってありなんか？とは思ったが、GETならどうせ同じ(はず)だからいいのか？ となると、リバースプロキシって、誰かの操作を横から盗み見してる感じになるのか？ > 原文はRust最強みたいな変な誤解をされないように注意深く書かれている 信者が発狂するからといってオブラートに包みすぎ。原文は以下 > This is not because we run code faster. まあCと比べればRustも遅いから、これはどうにもならんが http://mevius.5ch.net/test/read.cgi/tech/1645915400/981
982: デフォルトの名無しさん [sage] 2025/05/20(火) 22:43:28.20 ID:5IEvPsHE Rustスレでやろうぜ http://mevius.5ch.net/test/read.cgi/tech/1645915400/982
983: デフォルトの名無しさん [sage] 2025/05/20(火) 22:44:31.07 ID:5IEvPsHE GoクンのHPはもうカツカツよ🥺 http://mevius.5ch.net/test/read.cgi/tech/1645915400/983
984: デフォルトの名無しさん [sage] 2025/05/20(火) 23:12:32.78 ID:C5OyrGcX 次スレ Go language part 6 https://mevius.5ch.net/test/read.cgi/tech/1747750228/ http://mevius.5ch.net/test/read.cgi/tech/1645915400/984
985: デフォルトの名無しさん [sage] 2025/05/20(火) 23:47:56.43 ID:MuN0b/Nd >>981 一般的なリバースプロキシじゃなくて、あくまでCDNだからね 基本的に全部パブリックリソースのGETだし、どのみちオリジンサーバーから見ればCDNからのリクエストだから一緒 http://mevius.5ch.net/test/read.cgi/tech/1645915400/985
986: デフォルトの名無しさん [sage] 2025/05/21(水) 10:46:48.11 ID:va6/rMba MITM http://mevius.5ch.net/test/read.cgi/tech/1645915400/986
987: デフォルトの名無しさん [] 2025/05/28(水) 04:53:46.40 ID:TwWA6F4N つるつるわれめ http://mevius.5ch.net/test/read.cgi/tech/1645915400/987
988: デフォルトの名無しさん [] 2025/05/30(金) 13:31:36.30 ID:XWQpoVmB 梅八日 http://mevius.5ch.net/test/read.cgi/tech/1645915400/988
989: デフォルトの名無しさん [sage] 2025/06/02(月) 21:47:55.19 ID:wcsvfY5O 適当なんだけどこれであってる？ 肯定/訂正してくれたら嬉しい 1. ローカル変数(sliceはそのヘッド)はescape analysisでスタックやレジスタ割り当て 2. ヒープの頻繁確保解放は総量上限が分かるならプール 3. ロジック的に寿命が長いやつはそもそもGC影響は軽微 http://mevius.5ch.net/test/read.cgi/tech/1645915400/989
990: デフォルトの名無しさん [sage] 2025/06/02(月) 21:51:04.00 ID:wcsvfY5O 配列/スライスの添え字アクセスは境界チェックされる http://mevius.5ch.net/test/read.cgi/tech/1645915400/990
991: デフォルトの名無しさん [sage] 2025/06/02(月) 21:52:50.52 ID:wcsvfY5O dangling pointerは発生しない http://mevius.5ch.net/test/read.cgi/tech/1645915400/991
992: デフォルトの名無しさん [sage] 2025/06/05(木) 21:11:14.75 ID:ZsUexMhd Go言語がエラー処理構文の導入を「一旦諦める」と宣言 — 7年にわたる検討の末コンセンサス得られず https://techfeed.io/entries/6840c4096749026b87829bb9 http://mevius.5ch.net/test/read.cgi/tech/1645915400/992
993: デフォルトの名無しさん [sage] 2025/06/05(木) 21:36:51.37 ID:YBXwJM9k 今のままでいいぞ。例外処理はワイには100年早い http://mevius.5ch.net/test/read.cgi/tech/1645915400/993
994: デフォルトの名無しさん [sage] 2025/06/05(木) 23:37:51.96 ID:Hk1mFN4z >>992 (他言語含めて)前から思ってるんだけど、コードは縦に書くもの(＝改行するもの)だと洗脳されてるよな 読みたくないコードはアナログに右に書けばだいたい解決する 今更「一行は80文字まで」等の化石コーディングルールを脳死で守ってるなら尚更 func printSum(a, b string) error { x, err := strconv.Atoi(a); if err != nil {return err} y, err := strconv.Atoi(b); if err != nil {return err} fmt.Println("result:", x+y) return nil } これでスッキリだろ 生理的に許せんならフォーマッタ使えで終わるし(逆も然りだが) http://mevius.5ch.net/test/read.cgi/tech/1645915400/994
995: デフォルトの名無しさん [sage] 2025/06/06(金) 00:36:59.99 ID:pqJl8iQF printしてpanicしてエラースッキリ http://mevius.5ch.net/test/read.cgi/tech/1645915400/995
996: デフォルトの名無しさん [sage] 2025/06/06(金) 00:55:09.52 ID:56KGrjta >>994 フォーマット以前にサンプルとはいえそんなクソコードを書くやつのほうが生理的に許せんわ http://mevius.5ch.net/test/read.cgi/tech/1645915400/996
997: デフォルトの名無しさん [sage] 2025/06/06(金) 00:56:27.07 ID:MkNISVMm go lint http://mevius.5ch.net/test/read.cgi/tech/1645915400/997
998: デフォルトの名無しさん [sage] 2025/06/06(金) 01:10:46.44 ID:7Uf7u6qh >>996 それは俺も思ったが、ここで言う意味もあるまい (もし俺がサンプルを作ったと勘違いしてるのなら、リンク先確認しろ) http://mevius.5ch.net/test/read.cgi/tech/1645915400/998
999: デフォルトの名無しさん [sage] 2025/06/06(金) 10:14:03.88 ID:EuijCvJq IDEに見た目の折りたたみさせればよくね http://mevius.5ch.net/test/read.cgi/tech/1645915400/999
1000: デフォルトの名無しさん [] 2025/06/08(日) 09:10:52.84 ID:nTaYMW6S 質問いいですか？ http://mevius.5ch.net/test/read.cgi/tech/1645915400/1000
1001: 1001 [] ID:Thread このスレッドは１０００を超えました。 新しいスレッドを立ててください。 life time: 1197日 1時間 27分 33秒 http://mevius.5ch.net/test/read.cgi/tech/1645915400/1001
1002: 1002 [] ID:Thread 5ちゃんねるの運営はUPLIFT会員の皆さまに支えられています。 運営にご協力お願いいたします。 ─────────────────── 《UPLIFT会員の主な特典》 ★ 5ちゃんねる専用ブラウザからの広告除去 ★ 5ちゃんねるの過去ログを取得 ★ 書き込み規制の緩和 ─────────────────── 会員登録には個人情報は一切必要ありません。 4 USD/mon. から匿名でご購入いただけます。 ▼ UPLIFT会員登録はこちら ▼ https://uplift.5ch.net/ ▼ UPLIFTログインはこちら ▼ https://uplift.5ch.net/login http://mevius.5ch.net/test/read.cgi/tech/1645915400/1002
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.019s