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/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最強みたいな変な誤解をされないように注意深く書かれているから、ちゃんとその辺りを理解してあげないと失礼

**デフォルトの名無しさん** · 2025/05/20(火) 11:16:09.13

遅いGoやC#などで作っても勝てないし
C/C++で非同期プログラミングは未だに様々な問題を抱えていて不利なので
速さも環境も整っているRust一択になっている状況

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

クラウドフレアはFPGAを使うべきでは？
LuaスクリプトよりRustのほうが速いという主張も良くわかりませんでした
それは当たり前では？

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

>>967
単純に、「重い」と認識できてない馬鹿と、分かってても変更しない意識高い系馬鹿の合わせ技でしょ

1995時点で「お前らのマルチスレッドはスイッチングが重すぎてまるで機能していない」と看破できたのはJSだけ
大半の言語はこれを認め、JSと同様に「手動」で軽量化も可能なよう、async文法を導入した
ただし実際、手間が増えてるのと、将来的にOSレベルでのスイッチングが軽くなった場合に、asyncで書かれたコードはゴミになる
だから「抽象度が高い状態で書きたいのだ！！！」「OSで『自動』的にやらせたほうがコード資産の価値は高いのだ！！！」という言い訳はできる
(問題は軽くなる予定が全く無いことだが)

この意味では、「asyncが必要なのではなく、OSがポンコツすぎるのだ！！！」と責任転嫁することも出来るはずだが、
誰もやらないところを見ると、OSは限界までは軽いんだろうな

そして逆に、アプリ側でasync必須でスケジューラも持ってれば、OS側で持ってるのは無駄なので削除して軽量化することは出来る
chromiumOSが奇妙に軽いのはこの辺かもな(＝JS専用OS)

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

> プリエンプティブ
> 協調スケジューリング
改めて考えてみたが、「同期APIを使える」くらいしか利点を思いつかない
協調スケジューリングの場合は「非同期API強制」となるからね
JSは2013年頃でも「SLEEPは？」とか言われてたし、889のような馬鹿げたブログ(2015)を書くやつも居るしで、
非同期アレルギーはそうならなかったやつの想定以上に激しいのかもしれん
(俺に言わせれば、SLEEPは別の書き方があるからそれでいい、Promiseはゴミ、コールバック地獄になるのは腕前の問題、
この辺JSは全関数がクロージャなのだから適当に関数ぶった切って書き、コールグラフを整理すれば回避出来る、となるが)
そして出自がJSというのも当たりは悪い
フニャフニャ文法、階層が関数、専用構文とprivateのないオブジェクト指向、
ダックタイピング、動的に変化するthis、他型のメソッドも使える、で、
正統派オブジェクト指向のC++/Java/C#勢からすれば十分異端すぎるのに、更に、非同期、イベントドリブン、だからね
JSモデルが想定以上に速かったから、他言語開発者はJSを研究せざるを得ず、
何じゃあこれはーーー！！！となるのは分かる(＝JSアレルギーの発症
俺の場合は、え？こんなので大丈夫なのか？→あれ？意外と問題ねえな→実は他言語が無駄に冗長過ぎただけでは…、となったが)
まあブレンダン・アイクは本当に上手く攻略したな、とは思うよ

とはいえ、『同速なら』同期APIのコードの方がマシなのは事実だから、
同期API派はさっさと同速になる方向の努力をすべきだと思うがな

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

>>976
> skipping TCP and TLS handshakes required on a new connection.
いやこれってありなんか？とは思ったが、GETならどうせ同じ(はず)だからいいのか？
となると、リバースプロキシって、誰かの操作を横から盗み見してる感じになるのか？

> 原文はRust最強みたいな変な誤解をされないように注意深く書かれている
信者が発狂するからといってオブラートに包みすぎ。原文は以下
> This is not because we run code faster.
まあCと比べればRustも遅いから、これはどうにもならんが

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

Rustスレでやろうぜ

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

GoクンのHPはもうカツカツよ🥺

**デフォルトの名無しさん** · 2025/05/20(火) 23:12:32.78

次スレ
Go language part 6
https://mevius.5ch.net/test/read.cgi/tech/1747750228/

**デフォルトの名無しさん** · 2025/05/20(火) 23:47:56.43

>>981
一般的なリバースプロキシじゃなくて、あくまでCDNだからね
基本的に全部パブリックリソースのGETだし、どのみちオリジンサーバーから見ればCDNからのリクエストだから一緒

**デフォルトの名無しさん** · 2025/05/21(水) 10:46:48.11

MITM

**デフォルトの名無しさん** · 2025/05/28(水) 04:53:46.40

つるつるわれめ

**デフォルトの名無しさん** · 2025/05/30(金) 13:31:36.30

梅八日

**デフォルトの名無しさん** · 2025/06/02(月) 21:47:55.19

適当なんだけどこれであってる？
肯定/訂正してくれたら嬉しい

1. ローカル変数(sliceはそのヘッド)はescape analysisでスタックやレジスタ割り当て
2. ヒープの頻繁確保解放は総量上限が分かるならプール
3. ロジック的に寿命が長いやつはそもそもGC影響は軽微

**デフォルトの名無しさん** · 2025/06/02(月) 21:51:04.00

配列/スライスの添え字アクセスは境界チェックされる

**デフォルトの名無しさん** · 2025/06/02(月) 21:52:50.52

dangling pointerは発生しない

**デフォルトの名無しさん** · 2025/06/05(木) 21:11:14.75

Go言語がエラー処理構文の導入を「一旦諦める」と宣言 — 7年にわたる検討の末コンセンサス得られず
https://techfeed.io/entries/6840c4096749026b87829bb9

**デフォルトの名無しさん** · 2025/06/05(木) 21:36:51.37

今のままでいいぞ。例外処理はワイには100年早い

**デフォルトの名無しさん** · 2025/06/05(木) 23:37:51.96

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

これでスッキリだろ
生理的に許せんならフォーマッタ使えで終わるし(逆も然りだが)

**デフォルトの名無しさん** · 2025/06/06(金) 00:36:59.99

printしてpanicしてエラースッキリ

**デフォルトの名無しさん** · 2025/06/06(金) 00:55:09.52

>>994
フォーマット以前にサンプルとはいえそんなクソコードを書くやつのほうが生理的に許せんわ

**デフォルトの名無しさん** · 2025/06/06(金) 00:56:27.07

go lint

**デフォルトの名無しさん** · 2025/06/06(金) 01:10:46.44

>>996
それは俺も思ったが、ここで言う意味もあるまい
(もし俺がサンプルを作ったと勘違いしてるのなら、リンク先確認しろ)

**デフォルトの名無しさん** · 2025/06/06(金) 10:14:03.88

IDEに見た目の折りたたみさせればよくね

**デフォルトの名無しさん** · 2025/06/08(日) 09:10:52.84

質問いいですか？

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 1197日 1時間 27分 33秒