Go language part 3

**デフォルトの名無しさん** · 2019/10/17(木) 21:38:04.78

Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。

公式ドキュメント
http://golang.org/doc/

日本語訳
http://golang.jp

※前スレ
Go language part 2
https://mevius.5ch.net/test/read.cgi/tech/1510395926/

**デフォルトの名無しさん** · 2020/08/13(木) 19:06:58.68

>>685
google翻訳にぶっこめばいいだろ。
技術屋だったら英語の使い方は勉強しとき。

**デフォルトの名無しさん** · 2020/08/13(木) 19:50:58.84

今なら Deepl がオススメ

**デフォルトの名無しさん** · 2020/08/25(火) 10:24:08.87

すんでで気がついて事なきを得たけど
参考にしたサンプルからコピーしたコードだったんで
context.Background() を、そのまま使ってた
マルチスレッドではWithCancelなどで別々に作ってやらなきゃなんないよな

**デフォルトの名無しさん** · 2020/08/25(火) 14:37:27.29

英語読めないって人って高卒？
受験で勉強すると思うのだが

**デフォルトの名無しさん** · 2020/08/25(火) 23:26:52.17

>>689
Golang Cafe — The Best Place To Find Your Next Golang Job
https://golang.cafe/about
https://twitter.com/golangcafe
https://www.youtube.com/channel/UCq4YrlwwXwF74Z3g-VDae2w/videos

「!gocafe remote」をDuckDuckGoで検索
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2020/08/31(月) 11:00:12.17

ホストがMacなんだけど、dockerでgolang/Fyneを試してみたいんだけど無理かな？
なんかXエラーみたいな感じなの

**デフォルトの名無しさん** · 2020/08/31(月) 13:01:38.43

iOSはBSDベースなんだから余程アップルが魔改造してなきゃBSDと同様な程度にはサポートされてるだろ？
BSDでリリースされてるかどうか知らないんだが

**デフォルトの名無しさん** · 2020/09/04(金) 13:17:23.06

まずgolangに関係のない話
chrome だけかもしれないけど XMLHttpRequest だと単純リクエストなのに CORS に引っ掛かってしまう

で、ここから本題
echo 使ってるんだけど、ハンドラ別に allow なオリジンを切り替えたいんだけど、やり方が分からなかった
orz

**デフォルトの名無しさん** · 2020/09/06(日) 14:36:03.50

a := make([]int, 0)

makeの第一引数って何を渡してるの？
普通のプリミティブじゃないよね

**デフォルトの名無しさん** · 2020/09/06(日) 15:27:49.33

長さだよ。2番目は容量な

**デフォルトの名無しさん** · 2020/09/06(日) 15:50:34.25

[]intが第一引数で、0が第二引数じゃろ？

**デフォルトの名無しさん** · 2020/09/06(日) 19:34:19.64

言語仕様にスライス、マップ、チャネルの型って書いてあるじゃん

**デフォルトの名無しさん** · 2020/09/06(日) 19:37:12.75

その辺は最近のモダンな言語からしたらすげー泥臭い仕様だよな

**デフォルトの名無しさん** · 2020/09/06(日) 20:33:01.20

なんか全体的にそんなところがあるよな。べつに機能的に問題があるというわけじゃないんだが。

**デフォルトの名無しさん** · 2020/09/06(日) 21:12:04.30

"[]int"だとstringだけど、ダブルクォーテーションなしだと何を渡してるんだろうと思って

**デフォルトの名無しさん** · 2020/09/06(日) 21:17:56.45

確かにもやっとしないでもないね
t := []string
とかで型の変数を作れる訳でもないのにポッと出てくる型指定

**デフォルトの名無しさん** · 2020/09/06(日) 21:28:38.24

引数に見えて引数ではない構文の一部

**デフォルトの名無しさん** · 2020/09/06(日) 21:49:44.73

makeは組み込み関数にカウントされてるから、むしろ型を変数として生成できないという縛りなんだな

滅多にmake関数使わないな
チャネルの容量を設定する時くらい
固定長配列なんて作らないし

**デフォルトの名無しさん** · 2020/09/06(日) 21:53:27.07

構文見てて思った

new関数なんてあったのか
使ったことある？

**デフォルトの名無しさん** · 2020/09/07(月) 00:08:24.76

makeが関数でrangeが式なの違和感あるんだよな
逆であるべきなのではと思ってしまう

**デフォルトの名無しさん** · 2020/09/07(月) 00:52:09.45

その辺は一貫性より実用性を重視した結果だろう

**デフォルトの名無しさん** · 2020/09/10(木) 17:49:37.70

go: finding dmitri.shuralyov.com/gpu/mtl latest
go: downloading dmitri.shuralyov.com/gpu/mtl v0.0.0-20191203043605-d42048ed14fd
go: extracting dmitri.shuralyov.com/gpu/mtl v0.0.0-20191203043605-d42048ed14fd
build dmitri.shuralyov.com/gpu/mtl: cannot load dmitri.shuralyov.com/gpu/mtl: no Go source files

● 根本原因
dmitri.shuralyov.com が落ちてるんで GCP のビルドが通らない

● 状況
go.sum 見てみるとfirebaseが要求してるパッケージ
したがって firebase を使って GCP でサービスを提供しているすべてに影響するはず

こまるわー

**デフォルトの名無しさん** · 2020/09/10(木) 17:52:24.85

既存のパッケージがGOPATHにはあるはずなんだけど、どうしたらいい？

**デフォルトの名無しさん** · 2020/09/10(木) 18:01:50.68

firebaseにはissue上げたけど

**デフォルトの名無しさん** · 2020/09/10(木) 18:56:30.40

なんとなくGCPのビルドシステムの問題にも思えてきた
だってGOPATH(~/gopath/pkg)には一式存在してるもん
なんでダウンロード(というか最新版チェックしに行ってる？)できないからってビルドを失敗にすんのよ

**デフォルトの名無しさん** · 2020/09/10(木) 19:25:21.92

いや困ったね…

インポートを辿ったら
https://github.com/googleapis/google-cloud-go
が原因っぽい

個人ホストに依存しちゃうライブラリって、ビジネス的に極めて不味くないか？

**デフォルトの名無しさん** · 2020/09/10(木) 19:46:17.35

個人ホスト？

**デフォルトの名無しさん** · 2020/09/10(木) 20:19:53.75

>>712
dmitri.shuralyov.com って個人じゃないのかな？
企業ってこともあるのか

**デフォルトの名無しさん** · 2020/09/11(金) 00:38:28.29

よかった復活した
そしてやはり個人持ちのホストの模様
ホストでしっくりこないならサーバー
Google Domainsでドメイン管理してるからGoogleCloud上にあるのかも

**デフォルトの名無しさん** · 2020/09/11(金) 20:06:33.99

しかし個人のホストからimportするリスクやばいな
Goチームの人だから許されてるのか？

**デフォルトの名無しさん** · 2020/09/11(金) 20:12:33.09

GitHubかGoogleSourceRepositoryにホストすればいいのにな

**デフォルトの名無しさん** · 2020/09/11(金) 20:20:51.53

う、Google Source Repositoryって、もしかして
source.developers.google.com/p/プロジェクト/r/リポジトリ/...
ってパッケージ名になるのか？長

**デフォルトの名無しさん** · 2020/09/29(火) 08:17:01.67

引数を値渡しするか、ポインタ渡しするか
それが問題だ

sliceは値渡しでも良いよね
要素を追加しようとすると結局新しいsliceが必要
ポインタのポインタとかやりたくないし
stringは普通は変化させる時は新しい物を作るから、値渡しで充分
空を表現するには空文字列で良いし

構造体はどうすべきか
全部ポインタ渡し？

**デフォルトの名無しさん** · 2020/09/29(火) 08:42:58.32

>>718
基本的にポインタで渡すべきと思ってる
値を使うには細心の注意が必要になるから

速度的に有利とかいう話はあるけど
スライスなんかは内部にポインタ入ってるし、文字列だってポインタだから、メンバとしてそれらを持ってる構造体を値渡しするのもナンセンスじゃね？
それらのメンバにアクセスしたとたんにページフォルト起こる可能性があるから、速度面での優位は怪しくなるという意味でナンセンスだろうという
値渡しはスタックに積むだろう(それ以外に方法があるのか知らない)から、スタックを圧迫するはずという理屈も加味

**デフォルトの名無しさん** · 2020/09/29(火) 09:38:24.05

>>719
いや、サイズが大きいのは基本的に可変長であるスライス、string、mapなのだから、それらだけは内部的にポインタを持って実質的に常にポインタ渡しとなるようにしておけば、常に値渡しでもパフォーマンス的にほぼ問題にならんだろうというのがGoの設計意図だよ
個人的には、同一の実体として振る舞うようなOOのインスタンスに近い性質の構造体はポインタ渡し、単なる値の寄せ集めは値渡しとして使い分ける

**デフォルトの名無しさん** · 2020/09/29(火) 15:53:59.37

>>720
ググってみたら、goではスタック足りなくなると拡張すんのか……すげーな

**デフォルトの名無しさん** · 2020/09/29(火) 16:39:20.25

論理アドレス空間ははじめから確保してるんじゃないの？
だったら他の言語と変わらない気が

**デフォルトの名無しさん** · 2020/09/29(火) 17:34:34.66

例えばjavaではStackOverflowErrorになるし、cだと検出すらされない(今は知らない
goでは関数呼び出し時にオーバーフローをチェックして拡張するらしく、初期値は4KBだとか
ほんまかいな？

**デフォルトの名無しさん** · 2020/09/29(火) 17:41:44.13

考えてみれば何万とgoroutine作ってもびくともしないようにするには、それくらいやらなきゃダメだろうから納得すべきか

**デフォルトの名無しさん** · 2020/09/29(火) 20:23:20.93

>>723
1.4までは8kB、今は2kB
1.4リリースノート

**デフォルトの名無しさん** · 2020/09/29(火) 23:23:58.36

>>723
>cだと検出すらされない(今は知らない
今でもOS任せですよ。Windows だと例外としてキャッチできますが。

**デフォルトの名無しさん** · 2020/09/30(水) 05:11:09.54

Elixir は、10万の小プロセスが、並列で動く

結局、Rust, Elixir は、普及のキャズムを越えられなかったから、
Go の1強になってしまったけど

**デフォルトの名無しさん** · 2020/09/30(水) 05:27:53.12

かえすがえすも、名前がイケてないのが悔やまれる
もっとマシなネーミングをできなかったのか

**デフォルトの名無しさん** · 2020/09/30(水) 12:14:35.40

では、Gopher言語でよろしいか

**デフォルトの名無しさん** · 2020/09/30(水) 12:40:46.26

ごふぁっ、ゲホッがはっ、ゴホゴホッ

**デフォルトの名無しさん** · 2020/09/30(水) 18:10:46.15

正直goって流行っている感じじゃないんだよなぁ
めんどくさいし

**デフォルトの名無しさん** · 2020/09/30(水) 19:21:27.15

むしろGoよりめんどくさくない言語の方が少ないだろ

**デフォルトの名無しさん** · 2020/09/30(水) 20:05:41.54

ゴリゴリ書かなきゃいけないという点で面倒くさいけどゴリゴリ書いてしまえるという点で面倒くさくない

**デフォルトの名無しさん** · 2020/09/30(水) 20:17:57.84

Pythonとかの思い付くまま適当に書いたらシンタックスシュガーでなんとなく動く、それを簡単だと言ってるんだと思う

**デフォルトの名無しさん** · 2020/09/30(水) 20:32:41.83

PHPとかの方面の人から見ると、面倒で使えないと思うんだろう
node.jsやらと比べて数倍の性能を叩き出すWebAPIをちょちょいと書けてしまうから手放せない
Webアプリなんて、WebAPIとJavaScriptとHTMLがあればすむ話だからPHPとかやる奴こそ面倒なことやってんなーと思う

**デフォルトの名無しさん** · 2020/09/30(水) 21:03:01.73

>>735
ひと昔前はそれが普通だったからねえ
railsもphpもサーバーがHTMLを組み立てるという思想ありきで生まれたから仕方ない
今その役目は消えたからほぼ全てのフレームワークがオーバースペックになってしまった

**デフォルトの名無しさん** · 2020/10/07(水) 08:43:42.09

Pythonでマップのインデックスで {(a,b): c} とやってるのを見て、ちょっと羨ましく感じた
Goだとタプルは型じゃないもんな

**デフォルトの名無しさん** · 2020/10/09(金) 10:30:34.93

エディタは何使ってる？

**デフォルトの名無しさん** · 2020/10/09(金) 10:40:12.61

VSCode
VSCodeのGoの拡張機能は結構クソだが、Goばかり書くわけじゃないのでGoに最適なエディタはどれかとか興味ない

**デフォルトの名無しさん** · 2020/10/09(金) 10:45:34.46

>>739 ありがとう。使ってみる。

**デフォルトの名無しさん** · 2020/10/09(金) 11:57:27.87

>>740
他のエディタ使ってないからVScode特化の話なのかわからないけど

おかしい動きを見せたら、まずコマンドで Restart Language Server

**デフォルトの名無しさん** · 2020/10/09(金) 12:01:58.43

>>740
それでもダメな場合
Install/Update Tools
全部チェックして実行

**デフォルトの名無しさん** · 2020/10/09(金) 12:20:13.85

VSCODE良いね。
Goプログラマーの仲間入りしました。

**デフォルトの名無しさん** · 2020/10/13(火) 13:52:15.74

>>740
lint使えばvscodeでも快適だぞ
依存しているパッケージも拾って来てくれるから

**デフォルトの名無しさん** · 2020/10/13(火) 16:42:37.40

Goは補完が大事だから他の環境はマジで貧弱すぎる
vim拡張とかこれでコード書いてる人いるのか？と感じた

**デフォルトの名無しさん** · 2020/10/13(火) 23:14:35.57

俺は補完は好きじゃなくて逆に鬱陶しく感じてしまう。
タイピングのリズムというか、今xxxという操作/入力しようとしたのに余計なことすんなと思うことしばしば。

**デフォルトの名無しさん** · 2020/10/14(水) 07:23:06.90

わかりみ

**デフォルトの名無しさん** · 2020/10/14(水) 10:18:40.21

「(」打つと勝手に「)」も入るやつとか
おせっかいに「()」の真ん中にカーソル移動するやつとか
自分でタイプすると hoge()) みたいになってうざい

**デフォルトの名無しさん** · 2020/10/14(水) 10:40:49.08

設定変えろよ無能

**デフォルトの名無しさん** · 2020/10/14(水) 22:53:52.84

変えてるに決まってるだろ

**デフォルトの名無しさん** · 2020/10/14(水) 22:57:57.74

go.modに勝手にgo1.13みたいなものが入ります
やめてほしいですが誰に言えばいいですか？

**デフォルトの名無しさん** · 2020/10/15(木) 00:02:00.61

>>751
ロブパイク

**デフォルトの名無しさん** · 2020/10/15(木) 13:01:09.76

自分で指定すると思ったけど
もしかすると、参照するパッケージに引きずられる可能性があるのか？
パッケージがリンクするランタイムの中で最新になっちゃうとしたらどうしようもないかな

**デフォルトの名無しさん** · 2020/10/15(木) 17:14:56.53

ツールアップデートしたら#41870にバッチリ引っ掛かってしまった

**デフォルトの名無しさん** · 2020/10/28(水) 09:08:16.05

俺はコンパイラが無様すぎると思うんだけど、どう思う？

https://play.golang.org/p/XRFmBiqhqJp

インタフェースAを返すメソッドを持つインタフェースB。

そのメソッド実装がインタフェースAを実装しているポインタを返しても、

./prog.go:34:4: cannot use &Base literal (type *Base) as type IBase in assignment:
*Base does not implement IBase (wrong type for Sub method)
have Sub() *Sub
want Sub() ISub

と、インタフェースAを返しているとは認められない。

**デフォルトの名無しさん** · 2020/10/28(水) 10:08:54.99

天才のお前が新しい言語でも作ってくれよ

**デフォルトの名無しさん** · 2020/10/28(水) 11:33:48.41

C / C++ のプリプロセッサのマクロって
#define A(X, ...) X A(__VA_ARGS__)
みたいな再帰的な処理出来ないけど
この問題昔から指摘されてるのに
40年経っても1000年経っても解決されないよね
解決しようと思えば出来るのに C++ の拡張とかばっかりやってる

**デフォルトの名無しさん** · 2020/10/28(水) 11:46:44.44

>>757 そしてあなたも解決しようと思わないのでしょう？

**デフォルトの名無しさん** · 2020/10/28(水) 11:52:07.24

>>757
「型無しのマクロを使うな。template使え。」という方向だよ。
C++で今さらそんな拡張ありえん。

**デフォルトの名無しさん** · 2020/10/28(水) 12:47:58.74

>>758
解決しようとした人は *ｂｙや python や D を造ってしまいましたね
既存の C/C++ そのものに手を入れるのは中の人以外には無駄な努力に感じます
再帰マクロ専用のぷりぷりプロセッサを書くのは手かも知れません
あと #include __FILE__ でループしてる人はいるようです
https://qiita.com/alucky0707/items/3599cdcf973382df978b

**デフォルトの名無しさん** · 2020/10/28(水) 12:50:42.86

スレ違いも甚だしい

**デフォルトの名無しさん** · 2020/10/29(木) 21:05:36.10

>>760
スレ違いだが通りすがりに言っておくと、
マクロにそこまでの機能を求めるのなら、
自前でスクリプト言語(AWK/Perl/Python/Ruby)等でソースの事前処理をmakefileに書いた方がいい。
それだと無限に機能拡張出来る。

だからC++というかmakefileシステムでそれをやる意味はない。
よってまともな奴は誰もマクロの拡張なんかしようとは思わない。
「言語」にそれを持たせる意味がないから。
(言語による垂直統合ではなく、makefileによる水平分業で全く問題ないし、融通も利く）

ただしGoはそれを標準機能で付けてる。
これがどう役に立っているのかは知らん。
(Go generate、AST木が参照出来るので上記のマクロ拡張とは次元が違うが)

**デフォルトの名無しさん** · 2020/10/30(金) 00:29:21.26

makefieて

**デフォルトの名無しさん** · 2020/10/30(金) 09:21:51.84

知らないだけかも知れないけど、generate が build と分けられてるのが使いづらく感じる
go.mod に generate のパラメーター書いておくと build で実行するとかじゃダメなのかな

**デフォルトの名無しさん** · 2020/10/30(金) 10:57:17.98

Qt良いよね

**デフォルトの名無しさん** · 2020/10/30(金) 11:07:56.86

そもそもプリプロセッサーが何をやっているか考えたら再帰なんかできない事ぐらい分かるやろ
もう相当前のものだしなぁ
逆にC#とかだとCで出来たような事が出来ないから不便だと思った事があるわ

**デフォルトの名無しさん** · 2020/10/30(金) 22:12:31.86

いまどきポインタとかｗｗｗ

**デフォルトの名無しさん** · 2020/10/31(土) 11:21:06.88

今時も何もgolangではポインタはバリ現役
というか、golang使ったことないんだな哀れ

**デフォルトの名無しさん** · 2020/10/31(土) 15:42:09.93

ポインタが散々叩かれて色んな言語で無くしたけど
最近のモダンな言語では復活してきてるのは面白い

**デフォルトの名無しさん** · 2020/10/31(土) 16:08:49.76

ぽ、ポインタじゃねえし！リファレンスだし！

**デフォルトの名無しさん** · 2020/10/31(土) 16:39:03.74

つーか名前をへんてこにして誤魔化すとかじゃなく
リアルにポインタの概念(何かのオブジェクトを指す変数)を消し去ろうとしたら
あらゆるものをコピーでもっといてしかもそれらを常に同期して同じ値になるように
常に維持する仕組みにするしかないがそんな非効率きわまりない言語が実用に値するはずがない

**デフォルトの名無しさん** · 2020/10/31(土) 16:55:27.17

lisp とかってコピーしてないの？

**デフォルトの名無しさん** · 2020/10/31(土) 17:00:05.47

ポインタがない言語ではオブジェクトは参照コピー
プリミティブはコピーというのが最近のスクリプト言語の常識
ただ細かい違いは言語ごとに違ってハマりどころになってる

**デフォルトの名無しさん** · 2020/10/31(土) 17:32:11.09

>>771
全部イミュータブルにすりゃいいんだよ
コピーと参照渡しを区別する必要がなくなる

**デフォルトの名無しさん** · 2020/10/31(土) 17:59:24.46

>>774
全部は極端だ
カウンタはどうするん？

**デフォルトの名無しさん** · 2020/10/31(土) 20:21:41.59

>>775
Haskellはモナドの裏に隠してる
正確にはランタイムと言った方が近いかもしれないが
ていうかHaskellのイミュータブルな配列でもUArray（UnboxedのU）が提供されてるしポインタ・参照・Boxedからは逃れられんよ

**デフォルトの名無しさん** · 2020/10/31(土) 21:01:42.97

>>771
>>773
×　最近のスクリプト言語
○　ポインタを使えないほぼ全部の言語
だよ。C#もJavaも同じだ。

ただ実際のところ、これで大して問題にも遭遇しない。
そもそもCですら . なんてゴリゴリ速度チューニング時以外は使わず、 -> と　[]ばかりだ。
そしてC++で参照(&)が導入され、今君が認識しているいわゆる「オブジェクト参照」は全部これになった。

だから俺はあんまりポインタは必要なくて、 -> を . として結果的に -> しか使えないようにした、
最近のほぼ全ての（というかC/C++以外全部、多分Goも含めて)言語の方が正しいと思ってるけど。
Goも制限付きポインタで、C++の&相当でしかなかった気がしたけど、違ったっけ？

なお、ポインタという「概念」を消し去るのは無理だよ。
これを何故か理解出来ない馬鹿が多いのか、Python使いは無駄に吠えてくるけど、
プログラミングを本気でやるつもりなら、その根幹の実装を理解することは避けて通れない。

>>775
erlangは全部インミュータブルで、ループ(for文）すらなく、全部再帰らしいよ。

**デフォルトの名無しさん** · 2020/10/31(土) 22:40:56.17

c#はunsafeでめちゃくちゃできるけどね
やろうと思わんが

**デフォルトの名無しさん** · 2020/10/31(土) 23:29:32.75

>>778
うん知ってる。
ついでに言うとstructが値渡しで、Cで言う . による高速化もつまみ食い出来るようになっている。
ただしこちらも主な使い方ではなく、実際に効果が出る小オブジェクト(確か16バイト以下）で限定使用することが推奨されてる。
その辺はC#は実用言語だから地味に整備してある。
unsafeもその一環でしかない。

だが結局のところ、その辺の小異に目をつぶればC/C++/C#/Java/Python/JavaScript等の現在の主力言語はどれもほぼ同じで、
C/C++だと直接ポインタを扱える、位の違いしかない。
それはつまらないとして、敢えて独自路線を行ったのがGoだが、ポインタ周りは大して独自でもなかった気がした。
Goじゃないと出来ない/他言語でやると凄く苦労する、てのはないよね？
（というかポインタ自体Cの時点で完成してて、その後は精々間違いを自動検出する方向にしか進化出来てない）

多分Goの売りはgoroutineとgenerateなのだと思う。
ただ俺にはgoroutineがそんなに便利とは思えなかったし、そもそもあれコルーチンではなく単なるスレッドだから名前間違えてるだろ、だ。
generateについてはCマクロをゴリゴリしたい奴には非常に有用なのだろうけど、そもそもそんな奴は多数派ではないし、俺もそうじゃない。
ただしAST木が標準で出せるというのはかなりインパクトはある。
とはいえ、AST木では低レベル過ぎて困るので、本当はもっと上のレベルが欲しいのが大半なんじゃないかと思う。

ちなみに最近の言語でも評価が固まってないのは例外周りで、これは各言語によってまるっきり違う。
Goはドベタにerrを値で返す、仕様としてはCモドキだが、現実的には一つの選択肢だとは思う。
格好良くはないが。

**デフォルトの名無しさん** · 2020/11/01(日) 07:15:14.81

>>779
いや、goroutineはスレッドとは隔絶してるんよ
そしてこの間まで理解してなかったけど
goのスタックフレームつまり自動変数も他の言語とは隔絶
それはgo独自の優位性で、goroutineは初期スタックサイズは今では2kBしかない
そのため、数百万のgoroutineを作成できる
これは巨大なコンテキストを必要とするスレッドでは太刀打ちできない性能なん

**デフォルトの名無しさん** · 2020/11/01(日) 08:14:15.41

>>780
> goのスタックフレームつまり自動変数も他の言語とは隔絶
どこが？サイズだけならCは調整出来たと思ったけど

> そのため、数百万のgoroutineを作成できる
それは既に結論は出てる。
以下ブログ、俺が読んだ時とはだいぶ趣が異なるが、（当時は確か初期サイズ4KBだったはず）
https://github.com/maxpert/raspchat/releases/tag/v1.0.0-alpha
要は2KBでも十分大きすぎて、Nodeの方が断然まし、ってことになってる。

これは当たり前で、Linuxのkernel領域でのスタックサイズが128Bだったか256Bかに制限されているらしいから、
その気になればLinuxは256B/threadでスレッドを起動出来る。
そしてNodeはシングルスレッドだからスタック領域が余すところなく全部消費される。
これはGoではどうやっても出来ないことだ。
というよりJSのシングルスレッドアーキテクチャは最初からこのc10k問題解決を主眼にしてる。
だからその領域ではそれ用に作られたJSに勝てるはずもなく、実際そうだった、というだけ。

goroutineのサイズをケチってどうこう、って作戦は究極にはJSのシングルスレッドアーキテクチャに行き着く。
だからその方向ではNodeには勝てないのは仕様だよ。
そうじゃなくて、言語サポートがあるからスレッドがお気楽に使え、それがgoroutineです！って方が順当で、
実際そのブログの作者も喜んで使ってみたが、思ってたと違う、、、というのがそのブログだよ。

> そのため、数百万のgoroutineを作成できる
数百万のthreadなんて実際あり得ないし、管理も出来ない。
そこをgoroutineならお気楽に生成/消滅出来るので、これまで「面倒/管理が難しい」等でthread起動しなかったところを、
「これは別スレッドでも動く」というだけの理由でお気楽にすべてgoroutineで切り離して行けば一見超並列出来そうに見える。
ただ、実際それをやったらそこで遭遇している問題、つまりgoroutineは思っているほど軽くない、に遭遇してしまう。
現実的にはthreadなんて論理CPU数の2倍程度あればCPU処理だけなら埋まってしまうからそれ以上起動しても意味がない。
I/Oで引っかかった時のスタックサイズをケチりたいのなら、
JSのように非同期でシングルスレッドにする方が原理的に上だし、実際そうだった、というのがそのブログだ。

**デフォルトの名無しさん** · 2020/11/01(日) 09:44:48.65

軽さ速さは環境によって変わる
少コア環境ではM:Nスレッドモデルのgoroutineは有効に機能しない場合がある
少なくともGo開発側はM:Nスレッドモデルに合わせるにはasync/awaitモデルよりスレッド/チャネルモデルの方がいいと判断した

位の話でしょ

goroutineのモチベーションは非同期処理についてG社が持つようなメニーコアかつ分散な環境でスケールするかって話をしないと伝わらないよ

**デフォルトの名無しさん** · 2020/11/01(日) 09:56:36.00

あんまGo知らない、まで読んだ。

**デフォルトの名無しさん** · 2020/11/01(日) 10:42:25.33

>>782
逆に言えばそれ以外の環境では他言語に劣るわけだろ。

元々は多分、命名からして、コルーチンをgoroutineで、ということなのだと思う。
コルーチンは通常は本体側と交代で間欠的に動作する前提で書かれているから、スレッドで切り離すことはしない。
ただ、もしそれが本体と並行に動作可能なら、スレッドとして切り離せば、
本体側が動いている間に次のyieldまで動作させられ、コルーチン部分の処理時間を見た目ゼロに出来る。
実際、大半のコルーチンはこれが可能なはずで、これまでは単に面倒/スレッド生成消滅のコストの為にそこまでやらなかっただけ。
だから、スレッドよりもっとお手軽で軽いgoroutineを用意すれば、という訳だ。

OSでの並行はprocessだが、multi processは重すぎるのでアプリ内processとしてthreadが出来た。
それと同様に、thread内の並行として、goroutineという、もう一段軽い物を用意した。

だからここまでのストーリーは辻褄が合っているとして、それがどこに適用出来るかだよ。
CPUが精々数個しかないそこら辺のPCだと、threadだけで埋めきれるので、普通にそれが最適解になる。
threadだけでは埋めきれないほどのCPUがあり、積極的に並行goroutineとして切り出してくれないといけない、
という、いわゆるメニーコアならGoの方が有利になる可能性があるけど、実際この場合はキャッシュコヒーレンシの問題が発生してくる。
勿論チャネルだし、後はオブジェクトの中身も含めてインミュータブル、
つまりErlangの世界まで行けたらこの辺の問題も無くなるけど、Goはそういう感じじゃないでしょ。
そもそもメニーコアの筆頭のXeonPiも死に体だし。(これはGoのせいではないけど)

**デフォルトの名無しさん** · 2020/11/01(日) 10:42:50.15

だから、>>782の観点だけなら、
Goは素晴らしい実験用言語だったけど、現実的ではなかったね、で終わると思うよ。
実際、Goって使用者は増えてるのか？
Rustは前年度「Rust新規に始めた人数よりCを新規に始めた人数の方が多くなっちまったよオイオイ」とか話題になっていたが。

JSはプログラマに、I/Oを明示的に切り離して高速化することを求め、(実際あの非同期は壮絶にウザイが)現実的にはものすごく機能してる。
Goはプログラマに、並行可能な部分を積極的に切り離すことにより超並行によって高速化を目指している、と捕らえることは出来るが、
実際これは全く上手く行ってないし、今後とも上手く行く気配もないでしょ。
一時期、CUDAよりもXeonPiだ、という時期もあったはずだけど、なんか話題はCUDAに戻ってるしさ。