Go language part 4

**デフォルトの名無しさん** · 2020/11/16(月) 04:14:40.64

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

公式
https://golang.org

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

公式外パッケージドキュメント
https://godoc.org

ブラウザ上で試し書き
https://play.golang.org

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

**デフォルトの名無しさん** · 2021/11/28(日) 13:32:08.20

> 俺はチャネルとgoroutine好きだけど、よく考えるとみんなうまく使えてないんだよなあ・・・

太田道灌

**デフォルトの名無しさん** · 2021/11/28(日) 13:35:20.14

>>730
出来るのは分かるが、使い道がないんだよ。

俺もPromiseは要は予約を積んでるだけなので無限に動的に積んで色々出来るか？と思った事はあった。
async/awaitはその点ハードコードだからそのルーチンしか処理しないし、狭い範囲で確定的だ。
ただな、Promiseに動的にいろんな場所からPromiseを積み重ねないといけないような状況はないんだ。
単にasync/awaitでまっすぐ書くだけで十分なんだよ。

**デフォルトの名無しさん** · 2021/11/28(日) 13:37:04.91

ダメだ完全に発狂しとる

**デフォルトの名無しさん** · 2021/11/28(日) 13:39:44.17

>>731
> 俺はチャネルとgoroutine好きだけど、よく考えるとみんなうまく使えてないんだよなあ・・・
ならお前が上手く使ってる例を布教すればいいだけ。
それが凄く有用で、現行のasync/awaitやPromiseでは実現出来ないものであれば、
Goスゲーって事になるだけ。

JSも2005にXHRが再発見されるまではオモチャ扱いだったし、ワンチャンはあるぞ。

**デフォルトの名無しさん** · 2021/11/28(日) 14:03:02.10

>>733
めちゃくちゃ使うよ。

既にメモ化されたデータがあればそれを使う、そこに無ければ動的にイベントハンドラー仕掛けておいて、一定時間内にそのイベントが発火したならそのイベントの引数を返すが、発火しなければrejectする、みたいな。

async/awaitしか使わない、CPUをきちんと解放しろ、と言う話なら、Goならランタイムが自動的にやるので気にせず同期型のように書いて良いぞ。

**デフォルトの名無しさん** · 2021/11/28(日) 14:08:56.82

>>736
よく分からんからコードで頼む。
君のコードでなくてもいいし、誰かのGitHubでもいいので。

要はその、Promiseでは簡単に出来るが、async/awaitでは無理（または複雑になる)、っていうコードを。

**デフォルトの名無しさん** · 2021/11/28(日) 14:10:43.62

>>735
おれの知識はほぼほぼ「Go言語による並行処理」だから、これを読め、で終わってしまう・・・

**デフォルトの名無しさん** · 2021/11/28(日) 14:37:47.26

>>737
この説明でわからなければ、どーせメリットもわかんないだろうから「めんどくさいコード書くな」で終わるでしょw
実際に使ってる自分のリポジトリ晒すのもアホだし、Zennの記事はっとくわ。

https://zenn.dev/uzimaru0000/scraps/b4445cfed8f42f

**デフォルトの名無しさん** · 2021/11/28(日) 14:39:55.58

こんなんも便利よね。
https://qiita.com/jkr_2255/items/628f0507456eb841497c

**デフォルトの名無しさん** · 2021/11/28(日) 14:44:16.89

async/await(だけ)では面倒で、Promiseと可換だからこそ便利だ、と言ってるんよ。
C#でも皆に臨まれてTask Likeな自作クラスが作れるようになったわけだが、いかんせん大袈裟な作りがいる。

**デフォルトの名無しさん** · 2021/11/28(日) 18:42:46.20

>>739-741
うん、分からんね。ただ君の説
> Promiseと可換だからこそ便利だ
についてはC#はそうなってないからじきに結果は出るだろう。
とはいえヘルスバーグは知っててPromiseは不要だと判断したのだし、俺もそう思えるのだけど。
(ヘルスバーグについてはインタビューがあったはずだがググっても出てこない）

一応各URL内容に対し回答しておくと、
> await click().then(click).then(click)
については、
await click();
await click();
await click();
で、すさまじく馬鹿っぽい事以外の問題点はない。

> 遅れてのセット…Promise#thenはresolve前でもresolve後でも問題なく動く
についてはまあそうなんだけど、これはどちらかというとonload系イベントの問題で、
この方法でも根っこの部分、つまり最初のPromiseを設定する時点で既に onload 済みなら発行されない問題が解決出来ておらず、
結局ユーザー側が onload 済みかチェックする、または絶対に onload 未発行の時点で実行する必要がある。
だから onload 系のイベントが最初から全部 Promise だったら綺麗に解決してたのだろうけど、実際そうじゃないので言うほど利益がない。
Promiseが残るか自前でonload発行をチェックしたフラグが残るか程度だ。

> 複数の条件…Promise.allで取れる
これはその通りなのだけど、馬鹿っぽくてよければ同様に await 縦積み、
await sumefuncA();
await sumefuncB();
await sumefuncC();
で行ける。(C#はこれでいけるはず。JSはもしかしたら駄目かも）

**デフォルトの名無しさん** · 2021/11/28(日) 19:04:46.48

742最後補足＆訂正
JSの場合も縦積みは出来るが書き方が違うようだ。
(というかC#も間違えていたので書き直すと）

await someAsyncFuncA;
await someAsyncFuncB;
await someAsyncFuncC;

となる。以下は https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/async_function より。(720で貼り損なったので)
async function concurrentStart() {
console.log('==CONCURRENT START with await==');
const slow = resolveAfter2Seconds() // ただちにタイマーを起動
const fast = resolveAfter1Second() // ただちにタイマーを起動

// 1. これは即時実行される
console.log(await slow) // 2. これは 1. の 2 秒後に実行される
console.log(await fast) // 3. fast はすでに解決しているので、これは 1. の 2 秒後 (2.の直後) に実行される
}

**デフォルトの名無しさん** · 2021/11/28(日) 20:06:47.00

推してる癖に間違えるくらい千差万別なのね

**デフォルトの名無しさん** · 2021/11/28(日) 20:25:18.89

>>744
間違えたのは俺の問題であって、C#もJSもawaitの書き方は同じ。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/async_function
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/concepts/async/task-asynchronous-programming-model

**デフォルトの名無しさん** · 2021/11/28(日) 20:31:19.41

>>710
一回だけ使うはずなのを二回以上使うと不具合があるのが問題とか言い出したら
副作用のある関数の呼び出しも問題ってことになるよな
「単一の結果の生成をもって完了するというセマンティクス」というのもないし

**デフォルトの名無しさん** · 2021/11/28(日) 20:36:54.41

まあゴル同士で複雑なハンドシェイク的な値のやり取りはしない方が良いね
少なくとも俺はバッドパーツ認定してる
結果をkey-value storeに吐くとかそういう使い方しかしてない

**デフォルトの名無しさん** · 2021/11/28(日) 22:35:18.85

>>746
そうだね
副作用があって2回呼び出したら死ぬ関数より、冪等な関数の方が望ましいよね
だから単一の結果を生成するだけの処理にchannelを使うのはクソだよね

**デフォルトの名無しさん** · 2021/11/28(日) 23:26:53.57

>>748
副作用のある関数もクソということになるだろうって話だがな
呼び出すべきじゃないところで誤って呼び出すと不具合があるから問題だと言い出すんだから

**デフォルトの名無しさん** · 2021/11/29(月) 00:36:52.64

C#おじさんの大暴れ回

**デフォルトの名無しさん** · 2021/11/29(月) 02:15:08.24

>>742
C#もそうなりましたが…。
https://qiita.com/inasync/items/6417933e258b53b5bbd3

こっちでは似たような事やってるね。
https://www.buildinsider.net/column/iwanaga-nobuyuki/009

あんまり知らんだけでは？

**デフォルトの名無しさん** · 2021/11/29(月) 09:11:23.82

>>749
それはその通りで、一般論として、副作用のない関数より副作用のある関数のほうが相対的にはクソだろ？
本来副作用の必要がない場合でも常に副作用のある関数として実装しなければならないとしたら、本来例えば半分程度で済むはずが全てクソ関数になっちゃうじゃん
それがchannel

**デフォルトの名無しさん** · 2021/11/29(月) 11:31:15.42

まあGoの設計思想的としてはそもそも非同期関数を作っちゃいけないんだろうな
常に非同期で使用することが明らかな場合でもchannelを引数に取るような関数をパッケージ外に公開するような設計はすべきじゃなくて、
普通に同期関数にしといて使う側で必要に応じてgoroutine使えということなんだろう

**デフォルトの名無しさん** · 2021/11/29(月) 12:15:00.68

え？goroutineにチャネル渡さなけりゃクロージャで渡すしかないから共通関数にできんし
ちょっと何を言ってるのか分かりませんね

**デフォルトの名無しさん** · 2021/11/29(月) 12:15:45.71

外部関数

**デフォルトの名無しさん** · 2021/11/29(月) 12:23:12.94

ツアーでもチャネル渡すコーディングしてるよ
https://go-tour-jp.appspot.com/concurrency/2

**デフォルトの名無しさん** · 2021/11/29(月) 12:35:27.53

tourはあくまで機能の紹介だろ。
hello worldを実務で書くか？

channelの何が気に食わんの？デッドロックするところ？
別に後続の関数投げても良いんだぞ。

**デフォルトの名無しさん** · 2021/11/29(月) 12:39:01.25

>>754
>>753 が言ってるのはライブラリの公開関数の話で、753のコメント通りでしょ
goroutine使えば同期関数を簡単に非同期にできるから、ライブラリの高階関数は同期にせよ、っていう思想っぽい

標準ライブラリにもチャネルを受け渡しするやつはあるのかもしれないけど、少なくとも俺はしらない

**デフォルトの名無しさん** · 2021/11/29(月) 12:46:47.06

標準のライブラリは低レベル機能しか持たせてないじゃん
だからといって、非同期に使うことは好ましくないという設計思想だとかかなり無理があるだろ
ツアーは基本的な使い方のサンプルなんだから、基本的に非同期で動かす関数を書くにはチャネルを渡しましょう！と大々的に宣言してる証拠じゃないのか？

**デフォルトの名無しさん** · 2021/11/29(月) 13:18:56.71

まだやってた

**デフォルトの名無しさん** · 2021/11/29(月) 13:51:14.56

好きだよね～

**デフォルトの名無しさん** · 2021/11/29(月) 14:19:10.41

>>752
>本来副作用の必要がない場合でも常に副作用のある関数として実装しなければならないとしたら

そんなのがどこから出てきたんだか。
呼び出すべきじゃないところで誤って呼び出すと不具合があるからクソだと言い出すなら
入出力とか、副作用を持つ関数もクソということになるって話だがな
戻り値を変数に入れて置けば良いだけなのにそれを出来ずに
2回呼び出すと不具合が起こると文句を言ってるんだよな

**デフォルトの名無しさん** · 2021/11/29(月) 16:44:46.78

チャネルが理解できないC#おじさんがID変えて自己弁護しながら暴れてるだけ
>>752
「副作用のない関数より副作用のある関数のほうが相対的にはクソ」
一般的には手続き型言語であればサイドエフェクトがある関数が普通で、純関数言語のようなほとんど副作用の
無い関数などはI/O処理などでビックロックなどで誤魔化してるに過ぎない。
>>753
そもそもGoは全部が非同期・並列だから逆。メインでさえgoroutineの１つで、デフォルトでGOMAXPROCS
「channelを引数に取るような関数をパッケージ外に公開するような設計はすべきじゃなく」これも逆です。
structには本来はchannelやcontextを含めるべきではなく、引数に取ることが推奨されている
>>759
「標準のライブラリは低レベル機能しか持たせてない」最近の言語は、標準のライブラリという重大なクソを
薄く小さくするのが流行り、なぜなら稚拙な標準のライブラリをリリースしてしまい、後からもっと効率的で
理論に裏付けされたライブラリが出てくる。そしてクソな標準が互換性のために直せない。薄くて小さい
ライブラリは速く、メンテナンスも容易で、依存性も少ない。
逆に、標準のライブラリに重厚長大を求めるのは何かが間違ってる。チャネルを渡すことを使う事を禁忌したい
気持ちが奥底にあるから「証拠」なんて言葉が出てくる。Tourなどのパイプライン処理とかを見ればチャネルを
受け渡すことの効率性と高い非依存が良くわかる。aync系の言語でやろうとしたらミューテックスでロックして
処理の終わりでwaitしてなど極めて並列度が低く、依存性が高く、ゴミのような自己満足が広がる
だから遅くて成果物はデカい

**デフォルトの名無しさん** · 2021/11/29(月) 19:32:28.88

まぁまぁ、顔真っ赤にして投稿するのやめよ？落ち着こうな

**デフォルトの名無しさん** · 2021/11/29(月) 20:00:58.25

昨日からなにが言いたいのかさっぱり
自分でも頭おかしくなってるんだろうか

**デフォルトの名無しさん** · 2021/12/20(月) 18:58:52.11

Go 1.18 Beta 1 is available, with generics, 14 December 2021

**デフォルトの名無しさん** · 2022/01/07(金) 00:14:05.77

ちょっとかじってみたニワカの感想なんだけど
Go言語ってBetter Cって感じだな。

**デフォルトの名無しさん** · 2022/01/07(金) 00:38:05.83

>>763
チャネルを渡すことに積極的な>>759に、真っ赤になってチャネル渡すコーディングを語ってて草

**デフォルトの名無しさん** · 2022/02/06(日) 12:21:06.60

GoのジェネリックがGo 1.18 Beta 1でデビュー
https://www.infoq.com/jp/news/2022/01/go-generics-beta/

func SumIntsOrFloats[K comparable, V int64 | float64](m map[K]V) V
type Number interface { int64 | float64 }

**デフォルトの名無しさん** · 2022/02/07(月) 09:14:37.90

お前らが煩いから…

**デフォルトの名無しさん** · 2022/02/19(土) 10:13:03.12

最近goよりrustが気になってきた
コンパイラ型の早いモダンな言語ということで安易にgoやってたけど
rustにすべきだったか

**デフォルトの名無しさん** · 2022/02/19(土) 11:35:19.56

rustは学習時間がかかる

**デフォルトの名無しさん** · 2022/02/19(土) 13:51:37.16

利用範囲というか得意範囲が違うから興味はない
まして癖が強いんで覚えなきゃならんことが多すぎる
出始めのJavaより癖が強くないかあれは
今は皆が馴染んだけどJavaのIO周りとか、解らねぇ！という声が多かった記憶
だから少なくとも10年は待つのが正解

**デフォルトの名無しさん** · 2022/02/19(土) 15:23:37.32

>>771
用途が違うんだから、両方やればよろし

**デフォルトの名無しさん** · 2022/02/19(土) 16:39:42.26

Goは向いている適用範囲が狭い
他の言語も併用せざるをえない

**デフォルトの名無しさん** · 2022/02/19(土) 19:00:07.51

それでいいんだよ

**デフォルトの名無しさん** · 2022/02/19(土) 23:50:48.59

Go 1.18 Release Candidate 1 is released 2022/02/18 2:04:17 (昨日)
https://groups.google.com/g/golang-announce/c/QHL1fTc352o/m/5sE6moURBwAJ

**デフォルトの名無しさん** · 2022/02/20(日) 11:21:21.17

> 早いモダンな言語
速くもないしモダンでもない

**デフォルトの名無しさん** · 2022/02/20(日) 12:17:41.07

1.18 finalは3月に持ち越しか

**デフォルトの名無しさん** · 2022/02/20(日) 12:35:50.50

単体のマシンで並列処理をひたすらに行うという涙ぐましい用途特化よね
無駄金がありゃ分散化してロードバランサ使ってしのぐと思う

**デフォルトの名無しさん** · 2022/02/20(日) 13:24:25.85

Goは並列処理が書きやすい簡単な静的型付け言語って感じよな
Goの文法はモダンとはとても言えないけど、わりと早いビルド、gitとの連携、fmt、とかもろもろのエコシステムを総じて言えばモダンと呼べそうではある

逆に、例えばD言語は文法が良いのにエコシステムがウンコだったから人気出なかったんだと思う

**デフォルトの名無しさん** · 2022/02/20(日) 15:45:27.00

分散しないでも程よく性能が出るって点から、ネットワーク関係の組み込み機器(ルータとか)に向いてるような気もする(気がするだけ)んだけど、特に席巻してるとも聞かないから使われてないのかな

**デフォルトの名無しさん** · 2022/02/20(日) 15:47:35.30

busybox的な作りならメモリも圧迫しないだろという考え

**デフォルトの名無しさん** · 2022/02/20(日) 18:28:36.22

>>782
ルータの中身なんてlinuxでCだろ
組み込みはCPUパワーと消費電力に厳しいのでC以外に現実的に解がない
逆に言えば、C以外で組んだ時には価格と消費電力でその商品に訴求力が無くなる
Cでは実現不可能な程のファームウェアアップデートの頻度が必要な商品もないだろ

**デフォルトの名無しさん** · 2022/02/20(日) 18:35:18.72

Google的には組み込み向けはFlutter/Dart

**デフォルトの名無しさん** · 2022/02/20(日) 18:37:32.10

>>781
goroutineが正解だと間違えた失敗言語だろ
このチャレンジ自体は良い事だが、正解はasyncだった

複雑になりすぎたC++を嫌い、またWeb系での最速を求めた連中はRustに行った
型を知らなかったWeb系の馬鹿共には丁度良かったが、そいつらはTSに行った
ast木がデフォで出るのは面白いが、あれはプログラマ的にはレベルが低すぎて使えない（自前で正規表現でやるよりはまし程度でしかない）
ならいっそのことあれこれやりまくる実験言語にしてもいいとは思うが、仕様の追加は他言語と比べても遅い

現在新規でGoをやる意味はないから、あとは廃れるだけだろ

**デフォルトの名無しさん** · 2022/02/20(日) 20:11:46.12

web系のバックエンドである程度速度求める層には使われてくんじゃないかな。楽だもん。
個人的にはnull安全じゃない点でもういいやって感じだけど。

**デフォルトの名無しさん** · 2022/02/20(日) 21:46:42.94

>>787
> ある程度速度求める層
これは基本的にない。
速度が問題になると分かっていて、チームがRustを使える場合、100%Rustを選択する。
Rustが使えない場合、今現在の第一選択肢はTSだろ。
そこそこ速いし、最悪はJSエンジニアを流用可能だし、全く新規に教育するにしてもフロントエンドでも使えるし。
Web系の現場でGoをわざわざ教育する意味はない。

（飽和した市場においては）商品は尖ってないといけないとよく言われるが、Goは今現在尖ってないんだよ。
速度が欲しくてガッツリ組みたければC#でもいいし、実際にASP.NETのシェアは7.9%でPHPに次ぐ第2位だ。(なおGoは0.0007%、Rustはそれ以下）
https://w3techs.com/technologies/overview/programming_language
TSよりはGoが速いのも事実ではあるが、
https://atmarkit.itmedia.co.jp/ait/articles/1909/13/news133.html
googleがrubyを切った時のようにチーム内で言語を統一するなら、今ならJSかTSになる。Goはあり得ない。
今現在もシェアが低い＝使える奴が少ないのだから、このままだと数多のマイナー言語と同様にポシャって終わり。

バックエンドで速度を求める際、最速はRustだけど、これが嫌ならC#で、ここで終わってしまう。
C#の駄目な点は仕様が重量級で勉強するのが大変な事位で、速度も安全性も生産性もGo以上だから。
Goは、速度がある程度必要だが最速である必要はなく、RustやC#は絶対に勉強したくない層向けになるが、これは現実的に無い。

**デフォルトの名無しさん** · 2022/02/20(日) 22:04:59.75

>>788
なるほどね。

**デフォルトの名無しさん** · 2022/02/20(日) 22:33:50.88

>>788
JS/TSの人材がNode/Denoでサーバーサイドもいけるからね
そしてそれでは性能面リソース面で満足できないならRustが記述しやすくていい

**デフォルトの名無しさん** · 2022/02/20(日) 22:37:24.33

Rustが使えない場合で、かつ速度が必要な場合にTS使う訳無いだろ。
C#はわかるが。
マルチコアに弱すぎるわ。
C#ではなくGo選ぶケースってのはGoならではのメリットがあるシーンが多い。

**デフォルトの名無しさん** · 2022/02/20(日) 23:21:45.49

>>791
> Goならではのメリット
だからそれは何？って話だろ。

C#で駄目でGoってのは学習コストくらいだが、学習コストが問題ならWeb系ならTS/JSで決まりだよ。
Goはgoroutineかgo generateが大当たりすれば良かったが、そうでない以上、C#に勝てる仕様がない。
現在シェアでボロ負けしてて光る仕様もなければ、このまま沈没以外にない。

Rustを考えれば分かりやすいが、シェアでボロ負けしててもC#に速度で勝てるし、
安全性も一応最高を目指してるから、選ぶ理由はあるだろ。
GoはRustが出てきた時に身の振り方を考えなければならなかったんだよ。

**デフォルトの名無しさん** · 2022/02/20(日) 23:56:31.79

>>792
そのGoroutineだよ。観測範囲狭いのでは…？
C#のasync awaitとスレッドプールは詰まる。

**デフォルトの名無しさん** · 2022/02/21(月) 00:13:42.23

>>793
asyncな関数を呼べばスケジューラに戻るわけだから
長時間ループで計算のみを続けることでもない限り詰まることはないでしょ

**デフォルトの名無しさん** · 2022/02/21(月) 00:16:41.00

>>793
詰まるって何が？
これ？なら仕様を知らないだけだね
https://oita.oika.me/2016/02/18/task-and-threadpool/

まあいずれにしても、C#で問題があれば、速攻対策されるよ

**デフォルトの名無しさん** · 2022/02/21(月) 00:26:24.14

あとこんなんも出てきた
https://www.rox-note.tech/?p=30

まあスレッドプールはそういう設計なのだから、デフォで問題ない使い方をしないのなら自前で設定してやらないと駄目だね。
でもスレッドプールはプールであって、goroutineみたいにスレッド占有（スタック保持）ではないので、
動いてないスレッドはプールに返されて結果的にCPUは最速で動くはずだけど。

**デフォルトの名無しさん** · 2022/02/21(月) 01:57:33.27

長時間、膨大なタスクを動かしたいんだよ。

**デフォルトの名無しさん** · 2022/02/21(月) 01:57:59.42

Go使う前はErlang使ってた案件。

**デフォルトの名無しさん** · 2022/02/21(月) 02:23:44.32

C#ってサーバというかバックエンドで使えるのか
知らなかった

**デフォルトの名無しさん** · 2022/02/21(月) 03:00:09.00

>>797
膨大なタスクでも途中で何らか入出力すればスケジューラに戻るからタスクが切り替わる
入出力ゼロならばそれは延々と算術計算するだけなのだから別スレッド立ち上げればよい

**デフォルトの名無しさん** · 2022/02/21(月) 03:32:12.85

goroutineが理解できないC#おじさんがのC#のasyncで騒いでるだけ
こいつは数多くの言語が採用してるchannelの原理も理解できない。

**デフォルトの名無しさん** · 2022/02/21(月) 08:43:31.09

>>800
スレッドだと必要な数が多すぎて回らない。
シミュレーションの類やってる。

あとバッチで集計処理していくとかも作ってるけど、これも一億行百万ファイルとかが対象。

**デフォルトの名無しさん** · 2022/02/21(月) 08:44:21.18

>>801
なるほど。説明しても理解できてないから無駄だし、
理解する気が無いのか。

**デフォルトの名無しさん** · 2022/02/21(月) 17:01:09.43

>>802
まず、論理CPU数よりも多いスレッドを立ち上げても余計に遅くなる。
だから長時間膨大なタスクの結果を最速で得るためには、
論理CPU数と同じスレッド数で順に処理する事であり、
当たり前だがC#も含めてスレッドプールはこういう設計になる。

膨大なジョブを論理CPU数よりも多いgoroutineでカバーするのは、一般論としては組み方が悪い。
それで速くなる事はないから。
一般的にはその場合はスレッドではなくただのデータオブジェクトとし、論理CPU数と同じスレッド数で回す。

例えば有限要素法のシミュレーションを行う場合、当然データは100万個とかになるが、
CPUが10個なら10分割して、内部は完全に独立して回し、
他CPU担当と隣接してるノードは致し方ないので通信し、CPU10個で協調させながら回す。
これをgoroutine100万個として組むのがGoの思想なのかもしれないが、速くはならないね。
ただし、プログラムは簡単にはなる。

Erlangはだいぶ思想が違う。
あれはスケールアウト時のパフォーマンス低下を回避するために疎結合にしたもので、
実際スケールアウトしてもほぼ性能低下がないのでひたすら物理で殴れるらしいが、
それならErlangでいいよね、でしかない。

尖るってのは、「○○でも出来る」ではなくて、「○○じゃないと出来ない」の事。
Goにはこれがない。
なおC#、.NET4.0の64bit環境では32767個のスレッドが上限らしい。
https://stackoverflow.com/questions/145312/maximum-number-of-threads-in-a-net-app
一般的には、こんなにスレッドが必要な時点で組み方がおかしい、となる。（上記の通り）

> 一億行百万ファイル
普通は10CPUなら10分割して1,000万行10万ファイル*10ジョブにして投入、
レイテンシがバラつくようなら例えばさらに10分割で100万行1万ファイル*100ジョブにする。
これを1,000,000 goroutineで回すメリットは何？

**デフォルトの名無しさん** · 2022/02/21(月) 17:23:04.30

>>804
その考え方が古いでしょ。goroutineは軽量スレッドで実質async await+スレッドプールだよ。

https://zenn.dev/hsaki/books/golang-concurrency/viewer/gointernal

>>804
チャンネルでfan in/fan outしてる。

**デフォルトの名無しさん** · 2022/02/21(月) 17:48:23.98

>>801
それは例として厳しいかな
C#については全く知らないが
例えばRustではchannelの送受信もasync環境ではasyncとなる
つまりgoroutineのようにchannel送受信だけを永遠にする長時間タスクがあってもタスクは切り替わる
だからそういう例でも大丈夫
おそらくC#でも同じ状況ではないかと推測

**デフォルトの名無しさん** · 2022/02/21(月) 18:21:27.64

goにおけるチャンネルって、概念的には別スレッドのI/Oにデータ渡して発火させる感じだよね
最大スレッド数は開いているチャンネル数以上になることはないし、
メインスレッドには関係ない

async/awaitで詰まるってのはawaitが文字通りメインスレッドで待つからって話ではなく？

**デフォルトの名無しさん** · 2022/02/21(月) 18:35:22.44

goroutineも実質スレッドプールなのは事実だね
async/awaitはawaitの区切りでしか中断できないのに対してgoroutineはGoのユーザーコードならどこでも中断できるので、どちらがより詰まりにくいかといえばGoかもしれない
とはいえGoもシステムコールの中断はできないから、現実には差は出ないだろうね

**デフォルトの名無しさん** · 2022/02/21(月) 18:56:08.62

>>804
Erlangは「スケールアウト時のパフォーマンス低下を回避するために疎結合にしたもの」じゃないよ。プロセスが落ちることを前提にしたもので
パフォーマンスなんて考えてないというのは言い過ぎだが、フォールトトレラントでプロセスが落ちるから沢山のプロセスが起動できるようにした
ものであり、スケールアウトによる性能の保持はその結果に過ぎない。
「一億行・百万ファイル」このように初めから総数が分かっていれば分割できますが、総数が分かっていない場合には、「一行・10億ファイル」
かもしれない。この時に「絶え間なく処理結果が欲しい」ような場合だとスレッドを張り付けた処理は、分割された連続処理群が終わるまで
待たねばなりません。GoやErlangだとこのような処理の次に続く処理があった場合、パイプライン処理として処理します。

**デフォルトの名無しさん** · 2022/02/21(月) 19:20:21.68

>>805
> その考え方が古いでしょ
これがGo界隈のキモさだよね。自分らが先進的だと勘違いしてる。
なら、何故その先進的な言語がここまで無視されてるのか考えるべきだよ。
シェアで見たら、誰も使ってない言語だよGoなんてさ。
なおRustはポリコレを持ち込んだ馬鹿がいて同様にウザがられているが。

C#のスレッドは論理CPU数を越える起動用には最適化されてないはず。
だからそういう使い方をするためにはスタックサイズをいじらないといけない。
出来たはずだがやり方は知らん。
ただしそれやっても速くはならないよ。（Goもこの点は同じ）

> goroutineは軽量スレッド
これも嘘で、今探しても出てこないが、ラズパイ環境でゴミだったからNodeに戻ったというブログが有ったはず。
512MBのRAMで4kB/goroutineでは十分な量のgoroutineを起動できず、(なお今は2KB/goroutineも選べるんだっけ？)
Nodeでシングルスレッドで処理した方が断然速かったというもの。
Go信者はgoroutineのコストがゼロだと仮定しているが、まったくそうじゃない。
メモリも食うし、空間が別なんだからキャッシュの張替えも発生する。
(Cが地味に速いのはキャッシュにひたすらヒットするから、というのもある）

> チャンネルでfan in/fan outしてる。
意味分からんが、ハードウェアのゲートみたいに各チャネルが複数の入力/出力を持っててネットワークが割と複雑だって事か？
ただこの場合はイベントドリブンで組むことになってて、一応それが一番速いはず。
ハードウェアのゲートを１対１でgoroutineにすることはプログラムとしては記述出来るが、
1億ゲートとかだから4kB/goroutineではオーバースペック過ぎて無駄だ。
ゲートシミュレーションなら精々64Byte/goroutineとかじゃないと駄目だ。だけどこれは無理だろ。
(4kBに縛られてるのはCPUのページサイズに因っているから)

**デフォルトの名無しさん** · 2022/02/21(月) 19:28:42.96

>>804
それに「Goにはこれがない。なおC#、.NET4.0の64bit環境では32767個のスレッドが上限らしい。」という中途半端な知識表現に
ついても一般的なOSではスレッドの上限は16bitの域を出ないで少ないのは当たり前で、それはスレッドがあまりにもOSにとっては
重すぎるから。(メモリやコンテキストスイッチなど払う代償が大きい）
Erlangはだいぶ思想が違うのはその通りだけど、GoはErlangほどではないが、小さいコストで多数の軽量スレッドを用意したもので
あり、これが何のために「Erlangで良いよね？」にならなかったのかといえば、背景にあるのは多数コアを搭載した近年のハードウェアを
生かし切れていない言語が溢れていたから
じゃあGoの役割はなんなのと言えば、Erlangはプロセスがネットワーク分散を簡単にできるが（その分遅め）、Goはコンパクトな
1つのマシンの中で上記のようなパイプライン処理をコンパクトに「なるべく早く」出来るよう考えられた。

**デフォルトの名無しさん** · 2022/02/21(月) 20:10:22.24

>>810
あんたのほうがキモイけど、C#の先進性なんて何があるの？俺スゲーのシンタックスシュガーだけでしょ？C#がスタックサイズなんて
弄るのはJavaと同じで基本がClassであり、さらには意味不明な意識高いバカが再帰処理などでメモリーが足りなくなるからです。

シングルスレッド言語とマルチスレッドでメモリ量を比べて起動できないなんて意味ありますか？当然作り方次第でご自慢のC#も
同じになるはずですし、RustやCでも同じことが起こりえますが？逆に言えばGoであってもgoroutine数を少なめにして、スレッドで
アフィニティを設定して使用するCPUをPinningしてやればほぼシングルスレッドと同じ状態を維持できるはずです

「Go信者はgoroutineのコストがゼロだと仮定」これもダウトです、Goを始めたばかりの人だけです。こんなことを言っているのはｗ

膨大な配列を処理するときにCPUのコア数にきっちり分割して、間にコンテキストスイッチなどを挟まないほうが速いのは当たり前で
鬼の首を取ったように書かなくても多くの人はわかります。だが、Goの開発目的はそうではありません。同様に、Erlangのように
プロセスが落ちる前提で高い耐故障性を前提にするためでもありません。
また今はデフォルトは2kのスタックであり、「4kBに縛られてるのはCPUのページサイズに因っているから」とか、どこの知識なのか逆に
問いたいぐらいです。世の中いろいろなCPUアーキテクチャがありますが？現に多くのCPUは4kですが、s390は2kです

最速を求めるのであればGoもC#でもRustでもなく、ランタイムチェックのないCやアセンブラで書いてなさい。またCが速いのは
「キャッシュにひたすらヒットするから」ではありません。ランタイムチェックが無いからです、近年のマイクロベンチマークを１回でも
見たことありますか？近年のCPUのキャッシュサイズはMB級あるのを知っていますか？

**デフォルトの名無しさん** · 2022/02/21(月) 20:13:57.83

>>810
お前読んでるか？

**デフォルトの名無しさん** · 2022/02/21(月) 20:27:03.44

Goのランタイムのフットプリントはかなりでかいし、GCだけでなくそういうコストも許容できる贅沢な環境で、手抜きをして並列処理を書ける言語だよ

ようするに、RustやCで書くのはめんどいしメモリ食われてもいいけど楽してM:Nスケジューラ使いたい、みたいなときには適してる、っていえる言語ではないかと
非同期シングルスレッドしか使わない、っていうんならいろんな言語が選択肢に入りそう

**デフォルトの名無しさん** · 2022/02/21(月) 20:29:37.24

>>812
>「Go信者はgoroutineのコストがゼロだと仮定」これもダウトです

これ確かにGoroutineがコスト高いことを知らない人たちが意外に多い
例えばRustのタスクなんかはGoroutineに比べたら本当にコストゼロ
スタックレスであるし素朴な状態マシンとしてコルーチンとして機能するだけ
だからGoroutineよりリソース的にも軽いし起動も軽いし
巨大なランタイムを必要とするGoと違って非常にシンプル

**デフォルトの名無しさん** · 2022/02/21(月) 20:46:25.71

>>809
いやErlangは電話交換機用に開発された言語で、メタル回線時代だから最初から物理で殴る前提だ。
（収容数が増えたらラックを増やすしかない）
プロセスどうのこうのはOSの話だ。ただしErlangが生まれた80年代はそこまで綺麗に分離してなくて、
ErlangのランタイムがOS扱いだったのだろうけど。
フォールトトレラント性も多分最初から考えられていたのだとは思う。

> 「一行・10億ファイル」
論理CPU数を数万倍越えるジョブがあると分かっているのなら、纏めればいいだけの話。
単に1ジョブ毎に放り込むのではなく、100ジョブ纏めて取ってきてから放り込めばいい。
原理的にはgoroutine*100と同じ速度が出る。

**デフォルトの名無しさん** · 2022/02/21(月) 20:54:53.07

>>811
> 一般的なOSではスレッドの上限は16bitの域を出ないで少ないのは当たり前
そうじゃなくて、そういう風に作ってないだけ。
つまり、現行のOSでは、スレッドはそこまで使わない前提、そういう風には使わない前提だ。

> 小さいコストで多数の軽量スレッドを用意したものであり、
これをどう見るかだが、本来ならそれ用のOSを作らないといけないんだよ。
ただし実際はGoのランタイムでどうにかなる（=ハードウェアサポート無しでいい）から
そういう動きもないのだろうけど。

> Erlangはプロセスがネットワーク分散を簡単にできるが（その分遅め）、
> Goはコンパクトな1つのマシンの中で
これはその通り。Erlangは疎結合にしすぎてて、近年のハードウェア向きではない。
とはいえGoもまた行きすぎだよ。
論理CPU数を遙かに越える数のgoroutineを起動しても、速くはならない。
(ただ、コードは簡単に書けるだろうけど)

**デフォルトの名無しさん** · 2022/02/21(月) 21:16:05.40

>>812
一応言っておくが、俺はC#書いてないぞ。

> C#の先進性なんて何があるの？
いや色々ありまくりだろ。asyncもlinqもそれ以外も色々有ったと思うけど。
今現在メジャー言語で一番先頭走ってるのはC#だろ。
それぞれの機能は他マイナー言語で既にあった物を取り込んだだけなのかもしれんけど。

> C#がスタックサイズなんて弄る
基本いじらないけどね。
デフォで2Mのはずで、少々アホな再帰をやったところで埋まらない。

> シングルスレッド言語とマルチスレッドでメモリ量を比べて起動できないなんて意味ありますか？
これは書き方が悪かったか？
要はラズパイみたいに貧弱なハードウェアだとGoは機能せず、Nodeの方が速いというだけの話。
goroutineで楽して速いってのは贅沢なハードウェアありきの話。
なおJSはCPUをひたすら突っ走らせる構造にすることをプログラマに強制するから、
その分CPUは無駄なく動く(スタックとかが小さくて済む)ので
同一ハードウェアだと他言語でシングルスレッドにするよりは原理的に速いけど。
(実際は動的言語の分遅いが、TSコンパイラとかが出てくれば面白くなるとは思う）

> s390は2kです
ほう、メインフレームのはそうなんだ。初めて知ったよ。
ただ知ってるつもりなら、現行で普通に使われてるCPU、例えばx86なりARM等で4kじゃない奴を挙げてみろよ。
ないと思うぜ。

> 「キャッシュにひたすらヒットするから」ではありません。ランタイムチェックが無いからです
違うぞ。ランタイムチェックがないのも要因の一つで、RustやJavaの連中の言い訳になってるが、
それだとCとC++でCの方が速い理由を説明出来ないだろ。

**デフォルトの名無しさん** · 2022/02/21(月) 21:18:38.69

で、Rust vs GoだとConcurrencyどっちがすごいんよ？
https://deepu.tech/concurrency-in-modern-languages-final/
https://i.imgur.com/JGoa8Xe.png
これだとRustがさいつよらしいけど

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

そら最速を求めるならクソデカランタイムが仕込まれてるGoが勝てるわけがない

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

>>813
ああすまん、リンクは完全に失念してた。

で、読んだが、何だ？知ってたような内容しか書いてないが。
わざわざ指摘してくるのだから、fan in/fan out の説明があるのかと期待したが。

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

書きやすさ&ビルドのしやすさ、なんてのも実務的には大切。
ザクッと書いてクロスでコンパイルして大量のサーバに撒く、がめちゃくちゃ楽だよ。

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

>>821
実際、軽量スレッドな事は知らなかったじゃん。
知ってたような事が書いてたけど誤解してたの？間抜けだな。

**デフォルトの名無しさん** · 2022/02/21(月) 21:56:26.38

>>819
フレームワークを使うともっと速くなるみたいで、最初はRust負けててactix使ったら勝ったらしい
フレームワークのベンチならこっちにある
https://www.techempower.com/benchmarks/
フレームワークを使わないケースだと、同じような実装にする努力の跡は見えるが、結果が言語単品の性能を表しているのか標準ライブラリの質を表しているのか、はたまた測り方なのか、何を表しているのかは知らない

**デフォルトの名無しさん** · 2022/02/21(月) 22:05:32.26

>>823
いや知っててあの内容だが？
それで納得出来ないのならそれでいいが、
goroutineは軽くはないし、ゼロコストでは全然無いよ。

**デフォルトの名無しさん** · 2022/02/21(月) 22:10:46.33

>>819
サンプルコード見たけど酷いな
言語そのものの速度を比較するためのものとは思えない
典型的スクリプトキディのおじさんだ

**デフォルトの名無しさん** · 2022/02/21(月) 22:19:17.65

>>819
本文は全部読んだ。(コードまでは見てない)

まずグラフがどうかだが、これを信じるなら、
Rusr/Java/Goは妥当、異様なのはJS(multi-threaded)の速さだよ。

詳細は本文に書いてあるけど、色々苦労してる。
問題はGo(HTTP)がぶっちぎりに速かったので、これは何だ？って事で、
どうやらライブラリの最適化に因るらしく、
わざわざ他言語でも最適化ライブラリを持ってきて比較し直してる。
で、Rustの方がGoの倍速く、JavaはRustと同程度（微妙に速いが）とかなってる。

ただこれ見る限り、CPU時間とかバラバラだし、
最適化ライブラリを用いたらRust/Java/Goどれも6倍になってるので、
言語の差よりもライブラリの最適化の方が断然重要って事になる。
本人は言語の実力の差をベンチマークしたかったのだろうけど、
ライブラリの最適化で6倍も変わる状況で言語での差をあぶり出すのは難しい。

本人が結論に書いてある事はまあ同意。なお、
> The community consensus when it comes to concurrency performance is quite split.
> For example, both Rust and Go communities claim to be the best in concurrency performance.

**デフォルトの名無しさん** · 2022/02/21(月) 22:26:10.00

Goは何も考えんでも、公式の実装がハズレ無いのでオーダーさえ考えて実装してれば間違いは無い。
まぁ、そもそもオーダーの計算を失敗しがちなmapとかflatMap無いからな。全部ループ。
そのおかげでめちゃくちゃキャッシュにきれいに載るというのもある。
思ってるより早いよ。

**デフォルトの名無しさん** · 2022/02/21(月) 23:09:18.19

まあ一応書いておくと、最適化云々言ってるけど、標準ライブラリのコンパイルオプションを変えたのでなく、標準ライブラリをactixで書き換えただけな
■標準ライブラリ版(遅い)
https://github.com/deepu105/concurrency-benchmarks/blob/nosleep/rustws/src/main.rs
https://github.com/deepu105/concurrency-benchmarks/blob/nosleep/rustws/src/lib.rs
■actix版(クソ速い)
https://github.com/deepu105/concurrency-benchmarks/blob/nosleep/rust_actixweb/src/main.rs

**デフォルトの名無しさん** · 2022/02/21(月) 23:34:23.82

>>819
.NET他環境の半分程度の性能しか出ないのかよ
C#おじさんのご高説はなんだったの？戯言？

**デフォルトの名無しさん** · 2022/02/22(火) 00:01:25.72

>>830
Goも同程度に遅いけどな。
と言うかこれはUndertow(Java)がずば抜けて速いんだよ。これは本人も書いてるとおり。

本来は

Rust(ネイティブ、ランタイム無し)
Go(ネイティブ、ランタイムあり）
Java/C#(VM)

の順になって然りで、VMと同レベルになってしまってるGoは遅すぎ。
C#は一応ネイティブにする方法はあるらしい。
VMからネイティブにすれば本来は1.5～2倍速程度は期待出来る。
https://docs.microsoft.com/ja-jp/windows/uwp/dotnet-native/
現在これが現実的に使えるものなのかは知らん。

ただまあ、同速しか出ないのなら、Goを選択する理由はないだろ。
まともな頭ならC#を選択する。
サーバーシェアだけでも10,000倍違うし、しかもC#の主戦場はunityであって
ASP.NETなんて連中からするとオマケかもしれない状況でこれだ。
ただしC#は重量級であって、日曜大工でやろうというものではないが。

**デフォルトの名無しさん** · 2022/02/22(火) 00:59:20.84

>>831
C#のAOTはこのケースにはあんまりきかないない。
なおそこてはなくてこっち。
https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/docs/using-nativeaot/README.md
刺さるときはめちゃくちゃ刺さる。制約にひっかからないかぎりよく使うよ。
ただこれでもダメならGo書いた方が楽。

Goらしいコードが書けてないのでは？と言う印象だな。

C#の主戦場はUnityは言い過ぎでは？
お前業務システムエアプ勢か？