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/

**デフォルトの名無しさん** · 2024/12/30(月) 00:21:57.66

立ち読みしたけど至って普通だった
Goの本はレベル高いものが多いからそれに比べると普通に入門書レベル

**デフォルトの名無しさん** · 2025/01/04(土) 13:31:21.68

【IT】初心者が最初に学ぶプログラミング言語　3位「Python」、2位「C言語」、1位は？
https://egg.5ch.net/test/read.cgi/bizplus/1735924157/

**デフォルトの名無しさん** · 2025/01/04(土) 14:11:45.29

Rust

**!id:ignore** · 2025/01/18(土) 15:45:57.85

ジジイは死んだんか？w

**デフォルトの名無しさん** · 2025/01/18(土) 17:34:58.21

Javaはメソッド呼び出し時の引数が
プリミティブの場合、コピー渡し
オブジェクトの場合、参照渡し
合理的

**デフォルトの名無しさん** · 2025/01/18(土) 17:35:50.07

GoにはもしかしてちゃんとしたHTMLパーサーがあるのでは

**デフォルトの名無しさん** · 2025/01/18(土) 22:02:52.51

>>823
それは合理的ではないな
小さいオブジェクトでその値を書き換える目的でないならばコピー渡しが圧倒的に有利

**デフォルトの名無しさん** · 2025/01/18(土) 23:07:47.87

そもそも前提が間違ってる
Javaには値渡ししかない
これ何十年も前から何度も何度も初心者に言って聞かせるやつ
「プリミティブ型の値渡し」「参照型変数の値渡し」これしかない

void foo(std::string s) { // c++ 値渡し
s = "foo"; // 呼び出し元に影響なし
}
void bar(std::string &s) { // c++ 参照渡し
s = "bar"; // 呼び出し元に代入される
}
void foo(String s) { // Java 値渡し
s = "foo"; // 呼び出し元に影響なし
}

このことってそんなに難しい？
なんで初心者はいつもここ間違うの？

**デフォルトの名無しさん** · 2025/01/19(日) 07:54:07.72

Javaは参照型について
参照値自体の値渡ししか出来ないの？
参照値が指してる先の値の値渡しが出来ないってこと？
効率悪いね

**デフォルトの名無しさん** · 2025/01/19(日) 09:11:16.49

んなことはない
参照値自体の値渡し : 参照値をコピー→必要に応じて渡した先でデリファレンス
参照値が指してる先の実体の値渡し : デリファレンス→実体の値をコピー
ここで、一般に参照値のコピーは単なる64ビットの数値のコピーであるのに対して、実体の値は複合データであるため単なる参照値よりコピーのコストが大きい
従って、殆どのケースでは後者の方が非効率である

**デフォルトの名無しさん** · 2025/01/19(日) 09:57:03.41

>>828
間違っている
関数への参照(アドレス)渡しはその先で実際の値があるメモリを読み込んでようやく値を得るから遅くなる
呼び出し元関数でも実値を何らか処理していることが多いので既にレジスタ上にあることが多い
したがって参照アドレス渡しではなく値をレジスタ渡しで関数を呼び出すのが速い

**デフォルトの名無しさん** · 2025/01/19(日) 16:14:51.30

もし一般的にその説が成り立つなら大きな構造体のコピーを避けることを目的とした参照渡しをする必要はないことになるが、そう主張したいのか？

**デフォルトの名無しさん** · 2025/01/19(日) 16:41:50.96

>>830
常に参照を渡すばかりではなく適材適所で使い分けられることが重要という話だぞ
自分の関数でも処理をしているデータなら既にメモリから読み込んでレジスタ上にあるから遅くなるアドレス渡しの必要がないという話
もちろん関数にレジスタ渡しできるサイズは限りがありABIで定められている
例えば86系64bitでLinux等なら64bit✕6個まてはレジスタ渡しできる

**デフォルトの名無しさん** · 2025/01/19(日) 21:01:24.78

オブジェクトはコピーに時間と空間が必要なので参照渡し
合理的すぎる

**デフォルトの名無しさん** · 2025/01/19(日) 21:24:12.64

>>832
例えば小さいオブジェクトは参照アドレス渡しよりも値コピー渡しが速い
例えば一番小さく整数一つだけをオブジェクトに包んで専用メソッドを付けて単なる整数型とは別の型を作ることはよく行われる

**デフォルトの名無しさん** · 2025/01/19(日) 22:26:45.76

Goの場合は、
どうせコピーのコストが大きな問題になるようなオブジェクトはコレクションと文字列だけ
だからそいつらさえ常に参照(の値)渡しになるようにしときゃ構造体は基本的には値渡しで実用上問題ないだろう
という極めて雑というか実用主義的な判断のなされた仕様になっている
実際には参照渡しの方が効率的なケースも多いが、少々の効率を理由にポインタ渡しを選ぶことは好まれないのがGo流

**デフォルトの名無しさん** · 2025/01/21(火) 16:27:44.96

Javaは目からウロコが落ちる出来事だった

**デフォルトの名無しさん** · 2025/01/21(火) 16:29:19.66

ちょっと聞いてよ私はハゲ
20世紀からのC/C++使い

**デフォルトの名無しさん** · 2025/01/21(火) 20:51:56.00

お呼びじゃない
カエレ！

**デフォルトの名無しさん** · 2025/01/22(水) 16:05:32.40

だいたいGoって名前がダサすぎる
なんだよゴーってよ、ゴー!!ゴー!!ゴープログラミング!!ってかwwww昭和かよwwwwwwwwww

**デフォルトの名無しさん** · 2025/02/11(火) 23:43:29.84

アセンブラを知らないから
どういうコードに落ちるか
想像つかないんだろな

**デフォルトの名無しさん** · 2025/02/11(火) 23:45:13.36

昔はレジスタに値をセットして割り込みかけるのがシステム呼び出しだったから
どんな言語使ってようがアセンブラは必須だった

**デフォルトの名無しさん** · 2025/02/12(水) 10:56:43.50

ブブー
間違いです

**デフォルトの名無しさん** · 2025/03/02(日) 23:09:02.68

Javaで参照渡したいとき配列で渡してたわ

**デフォルトの名無しさん** · 2025/05/15(木) 21:27:28.17

【海外記事紹介】Go言語から離れる開発者が増えている？その理由とは
https://techfeed.io/entries/68250b69c4e1671f6888ca33

Go は 2007 年に Rob Pike、Ken Thompson、Robert Griesemer が開発し、クラウド・インフラ向け言語(“C of the Cloud”)として脚光を浴びた。しかし 2022 年頃から、早期採用者の間で「プロトタイピング専用言語」「入門用言語」として位置づけ直す声が増え始めた。背景にはエコシステムの限界や AI ワークフローとの相性の悪さがある。

Go から離脱する開発者が挙げる代表的な不満点は次のとおりだ。

エラー処理が冗長で、同じ if err != nil パターンが散在する。
goroutine は強力だが、競合状態や静かな失敗を招きやすく、テストが難しい。
“No frameworks” 文化により、共通機能を一から実装する負担が大きい。
Go エンジニアの母数が少なく、採用・オンボーディングコストが高い。
生成 AI が慣用的な Go コードを出力しづらく、Python などに比べ生産性が劣る。

一方で、パフォーマンスとシンプルさを兼ね備えた Zig、豊富なツールチェーンを持つ Kotlin、安全性と速度で評価される Rust などの新たな言語は、Go言語への不満を解消する選択肢として、開発者たちの関心を集めているという。

**デフォルトの名無しさん** · 2025/05/16(金) 10:08:38.99

pythonよりAIの相性が悪い？？動的言語なのにいいわけねーだろ笑

zigとRustとか流石にバカすぎるw 低レイヤ用の言語でIT土方は関わらない言語なのにw
そして書いてある欠点がないC#は無視されてて草

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

C＃はLinuxと相性悪そうだからね。候補に挙げられない

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