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/16(金) 12:30:40.01

>>845
今はもう完全にクロスプラットフォームだけど？無知乙

IDEもRiderが使えるしVSCodeでもいい

**デフォルトの名無しさん** · 2025/05/16(金) 12:32:36.26

>>846
そんな事ある?
MS関係者はもっとLinux事例のアピールしなきゃ

**デフォルトの名無しさん** · 2025/05/16(金) 12:34:31.04

IDEはjetbrains製のか。VSがLinux来ないと

**デフォルトの名無しさん** · 2025/05/16(金) 12:55:52.74

無知乙
2014から.NET Coreが出て完全にクロスプラットフォームだわ

Github ActionsとかC#で描かれてるし、stackoverflowもそう

開発PCはWindowsでサーバはLinuxを使えばいいだけ
Linux環境欲しいならWSL2を使えばいい
Macみたいなバカみたいな高いPC買う必要ないし会社でもメリットが多い

>>848
Goも同じだけど何言ってんだ？IDEはGolandしかないよね、LSPでVSCodeやneovimが使えるのはC#もGoも共通なんだが？

**デフォルトの名無しさん** · 2025/05/16(金) 13:17:59.65

IDEがないとビルドできないマンが量産されてるのか
Javaの二の舞

**デフォルトの名無しさん** · 2025/05/16(金) 22:37:19.26

Goはルーン文字と同じ運命をたどりそうだな
紙が普及した時代に原始的な彫刻文字は流行らない
時代に合わせて形を変えないと

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

GC付きCとしては残るんじゃね？
言語の衰退期に入ったのは事実だろうが、それならJavaやPHPも同じ
個人的には死んで欲しいのはRust、理由は信者がウザイから

○○付きC、が乱立気味なのは、Cがやる気無さすぎなのと、C++が暴走してるから
ゆうて今後コア数はてんこ盛りになるようだし、goroutineが速ければワンチャンあるが…
https://qiita.com/kawasin73/items/3d2aa21f0b4bf05de1c6

**デフォルトの名無しさん** · 2025/05/17(土) 12:23:41.13

>>844
Rustが低レイヤ用の言語ではなくて低レイヤもC同様扱える言語だね
Rustを使ってる人たちのアンケート調査で最大利用分野はWebだと判明しているよ

>>852
C/C++を置き換えられるのはRustだけで既に進んでいるからかなり長生きするだろうね

**デフォルトの名無しさん** · 2025/05/17(土) 12:39:18.59

>>853
> 既に進んでいる
と思ってるのは信者だけ。まだ実際は「入った」事がニュースになる程度
まあ昨日話題になってたがマスゴミ的に「モームリが大盛況！！！」と同レベル
そして必ず信者が沸くのが本当にウザイ

**デフォルトの名無しさん** · 2025/05/17(土) 12:49:46.67

>>854
その書き込みさえもRust製のPingoraを通過して5chに書き込まれているよ
世界のネットインフラのRust化の恩恵だね

**デフォルトの名無しさん** · 2025/05/17(土) 13:06:04.46

はいはいすごいね
だけどそんな事を言ったら、C無しで出来る事って何もないのでは？
JavaやC#も同レベルだし
マジでRust信者は死んで欲しいし、殺す為に新言語を開発したいと思うよ

**デフォルトの名無しさん** · 2025/05/17(土) 13:12:54.63

Rustスレでやってください…

**デフォルトの名無しさん** · 2025/05/17(土) 13:33:19.14

C言語の役目を完全に置き換えることができるRustの出現はデカいよな
Goはシンプルな芸術的な反面で色々と中途半端な機能と立ち位置になってしまった気がする

>>856
Rustを置き換えることができる新言語の開発すばらしい！
C→Rustで43年間かかったらしいけど
今はまだ芽も発見されてないから早くて20年後かなあ

**デフォルトの名無しさん** · 2025/05/17(土) 13:41:42.69

>>856
また信者が生まれるよ。君の信者だよかったね

**デフォルトの名無しさん** · 2025/05/17(土) 13:46:37.14

>>857
全くその通りだ
勝手にエコーチェンバーでホルホルしてればいいのに、出張ってくるからウザイ
まあ一応、俺の勝手な感想を>>843について述べておくと、

> エラー処理が冗長で、同じ if err != nil パターンが散在する。
Try-catchもろくでもない
現在のプログラミング言語はまだエラー処理に最適な記述方法を発見出来てないだけ

> goroutine は強力だが、競合状態や静かな失敗を招きやすく、テストが難しい。
静かな失敗がデッドロック等を意味するなら、そりゃそうだが、
ハードウェアの近未来(数年後)がEコアマシマシ方向なので、コンセプトとしては合ってた
ただ、そもそもメニーコアはおそらく現在のフルスペックなCPUの多数盛り(16-64コア)ではなく、
小型限定機能CPUの『超』多数盛り(1024+コア)が正解だと思うので、
ハードウェアもGo言語自体も中途半端な状況で、中期的(10年後)にも厳しい

> “No frameworks” 文化により、共通機能を一から実装する負担が大きい。
Framework on framework が乱立してる他言語に対してのアンチテーゼとしては意味があったし、
実際、dllはCで世界が構築されてるとき、つまりLinux等では有効だが、それ以外では依存性の問題が面倒なのは事実
しかし現実的には、frameworkをいくら嫌ったところで、同様のコードはどうせ記述する事になるのも事実
同じような事を何度もやる＝大企業内の職業プログラマにとってはframework学習の方がマシと見えるのもそうだろう
乱立してたframeworkも、各言語毎にほぼ統一気味だし

> Go エンジニアの母数が少なく、採用・オンボーディングコストが高い。
状況知らんのでなんとも

> 生成 AI が慣用的な Go コードを出力しづらく、Python などに比べ生産性が劣る。
Pythonは人数が多いだけ
そもそも自動生成コードで出力しづらいとかは言語に依らず、やってる人数だけの話

**デフォルトの名無しさん** · 2025/05/17(土) 14:11:35.74

>>859
実際、その方向で殺す事になると思うよ(俺の言語ではなくね)
今の『日本の』Rust信者って、Cを勉強しない言い訳としてRustをやってて、非Rust使いを排除して、俺ツエーホルホルしてるだけでしょ
『アメリカの』Rust使いは、「(Cを殺そうと思ってRustを出したのに)RustのおかげでCを勉強する奴が(以前よりも、またRustよりも)増えてしまったじゃねえかよ！！！」とか言ってて、
なるほど連中は正しく学習しているのだな、とは感じるが
なんつーかここら辺、アメリカがソフトウェアで圧倒的に強いのは、センスの違いを感じるよ
(まあアメリカのRust信者もウザイのは同じらしいが)

多分数年後、「Rustを超えた！！！」という言語が現れ、俺ツエーしたいだけの馬鹿Rust信者はそっちに移る
その辺でRust死んでくれねーかなと思ってる
(そしてこの意味では、俺ツエーしたいだけの馬鹿がたむろする言語は必ず存在してて、それがC++→Rustになってるのが今、というだけでもある)

>>858
> 今はまだ芽も発見されてないから早くて20年後かなあ
そう思ってるのはお前だけ
単純に、Cの駄目な点をチマチマ直せばいいだけの話

だから俺の場合は「新言語」ではなく「ハイパーCプリプロセッサ」になる
例えばif err != nil パターンが嫌で、try-catchで書きたければ、try-catchをif errパターンに変換する物があればいい、というだけ
Cがウザイのは記述レベルが低すぎるからであって、JSレベルでリテラル記述出来ればだいぶ変わる
というかCの問題は言語仕様ではなく、主に書きにくい点だけだから
(Rust信者はメモリ管理が出来ないのだろうが、Cを『正しく』使っててメモリリークする馬鹿は居ない)

**デフォルトの名無しさん** · 2025/05/17(土) 14:24:44.58

>>861
なぜCが捨てられRustへ置き換えられていってるか世界の流れの理由を把握した方がええよ
毎月どこかで言語の欠陥によるセキュリティホールが見つかる昨今
必ずミスを引き起こす人類に対して言語仕様で自動的に安全を保証する点が求められてる
その点Goは自己責任な面でちょっと向かい風なんだよね

**デフォルトの名無しさん** · 2025/05/17(土) 14:38:07.99

CとGoは同じ人が策定に関わってる時点で限界あるんだろうね。似てしまう

**デフォルトの名無しさん** · 2025/05/17(土) 14:40:21.44

>>862
> 言語仕様で自動的に安全を保証する点
俺はそれを言語仕様で「手動」ではなく、コンパイラやプリプロセッサで「自動」化する方向
まあ俺はC派なので馬鹿は死ねではあるが、Rustが馬鹿対策出来てる点は評価してるよ

というかね、お前のコードは「駄目」だからreject、となるとだいたい軋轢が発生するわけで、
その最低限のラインを「コンパイルが通る」として、プルリクされたコードは原則全てacceptならRustは昨今のGitHub的開発では強い
でもこんな運用出来てる奴居ないでしょ
結局人間が判断してるのならどの言語でも大して変わらん

> 言語の欠陥によるセキュリティホール
って何ぞ？
もしかして境界チェックの話？ならJavaだとセキュリティホールは存在しない事になるけど、そういうレベルの馬鹿か？

**デフォルトの名無しさん** · 2025/05/17(土) 14:44:35.88

コードが駄目って言語化が足りない。やり直し、レビュアーは60過ぎの頑固爺だな

**デフォルトの名無しさん** · 2025/05/17(土) 14:45:52.25

>>863
というか元からbetterCだろ
Cにそんなに不満がない人が作ったらそうなる
(というか多分、不満があったのはCではなくC++に対してなんだろ)

まあでも、C++ではないbetterCとしては、これもありかな、という仕様だとは思うよ

**デフォルトの名無しさん** · 2025/05/17(土) 14:47:41.15

境界チェックだけでなくnil (やnullやundefinedなど)チェックのミスなど色々あるね
ヌルポが起こるJavaなどは論外だね

**デフォルトの名無しさん** · 2025/05/17(土) 14:57:24.25

>>865
ゆとりか？
「駄目」ってのはこの文脈で一言で表現してるだけで、
実際の所は当事者間で何回も往復してて、もっともらしい理由は添えてると思うぞ

ただ、Cの場合に、駄目なコード(例：メモリリークを誘発するコード）を受け入れる事が出来ないのは事実なんだよ
そして、これを相手に説明しても、相手が理解する事はない
だってそもそも理解してないからそういうコードなんだし、逆に理解してたらそういう『駄目な』コードなんて書かないから
だからrejectはどうやってもけんか腰になるし、
この展開～結末を知ってたら最初からrejectとして何も言わない奴もでてきてもおかしくないし、実際に居るとも思うけど
(だからGitHub等では独裁/フォークであって、民主主義的多数決ではない)

こういうのを一々相手のせいにするのは、ゆとりやZの特徴ではあるが、
これも含めて昨今の情勢ではあるから、Rust的に文法にしてしまうのは一つの対策ではある
(ただしこれが機能するのは受け入れ基準＝文法とするときであって、実際にこういう運用をしてる奴は居ないと思うので意味無いが)

**デフォルトの名無しさん** · 2025/05/17(土) 15:00:26.74

>>867
俺はそういうのはリンターで対策出来ると思ってる
だからその場合はJava＋強力なリンターで落とせばいいだけの話

わざわざ新言語にして書き換え、他言語使用者を排除し、
結果的に少数精鋭！！！と勝手に妄想して俺ツエーやりたいだけの馬鹿は死ね、だね

**デフォルトの名無しさん** · 2025/05/17(土) 15:09:10.86

>>861
>> Cを『正しく』使っててメモリリークする馬鹿は居ない

メモリーリークによる穴の報告が常にあってなくならない理由をわかってないのか
複雑化するとどんなプログラマーもうっかりミスすることが判明している
静的分析でも一部しかミスを見つけられないことも判明している
そのため穴発生のレポートが絶えない

>>869
>> リンターで対策出来ると思ってる

静的分析では一部しかミスを見つけられないことが判明している

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

>>868
説明しても揉めるようなメンバーしかいないのか。あんた可哀想だな

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

>>870
> 静的分析でも一部しかミスを見つけられないことも判明している
> 静的分析では一部しかミスを見つけられないことが判明している
そういう問題じゃねえ

Rustは静的解析で完璧！！！なんだろ
なら、静的解析で出来るのは事実だろ
この矛盾にすら気づけないから馬鹿信者なんだよ

Javaで問題になるのはnullを代入してるからであって、
これはnull許容型と禁止型を明示的に分離してないからであって、やりゃいいだけの話だろ
要は、Rustと同じ手法で安全にする事は他言語でもやれば出来る
どこまで文法化し、どこからはプログラマに任せるかを各言語が決めてるだけ

Javaが中途半端だ！というのはごもっともだが、
それはセキュリティ要求とプログラマの想定知能レベルがJavaの頃と現在で変わったから
当然後発のRustの方が今に合ってるし、
Java7で10年弱全く変化しなかったから「死んだ」と開発元に言われてたし、実際そんな感じではある
とはいえ、RustよりJavaの方が殺しても死なないのも事実
Java8以降は半年毎に上げる事にしたようだし、既に後発言語になってるので、
必要なら上記の通り他言語を参考に新文法を導入していけばいいだけ
(この意味ではJavaもRustを殺せると思うけど)

信者は「Rustが！！！」と思ってるが、
正しくは「手法が」であって、当たり前だが他言語でも同じ手法で同じ事は出来る
だからRustは「現代的新文法詰め合わせ実験言語」であって、まあ頑張れといったところ
(ただ、言語としての筋が悪いので、どうせ駄目だと俺は見てるが)

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

> 複雑化するとどんなプログラマーもうっかりミスすることが判明している
これが間違ってるというか、考え方が根本的に違うと最近は感じてる
「無重力でも書けるボールペン」指向のbetterCがC++で、
「一方ロシアは鉛筆を使った」指向のbetterCがGoなんだよ
そしてRustは前者、ところがCに似合うコードは多分後者なんだな

そしてうっかり、とかいう話でもない
つか、お前も「トイレで『うっかり』ケツを拭き忘れた」事なんて、何十年も無いだろ
習慣化＋目に入る位置に紙がある、の合わせ技だが、でも見た目紙が無くても探すだろ
メモリリークしないのは、こういうレベルの話なんだよ
(だからRustが必要な奴＝ケツを拭く習慣がない奴には全く通じないのも事実だし、
実際お前が理解出来るとも期待してないが)

**デフォルトの名無しさん** · 2025/05/17(土) 21:51:30.90

Goも別にC/C++ほどにはプログラマを信用してないと思うけどな
GCはあるし、変数は必ず初期化されるし、ポインタへの算術演算も禁止してるし
そもそもCの置き換えを目指すような低レイヤーを扱う言語じゃないので

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

一応Java対抗よね。Oracleで混迷してるし、あってよかったと思うわ

**デフォルトの名無しさん** · 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}");