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/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秒