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/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に戻ってるしさ。

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

ホントにあんまり知らんのだろ。
恥かく前にやめとけ。

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

シリコンバレーって所でPythonから移行が進んでるそうです

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

yieldが必要なコルーチンとは全く関係なく、昔で言うグリーンスレッドを超低コストで実現してるという方が正しい。
エアプしてる時間があったらスケジューラの動きとか調べてみたらいいよ。

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

スレッドプールとかが効いてくるネイティブスレッドではなくて、あくまでグリーンスレッドだからな。

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

>>784
ここで言ってるメニーコア環境がXeon PhiなどではなくXeonやEPYCのようなパッケージのコア数の向上とそれを積んだ大規模分散環境の話だって伝わってないって事は分かった
どこまで適用できるかって話に関してはG社が自分とこに使えればそれでひとまずOKというラインがあるのでそっから先は知った事ではなくて良いのでは？

↑は >>785 にも続く話だけど現実的でないとか上手く行ってないとか結局それが現実的でなく上手くいかないタイプの分野・会社に君がいるだけじゃないの？と思ってしまうよ

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

メインスレッドすらグリーンスレッドで、数本立ってるネイティブスレッド上でタスクを持ち回りで実行してるから、await asyncは自動的にされてると思って良いぐらい。

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

>>784
コルーチンを指向していたならchannelなんて使わんだろう。
どっちかというと軽量プロセスの方向性。

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

>>788
> グリーンスレッド
この言葉は初めて聞いたが、確かにJavaやRubyでは普通に使われてる言葉らしい。意味は確認した。
なるほど、スレッドだと論理CPUを跨げるので、その部分がOS管轄になるから重いのか。

goroutineがグリーンスレッドなら、マルチコアだと全く性能が出ないな。
まあそれはいいとして。

なら、そもそもネーミングが悪いよ。
gogreenthreadとか、まんまの名前の方が良かったよ。
（ただしGoは意図的に他言語に合わせてない部分があるからここもかもしれんが）
確かにthreadではないのは理解した。

>>790
> Xeon PhiなどではなくXeonやEPYCのようなパッケージのコア数の向上とそれを積んだ大規模分散環境の話だ
いやそれは同じだぞ。少なくともプログラミングモデルは変わらないだろ。
実は俺は785投稿した後に、「あ、もしかしてNiagara等（有名なのは京)のCPU内メニースレッドの話か？」と思ってしまったが、
そうじゃないのならそっちも間違ってるぞ。
上記の通り、それだとgoroutineでの性能向上は不可能だ。

そしてグリーンスレッドだというのなら、CPU内メニースレッドには非常にマッチする。
実際Niagaraとか64スレッドだが、正直64スレッドなんて普通のthreadでは埋めきれないし、
それ向けにプログラマが積極的に切り出せ、というのは技術的にはかなり納得する。
だからグリーンスレッドの多用での性能向上を目指した、というのが合ってるんだと思うよ。

その後の話はその通り。
確かに俺にとって有用ではないから俺は使わない、で終わりだ。
やってる連中はそれが役に立つと思ってるからやってるだけ、というのは確かにそりゃそうだ。

**デフォルトの名無しさん** · 2020/11/01(日) 12:02:49.50

> > グリーンスレッド
> この言葉は初めて聞いたが、

ええっ！？

**デフォルトの名無しさん** · 2020/11/01(日) 12:21:49.13

>>791
まあとにかくgreenthreadだというのは理解した。
（仕様を確認したわけではなく、そちらの主張通りの方が色々辻褄が合うからそうなのだと思う）

> await asyncは自動的にされてると思って良いぐらい。
それはgreenthreadの話ではなく、他の普通のマルチスレッド言語は全部そうだよ。
実際、PHPが使いやすいのはこれだし。
むしろJSだけが異端。ただし、俺はあれはそうする意味があったと思っている。

>>792
> コルーチンを指向していたならchannelなんて使わんだろう。
これは間違い。
コルーチンならyieldだけであり、channelでも全く問題なく機能する。

そしてchannelにするのは、(君はおそらく完全なソフトウェアプログラマだから理解出来ないのだろうが)
一般的には共有メモリを使わせず、一番速い同期機構にする為。通常はそれがchannelだとされている。
ただし共有メモリが遅くなるのはキャッシュコヒーレンシがらみであり、
greenthreadなら共有メモリ同期でも全く遅くもならない筈だから、本来は禁止にする必要もないし、チャネル縛りにする必要もない。
（実際Goだと禁止も縛りもされてなかった気はするので、言語的には辻褄は合ってるが）
ただし間欠動作ではない為、mutex等の同期化機構は必要で、それも嫌だというのならチャネルになる。

> どっちかというと軽量プロセスの方向性。
これは俺はそう言ってる。

**デフォルトの名無しさん** · 2020/11/01(日) 13:36:21.44

>>791
ちなみにgreenスレッドスイッチは何で起動してるか分かるか？

なおgreenthreadについてはありがとう。これだと色々辻褄が合う。
781のブログも、「そもそもgoroutineってそんなに使いたいか？」という疑問があったのだが、
greenthreadでchannel同期なら、実装は単なるFIFO＝リングバッファだから原理的に最速だ。
だから何でもかんでも「goroutineに出来る物はgoroutineにする」という方向性で悪ノリしたくなるのは分かる。
ただ、2KBはオーバースペック過ぎるから、それで頓死するのも分かる。

さてスレッドスイッチ、理想的にはキャッシュミスでgreenthreadスイッチが行われればいいのだが、
現状のx86ではこれは出来ないよな？
そもそも例外はOSに行ってしまうし、キャッシュミス時はそのCPUスレッドはそこでストールしてしまう。
一番近いのはTLBミス例外だが、それもOS行きだ。
ページフォールトしていたらプロセススイッチで終わり、
していなければそのまま処理が返ってきてキャッシュが充足されるまでストールしたまま待たされるはずだが、
そこでCPUが遊んでいる時間を他greenthreadで埋めてしまえ、というのは思想としては分かる。
ランタイム側で「TLBミスからの復帰」だと分かればgreenthreadスイッチ可能だが、
一般的には例外からの復帰はユーザープロセスからは見えないだろうから、おそらくカーネルに手を入れないと無理だ。
それでもやってしまえば面白い。ただ、この場合にgreenthread間でスラッシングした場合は悲惨なことになるが。

というわけで、スレッドスイッチ起動のネタは分かるか？
従来通りタイマなら、面白くもないがまあ、というところ。
greenthreadで最小構成ならスレッドスイッチのコストはPC/SP/Flags復帰分＝関数1回呼び出し分でしかないから、スイッチし放題ではある。
だから豆にスイッチしまくりというのも面白いが、それでもキャッシュミスでのストールは避けられない。
そこでハードウェアサポートがあってキャッシュミス時にgreethreadスイッチが出来れば圧倒的に面白くなるが、
現状のx86だと出来ないよな？

**デフォルトの名無しさん** · 2020/11/01(日) 13:38:20.89

>>781
goだとスタックを動的に自動拡張するのが味噌
ケチってるんじゃないよ
関数呼び出し時にフレームをチェックして増量する

**デフォルトの名無しさん** · 2020/11/01(日) 13:40:27.88

>>781
あと10K問題とか勉強してからにしたほうが恥かかないよ

**デフォルトの名無しさん** · 2020/11/01(日) 13:43:22.40

>> どっちかというと軽量プロセスの方向性。
>これは俺はそう言ってる。

なんか言っていることがむちゃくちゃ。コルーチンの話はどこ行った？
そもそもchannelはコルーチンじゃ無理だろうて。

**デフォルトの名無しさん** · 2020/11/01(日) 13:47:11.06

>>797
それはわりとどうでもいいな。
だったらgoroutineの初期値も0であるべきだよ。
スレッド同期に2KBなんて普通は必要ないし。

とは781のブログからなら思うが、要はそんなケチ環境は相手してないって事か。
まあそれもありだな。

**デフォルトの名無しさん** · 2020/11/01(日) 13:58:10.45

>>769
問題はポインタそのものじゃなくて型の要件を満足しない型無しnilだしな。

nilポインタ禁止にすりゃ良かったのに。

**デフォルトの名無しさん** · 2020/11/01(日) 13:58:56.68

>>793
マルチコアで性能が出ない理由がわからん。
複数コアでタスクが空き次第実行してるから、単一コアのグリーンスレッドとは全然違ってフル回転するぞ。

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

>>795
phpはマルチスレッドと言うよりもマルチプロセスだろ。
他のマルチスレッド言語は言語によって全然違うよ。
pythonなんかは最近aioが整備されたじゃん。
select使うかどうかじゃね？

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

>>796
コンテキストのスイッチとスケジューラはなかなかなるほど賢いなって思うぐらいのアルゴリズムになってるから、俺が説明するより本家読んできたほうが為になるぞ。

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

なんで性能向上が不可能なんだろ。
goroutineがたくさん起動する状態だと、同じような処理がタスクの切れ目でスイッチされることになって、キャッシュのヒット率も低くないし、ブランチ予測もそれなりにあてになる状況だろ。
GILかかる言語でもあるまいし。

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

切り替えについてはこの辺が良いんじゃないか？
https://morsmachine.dk/go-scheduler
https://niconegoto.hatenadiary.jp/entry/2017/04/11/092810

**デフォルトの名無しさん** · 2020/11/01(日) 16:52:55.99

>>806
確認した。（日本語版だけ。英語版は後で読んで少なくとも感想は返す）
スライド若干間違ってる、というかこいつ自身同期分かってねえ感じだが、ソフト屋ならこんなもんだろう。
ただいずれにしろ結論として、「共有メモリは遅いから使うな」で良いし、実際それ以上の理解は現実的に必要ない。

>>805
話がずれているのは俺がgreenthreadの定義を狭く捉えすぎていたからだな。
その記事で言う N : 1 だと思っていた。
これまでの俺のgreenthreadについての書き込みは全てこの定義だ。
だから当然他CPUを掴めないので高速化しようがない。

ただしGoが M:N なのは分かった。
しかしこの場合にCPUを跨ぐ為には当然OSのサポートが必要で、
当然そのスライドでもメッセージをkernelに投げてる。

問題はM:Nだと大して美味しくもないことだよ。
いや、Go界では当然凄く美味しいことになってるんだろうけど、N:1だと使える爆速最小実装がまるで使えない。
なら次段階は通常は「常に同一コアに割り当てるスレッド」をグルーピングしてその間だけでもこれを利用しよう、となるところだが、これもやってない。
勿論こんな事をやると思想に反するからだろうけど。

ただまあ、思想として、スケジューラ周りをランタイムに丸投げして「どんなスケールでも最大効率」を目指してるのは分かった。
とはいっても、メッセージをkernelに投げざるを得ない構造になってるから、改善余地があるとすればスケジューラ程度でしかない。
そして、俺は別段OSのスケジューラが間抜けとも思えないけど。
あれ、CPUが余ってたら振ってくるだけだし、実際演算とかで100%CPU掴む環境ならそれで必要十分だからね。
あるだけよこせならpriorityを上げればいいだけだし。

あと強いて言うならスレッドのスタックサイズが小さく済むことか？
しかしあれ、俺は知らんがthreadがOS管轄ならOS単位でしか指定出来ないものなのか？
それも奇妙だと思うから、普通はシステムコール時に引数与えて指定出来て然るべきであって、
今のLinuxがそうなってなくても当然いつかそうなるものだとも思うけど。
少なくとも.NETはnew Treaadでスレッドの最大サイズを指定出来る。
こいつもランタイムが管理するスレッドかもしれんけどさ。

**デフォルトの名無しさん** · 2020/11/01(日) 16:54:30.98

ってなんなのこの流れ

**デフォルトの名無しさん** · 2020/11/01(日) 17:03:11.92

毎度恒例の一人語り祭り

**デフォルトの名無しさん** · 2020/11/01(日) 17:12:55.06

>>807
ソフト屋ソフト屋と言ってるが、何屋なんよ。
解ってないと言うか、お前が何か変な想定してると思うぞ。

M:Nで、かつスケジューラがまともな場合、に関しては相当美味しいと言う事が理解できて、スケジューラのソースはgithubにあるはずだが、読んだ？
stealは無差別にstealする訳じゃないぞ。

1コアあるだけよこせだと、IOバウンドな処理の時に勿体ないでしょ。

小さく済むと言うか、バカほど立てられるんよ。
.Netの話はネイティブスレッド。お前ホント理解できてないのな。

**デフォルトの名無しさん** · 2020/11/01(日) 17:13:59.67

>>807
常に同一コア云々に関しては、ソース読め。

**デフォルトの名無しさん** · 2020/11/01(日) 17:19:00.38

>>807
CPUをまたぐ場合にはOSのサポート、もちょっと違うだろ。
あくまでグリーンスレッドで、ネイティブスレッドじゃねえぞ。
システムコールだったり、アトミックに処理ができるだったりでタスク覗くときにどうなってるよって話じゃねえの？

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

マジで自演人形劇はやめとけって
どんどん病気がひどくなるぞ

**デフォルトの名無しさん** · 2020/11/01(日) 18:37:50.76

>>810
> M:Nで、かつスケジューラがまともな場合、に関しては相当美味しいと言う事が理解できて
俺は別に美味しいとは思ってないぞ。
M:NならOSのスケジューラと大差ない筈だし、
実際ランタイム判断でN:1に出来る状態でもNodeに負けてるだろ。
カッコイイスケジュールをやりきるより、スケジュールなんてしない、の方がシンプルで速いんだよ。
Goは例の「一方ロシアは鉛筆を使った」のアメリカ側をやりきってる感じがある。
とはいえそれもソフトウェア全体の成長の芽の一つだから、やること自体は頑張れ、でしかないが。

> スケジューラのソースはgithubにあるはずだが、読んだ？
読んでねえよ。ただ、読む価値ねえから読まねえよ。遅いスケジューラなんて意味ねえし。

> Netの話はネイティブスレッド
つまり普通のスレッドだろ？ならWindowsはスレッドのスタックサイズを指摘出来ることになる。
Linuxでこれが出来ないとも思えないので、goroutineは軽いんです、なんて利点はなくなると思うが。

>>812
そりゃお前が理解出来てないと思うぞ。
上述の通り、スライドでもメッセージをkernelに投げてるだろ。
そこを同一CPU内にディスパッチされた場合にのみN:1専用超軽量ルーチンで処理するよう、
スレッドスイッチの際に全部張り直す、というのもありだが、実際それやってても大して速くないと思うぞ。

そこは本来はプログラミングモデルを明示的に変えないと駄目なんだよ。
同一CPU内でのみ動作するスレッドであれば、スイッチのコストはほぼゼロだから、がんがん切り出して問題ない。
一方、メッセージにkernelを挟む必要があるのなら、それはそれだけでコストがかかるから、何でもかんでも切り出したら余計遅くなる。
だから本来は goroutine のみではなく、 golight とか、N:1スケジュール専用のgoroutineを用意しないと駄目なんだ。
それがなくて全部goroutineで扱うから全体的に遅くなってしまう。それがブログ主がやった事だよ。
ただこれを分離するのは思想的にやりたくないんだろ？ならそこが限界だよ。

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

>>806
さて英文の方も読んだ。

なるほどGCの為にスレッドの動作状況を調整する必要があるから、スケジューラはどのみち内部に必要なのか。
これは俺はCでしかスレッドを使ってないから気づかなかったわ。
ただその後GoはノンストップGC入れたと聞いたから今は要らんだろとも思うが。

Syscallの時にハンドオーバーしたいのは、ぶっちゃけもう一つthreadを立てておけば済む話だよね。
(GOMAXPROCSをCore数ではなく、Core数+αにする。ただしそれに似たような話は書いてあるが）

内容は日本語版と同じだね。そりゃそうだが。
ただ、英語版の方が確かに実装した理由が書いてあったから読み物としては良いが。

**デフォルトの名無しさん** · 2020/11/01(日) 20:36:44.54

>>814
スケジュールなんかしない、って全然ありえないんじゃないか？それこそ非同期の時代に。
Nodeにはだいたい勝ってるかと。

読んでもないのに読む価値がわかるとは凄いな。

スレッドのスタックサイズが問題ではなくて、ネイティブスレッドか否かが問題なの。アホか？

だから、スレッドではないから、スイッチのコストが全然違うの。
goroutineはスレッドのようなものであって、スレッドではないからそもそも切り替えのコストがほぼない。
だからガンガン切り出していいの。
なんにも聞いてないのな。グリーンスレッド勉強になったんじゃないの？

**デフォルトの名無しさん** · 2020/11/01(日) 20:37:48.97

>>815
もう一つスレッドを立てるとか言う観点がナンセンス。
何度も言うがgoroutineはスレッドのようだがスレッドではない。

**デフォルトの名無しさん** · 2020/11/01(日) 20:48:36.50

古いPerlスクリプトをGoogle Compute Engineの無料枠で動かそうとしたら
cpanのDBD:mysqlのmake時のテストで多分メモリエラーで落ちた
いい機会だからgoで作り直すことにしたわ(´・ω・｀)

**デフォルトの名無しさん** · 2020/11/01(日) 20:53:11.08

一応調べたぞ。

スレッドのスタックサイズは、
.NETのはデフォ1Mで最小値はシステムによるがVista(.NET2.0)なら256KBだそうな。
それより新しいのはよく分からんがこの雰囲気だと64KBか。
https://docs.microsoft.com/ja-jp/dotnet/api/system.threading.thread.-ctor?view=netcore-3.1#System_Threading_Thread__ctor_System_Threading_ThreadStart_System_Int32_
https://docs.microsoft.com/en-us/windows/win32/procthread/thread-stack-size

pthreadはこちらも具体的には書いてないから推測になるが、
oracleが16KB指定してるし、MANPAGEにも書いてあるからここまでは行けるのは確実。
オーバーフロー検出の項目で1ページ以下にも指定出来るとあるから、
スタックサイズは4KBかそれ以下にも指定出来るとも思われるが、断定は出来ない。
https://docs.oracle.com/cd/E19253-01/819-0390/attrib-45427/index.html
https://linuxjm.osdn.jp/html/LDP_man-pages/man3/pthread_attr_setstacksize.3.html
https://linuxjm.osdn.jp/html/glibc-linuxthreads/man3/pthread_attr_init.3.html

いずれも起動時にパラメータでスタックサイズを指定出来る。

**デフォルトの名無しさん** · 2020/11/01(日) 20:58:17.56

>>819
それはネイティブスレッドな。

**デフォルトの名無しさん** · 2020/11/01(日) 21:30:51.41

>>816-817
実際Nodeに負けてるのは事実だし、あのブログ読んで技術的に俺は納得してる。
782も納得してるし、他の連中もあの貧弱環境ならそうだな、となると思うが。

ちなみに当たり前だが全ての環境で全敗するわけではないぞ。
俺も数年前に味見でPHP/Node/Goで同じものをPCのXAMPP上で試したが、
GoはNode比2倍、PHP比6倍のパフォーマンスが出た。
（僕のカワイイGoを虐めるな！って感じだから、、これを言ったら満足するか？)

それで俺はPHPで行くことに決定した。
PHPのパフォーマンスで俺には十分だったし、無料鯖は現状PHPのみだからだ。
そしたらGoでやってた奴が「ゴラアふざけんな！」って言ってきたが「知るかボケ」と返した。
あいつはPHPの糞コードがこれ以上世の中に増殖するのが許せなかったらしい。
実は本当はNode無料鯖が大量にあればNodeにしたいのだが、今はそうではない。
よって糞とは分かっているがPHPだ。
ただ、そのGo使いは「Goなんて遅すぎ、Rust行くわ」と言って今はRustでやってるよ。
そりゃパフォーマンスだけで勝負するならRustになるし。

静的なコンパイル言語なんだからスクリプト言語と比べて速いのは当たり前。
それが貧弱環境だと覆るのはアーキが悪いんだよ。
そして何故そうなるのかを色々理解した上で、それぞれが用途に適したものを使えばいいだけ。
今のところ俺がGoを使うことになる芽はない。だからって何だよ、でしかないとは思うけど。

最近のお前らがよく分からんのは、言語べったりで言語と心中しようって奴が多すぎることだ。
お前の使ってる言語が良くても悪くてもお前の成果でもないし、悪口でもないだろ。
ぼくがつかってるげんごすごい＝ぼくすごい、なのはゆとり特有な気がするが、
何故お前らがそうなるのかさっぱり分からん。

**デフォルトの名無しさん** · 2020/11/01(日) 21:50:55.32

>最近のお前らがよく分からんのは、言語べったりで言語と心中しようって奴が多すぎることだ。

なかなかの妄想力

**デフォルトの名無しさん** · 2020/11/01(日) 21:54:59.97

後半完全に何言ってるのか分からん
病気じゃないのかお前

**デフォルトの名無しさん** · 2020/11/01(日) 22:00:10.95

>>821
PHPは歯ブラシとしては優秀だからな。
それは認めるわ。

ただ、XAMPPとか無料鯖とか言ってる次元で意味がわからん。
普通自鯖だろ。

ちなみにRustが持て囃されてるのは、早いからではなくて安全だからだぞ。
大量の並行処理をさばくならGoの方を俺は選ぶが。

言語べったりと言うが、このスレはGoのスレなんだし、そもそもお前が他の言語に対して理解がなさすぎて、何でも自己流の解釈するから頭おかしい結論になるんじゃねえか？

**デフォルトの名無しさん** · 2020/11/01(日) 22:05:20.17

病人構うな

**デフォルトの名無しさん** · 2020/11/01(日) 22:20:51.95

お前らな、「グリーンスレッド？知らんかったわｗ」の時点で気付け

**デフォルトの名無しさん** · 2020/11/01(日) 22:45:13.37

わざわざgoスレに乗り込んできて何がしたかったんだろ

**デフォルトの名無しさん** · 2020/11/02(月) 08:42:57.13

スレッドのようなもので、スレッドではないって言ってんのに頭の中スレッドでいっぱいだから理解もできてないし。
何なんだろうなホントに。

**デフォルトの名無しさん** · 2020/11/02(月) 11:21:06.04

勢いがあってよろしい

**デフォルトの名無しさん** · 2020/11/02(月) 12:09:27.63

goroutineのオンリーワンは当分揺るがないだろな
同接数十万以上とかのWebAPI作るならgolangが第一候補
そこまで性能が求められない場合では、保守性からJavaとかNodeみたいな人員調達容易な言語

**デフォルトの名無しさん** · 2020/11/02(月) 13:55:39.65

Gopherくんがキモいのが全部悪い

**デフォルトの名無しさん** · 2020/11/02(月) 16:49:39.29

Gopherキモいのが何もかもダメにしとる

**デフォルトの名無しさん** · 2020/11/02(月) 17:41:48.74

Go書けるまともな人相当少ないからかなり美味しいんだよな
世の中の人プログラミング苦手なのか？と思ってしまう
スクリプト言語かいてイキってた人達が沈黙したし

**デフォルトの名無しさん** · 2020/11/02(月) 19:04:40.88

この10年ぐらいはスクリプトでイキリがほんと多くてウンザリした

**デフォルトの名無しさん** · 2020/11/02(月) 21:24:24.64

>>816
君がその程度の理解なのは理解した。
ただそれはGoの思想「何でもかんでもgoroutineに切り出せば自動的に速くなります」なのだろうからGoUserとしては悪くない。
しかし現実にはNodeに負けてる、ってこと。

君らの問題は、何故それが起きるのか理解出来ないことだ。
これは806のスライド作った奴もそうだが、何故遅くなるのか、何故速くなるのか、理解出来てない。
ただ、そう教えてもらったから、という知識しかない。

しかしこれもそんなに酷いことではない。
最近は複雑化したハードウェアに対応する為に、ソフトウェアも複雑化してる。
学生では単純に知識量が追いつかない。
となるといわゆる正しい作法で洗脳する、というのが現実的な解で、
それがJavaでのオブジェクト教、Goの場合はgoroutine教なのだろう。
しかし既に言ったがchannelしか使わないのなら現実的にそれでいいんだよ。理由は分からなくても。
ソフトウェアを資産として捉えた場合、正しい作法で書かれた物が大量にあることが重要であり、
君らがGo流の正しい作法で書くのなら、それはGo界の資産となる。だから貢献してる。

**デフォルトの名無しさん** · 2020/11/02(月) 21:25:09.49

問題は、その程度の理解なのに限界領域の最速を目指せると勘違いしていることだ。
それは無理なんだよ。ハードウェア上で動いているのだから、ある程度のハードウェアの知識がないといけない。
実際、Nodeに負けてるのも、その理由も、君には理解出来ないんだろ。

なおNodeのはスケジューラとは言わない。ああいうのはキューという。積まれた順に吐いているだけだから。
あれをスケジューラと呼ぶのは、まともなスケジューラ作ってる(つもり)なGoの連中に対しても失礼だ。

ただそこで負けてるのはやっぱりアーキが悪いんだよ。
スケジューラを入れると、一般的にディスパッチの際にその分オーバーヘッドが入る。
だからディスパッチされるジョブが小さければ小さいほどそのオーバーヘッドが大きく見えてしまう。
それは「goroutineで何でもかんでも切り出せ」という思想と矛盾してしまうだろ。
だからNodeに負けた。

**デフォルトの名無しさん** · 2020/11/02(月) 21:25:43.73

C界で有名な話で、「K&Rのmalloc(30行程度)に勝つ為には5000行のコードが必要だった」というのがある。
https://www.wdic.org/w/TECH/malloc
何もやらないのが一番速いから、シンプルなソフトウェアはそれだけで速い。
OSのスケジューラもほぼキューでしかないはずで、Nodeと同様に「積まれた順に吐くだけ」だけど、
逆に、それでいい領域であればそれ以上のスケジューラを持たせても原理的に勝てない。
それがNodeに負けた理由。

JSのシングルスレッドアーキテクチャというのはかなりトリッキーなアイデアではあるが、
ああ割り切ってしまえば世界がシンプルになるから色々省略出来る。
結果、ソフトウェアが全体的にコンパクトになるから思っている以上に速くなる。
それがNodeに負けた理由。

逆にGoの思想でNodeに勝つ為には、「積まれた順に吐くだけ」な馬鹿キューを上回る為に、
「このgoroutineは『いつ』『どこ』にディスパッチすべきか」をきっちり管理しないといけない。
それは今の「空いてれば取ってきます」程度では全然駄目で、上記mallocの戦いなら今はまだ一合目でしかない。
後10倍くらい複雑化してプロファイラーも整備しなければ「シンプルなだけ」のソフトには速度で勝てない。
(プロファイラーを実装したくなければユーザーが明示的に指定するgolightみたいなのがあればいいのだが、
そういうの無しでやりたければ、プロファイラーが要る)

後君らが見えてないのは、複数のCPUを並列/並行動作させるのは実はものすごくオーバーヘッドがあること。
これはx86だと全部ハードウェアがやってくれるのでソフトウェア上では負担がないのだけど、
それはコードから見えないだけで、実際のCPUは止まりまくってるから実行速度はがた落ちになってる。
それがNodeに負けた理由。シングルスレッド限定だとこのオーバーヘッドがないんだよ。

**デフォルトの名無しさん** · 2020/11/02(月) 21:27:00.51

>>830
CPUリソースを余すことなく使う、という意味では原理的にNodeの方が上なんだよ。
本体ジョブしかしないんだから。

ただNodeの場合はマルチコアだと束ねて使うしかない。
これも既に行われているはずだけど、この場合はそれぞれのNode間の直接情報交換は無理筋になる。
(やる場合はDB(或いはエミュレーションレイヤ)経由だが、直接RAM上での交換とは速度では全く勝負にならない)
しかし数十万のコネクションを一度に張って、その間で頻繁にやりとりするって何がある？ほぼ無いよね？
チャットはそうだけど、だからこそチャットアプリでNodeに現実的に負けたあのブログは大きいんだよ。
だからGoUserが噛みついてDisclaimerまで付いてGitHubにまで追いつめられちゃって、になってる。

ただし、実は現実的にはネットワーク出力は一つなのだからチャットでも何でもシリアル処理実装で全く問題ない。
よって根本的にはCPU単体速度>=ネットワーク速度なそこらのPC程度だとNodeでも問題の発生しようがなく、対応出来てしまう。
これはレン鯖等も含めて。
そうではなく、ネットワーク速度>>>CPU単体の速度、な環境ではNodeでは全く無理筋だが、これがどこにあるかだよ。
クラスタで中身は束ねたPC程度だとNodeで全く問題は発生しないはずで、実際それがNode鯖を使ってる連中の使い方だろ。

GoはNodeの思想からすれば盛大に屋上屋を架している。
それでパフォーマンスが出れば大したもんだけど、スケジューラがあの程度ならまだまだ遠いよ。
「CPUが十分速い」という大前提が成り立つ限りJSの思想はかなり筋が良いんだ。
ただそれが1995の時点で見切れたのか、単にラッキーなのかは謎だが。

**デフォルトの名無しさん** · 2020/11/02(月) 21:28:45.62

>>830
と思ったが、オンゲか？
オンゲは確かにNodeでは無理だろう。これは根本的にNode向きではないから。
コネクション単品の処理も重く、コネクション間の情報交換も多い。
逆にコネクション単品が軽いチャット程度だと、goroutineがオーバースペック過ぎてNodeに負けてしまってる。
これはある意味単なる設計ミスで、起動時にもっと小さいスタックサイズを指定出来るようにすれば済む話なのだけど、
それをしないところをみると何か出来ない/したくない理由があるんだろう。
あのブログを出されて噛みつくってのは民度が低くて、スタックサイズを可変にするってのが建設的対応だよ。

ただ、可変スタックサイズなんてやれば出来る話でしかないし、
理由はおそらくスケジューラの性能がその辺だからだろう。
goroutineに切り出すと「スケジューラ」「同期化機構」分だけオーバーヘッドが生じる。
それは「賢いスケジューリング」で取り戻すしかないが、元々軽いgoroutineでは無理がある。
だからある程度重いジョブをgoroutineに切り出すことが必要で、
それ以下の軽いジョブだと到底無理だから消極的に制限してるのだろう。
これだとチャットでNodeに負けた理由も、
またそれでもなおgoroutineのスタックサイズを2KBと巨大なままに保っていることも説明が付く。
実際、データを置かず、再帰も必要な時にしかしないのなら、スタックサイズ2KBなんて埋めようがないし。

**デフォルトの名無しさん** · 2020/11/02(月) 21:30:11.08

長くて読む気がしない
3行にまとめて

**デフォルトの名無しさん** · 2020/11/02(月) 21:34:24.83

>>835
Nodeに負けてるが定量的でないぞ。
お前が書いたNodeのコードに負けてるのであれば、goroutineをどう使えばよいか解ってないお前がポンコツだって事だ。
主観的すぎる。やりなおせ。

**デフォルトの名無しさん** · 2020/11/02(月) 21:44:01.67

また発作か…

**デフォルトの名無しさん** · 2020/11/02(月) 22:10:55.63

>>841
負けてるのは781のブログだよ。詳しく知りたければ読めよ。
俺は彼の分析には納得してるし、その通りだと思ってる。
だから同じような環境なら間違いなく負けるとも思っている。

お前らって（というよりは最近は他言語もだが）
結局Goが「最速最高」じゃないと文句を必ず言ってくるけど、それはないでしょ。
速度ならC/C++/Rustには負けるし、お手軽さではPHPやJSには負けてる。
だからいちいちそんなところで噛みついてくて欲しくないね。建設的な話が出来ない。
完璧な言語なんてないのだから、己の状況でどれが一番ましか判断してそれを使うしかない。
なら、いろんな言語を客観的に見てないと駄目でしょ。

ただ、スレッドで切り離せるところをgoroutineで積極的に切り離せば解があるのではないか？
という着眼点でGoが動いているのは分かった。
確かにこれは面白いし、実際threadはそういう風に使われることを想定されてない。
だからこれをやりたかった人達はネイティブスレッドには文句たらたらだったのだろう。

ただ問題は、同期自体が凄く重いのと、
現存のハードウェアはそういった大量の軽量スレッドを生かす方向には出来てないことだよ。
Niagaraは比較的向いてるけど、SPARC自体が死んでしまってるし、富岳もARMになってしまったからね。

**デフォルトの名無しさん** · 2020/11/02(月) 22:29:00.53

と思ったけど、SPARCはOracleが独自改造しまくってたな。
実際OracleみたいなDBサーバーならGoはハードウェア的にもソフトウェア的にも向いてるのかもしれん。

**デフォルトの名無しさん** · 2020/11/02(月) 22:39:52.04

>>833
>>834
俺から見ればGo使いも十分イキってる馬鹿だけどな。
そしてスクリプト言語使いがイキってるのを止めてる気配も感じないが。特にＪＳ/TS。

ただPHPerは叩かれすぎだとは思う。

**デフォルトの名無しさん** · 2020/11/02(月) 23:27:43.59

>>845
俺から見れば1番イキってるのは君だよ

**デフォルトの名無しさん** · 2020/11/03(火) 00:10:32.82

>>846
そりゃご丁寧にどうも。

ただ、今ここで話した限り、以前の印象「Go使いはC++を使えない馬鹿」ってのを再認識したけどな。
C++も無駄に複雑になって、しかもそれを使いこなすのが目的みたいな勘違い野郎がネット上には増えてるし、
あれはあれでおかしな事になってるが。

ただGoはちょっと立ち位置が悪い。
「端の言語」はとりあえずは生き残れるんだよ。Goはどの面もそこに該当しない。
今なら「最易」枠がPHP/JS/Python。
「最速」枠がC/C++。
「堅牢」枠がJava。
中庸といえば聞こえは良いが、実際に積極的にGoを選ぶ理由がない。
上記の言語はそれなりに糞だと分かってても最○を求めたら他に選択肢がないから選ばれる。
だからのさばってる。

goroutineの思想は確かに面白いが、今はそれを生かせるハードがない。
そしてそのハードを開発させるほど影響力も大きくない。
(ただしGo向けハードウェア開発自体は簡単だから、やる気になればすぐ出来るが)

あとはgenerateだね。
ただしgenerateが向いてるのは下地の言語が全機能を持っている場合であって、(つまりC++)
Goみたいに綺麗に制限されてる言語には向いてないんだな。

**デフォルトの名無しさん** · 2020/11/03(火) 00:18:35.41

↑ キング・オブ・イキリ

**デフォルトの名無しさん** · 2020/11/03(火) 01:02:06.59

>>843
だからスレッドではない。
同期も重くない。
同期しないためのchannelとselectだよ。
もう少し調べてから書け。

**デフォルトの名無しさん** · 2020/11/03(火) 01:05:11.27

>>847
goはバランスをとったのだと思うな。
最易ではphpやpythonに負けるけどそれらよりは速くできる。
最速ではc, c++, rustに負けるけどそれらよりは簡易に利用できる。
堅牢さでは、、、んー、これはjavaに負けてるのかな？rustには負けてそうだけど。

バランスとったから突き詰めたら他のものに負けるのはしょうがない。
0か100じゃないんだからそれでいいと思う。

goの良さはchannelやgoroutineを用いて従来言語よりcsp(communicating sequential processes)を利用しやすくなったところだと思う。

**デフォルトの名無しさん** · 2020/11/03(火) 02:20:11.37

疲れてるのに長い文章読む気もおこらんから読んでないが
>>847 だけ読んで俺は基本的に同意の人間なんだが・・
ちなみにわしはC++が一番好みで最初の数行に同意なんだが
複雑すぎるとか難癖つけるやつが多いがC++が今の形に発展したのには理由がある
哲学、美学先行で必要もなくわかりにくくしているわけではない実用が最優先言語なのだ
Go も正直なんでこんな流行してるのか今一理由がわかんない
これ使うくらいなら既存言語を用途にあわせてチョイスすりゃいいじゃん、ともおもうが
まあ小型のプログラムをサクサクと書くには便利な言語だね
ただし、Go は名前がクソ
あとエラーハンドリングはなんとかしろわりとマジで

**デフォルトの名無しさん** · 2020/11/03(火) 02:32:57.50

　 /＼＿＿_／＼
／　／　　　ヽ ::: ＼
|　（●）,　、（●）、　| 　　／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ　 .:::::| 　　＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐—´´＼

**デフォルトの名無しさん** · 2020/11/03(火) 02:34:49.96

思うに、go言語に未練あるけどもういじりたくない（または理解できなかった）人なんだろうな
どうにかして貶めたいという固い意志を感じる

**デフォルトの名無しさん** · 2020/11/03(火) 07:09:16.22

Goが理解できなかったわ無いわ
こんなのスクリプト言語レベルだろ

**デフォルトの名無しさん** · 2020/11/03(火) 07:45:30.12

>>850
バランスというより、なんか独自進化じゃないかな。
後出しジャンケンでインターフェイスを実装したことにするとか。

>>851
軽量スレッドなんかは既存言語にはできない事だからな。

**デフォルトの名無しさん** · 2020/11/03(火) 12:41:08.52

goroutine はスレッドをダメだこりゃと車輪再発明する暴挙に出た一品
更にスタックが固定じゃ限界があるって考えて魔改造
そこまで無茶苦茶やらかすことで数百万の平行処理を可能とした鬼子
逆を言えば、そこまでしなければ数百万のリクエストは捌けない
デメリットは関数呼び出しからやらかしているためC呼び出しな低レベル処理が書けないという点
WebAPI用途のドメイン固有言語と言ってもいいかもしんない？

到るところでベンチマークが出ていてすら認めたくないのが笑える
https://postd.cc/the-way-of-the-gopher/

**デフォルトの名無しさん** · 2020/11/03(火) 14:25:22.75

erlangなんかはこういう発想で軽量プロセスにしてるよね。
とはいえCouchDBでしerlang使ってないけど。

**デフォルトの名無しさん** · 2020/11/03(火) 19:17:11.84

goは名前とマスコットキャラがダメ

**デフォルトの名無しさん** · 2020/11/03(火) 19:57:00.21

サーバーサイドはGo一択でいいんじゃないか？
速いし運用もこれまでのlinuxの知識があれば問題ない
ライブラリも充実してるし
並行処理も便利
これまでforkを駆使して面倒なことしてたけどしなくて良くなった

**デフォルトの名無しさん** · 2020/11/03(火) 20:15:39.32

goも性能やスケールを突き詰めていくとダメよ。
https://www.atmarkit.co.jp/ait/spv/2002/10/news038.html

**デフォルトの名無しさん** · 2020/11/03(火) 20:58:25.32

>>860
そもそもこいつらが使ってるCassandraなんてまさにGCでフリーズする(笑)はずのJavaなわけで、眉唾な話だな
もうJavaで書けばいいんじゃないかっていう

**デフォルトの名無しさん** · 2020/11/03(火) 21:11:05.72

>>850
> csp(communicating sequential processes)
何ぞそれ？と思ってwiki読んだが、「応用」以前はハア？って感じだな。
応用部分は納得出来るが、それはどちらかというとモデリング＆シミュレーションであって、(従来の)プログラミング言語って感じではない。
勿論それ以前の部分はプログラミング言語としてのCSPについて説明してあるはずなのだが、
大半の連中はこれ読んでも俺と同様「何のこっちゃ？」だと思うぜ。

それはさておき、記述しやすいのは事実だから、cspに金脈があるのならいきなりブレークするのだろう。

**デフォルトの名無しさん** · 2020/11/03(火) 21:21:56.26

>>851
C++の現状に歴史的経緯と必然性があるのは認める。
しかしそれは新しく始める人にとっては関係ない話なのだから、言い訳にはならないだろ。
C++は（普通のプログラミング言語を目指すなら）ちょっと仕様を整理しないと駄目だよ。
ただC++陣営は「全部入り、仕様の整理は各人がコーディングルールで制限しろ」で多分考えてて、
確かにそれもありではあるのだが。
実際、C++を気に入ってる奴って、「俺がこうしたい」を記述する方法があるからだろうし。
他言語で「それは書けない」に遭遇すると本当にどうしようもないからね。

Goが受けてるのは簡単だからだよ。
PHPは簡単だがパフォーマンスと文法が糞過ぎ。
JSは非同期がウザ過ぎ、あとフニャフニャすぎて駄目。
Goは型もあるし！難しくないし！パフォーマンスも出るし！
となるだけ。俺個人はJSのフニャフニャっぷりが気に入ってるのでそこで止まってるが。
型あり言語出身の奴等が上記フローを流されたら順当にGoに行き着く。最近はTSに行ってるかもだが。

**デフォルトの名無しさん** · 2020/11/03(火) 21:22:40.23

あとGoは意図的に「若者の楽園」を目指しているのが、「見た目は」奏効しているかも。
意図的に用語等を他言語と変えていて、既存言語既習者の参入障壁を上げている。
色々あるが今回ならgoroutine、やっぱりあれはgolwp(lightWeightProcessの略)とかが妥当だろ。
それをgoroutineなんて言葉を使うから、thread/lightWeightProcess/co-routine/greenthread等を知っている奴等は余計に混乱する。
ところがこれらを何も知らない若者は全く混乱しない。だから結果的に若者が後れを取らない。

ちゃんと用語を合わせた新規言語（Go以外は全部こうだが）を作った場合、
他言語既習者は文法だけの修得でがんがん進めるのに対し、
新規プログラミング学習者（＝若者）はOOP等の「プログラミングそのもの」の部分で学習に時間がかかり、
早々に頭を抑えられて、結果、「老害」とわめくことになる。

Goのように意図的に既存言語から変更している場合、既存言語を知っている奴等だけが混乱する。
結果的に、既存言語既習者の流入が減り、「老害」が比較的少ない環境＝若者にとって居心地が良い環境になるわけだ。
ただしそれは見た目だけで、実際は人材が枯渇してる。「老害」と共に「老兵」も来なくなるから当たり前だが。
例えば、806のスライド、作ったのは東大の学生のようだが、中身を見る限り、こいつは、
共有メモリを使ったことがないし、それが何なのかも理解してない。
というより多分Goのチャネルしか使ったことがない。
その程度の奴をカンファレンスに呼ばないといけないほど人材がいない。

そしてここで「Goのスケジューラが読むに値するコードだ」と吠えている馬鹿もそう。
その程度のコードをありがたがらないといけないほど全体のレベルが低い。
「空いてりゃ取ってくる」程度のスケジューラなんてすぐ書けるし、
むしろそれすら書けない馬鹿は死ね、なのがC/C++/Rustの世界だと思うが、Goはそうじゃない。
だからこの意味ではGoUserは「イキっている」のを自覚出来てない。

**デフォルトの名無しさん** · 2020/11/03(火) 21:23:08.75

ただこれはGoの仕様だ。
実際いちいちグダグダ言われてもモチベーション下がるし、やりたいようにやらせろ、ってのはある。
そこで若者が天才的なコードを連発出来れば素晴らしい楽園が出来上がるわけだが、
実際はプログラミング自体、才能だけで突破出来るものではなく、地道な修練が必要なものだから、
そうは行かなかった、というだけ。（若いだけでは何ともならない）
結果的に「若者の楽園」＝レベルの低い「馬鹿者の楽園」になってる。ただまあ、それもありだと思うけど。
ただそれによって本来はGo界にも存在したはずの「凄いコード」に触れられる機会を逸していることは認識した方がいいとは思うが。

だから「若者」に受けているだけだとは思うが、実際それも分かる。
今のC++の仕様なんて色々複雑になりすぎてるし、あれ見たら引くだろ。使いもしない細かい仕様が多すぎる。
Javaは無駄に清書させられる、C++は意味不明、Rustはコンパイルが通らん、CはGUIには不向き、ならGoになる。
他のスクリプト言語よりは速いし。

伝わるかな？言い方を変えればユース、サッカーのU21みたいなのをプログラミング言語界に意図的に作ってる。
そこでは若者が馬鹿やってる、勿論レベルは低いがフルレギュで戦ってる大人がそれを揶揄するのは野暮ってもの、みたいな。
実際「共有RAM知りません」「空なら取ってくるだけのスケジューラは凄いです」
（この後投稿するが）「なんとNodeはシングルスレッドでした！」とか、グーで殴るぞ、のレベルだろ。
ただそれでもそういう環境の方が合う奴もいるだろうから、本人が選べばいい。

**デフォルトの名無しさん** · 2020/11/03(火) 21:23:25.98

インメモリなキャッシュと分散データベースでメモリ管理コストが影響する幅は変わるに決まってるし、そうでなくとも実測で改善してるならそれが全てでしょ
ここで比較するならC/C++/Rustみたいな言語で書き切るコストやそれを行える人材を確保するコストに対して、Goのまま書き換えなり他の手段で対処するコストがどうなのかという話だと思うよ
JavaのGCだって今や複数のリリース元から日夜改善されてってる訳で
Go自体は良さがあると思ってるけど他を眉唾だなどと語り貶めす形で話をするのはいい気持ちしないなぁ

**デフォルトの名無しさん** · 2020/11/03(火) 21:23:39.46

あと話を聞いてる限り、新規の若者は「全部の文法」を抑えてから次に行こうとする。
本来はこれが一番効率がいいから当たり前なのだが、
C/C++はその点、古い文法＝今では使うべきではない、というのがそのまま残っていて、
何も知らない若者がそれを活用しようとしてるのが散見される。
んで、「そんなん使うなボケ」と言ったら逆ギレされることが多々ある。
ただこれらも新規参入者にとっては落とし穴でしかないから、ウザイのは事実だよ。無いに越したことはない。
これらが存在する理由はレガシー＝互換性だから、新しい言語なら比較的少ないのも事実。勿論Goも。
だからC/C++なんて最速枠でなければとっくに死んでるよ。C/C++は新規を獲得する努力をしてない。

**デフォルトの名無しさん** · 2020/11/03(火) 21:54:35.32

>それをgoroutineなんて言葉を使うから、thread/lightWeightProcess/co-routine/greenthread等を知っている奴等は余計に混乱する。

名前だけ見てコルーチンみたいなものだろうなんて思い込むうのはおっちょこちょいだろうが
使ってみりゃすぐわかるだろう、普通。

**デフォルトの名無しさん** · 2020/11/03(火) 22:02:11.61

つーか Go の発案者て老人ばっかりじゃなかったっけ？
なんか皆 C++ 嫌い(それもいかにもロートルにありそうな理由)で
それであえてC++的な要素(ジェネリック、継承によるオブジェクトの多態モデル
try..catchスタイルの例外等々)は全部入れないようにしたって話だが
つまり若者向けではなく、モダンなプログラムをやりたいがCではきついので
ちょっとだけモダンになったCっぽいシンプルな言語、みたいなイメージだと思ってた

**デフォルトの名無しさん** · 2020/11/03(火) 22:10:57.27

>>869
多分それで合ってるぞ。
それに若者が食いついただけ。
既にC++使えてる奴は全く食いつかないし、食いつく必然性もない。

**デフォルトの名無しさん** · 2020/11/03(火) 22:17:11.15

今日もイキリの神様が暴れているのか