Go language part 5

**デフォルトの名無しさん** · 2022/02/27(日) 07:43:20.04

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/

**デフォルトの名無しさん** · 2025/05/17(土) 22:53:10.81

>>874
CはCPUが遅かった時代だから余分な事を一切しないだけで、信用と言うよりは放任
なのでプログラマ間で信用出来ないコードをrejectする事が必要になる

> そもそもCの置き換えを目指すような低レイヤーを扱う言語じゃないので (>>874)
> 一応Java対抗よね。Oracleで混迷してるし、あってよかったと思うわ (>>875)
いや当初はシステムレベルも記述可能と謳ってたはず
実際、出来るとは思うし
(とはいえCの方がいいのでほぼ誰もしてないが、Dockerはシステムレベルとも言える気が)

Java対抗なんて初耳だが、最近は看板掛け替えたのか？
Javaとダダ被りなのはC#のはずだが
Java＋ナマポ＝ Go になるのか？バイナリではあるが、最近なら問題にならないだろうし
ただJava案件をGoで書き換える、なんてのは聞いた事無いが

**デフォルトの名無しさん** · 2025/05/18(日) 00:19:36.18

GoogleがC++とJava使ってるっぽいからそれの代替用途でしょ
Cの代替ではない、あくまでも高級言語

**デフォルトの名無しさん** · 2025/05/18(日) 00:24:42.72

>>876
低レイヤーという意味でのBetter Cになるのは多分Zig (まだver.1未満だけど)
Goが使われるのはCLIやWebのバックエンドなので、CよりかはJavaやC#のレベルだと思う
GCがある以上、例えばLinuxカーネルのようなシステムプログラミングの領域を置き換えるのは正直無理

> Java＋ナマポ＝ Go になるのか？
Goらしさとして必要なのはポインタでなくGoroutineだと思う
並行処理を比較的簡単に書けるのがバックエンドの要件に合ってるから流行った感じなので

> ただJava案件をGoで書き換える、なんてのは聞いた事無いが
現在Javaでやってる案件はそのままJavaを使うんじゃない？
置き換えはそもそもリスクが大きいので (規模が大きいと特に)
仮に置き換えるとしても、同じJVMで動くKotlinという選択肢もあるし

**デフォルトの名無しさん** · 2025/05/18(日) 00:43:52.11

>>876
Goの開発当初Javaはなかったので、Google社内でもGC付きの言語を開発しはじめた。などという開発秘話を読んだことあるよ

**デフォルトの名無しさん** · 2025/05/18(日) 00:46:18.40

たまたまGC付きでCより高級で安全だからJavaと守備範囲が被るというだけで、置き換え用で開発していたわけじゃない。

**デフォルトの名無しさん** · 2025/05/18(日) 02:04:06.55

ネイティブスレッドを扱えずにグリーンスレッドモデルの時点でCの代替を想定してなさそうだけども

**デフォルトの名無しさん** · 2025/05/18(日) 11:14:11.80

>>877
GoでC++とJavaをリストラする、というのは技術的には面白いと思うが、
Android(Java)とchrome(C++)を抱えているgoogleには現実的に無理だな

>>879
それが本当なら、Java(1995)に対してGo(2009)は出てくるのが遅すぎる
> 後のインタビューで、3人の言語設計者すべてが、新しい言語を設計する主なモチベーションとしてC++が好きでないこと（英語版）を共有していたことを述べている (wiki)
なら、Javaと同時期に出せれば、C++嫌いな奴(＝その時期にJavaを選んだ連中の大半)には受けただろうに

**デフォルトの名無しさん** · 2025/05/18(日) 11:15:06.82

>>878
Zigは全く知らないのでチラ見してみたが、かなりC/C++を意識してるな
流行ってRustが滅んでくれれば俺は万々歳だが

> CよりかはJavaやC#のレベルだと思う
そりゃCよりはな
ただ、フレームワーク前提ではなかった『当初の』Javaは、確かにGoとレベルは被るのかもな
フレームワークが肥大していったJava、フレームワーク前提だったC#と並べれば C << Go <= Java <= C#

Goヨイショ気味の記事を見つけた
元JavaエンジニアがGoに感じた「表現力の低さ」と「開発生産性」の話
https://inside.dmm.com/articles/ex-java-engineer-thoughts-about-go/
> Optionalにはmapやfilter、orElseなどといった、Optionalのままで値を操作できるメソッド群が用意されており、これらを駆使することで、
> nullチェックをせずともnull-safeに処理を書くことができるようになっています。
出発点はおそらく「既存コードを変更無しでnull-safeにする」だったんだろうが、
多分このコンセプトが暴走気味で、余分な知識が必要で生産性を下げている、という例。これがC++/Java/Rustの方向
一方Cは、「null-safeが欲しいのなら毎回nullチェックしろ」であって、これはGoも同じ
言語としての基本的方向が違うから、RustはC++は殺せても、Cは殺せない
GoならCは殺せる可能性があるが、殺す気はないらしい
というより、多分Goは、そんなにCが嫌いではなく、C++が嫌いな人のための言語
(だからGo使いに対してはもっと低レイヤが欲しければC使えで平和に終わる
Rust使いにとってはCの思想は許容できないので喚き散らすことになる)

**デフォルトの名無しさん** · 2025/05/18(日) 11:15:45.42

Java案件は今後共Javaなのは俺も思う
C#のMSベンダロックを嫌ってるらしいが、Oracleロックはいいのか？とも思うが、
発注元が公務員、及び公務員じみた、「僕は悪くないもん！」が確保できればいい連中だけなので、今後共変わらない

だとすると、Goは基本的に置き換えなし、『新規』Web/バックエンド案件しかないが、これも一周気味だし、てなところか
と考えてたら、Rustがウザいのは『既存』案件の置き換えを迫ってくるから『押し売り/ゴリ押し感アリアリ』なところかとも
「間に合ってます」で終わるのに、
トイレでケツをしょっちゅう拭き忘れるガイジ/自分が何故数十年もケツを拭き忘れたことがないのかに思い至らないガイジ、しか居ないので話が通じない
この点、
> プロトタイピング専用言語 (843)
は悪く言われてる感があるが、良く言えば「プロトタイピング＝サラッと書いてサクッと動かすときに生産性が高い」のは利点でもある
(というよりRustはプロトタイピング時に生産性が皆無だから「新規」案件が出来ず、
結果的に「既存置き換え」の清書用言語としてガイジが勧めてくるが、「間に合ってる」連中にとっては糞ウザい)

**デフォルトの名無しさん** · 2025/05/18(日) 11:16:39.56

> 並行処理
wikiも見たがGo界隈では『平』行ではなく『並』行なのか？
まあ俺は一般の平行(coherency:違う処理を同時に行う)と並列(parallelism:同じ処理を同時に行う)を使うことにするが

> Goroutine
JSは、「同期/マルチスレッド」な他言語に対して、「非同期/シングルスレッド」という異端めいた選択が大当たりしたから蔓延ることになった
逆にGoがいまいち蔓延れないのは、Goの売りであるGoroutineがハズレたからだ

各プログラミング言語は、プログラマに何を「明示的に書くか」を要求する
JSは「I/Oを分離」することを要求し、報酬として「シングルスレッド化によりマルチスレッド時の諸問題が消滅する」ことを提示した
「お前のプログラムはすべてI/Oが律速しており、実はCPUなんて一つで足りる」とするJSに対して、
「そんなことはない！！！CPUが一つでは絶対に足りない！！！」と考えた他言語だが、結果はasyncの圧勝で終わった

Goroutineは、プログラマに「データフローの依存関係を明示的に書く」ことを要求する
つまり、平行/並列出来るものはすべてGoroutineとして分離し、大量のスレッドプールでこれを処理すれば、
処理性能は自動的に最大に貼り付き、スケールアウトも自在、というわけだ
このコンセプトはありだろう

**デフォルトの名無しさん** · 2025/05/18(日) 11:17:23.81

ただし現在は、これを処理するハードウェアがない。また、今後とも多分ない
超並列は現状CUDAの圧勝だし、こちらはそもそもハードウェアが起点なので、最初から専用ハードありきで言語も設計されてる
CUDAが出来ない超平行は、本来Goroutineが活躍する分野だが、
言語として本来要求すべきは「最小粒度でGoroutineに分離」で、
それを各処理系にマッチした粒度に『コンパイラが自動で』変更/割当すべきなのに、852内URL読む限りこれが出来てない
プログラマに粒度を調整させてるようでは、「資産」としてのソースコードは劣化する(全ハードウェアで同じソースコードを使えない)のだが、
GoはC側の「それが必要ならそう書け」であって、
C++/Java/Rust側の「コンパイラが自動的に行い、ソースコードからは隠蔽する」ではないのでこれが出来ない
(つまり、根本の思想として矛盾してる)

そして、仮に最小粒度でGoroutine書けたとしても、これを実行する最適なハードウェアは
「I/OはシンプルなFIFOとローカルキャッシュのみ(=グローバルメモリアクセスは出来ない、キャッシュのコヒーレンシは必要ない)、
最小命令セットのCPU」を「出来るだけ沢山」なのだが、
こんなハードウェアを作る予定があるところはない
(Intelはメニーコアをずっとやりたがってるが、フルスペックのx86なんてGoroutineでの超平行には必要ない)

冷静に考えれば、最小粒度の超平行＝ハードウェアであって、
Goroutineで攻め込むべきはVerilog/VHDLの分野なのだが、これをやろうともしてない
(というか、現状、ハードウェアエンジニアとソフトウェアエンジニアは明確に分離されており、やる必要自体がない
IntelがAlteraを買収し、今後はCPUにFPGAが載るのか？と思われたが、結局Xeonの一部に載っただけで頓挫した
まあその製品はネットワーク系ではすごく使えたらしいが)

だから、今後共Goroutineで頭抜けることはない、というより今の所「兆し」がどこにもない
結果、GoはGoroutineが本来提供すべきだった報酬、
「Goroutineに分離すれば自動的に性能は最大になり、スケールアウトも容易」が提示できてないから(圧倒的には)支持されない
一方、async(というコンセプト)でブチ抜いたJSは蔓延った、というだけ
(勿論GoroutineがGoの特徴ではあるが、他言語者がそれを使う理由がない)

**デフォルトの名無しさん** · 2025/05/18(日) 12:49:49.95

Javascriptでフロントエンドプログラム初心者が簡単に使えるから流行っただけ
async/awaitの発祥はC# (F#)だけどGoと同じくマルチスレッド非同期だわ、async awaitがシングルスレッドと勘違いしているようだが元々JSがその仕様だったのをそれにあわせて実装しただけ

JSはC#のasync/awaitをパクった劣化版に過ぎない、標準ライブラリはコールバックでawait使えなかったりキャンセル処理もサポートしてないゴミ

**デフォルトの名無しさん** · 2025/05/18(日) 13:06:33.55

シングルスレッドで十分w
じゃあなんでRedisに対してDragonflyやGarnetが出てきてるんだ？

**デフォルトの名無しさん** · 2025/05/18(日) 13:12:33.86

歴史的に見れば
・PythonやJavaScriptはもともと1スレッドで動く言語だった
・C#においてMスレッドN並列を扱いやすくする仕組みとして async/await ができた
・それが Python や JavaScript にも輸入された　

だからな
JSが勝ったのは、それがブラウザで動く事実上ただ一つの言語だからであって、別にシングルスレッドでの並行処理が良いなんてことはない

処理系がよしなにスレッドを切り替える (async/awaitのように切り替えポイントを明示しない) という点でGoに近いのは Erlang や Elixir あたりかな
理想的にはasyncの方が効率的になり得ると思うけど、これは呼び出し側も含めて async にする必要があるという感染的な性質を持つ
(https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ みたいに、これは「色付きの関数」みたいに言われる)

Goは「普通の関数をそのまま並行に動かせる」感じなので、その手軽さが好まれてると思う
CPUバウンドな計算には向かないけど、IO中心のタスクなら十分に良い性能にはなるので

**デフォルトの名無しさん** · 2025/05/18(日) 13:19:05.01

>>887
プログラミング初心者かよ
コールバックがあればPromise作って返せるからasync/awaitを使える
そういう基本的なことを知らずに批判しているのか？
仕組みを理解せずに表層的にasync/awaitを見てるからそうなる

**デフォルトの名無しさん** · 2025/05/18(日) 13:38:16.33

>>890
だからいちいちコールバック形式の関数をプロミス化するのが面倒だって言ってるんだろ
キャンセル処理すら最近になるまで対応してなかったゴミ、今もまともに扱えない
.NETだったら全部xxxAsyncとxxxの2つが用意されててAsyncには必ずキャンセル用のCancellationTokenを渡せる
Goはcontextを全て渡せる
JSはabortcontrollerはほぼ対応してない、あまりにも終わってるゴミクズ

Node.jsやらDenoとかいうのは最悪の発明だわ、JSをブラウザ以外の環境で流行らした愚行、そんなゴミ言語とか使いたくないんでね
なんでブラウザ以外でjsだのtsだのゴミ言語ランタイム使わないといけねーのw
作者は死んだ方がいいわ

**デフォルトの名無しさん** · 2025/05/18(日) 13:44:45.47

>>890
お前が言ってることはC#でTaskCompletionSourceやTaskFactory.FromAsyncで旧来の非同期処理をTask化してasync awaitで使えるから標準ライブラリは前の型式のままでいいって言ってるようなもん
.NETはちゃんと全ての非同期処理をTask化してるからそのままasync awaitが使えてスムーズ

Node.jsは一度コールバック形式を全てpromiseした後何を血迷ったかまだコールバック形式に戻してその後async/awaitを実装したっていう経緯があるめちゃくちゃランタイムなの知らないんだろうなお前は

結果的に標準ライブラリをそのままスムーズにasync awaitで使えないゴミ環境が出来上がったw

**デフォルトの名無しさん** · 2025/05/18(日) 14:00:53.82

>>891
Promise作るのにどこに面倒があるんだ？
プログラミングしたことがないエアプかよ
自作できないならお子様向けのpromisifyもあるだろ

**デフォルトの名無しさん** · 2025/05/18(日) 14:05:05.90

>>892
呆れた
表層的知識でPromiseの理解と実装をできないからそんな勘違いを犯すんだな
JavaScriptならasync/awaitはPromiseのシンタックスシュガーだ
Promiseを作って返したらそのままasync対応したことになるのが一番の基礎だぞ

**デフォルトの名無しさん** · 2025/05/18(日) 14:27:42.23

>>893
async awaitで使うためにPromiseラップするのもpromify使うのもめんどくさーよ
その例でTaskCompletuonSourceとTaskFactory.FromAsyncを挙げた
ちゃんと読め文盲

仮に面倒じゃないならなぜfsにpromise版があったりhttpリクエストするだけのくせにnode-fetchやらgotやらaxiosやら使ってるんだ？

標準ライブラリでそのままasync awaitが使えないから使ってんだろ、これが完全にお前が間違ってることを証明してるだろ

>>894
だからC#のasync awaitを完全に理解してるから劣化版のJSだって理解してるよ、なんでその程度のこと理解してないと思った？

C#が発祥なんだからどのようにコンパイラがステートマシンに変換しTaskを利用し実装してるか深く理解してるよ
お前はJSがどう内部で変換して利用してるか理解してないんだろ？
promiseに変換する程度の浅い知識じゃなくて深く理解してないだろ

**デフォルトの名無しさん** · 2025/05/18(日) 14:39:10.49

お前みたいに jsだのゴミ言語だけ触って async/await を分かった気になってる知ったかクソ野郎がマウント取るからマジで終わってる
node.js だとのdeno だのゴミは地球上に生まれるべきじゃなかったお前みたいなマウントクソ野郎が現れるからだ。何がGoよりシングルスレッドモデルのJS async/await が優れてるだｗ
async/await が C# 発祥ってことも知らない。シングルスレッド前提だの荒唐無稽なデマを広げやがる
Node.jsがもともとイベントループでシングルスレッドモデルを採用してたから、それに合わせてasync/awaitをC#から逆輸入しシングルスレッドで実装したのが事実だわ無知野郎
ただ非同期処理に必須な統一されたキャンセル処理を実装しなかったから意味不明なことになってるけどなｗ普通パクる時ってのはパクリ元よりいいものに改善するのが普通だけどNode.js はただの劣化版だからなｗ

**デフォルトの名無しさん** · 2025/05/18(日) 14:46:40.43

>>895
まだ理解できていないんだな？
JSのasync関数はその返値のPromiseを返す関数そのままのシンタックスシュガーだ
他の言語ではasync関数がその返値のPromise(やFuture)を返す関数そのままではなくコルーチンなどステートマシンを伴うこともあるがJSはそのままで完成という本質的な違いがある

**デフォルトの名無しさん** · 2025/05/18(日) 14:50:23.49

例えばNode.jsの代表的なゴミ例として挙げられるのがスリープ処理な
C# だったら await Task.Delay(1000) で待てる、キャンセルしたかったらTask.Delay(1000, token)だ。実にシンプル
Go だったらグリーンスレッドだから time.Sleep(time.Second * 1) でよい

JS(笑) だと await new Promise(resolve => setTimeout(resolve, 1000)); だｗ
キャンセル処理を入れると ChatGPT実装でこうだｗ
await Promise.race([
new Promise(r => setTimeout(r, 1000)),
new Promise((_, rej) =>
ctrl.signal.aborted
? rej(new Error('canceled'))
: ctrl.signal.addEventListener('abort', () => rej(new Error('canceled')), { once: true })
)
]);

何が Promiseでラップするのは簡単だよｗ、じゃあなんでこれをsleep関数にしてる奴が大量にいるんだ？
この程度標準ライブラリで最初から用意しとけゴミ言語ランタイム
(最近にようやくpromise版が追加したようだが、今更無意味だ。遅すぎゴミ)

**デフォルトの名無しさん** · 2025/05/18(日) 14:56:03.43

>>896
おまえは別のやつの書き込みと勘違いしているな
書き込みを見返してみろ
俺はシングルスレッドにすぎないJavaScriptのasync/awaitが優れているとは一度も言ってないぞ
強いて言えば非同期タスクをスタックレスで実現しているRustのasync/awaitだろうな
Goroutineと同じN:Mモデルをスタックレスと両立させている

**デフォルトの名無しさん** · 2025/05/18(日) 14:57:26.44

ここはasyncスレ？

**デフォルトの名無しさん** · 2025/05/18(日) 15:03:12.65

>>897
JSでもasync await は generator を使ったステートマシンに変換されるよ
無知乙。ただPromiseに変換するだけじゃないからｗ
じゃあなんての呼び出しメソッドを async にしないといけないんだ？そんな簡単な変換じゃないからｗ

>>899
お前と同一人物だなんて仮定してないぞ、さっきからお前勝手に妄想しすぎ、ただJS信者という点ではお前と共通
お前みたいなのがいるからNode.jsは生まれるべきじゃなかった

**デフォルトの名無しさん** · 2025/05/18(日) 15:12:48.04

>>901
アホかよ
Promiseを返すだけの普通の関数がそのままasync関数の代わりに使えるんだぞ
その返したものをawait promise;とそのままawaitできる
シンタックスシュガーだからな

**デフォルトの名無しさん** · 2025/05/18(日) 15:31:42.85

>>902
その awaitってやった関数は必ずasyncにする必要がありコンパイラはこれをgeneratorベースのステートマシンに変換するからｗ
C# だって Task をそのまま返す関数をそのまま await できるだろ？一体何が違うんだ？

ほんとお前みたいな無知って困るわ

そもそも俺が話していたのはJSで標準ライブラリをいちいち promise でラップするのは面倒だって話だよね？
それは sleepの例だったり fs/promises の存在だったり、httpクライアントで誰も標準ライブラリを使わない点の3つで完全論破したはずだけど

ちなみに俺はC#でgithub star 2000ぐらいのOSS作ってるけどお前はそれぐらいの実績はあるんか？プログラミングしたことないエアプだの煽ってきてるけど

**デフォルトの名無しさん** · 2025/05/18(日) 15:39:51.60

何が違うの？そもそもお前が何を言いたいのかわからん

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");
}
}
```

**デフォルトの名無しさん** · 2025/05/18(日) 15:47:15.22

>>903
C#やRustなどの言語はステートマシンにする必要があるがJavaScriptはそのまま行けるところが最大の特徴
asyncもPromiseもないコールバックだけの時代からなぜコールバック待ちの間に無関係な他の関数が実行できるのかを理解できなかったのか？
その枠組があるから多数の非同期イベントが飛び交うブラウザ内でも並行処理ができる
知らないなら基礎だから勉強しろ

**デフォルトの名無しさん** · 2025/05/18(日) 15:55:47.79

>>905

だからこのJSの例だと main() 関数で await使うためにコンパイラが main関数を generatorベースのステートマシンに変換してるからｗ
そのまま行けるってのが意味わからんのだけど説明できないだろお前ｗ
別にこれはC#だろうだRustだろうが何も変わらないからｗ

C# もこの例だとMain関数がステートマシンに変換されていて、HelloAsyncはTaskを返すだけで何もしてない
一体JSと何が違うんだ？？？説明できないだろasync/awaitをそもそも理解できていないみたいだから

> asyncもPromiseもないコールバックだけの時代からなぜコールバック待ちの間に無関係な他の関数が実行できるのかを理解できなかったのか？

何言ってるのかわからん、コールバックだのTaskだのPromiseだのそれはコードの書き方の違いであって最終的にepoll や IOCPで非同期で処理されていることは何も変わらない
無知はお前だ、お前が勉強しろ
OSSスターで2000ぐらい獲得してから勉強しろだのマウントとってこいゴミ

**デフォルトの名無しさん** · 2025/05/18(日) 16:10:19.90

>>906
なんだ少しは理解してるじゃないか
言語の中でepollなどでイベントループを抱え込んでいてそれがPromiseもasyncも無い大昔からJavaScriptは同じ
つまりasync/awaitなんか関係なく初めからイベントループを内蔵している
これはWebブラウザという無数に非同期タスクが飛び交う必要性からその仕様となった
そのためC#などより早く非同期タスクが実現されてきた
そのためC#などようなステートマシン変換なんか必要とせずに単なるシンタックスシュガーだけでasync/awaitも導入できている

**デフォルトの名無しさん** · 2025/05/18(日) 16:32:11.94

WPFスレにもわいてるgithubでスターxxxx個君じゃん

**デフォルトの名無しさん** · 2025/05/18(日) 16:33:35.47

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シングルスレッドにしたかったらそれもできてロックフリーにできるんだわ
(マルチスレッド使った方が良いので普通やらないが)

**デフォルトの名無しさん** · 2025/05/18(日) 16:42:27.02

>>909
おまえまだ別人と勘違いしてるのか
俺はシングルスレッドにすぎないJavaScriptの非同期が優れているとは一度も言ってないぞ
CPUコアスレッドを透過的に使いこなせるN:Mモデルが一番優れていると伝えただろ

**デフォルトの名無しさん** · 2025/05/18(日) 16:46:23.38

>>910
まともに会話できないアスペ死ねよ
お前と同一視してないって言ってんだろ
JSを持ち上げる馬鹿としては同一だから言ってるだけ

話題そらしてないでこれの意味について論理的に説明してみろよ
> そのためC#などようなステートマシン変換なんか必要とせずに単なるシンタックスシュガーだけでasync/awaitも導入できている
上でC#コンパイラがどう async await を Taskベースのステートマシンに変換したかを教えたが
JSも別に何も変わらないから。結局お前が何が言いたいのかを説明しろ無知のくせにマウントとってくる無能

**デフォルトの名無しさん** · 2025/05/18(日) 16:54:47.55

>>911
何度も説明しているのに理解できないのは呆れる
async/awaitなんか導入する前からJavaScriptはPromiseで非同期に動いている
シンタックスシュガーにすぎないasync/await記法の導入によってステートマシンの導入なんか必要ない

**デフォルトの名無しさん** · 2025/05/18(日) 17:36:48.91

>>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 は導入されたのか

**デフォルトの名無しさん** · 2025/05/18(日) 17:40:07.52

理解してないなどと煽ってきたのはお前が先

Claude

```
質問: JavaScript の async/await は内部でPromiseを使ったステートマシンに変換されますか？

はい、JavaScript の async/await は内部でPromiseを使ったステートマシンに変換されます。
async/await は構文的な糖衣（シンタックスシュガー）であり、基本的にはPromiseベースのコードを書きやすくするための機能です。JavaScriptエンジンがコードを実行する際、async関数は内部的に以下のような変換が行われます：

async関数は常にPromiseを返すように変換されます
await式は、Promiseの解決を待つためのステートマシンの一部となります
関数内の各await式の前後でコードが分割され、Promiseのチェーンとして再構築されます

```

**デフォルトの名無しさん** · 2025/05/18(日) 17:50:18.44

>> 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の内部実装はどうでもいいからこれについて反論してみろ、無知のくせにマウントとってくる無能屑

**デフォルトの名無しさん** · 2025/05/18(日) 23:04:23.34

たまたま開いたスレでC#の話題がと思ったら…
Goの話しろよ

**デフォルトの名無しさん** · 2025/05/18(日) 23:23:54.26

Promiseが不便ならawait/async用に専用Taskの仕様を作ってクリティカルな部分だけ徐々に移行していけばいいじゃないと
傍観者は思うのであった

**デフォルトの名無しさん** · 2025/05/18(日) 23:50:58.93

>>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;
}

**デフォルトの名無しさん** · 2025/05/18(日) 23:54:17.15

>>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);
　　　});
　　});
　});
}

**デフォルトの名無しさん** · 2025/05/19(月) 00:01:41.90

Goの話しろよ…

横から少し突っ込むと、 >>915 が言ってるのは>>912にある「シンタックスシュガー」について、その糖衣構文が実際には何を行っているのかが分かっているか？ということ
C#でもRustでも、ユーザー側のコードにはステートマシンは出てこないけど、async関数はステートマシンに変換されてる (だから await の前にある変数をそのまま参照できる)
これはJSでも同じ

>>918 についていえば言語の仕様の違いなので仕方ない
JSではsleepみたいにブロックする関数 (CPUを使うような仕事ではないのに待たされる関数) はどうしようも無い
C#だとそれを逃がす方法 (Task.Run) もあるけど、これはスレッドプールと関係するから、シングルスレッドのJSだと使えない

いずれにせよGoと関係なさすぎ

**デフォルトの名無しさん** · 2025/05/19(月) 00:18:33.88

>>920
C#やRustは、await時に一時的にスケジューラに戻すために、ステートマシンのコルーチンに変換しますね。
しかし、JavaScriptはそのコルーチン化が不要なため、ステートマシンへの変換が不要ではないでしょうか？
実際にステートマシンを使わずに変換している>>919を使ってみたら、元のasync関数と全く同様に動作しました。

**デフォルトの名無しさん** · 2025/05/19(月) 00:20:32.66

長くて全部は読んでないがブロッキング処理を含んでるものを単純にPromisifyしたところでなんちゃって非同期になるだけだからちゃんとしたasync対応版が必要って話じゃねーの？

本当にPromiseでくくるだけでasync対応できると思ってるの？

**デフォルトの名無しさん** · 2025/05/19(月) 00:30:47.00

結果としては同じだよ
C#だって Task.ContinueWith (x => ...) と繋げて書くのと、async/awaitで書くのとで、タスクの実行結果として得られるものは変わらない

C#の場合は中間言語 (IL) へのコンパイルを挟むから、ステートマシンへの変換というのが可視化されやすい
JSだとこれは「JSのエンジン (V8) の中でどのように動作するか」という話で、これは普通は気にしない
だからJS界隈ではステートマシンという表現は使わず、「コードを直列化できる」といった機能面からの説明が多いのだと思う

予防線を張るけど、自分はJS詳しくないから間違いだったらすまない

**デフォルトの名無しさん** · 2025/05/19(月) 00:31:26.37

>>922
JavaScriptの場合はそうですよ
Promiseでくくれば本物の非同期で簡単に並行処理できます
C#のTask.Runも不要です
async関数の登場以前からasyncと同じ動作で動いていますよ
async関数は>>919のような感じのsyntax sugarなんです

**デフォルトの名無しさん** · 2025/05/19(月) 00:50:33.56

>>913
ChatGPTの回答が説明してるが例で書いてるPromise化されたコードも概念的にはステートマシンだよ
awaitの地点を基準に変換してるってのはどの言語も同じ
実際Node.jsはJSコードにトランスパイルしてるんじゃなくて内部表現で変換してるはずだが

ステートマシンだの内部実装はどうでもいい話で、それで他人に分かってないだの知識マウント取りに行ってるのがよくわからん

**デフォルトの名無しさん** · 2025/05/19(月) 00:57:23.60

>>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ブラウザの中で色んなイベントが自然に並行動作できるためだよ

**デフォルトの名無しさん** · 2025/05/19(月) 01:34:27.35

>>924
async/awaitがPromiseのsyntax sugarという話と
同期関数をPromiseでくくれば本当の非同期にできるかどうかは別の話
919の例は内部でsetTimeoutというノンブロッキングな処理しかしてないから問題ないだけ

**デフォルトの名無しさん** · 2025/05/19(月) 01:38:06.32

>>926
Task.Runについても他の言語についても勘違いしてるぞ
めちゃくちゃ基本的なんことなのでChatGPT等でもう少し勉強してからまだおいで

**デフォルトの名無しさん** · 2025/05/19(月) 01:41:44.47

チャンネルの概念が普及しなくて悲しい

**デフォルトの名無しさん** · 2025/05/19(月) 02:23:58.81

>>927
もしかしてJavaScriptを使ったことない人かな？
JavaScriptは昔からすべてノンブロッキングで一部の機能に「ブロッキングモードも」付いているだけだよ
シングルスレッドなのにブロッキングしたらブラウザが止まっちゃうでしょ
それからPromiseを使うと非同期になるのではなくてPromiseが導入される前の時代の最初から非同期なの
ブラウザではすべての機能が非同期に並行して動かないと困るでしょ

**デフォルトの名無しさん** · 2025/05/19(月) 03:23:55.32

プロミス以前はコールバックやで～

**デフォルトの名無しさん** · 2025/05/19(月) 03:52:20.75

>>931
そうだよ
その初期のJSの時点で非同期に並行に動いてる
そしてコールバックがあれば必ずPromiseを作ることができるという基本原理をわかってるかな？

**デフォルトの名無しさん** · 2025/05/19(月) 04:13:08.42

setTimeoutみたいな勝手に非同期になるのがある言語は気持ち悪い
明確に分けようという流れがあった
node.jsはシングルスレッドとマルチスレッドが分かれているのが良い
シングルならグローバル変数で渡せる
マルチにしたいならWorker Threadsを使う
Goroutineはマルチスレッド前提だから普通はグローバル変数で渡さない

**デフォルトの名無しさん** · 2025/05/19(月) 04:18:06.87

どうでもいい。誰に言ってるんだね

**デフォルトの名無しさん** · 2025/05/19(月) 04:20:05.27

settimeoutでプロミス使ってとchatGPTに頼もう

**デフォルトの名無しさん** · 2025/05/19(月) 04:32:36.09

>>933
勝手に非同期ではなく
setTimeoutだけではなく
昔からJavaScriptではブロックして待たせるのではなく非同期前提
そうでなければブラウザがマウスクリックにすら反応できなくなってしまう

例えばXMLHttpRequestでサーバからデータを少しずつ受け取りつつ
並行して画面を書き換えつつ
並行してUI入力があれば反応しつつ
すべてを非同期にシングルスレッドで行なうことさえも20年前に広まった
いわゆるAjaxだね
何もかもが非同期に並行に動く仕様だからこそ実現できた

**デフォルトの名無しさん** · 2025/05/19(月) 09:24:27.09

間違い訂正 >>885
✕ 平行(coherency
○ 平行(concurrency
まあ知ってりゃ分かる範囲だが

**デフォルトの名無しさん** · 2025/05/19(月) 09:25:09.06

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が駆逐されてた
(俺にとってはこうなってくれてたほうが良かったが)

**デフォルトの名無しさん** · 2025/05/19(月) 09:25:50.19

> 別にシングルスレッドでの並行処理が良いなんてことはない
これはお前の認識が間違ってる
非同期で平行処理をさばいたほうが「同期/マルチスレッド」よりも性能が出るので各言語は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に切り出し、
ただこれだけで十分だ、これ以外は切り出す必要もない、というわけ
(だから切り出し粒度の面でもそれまでのマルチスレッドからすると異端)

**デフォルトの名無しさん** · 2025/05/19(月) 09:26:28.98

もう一度整理すると、
他言語「全然処理能力が足りない！もっと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はその当時、誰も思っていなかった「金脈」を掘り当てた結果、報酬として蔓延る事になった、とも言える

**デフォルトの名無しさん** · 2025/05/19(月) 09:27:03.65

でまあ、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が指摘した形になる)

**デフォルトの名無しさん** · 2025/05/19(月) 09:27:53.50

だからGoが普及する為には、JS同様に何かしら「金脈」を掘り当てる必要がある
それが出来てないから今がある

Goの場合の想定「金脈」はGoroutine、
Java流に言えば、"Write once, perform anywhere"(一度書けばどこでも最大性能)だが、
実際の所はGoroutineのスイッチングコスト(とチャネルの通信コスト？)が高すぎて、最小粒度ではパフォーマンスがまるで出ない
逆にこれが出来てるのはGPU/CUDAであり、同じゲームプログラム(シェーダープログラム)で、
それぞれのハードウェアでの最大性能が出る
だからベンチでGPU毎のfpsがずらりと綺麗に並ぶ事になる

敗因は何か？と考えると、
・JS以外の他言語と同様、スイッチングコストを甘く見すぎ
・スイッチングコストを下げる努力をしてない、というよりプログラマ側の努力で下げられない
　(当然だが同一/最小粒度のままで。粒度を上げてスイッチングコストを下げるのは本末転倒)
かと。逆にJSは
・プログラマに強制的にI/O非同期化の努力をさせ、スイッチングコストゼロを目指す
というコンセプトが当たったから今がある

**デフォルトの名無しさん** · 2025/05/19(月) 09:28:31.40

> 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的文脈のキャッシュもないが)

**デフォルトの名無しさん** · 2025/05/19(月) 09:29:12.15

だから今すぐ出来る対策は、Goroutineのスタックサイズ制限でのスイッチングコスト低減だろうよ
コンパイラで各Goroutine毎の最大スタックサイズを静的に解析し、そのサイズに固定する
静的にスタックサイズを確定出来ないGoroutineのコードは、落とす(＝エラーとしてプログラマに書き直させる)、とかだね
(GPUは既にこうなってる《はず》)

とりあえずGPUでは"Write once, perform anywhere"出来てるのだから、
・依存性がない最小単位でGoroutineに分離/分割し
・スイッチングコストをゼロに出来れば
行けるはず。ただ、Goはこのどちらもやろうとしてないよね

これも駄目押ししとくと、
Go「グリーンスレッドだから軽い」
GPU/CUDA「Goroutineなんて贅肉多すぎのデブスレッド。本当のマルチスレッドを見せてやんよ」
てなところかと

**デフォルトの名無しさん** · 2025/05/19(月) 10:09:21.10

>>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}");

**デフォルトの名無しさん** · 2025/05/19(月) 10:23:40.26

非同期APIを流行らしたのは JSじゃなくて nginx だから
Node.jsが出たのは2009で、Go も2009、nginxは2004だ

あたかもJSやNode.jsが非同期を発明したかのように語るのやめろ、流行らしたのは事実だが

あとGoよりシングルスレッドの方のNode.jsの方がパフォーマンス出るとか言ってるのはお前だけだから、ソースを出せ

GPU/CUDAで行われる並列処理は Webで行われる並行並列とか全く異なるし、無能が長文書くの誰も読まないからやめたほうがいいと思うよ

**デフォルトの名無しさん** · 2025/05/19(月) 11:22:21.24

非同期が流行ったのはWin32のIOCPからじゃないかな
Windowsのマナーでは、1990年代から非同期が当たり前だったよ

**デフォルトの名無しさん** · 2025/05/19(月) 11:29:25.21

Goroutineみたいなマルチスレッドをブラウザ上でJavascriptで使うにはWeb Workerを使う
チャネルに相当するのはpostMessage

**デフォルトの名無しさん** · 2025/05/19(月) 12:25:32.76

Linuxのカーネル内では最初から非同期だよ。流行りもなにも非同期しかない

**デフォルトの名無しさん** · 2025/05/19(月) 14:06:50.34

>>945
それは
あんたの認識不足だな
C#ではそのようにTaskを起動してようやく2秒を実現
Goでもgoでgoroutineを起動しでようやく2秒を実現
JavaScriptでは関数を呼び出すだけで2秒を実現できている
この差が非同期が前提であるJavaScriptの実力だ

**デフォルトの名無しさん** · 2025/05/19(月) 14:11:01.04

非同期と並列実行は無関係だけどな

**デフォルトの名無しさん** · 2025/05/19(月) 14:13:24.79

職場で浮いてるかブリリアントジャークとして大活躍しとるんか

**デフォルトの名無しさん** · 2025/05/19(月) 14:19:01.58

>>946
JavaScriptは1995年からあり非同期で動いている
象徴的なXMLHttpRequestはIEで1999年からMozillaで翌年
念のため説明すると外部のサーバーからHTTPでデータを非同期に送受信できる
シングルスレッドでユーザーインターフェースの処理などをしながらサーバー群と通信しデータを処理し表示することを非同期に行える

**デフォルトの名無しさん** · 2025/05/19(月) 14:21:16.24

>>951
並列ではなく並行な
この2つを区別できないのはヤバいぞ
JavaScriptはシングルスレッドで非同期に並行処理が基本機能として備わっている

**デフォルトの名無しさん** · 2025/05/19(月) 14:33:46.83

ここは30代が50代園児に非同期を語るスレです

**デフォルトの名無しさん** · 2025/05/19(月) 15:00:01.58

>>950
お前底無しの馬鹿だろw

**デフォルトの名無しさん** · 2025/05/19(月) 15:19:35.67

>>956
技術的に反論できないの？
非同期並行が本質的に備わっているJavaScriptと他の言語との違いを理解しよう

**デフォルトの名無しさん** · 2025/05/19(月) 15:43:40.54

node.jsはグローバル変数がリクエスト間で共有される
書き方として楽なのはもちろん同期コストもかからない

**デフォルトの名無しさん** · 2025/05/19(月) 15:57:08.17

>>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が絡むものじゃないと向いていないゴミなわけだ
よってデスクトップやらモバイルで使う言語じゃねーんだわ、頼むからブラウザ以外で使おうとするのやめろゴミども

**デフォルトの名無しさん** · 2025/05/19(月) 16:08:08.14

>>958
それはJavaScriptの性質
node.jsはブラウザの外に出したことでようやく普通の言語と同様にローカルファイルアクセスやサーバー化ができるようになったことが本質
元々JavaScriptには非同期並行が前提の性質があるため
node.jsとなったことでその効率と利便性の良さをサーバーサイドでも発揮した
ただしシングルスレッドの限界があり別スレッドはWorkerという分離でダサい
マルチコアをN:Mモデルで透過的に活かせるGoやRustに利がある

**デフォルトの名無しさん** · 2025/05/19(月) 16:35:28.76

Goスレが糞言語の話題で埋まるのは偲び無い

**デフォルトの名無しさん** · 2025/05/19(月) 20:33:15.49

>>773を書いたのは自分だけど
別の言語の話題で盛り上がるスレになってしまったようだ

**デフォルトの名無しさん** · 2025/05/19(月) 20:41:50.05

nodeなんてExceptionキャッチ出来てなくてクソアプリ量産だよ
Goがいいいよ

**デフォルトの名無しさん** · 2025/05/19(月) 22:09:44.38

>>961
まったくだ

**デフォルトの名無しさん** · 2025/05/19(月) 23:46:27.40

>>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を一つのスレッドで処理する
　アクティブスレッド数：出来れば１、または最小
　狙い：マルチスレッドにおけるオーバーヘッドを無くすため、「出来るだけ少ないスレッド」に集約する

**デフォルトの名無しさん** · 2025/05/19(月) 23:46:56.13

で、従来型よりJS型の方がパフォーマンスが出ることが分かってしまったから、あらゆる言語がasyncを慌てて導入することになってる
だからasyncを導入した言語は、自ら敗北を認めてる
ただまあ、確かにGoはこの意味では負けを認めていないな

とはいえ、「出来るだけ少ないスレッド」という、マルチスレッドを根本から否定するJS型が勝ってしまった意味は大きい
そしてGo型は従来型をさらに発展させたものなのだから、お前らに危機感がないのはだいぶ狂ってる
この意味でなら、Goは負けを認めず、負け筋に乗り続けてるだけ
(だから今後共負け続ける)

Go型でJS型に勝つためには、スレッドスイッチのコストを最小化することが必要だが、Goはこれをやろうともしてない
だから、Goに勝ち筋は今の所無い

**デフォルトの名無しさん** · 2025/05/19(月) 23:58:00.24

Goroutineが重いプリエンプティブを選んだのはなぜだろうね
マルチユーザのマルチタスクなら強制的にプリエンプションせざるを得ないけど自分たちでコードを書くのだから協調スケジューリングで十分なはず
結果多くのコンテキスト切り替えスイッチングも重くスタックレスにも出来ず

**デフォルトの名無しさん** · 2025/05/20(火) 00:21:14.96

シングルスレッドの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 が全世界から優秀なエンジニアを集めて言語＆ランタイムを設計、開発させてるから
お前みたいな糖質が問題提起する内容などそもそも問題がないように設計されてるのよ

**デフォルトの名無しさん** · 2025/05/20(火) 01:00:38.79

ユーザ多いJavaもGoと同じくグリーンスレッドモデルだけどw
Kotlinもコルーチンでグリーンスレッドモデルだね

どの言語もJSのやり方とは別のアプローチでC10K問題を解消してるだけですよねw Goのgoroutineだけ否定する理由を全く論理的に説明できてないですねw

goroutineのスイッチングコストが高いと勘違いしているようだけど数個のレジスタを書き換えるだけで非常に高速に行われるはずだけどw

君のスイッチングコストが高いという主張を裏付ける記事やベンチマークを貼った方がいいんじゃない？

**デフォルトの名無しさん** · 2025/05/20(火) 01:31:58.27

50代園児達は厳しいのだ

**デフォルトの名無しさん** · 2025/05/20(火) 02:25:32.98

大量の非同期タスクで最も性能が出るのは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程度に収まっているとのこと。

**デフォルトの名無しさん** · 2025/05/20(火) 02:44:02.44

Perlに依存してるｗｗｗ

**デフォルトの名無しさん** · 2025/05/20(火) 08:09:09.31

>>971
それいつもの再設計で良くなったパターンじゃなくて？

**デフォルトの名無しさん** · 2025/05/20(火) 08:14:17.18

機能は絞ってるんだろうな

**デフォルトの名無しさん** · 2025/05/20(火) 08:22:55.01

>>971
最速と言われてきたNGINXの3倍速かよ

**デフォルトの名無しさん** · 2025/05/20(火) 10:42:26.74

原文読んだけど
https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/
- コネクションプール戦略の改善により遅延を削減できた
- NginxのLuaモジュールをRustに置き換えたことでCPUとメモリの使用量を削減できた

Rustだからというよりアーキテクチャの改善と汎用性や柔軟性を犠牲にした最適化でパフォーマンスを改善したってことだ
全体として原文はRust最強みたいな変な誤解をされないように注意深く書かれているから、ちゃんとその辺りを理解してあげないと失礼