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/

**デフォルトの名無しさん** · 2022/08/20(土) 04:18:43.73

>>473
ginのルーティングが糞なのは直ってるの？

**デフォルトの名無しさん** · 2022/08/20(土) 08:17:30.29

実際goをつかいはじめのころはチャンネルの仕様とか使いかたとか調べるのが面倒で
勝手しったるmutexばっかりつかっていた

**デフォルトの名無しさん** · 2022/08/20(土) 08:27:18.78

よーわからんし、echoで問題ないから使ってる

**デフォルトの名無しさん** · 2022/08/20(土) 11:47:33.07

俺もecho

**デフォルトの名無しさん** · 2022/08/20(土) 23:47:54.29

gin → beego → echo → chi イマココ

**デフォルトの名無しさん** · 2022/08/30(火) 15:48:26.25

言語仕様書の1.17を底本として翻訳してるんだけど、文書的に酷い(～;～の使いすぎが特に…)し、構成的にもクソだなぁ
underlying type に関係した性質なんて文書全体を読まんと把握できないわ

メソッド式の話では、ポインタによるレシーバーのメソッドは値による呼び出しは出来ないとか書いてあるけど、レシーバー宣言が値だろうがポインタだろうが、現行じゃ問題なく呼べるようになってる(更には値でセレクタ呼んでもポインタで呼んでも動く
つまりどこかで仕様が拡張されてるのに、仕様書は更新されてないっぽい疑惑

**デフォルトの名無しさん** · 2022/08/30(火) 15:50:42.61

仕様書なんて熟読しなくても、フィーリングで書いて動いちゃうから、今まで気にしたこともなかったし
気にしなくても動くんだからいいじゃない？とも思いはする

**デフォルトの名無しさん** · 2022/08/30(火) 22:31:49.83

そんないいかげんな感覚で思い付きどんどん拡張したその結果が今のC++のていたらくだ！！
反省しなさい！

**デフォルトの名無しさん** · 2022/08/31(水) 00:35:38.08

C++があんなことになったのはむしろ、C++プログラマたるもの仕様書くらい熟読しているだろうと開発陣が高を括ってきた結果だろう

**デフォルトの名無しさん** · 2022/08/31(水) 10:19:04.29

あんなブ厚いARMを読むなんて苦行が過ぎる
悟りに至りかねない危険な行為だ

**デフォルトの名無しさん** · 2022/08/31(水) 12:04:18.42

あるえー？
仕様書で終了ステートメントに続くステートメントに関する記述が無いんで、Playgroundでmainの最初にreturnを書いたらコンパイルエラーにならんかったし実行時エラーも起きない
到達不能ステートメントはチェックされないんだな

**デフォルトの名無しさん** · 2022/08/31(水) 12:08:28.43

そもそも規格化されてる言語じゃないし、コミュニティが用意した言語仕様書にそこまで大きな意味はないんじゃないの？
仮に処理系と内容が違っててもどっちのバグなのか第三者にはわからないこともあるだろう

**デフォルトの名無しさん** · 2022/08/31(水) 14:11:42.15

いかにも仕事が雑なグーグルらしい雑な仕様の言語

**デフォルトの名無しさん** · 2022/08/31(水) 15:08:28.04

そうか？Googleの割にはまともだったから普及したんだと思うぞ
いつものGoogleはWeb系のノリで言語作るからこんなもんじゃない、そして大コケする

**デフォルトの名無しさん** · 2022/08/31(水) 16:28:21.64

Rustほど初心者が書きにくくはないし
PythonやRubyよりは確実に速い
ちょうど良いところを付いたと思うよ

**デフォルトの名無しさん** · 2022/08/31(水) 17:49:58.71

だがバグらないために気を付けないといけないことが多い

**デフォルトの名無しさん** · 2022/08/31(水) 18:35:42.76

なんかしらんけどGoがしんどいなら使わなくてもいいんだよ

**デフォルトの名無しさん** · 2022/08/31(水) 20:53:39.37

バグらないために気を付けなきゃならんことなんて、他の言語に比べるとそんなに多くないだろ

**デフォルトの名無しさん** · 2022/08/31(水) 21:04:49.54

100 Go Mistakesを読むといいよ

**デフォルトの名無しさん** · 2022/09/01(木) 09:53:36.13

言語設計でしくじってるよなぁと思うのは、構造体の生成回りの構文というか思想
Cに引っ張られ過ぎてて生成の基本が実体を作ることになってる
構造体はデフォルトでアドレスとして出現し、Javaとかのように参照と命名しとけばよかった

そうすればスライスとかマップのイテレーションがクソみたいな落とし穴にならないし、マップをインデックス式でアクセスしてセレクタとしてフィールドにアクセスも出来るようにできた

実体を使いたい場合は*でデリファレンスして使う
実体ちゃんの変数も*Tという型とする
実体配列は[]*Tという配列を記述するようにする

*に関しては、レシーバーとか宣言で(r *T)とかデリファレンス演算子をポインタを示す記号に使うような一貫性のなさも解消する
プリミティブな変数が実体で、そのアドレスを&で取得するということからの一貫性に拘ってるんだろなぁ

実体配列なんて、Dockerの管理用配列以外で見たことないよ…少なくともレアな宣言だと思う

**デフォルトの名無しさん** · 2022/09/01(木) 11:44:46.07

欠点を挙げる流れだ
やっぱ入れ子の構造体の初期化でしょいかんよあれは

**デフォルトの名無しさん** · 2022/09/01(木) 12:50:03.20

この辺の問題が起きないようにしっかり対策取ってる？
https://www.uber.com/blog/data-race-patterns-in-go/
https://blog.acolyer.org/2019/05/17/understanding-real-world-concurrency-bugs-in-go/

**デフォルトの名無しさん** · 2022/09/01(木) 12:54:11.77

複合リテラルとして書けばいいんだし、落とし穴的な問題はなくない？
俺は悪くないかなと思ってるんだけど

**デフォルトの名無しさん** · 2022/09/01(木) 13:00:51.78

>>520
「これらの多くは、チャネルでの送信または受信の欠落、またはチャネルの閉鎖が原因です」
いや、mallocしといてfreeしてませんでしたレベルの話をされてもどうしろと？
普通に対策考えないでプログラミングなんてできないだろ

**デフォルトの名無しさん** · 2022/09/01(木) 14:02:59.57

>>518
ポインタを示す型なら&を使ってT &pにしてデリファレンスは*p
とか実際に書いてみたら物凄い違和感に襲われてしまった

…C言語の呪いって凄いわ

**デフォルトの名無しさん** · 2022/09/01(木) 14:17:02.40

>>522
それってプログラマー任せのノーガード戦法ってことでしょ？
リストアップされてるような各種バグに対してシステマティックに検知・防止する仕組みを実装できてる？

**デフォルトの名無しさん** · 2022/09/01(木) 17:08:27.97

データ競合はあまり遭遇したことないな
無駄に並列化したがるバカがチームにいると地獄を見るだろうというのはわかる
channel絡みのミスで固まるのはよくある

**デフォルトの名無しさん** · 2022/09/01(木) 18:05:50.03

>>522
けっこう終了時の後処理とか難しくない？
適当なツールとかだと雑に済ましちゃうし、割ときちんとやろうとすると書けない人多い印象。

**デフォルトの名無しさん** · 2022/09/01(木) 18:16:08.12

きつい現場のGoは他の言語より殊更きつそうだというのはわかるわ

**デフォルトの名無しさん** · 2022/09/02(金) 02:30:51.60

channelは複雑なデータのやり取りに使うには難しすぎると感じるね
どこで詰まるかわかったもんじゃないし
公式がまともなフレームワーク用意するわけでもないし

**デフォルトの名無しさん** · 2022/09/02(金) 03:08:08.96

epollを使うよりかはマシだし

**デフォルトの名無しさん** · 2022/09/02(金) 08:58:55.58

いや、Goに限らない問題でGoのダメなところとか言われてもなぁ

**デフォルトの名無しさん** · 2022/09/02(金) 09:55:02.48

いや、けっこうGoに限った問題
channelのユースケースの大部分は現実にはpromise/futureで十分で、遥かにミスを引き起こしにくい

**デフォルトの名無しさん** · 2022/09/02(金) 09:58:48.22

例えばCとかでファイルを排他オープンしたままクローズし忘れて書き込みのままになってて、別の箇所で読み込もうとしたけど開けなかったとして
これはC言語の不備だとか言うのか？と

**デフォルトの名無しさん** · 2022/09/02(金) 10:04:00.39

>>531
chan のユースケースといったら、パイプとしてストリーム的にデータを流すのが主だと思うんだが、promise, future でどうやって代替するの？

**デフォルトの名無しさん** · 2022/09/02(金) 10:06:18.95

>>531
select文のあたりでも書かれてたと思うけど、同期を取る目的じゃなくてパイプからの機能だよチャネル

**デフォルトの名無しさん** · 2022/09/02(金) 10:10:39.85

>>531
同期取るなら、sync.WaitGroup 使えばよくない？

**デフォルトの名無しさん** · 2022/09/02(金) 12:33:43.05

>>532
そういうことにならないようにGoのdeferやC#のusingやPythonのwithみたいな仕組みを言語機能として提供してるよね？

それらが不要だとでも？

**デフォルトの名無しさん** · 2022/09/02(金) 12:45:23.85

いや普通に同期を取る使い方もできるだろw
完了通知を待つ使い方
俺もその使い方しかしてない
async/awaitなんで構文として追加しても良いと思うのだけどね
channelは非同期機構を実装するパーツとしては優秀だから
フレームワークが欲しい

**デフォルトの名無しさん** · 2022/09/02(金) 13:40:10.47

そもそも本当にパイプとしてストリーム的にデータを流す必要のあるケースなんて稀
Goがchannel推しだから利用者もそれに引き摺られてストリームっぽい設計になりがちなだけで、結果として単一の値(又は配列)を返せれば殆どのケースでは十分
本当にストリームが必要ならJavaScriptのasync generatorのような設計も可能で、producerとconsumerが協調するからchannelより遥かに安全だ

**デフォルトの名無しさん** · 2022/09/02(金) 13:56:23.23

そもそもストリームモデルが必要なユースケースってほぼ
分散環境だと思うんだよな

**デフォルトの名無しさん** · 2022/09/03(土) 12:27:35.16

分散環境なら外部のメッセージバスに投げるだけだよね
せっかく小さいgoroutineを気軽にポコポコ起こせるデザインなのに、
結果を受け取る方法が、データ競合を起こさないように最大限注意して共有変数を使うか、パラダイムのミスマッチなchannelを使うかなのは片手落ちに感じる
単純にgoroutineの返り値をwaitできるようにしない理由ってあるんだろうか？既に議論されてたら知りたい

**デフォルトの名無しさん** · 2022/09/03(土) 13:39:36.59

>パラダイムのミスマッチなchannel

kwsk

**デフォルトの名無しさん** · 2022/09/03(土) 20:41:16.91

>>541
そりゃ>>533の通りで、channelはストリームでありfutureではない、ってことだ。
futureで済むケースにchannelを使うと、複数の値を返す可能性はないのか？1つも結果を返さなかったら？
そんな余計な心配が常に付き纏うことになる。futureなら全く無縁な心配がな。そしてその心配が現実になればプログラムは容易にデッドロックする。

**デフォルトの名無しさん** · 2022/09/03(土) 20:49:18.55

>>536
だからdeferあるんだし、ちゃんとリソース管理しろよ、という
Goのせいにするのはお門違いだろ、な？

**デフォルトの名無しさん** · 2022/09/03(土) 20:53:14.26

>>542
promise, future 程度のことをやりたきゃ、>>535で書いたけどsync.WaitGroup使ったらどうだ？

**デフォルトの名無しさん** · 2022/09/03(土) 21:09:58.32

パラダイムのミスマッチという理由がわからん。
goroutineは一つの関数を呼ぶためのもんじゃないぞ。
goroutine立てて一連の処理を同期的に書くためのもなんよ。普通に考えれば結果を受け取る必要が無いはずだよ。
どうしても集めるならfan inするように一つのchanで受ける。

Futureは要らないんよ。awaitとかしなくてもそこでCPU占有したり、ioなりなんなりが起これば自動的に別goroutineに制御が渡る。

**デフォルトの名無しさん** · 2022/09/03(土) 21:10:11.97

>>542
ストリームだとミスマッチでfutureだとミスマッチじゃないということか？
何と何がミスマッチなのかというところがよくわからんが。

**デフォルトの名無しさん** · 2022/09/03(土) 21:14:31.20

>>544
その場合は「共有変数を注意深く使う必要がある」よね

**デフォルトの名無しさん** · 2022/09/03(土) 21:22:59.76

>>545
だからそう言ってるでしょ
goroutineとchannelをfutureのように使おうとすればミスマッチのために煩雑でバグの生じやすいコーディングを強いられることになる
もちろんGoにはGoのやり方があるのは分かるが、一方でその結果が>>520の状況なのが事実だよね

**デフォルトの名無しさん** · 2022/09/03(土) 21:29:09.46

>>548
goroutineで処理すべき単位とか、ワークスティーリングの話してなかったかなと。

**デフォルトの名無しさん** · 2022/09/04(日) 00:29:35.08

まさかこのスレにホーアのCSP本読んでないやついないよな？な？

**デフォルトの名無しさん** · 2022/09/04(日) 00:54:37.91

いや、読んでませんが？

**デフォルトの名無しさん** · 2022/09/04(日) 17:28:10.39

>>550
読もうとしたけどガチの論理学的数学で挫折
しかしよく調べたらGoが参考にしたのはその本ではなく
最初にホーアが出したもっと簡単な論文の方だった
つまりその本は読む意味はない(Goの並行モデルの理解という意味で)

**デフォルトの名無しさん** · 2022/09/04(日) 18:08:07.32

>>547
それは認めざるを得ない
Mutexと会わせ技で使ってるから

**デフォルトの名無しさん** · 2022/09/04(日) 19:08:07.89

>>547
だけど、120行(+テスト75行)の隠蔽ライブラリを書いて使ってる
共通変数の管理なんてその程度の共通化でカバーできるタスクじゃん

**デフォルトの名無しさん** · 2022/09/04(日) 23:01:27.23

すまない誰かリングにかけろで例えてくれないか？

**デフォルトの名無しさん** · 2022/09/05(月) 01:58:21.42

Goがpromise(future)/async/awaitをサポートしてくれれば今より容易に安全に書けるケースが増えるのは事実だが、
この件も他の件と同様にGoはサポートしてくれないだろうという悲観的な現実と向き合って、
今ある手段で頑張って代替手段を安全に実現しよう。

**デフォルトの名無しさん** · 2022/09/05(月) 04:13:05.73

結局ゴルーチンの実装が中途半端だったんだろうね
分散環境でのストリームモデルならNodeみたいなノンブロッキングIOで外部のソケットを叩けるようにして
シングルスレッドにするのが良かったし
そうでないならFuture/Promiseみたいに安全にデータを受け取れる仕組みが欲しかった
この２つがちょうどうまくできないデザインになっちゃった

**デフォルトの名無しさん** · 2022/09/05(月) 04:31:49.54

またGoの言語仕様にも問題があった
ジェネリクスだ
ジェネリクスがない状態でfuture/promiseを安全に実装できない
なぜかアンチジェネリクス勢がGoには多く
コミュニティでの議論も進展しなかった
つまり全てがゴテゴテに回ってしまった
それならGoogleが並行処理のフレームワークを作ってくれるのかと期待していたが
その気配は全くなく使いにくいcontextのみを放り投げた状態でさあ作れと言った状態
そりゃ普通のユーザーは付いてこれない

**デフォルトの名無しさん** · 2022/09/05(月) 06:36:04.94

マルチコアを効率よく使うってのがそもそもコンセプトで作られたんだがNodeみたいにしろって意味わからん

**デフォルトの名無しさん** · 2022/09/05(月) 07:31:00.89

Goのようにマルチコアを効率よくスケジューリングできて
Goのgoroutineのように多数のタスクを身軽に簡単に起動できて
Goのようにそれらタスク間でchannel通信をすることができて
それらに加えてFuture / async / awaitもサポートしているプログラミング言語がありますよ

偶然ですがその言語は
Goと同じくclassや継承がなく
Goと同じく例外try-throw-catchもなし

**デフォルトの名無しさん** · 2022/09/05(月) 09:08:23.21

>>558
まずpromiseがどう有利なのか自分の口からどうぞ
そこにメリットを見いだせないから無視されるんだよ

**デフォルトの名無しさん** · 2022/09/05(月) 10:05:06.21

Goのモデルと比較してのpromiseの優位点としてはこんなとこかな
・一般に、並行性が多少犠牲になる代わりに並行処理の複雑性を局所化する方向へとデザインが誘導される傾向がある。結果としてバグが入り込みにくい。
・ワークフローを集約して記述しやすいため可読性保守性に優れる。
・(channelではなく共有メモリを使う場合と比較して)処理結果を他のスレッドで利用する際にデータ競合が生じない。
・channelと比較して、結果として単一の値を生成するというセマンティクスが型として明確に表現される。デッドロックや閉じ忘れの心配もない。

**デフォルトの名無しさん** · 2022/09/05(月) 10:15:26.20

うーん今の時代にpromiseの利点を理解できない人がいるとは驚きですが仕方ない出血大サービスだ

まず最初にマルチコアを活かすという点についてだが
基本的にゴールチンのような仕組みでは全く活かせないという点を強調しておく
まともにマルチコアのCPUの性能を引き出せるのはSIMD命令を使った計算のみ
SIMDが何なのかわからない人は調べてください
SIMD演算を直接言語でサポートしていないので計算の高速化は論外
ただのマルチスレッドと変わらない
マルチスレッドはOSレベルで実装されており
コンテキストスイッチの負荷も高くCPUキャッシュも消えるし
マルチコアを活かすような作りになってないのはご存知の通り

**デフォルトの名無しさん** · 2022/09/05(月) 10:28:17.92

>>562
嘘ついちゃだめ
promiseでもデッドロック起きる

**デフォルトの名無しさん** · 2022/09/05(月) 10:29:00.06

データ競合も起きる

**デフォルトの名無しさん** · 2022/09/05(月) 10:37:15.25

次にpromiseの利点について

並行処理の考え方としては大きく以下がある

1.処理をシーケンシャル実行して1つずつ結果を受け取る
Aが終わったらBを実行して
Bが終わったらCを実行する

2.複数の処理を同時に実行して結果をまとめて受け取る
A、B、C...の処理を同時に実行してその結果をreduceして受け取る

3.ストリーミングモデル
いわゆるproducer/consumerに代表されるようなモデル

1と2についてはpromiseで全て安全に楽に実装できる
ゴルーチンとchannelを使った実装なんか考えたくもない
100%デッドロックが起きる

3についてはゴルーチンとchannelが本来想定してるモデルなのだが
これを適切に実装するのが難しい
CでBlockingQueueの実装したことがある人は分かると思うが極めてデッドロックが起きやすい
複数のproduer/consumerを生成したい場合など考えたくもない
さらにこのモデルの場合は基本的に大規模な分散環境で実行することがほとんどである
シングルノードでproducer/consumerなどサンプルコードでしか有り得ない
こういう用途では複数ノードのソケットにリクエストを投げて結果を待つということになるので結局2に帰着される

**デフォルトの名無しさん** · 2022/09/05(月) 10:37:39.78

つまりpromiseがあれば全ては安全に解決される
ちなみにpromiseはスレッド実装する必要はないことに注意
rustはスレッドで実装されているがNodeはノンブロッキングIOを使っている
他にもグリーンスレッドを使うなどいろいろある
言語側が安全性を担保できるように実装できるのだ
そしてpromiseを型安全に実装するためにはジェネリクスは必須である

以上が私の考える
「ゴルーチンは実装が中途半端で実際のユースケースを考えた場合に非常に残念なことになっている」理由である
反論があればどうぞ

**デフォルトの名無しさん** · 2022/09/05(月) 10:37:59.16

そりゃpromiseでも共有メモリ触ったり外部のリソースをロックしようとしたりすればデッドロックするでしょう
promiseモデルとは関係ない話

**デフォルトの名無しさん** · 2022/09/05(月) 10:56:03.27

>>560
その言語はRustだな

>>565
Rustならデータ競合が絶対に起こらない
データ競合を起こすコードはコンパイラがエラーにできる言語仕様

>>567
ちょっと違う
RustのFuture(＝Promise相当)はOSスレッドとは全く別で関係なく
Goroutineとほぼ同様の気軽に大量に作れる非同期タスクとして扱える
もちろん安全に解決できる

今回の話で言えば大雑把に分けるとRustは3種類ともサポート
① Futureおよびそのasync/await
➁ Goと同様のchanel
③ メモリ競合を絶対に起こさない安全な共有メモリ

**デフォルトの名無しさん** · 2022/09/05(月) 11:03:44.74

>>569
なるほど流石Rust

**デフォルトの名無しさん** · 2022/09/05(月) 11:12:30.51

ぐちぐち言ってきたが
Goにはゴルーチンとchannelとcontextという良いプリミティブがあるのだから
適切にpromiseを実装して使えるようにして欲しいということ
であれば並行処理がメインのアプリにおいては第一選択にもなり得ると思う
ジェネリクスも入ったのだしやれるはずなんだよ
Googleがもうやる気ないのかもしれないけど

**デフォルトの名無しさん** · 2022/09/05(月) 12:10:29.88

>>568
channelと比較してデッドロック起きないとか痛い事言っといてそれはないわw

**デフォルトの名無しさん** · 2022/09/05(月) 17:07:29.06

Nodeしかさわったことないから詳しくは知らんけどasyncawaitモデルだと
async関数を使うには呼び出し元にどんどんasyncが汚染されて使いづらいイメージがあるな

その点Goは同期的なコードの一部を並行処理にするってのが非常にやりやすいと思う
タイムアウト処理もselectで簡単に実装できるし、シンプルなfork joinだったらsync.waitgroupで楽に実装できるし
何も困ったことがないな

そんなに優位性があるとは全然思わない

**デフォルトの名無しさん** · 2022/09/05(月) 21:20:50.97

>>573
Goは見かけ同期と誤認するけど
同じOSスレッド上でもメインや複数のGoルーチンがスケジューリングされて交互に非同期で動いているよ

例えばGoで
　func1()
　func2()
　func3()
と見かけ同期に書いているのは
async/await対応言語で
　await asyncfunc1()
　await asyncfunc2()
　await asyncfunc3()
と書いた時と同じ状態
つまり見かけ同期のGoの実態は非同期

「Goは最初から全てがasync汚染されているためasync汚染に気付かずに済む」が正解

**デフォルトの名無しさん** · 2022/09/05(月) 22:10:30.31

>>574
goキーワードなかったら同期的に動くだろ
ライブラリの中でgoキーワードが使われてるから暗黙的に使われるが正しいね。

非同期にしたい部分でgoをつけるのであってつけてないのに全部非同期だってのはおかしな話だな

**デフォルトの名無しさん** · 2022/09/05(月) 22:24:10.45

>>575
それは見かけ上だけ
goを付けなくても読み書きなど含めて時間がかかるものは
見かけ上だけ同期ブロックしているが
実際には非同期で動いており裏で別のgoroutineにスケジューリングされている
そしてその読み込みや書き込みが可能となると
見かけ上だけ同期ブロックしていたところへスケジューリングが戻る仕組みであってGoは常に非同期に動いている

**デフォルトの名無しさん** · 2022/09/05(月) 22:30:51.53

ユーザーに見せてるのは全てブロッキングなコードなわけじゃん
それをgoキーワード使って複数立てた時に非同期で動くって話で、単体の場合はあくまでも同期的に動くよね

mainルーチンでhttp.getってやったら同期的に動いてるよね？
これを別のgoroutineを立てて複数立ち上げればブロックする後は勝手に非同期で動くってだけの話

async汚染はユーザー目線で言ってるね
Goのモデルは既存のコードや構造に手を加えずに一部だけを非同期にするのが容易、これが一つのメリットではあると思う

**デフォルトの名無しさん** · 2022/09/05(月) 22:40:11.19

Node/Denoの作者も同じこと言ってるし、async/awaitモデルの方が優れている一言も言ってないな
むしろGoのモデルをほめてるわ
https://mappingthejourney.com/single-post/2017/08/31/episode-8-interview-with-ryan-dahl-creator-of-nodejs/

必死にasync/awaitの方が優れてるとか言ってるみたいだけど、逆にGoのモデルの方が使いやすいって人もいるわけだよ
自分の意見が全てだと思わない方がいいんじゃないかな
感覚的な話で優れてるって言われてもね

**デフォルトの名無しさん** · 2022/09/05(月) 22:48:10.04

>>577
> ユーザーに見せてるのは全てブロッキングなコードなわけじゃん

それは見かけだけだな
例えば>>574の
|　await asyncfunc1()
|　await asyncfunc2()
|　await asyncfunc3()
これも(同じく見かけだけ)全てブロッキングな同期で実行されるコード
そしてGoと同様に実際には裏で非同期に動く

> 単体の場合はあくまでも同期的に動くよね

それは見かけだけ
つまりasync/await対応言語がawait文で見かけだけ同期的に動いているように見せかけるのと完全に同じ

**デフォルトの名無しさん** · 2022/09/05(月) 23:00:13.19

うんだからユーザーに見せるコードが同期的なことろがわかりやすくて良いって言ってるんだけど？最初その話してたよね？同期的なコードって言ってるよ？
裏でepollやら使ってて非同期だから云々の話はしてないんで
ちなみになんでいちいちID変えるの？

**デフォルトの名無しさん** · 2022/09/05(月) 23:32:28.26

>>576
＞見かけ上だけ同期ブロックしているが
＞実際には非同期で動いており裏で

んなこと言ったらIO操作のあるあらゆる言語が低レベルでは非同期で動いてるじゃんよ。

**デフォルトの名無しさん** · 2022/09/05(月) 23:43:38.07

C10K問題から非同期が流行ったのに、メモリーを使いまわしてたら意味ないのでは？

一つのスレッドに一つのスタック、典型的に一つのスタックは1MB準備される。
10Kのスレッドがあれば、10GBのメモリーが必要。
256MBのSUNでは無理。

でも、非同期でも1MBの配列を用意してデータが届くたびに書き足していくなら同じことでは？

**デフォルトの名無しさん** · 2022/09/05(月) 23:47:49.38

ウェブ・サーバーが静的なファイルを送り出していた2000年ごろなら非同期が大それた力だっただろうけど。

全てが動的な現代において、非同期はめんどくさいだけなのでは？

**デフォルトの名無しさん** · 2022/09/05(月) 23:53:52.32

昔より回線が安価になって接続数が多くなったんだから非同期が必要でしょ

**デフォルトの名無しさん** · 2022/09/05(月) 23:56:02.82

どういうことですよ？

**デフォルトの名無しさん** · 2022/09/06(火) 00:05:01.14

静的なファイルを送るだけなら。

カーネルの送信バッファが空くのを待つ
↓
送信バッファと同容量だけ非同期にファイルの読み込みを開始する
↓
ファイルデータが読み込まれると、送信を開始する
↓
最初に戻る

この手順で、典型的なTCP通信なら20KB以下のメモリーで足りる。
でも、動的なコンテンツ生成では、そうはいかないのでは?

**デフォルトの名無しさん** · 2022/09/06(火) 00:56:32.90

ヒント:httpは同期通信

**デフォルトの名無しさん** · 2022/09/06(火) 01:32:17.99

>>563 のここがよく分からない

> まともにマルチコアのCPUの性能を引き出せるのはSIMD命令を使った計算のみ

SIMD命令付きのシングルコアCPUもあったじゃん。
古いけど MMX Pentium とか Pentium III とか。
この時代はSIMD命令は何を引き出してたの？

**デフォルトの名無しさん** · 2022/09/06(火) 02:05:21.99

>>566
1なんか一つのgoroutineに上から並べるだけで良いじゃん。

**デフォルトの名無しさん** · 2022/09/06(火) 02:06:28.41

えっ？もしかしてこの人
>>574
でもまだ理解してないの？

**デフォルトの名無しさん** · 2022/09/06(火) 03:40:36.05

>>587
httpを同期で実装するなんて昔のダメなシステムと完全ブロックしても困らない末端クライアントだけたぞ
httpクライアントとして動作する時もサーバーで使うなら同期ブロックしてしまうとスレッド資源を無駄に専有
だからhttpを使うなら何らかの非同期にするのが当たり前

**デフォルトの名無しさん** · 2022/09/06(火) 06:52:34.65

>>574
多くの言語でasync/awaitキーワードだらけになって反吐が出る気分だわ、これを良いと考えた人たちを殴りたい...
goにpromise/futureなんて絶対不要、こんなの必要だと思ってる人相当アホやぞ

＞「Goは最初から全てがasync汚染されているためasync汚染に気付かずに済む」が正解
なるほど意味わからん
asyncキーワードなんて無いのにスケジューリングで同期実行されるから汚染？ｗｗ新理論ｗ

**デフォルトの名無しさん** · 2022/09/06(火) 08:04:56.91

>>566
1なんてそのまま関数並べるだけだし
2はN件goroutine立ち上げてたらN回チャネル待ち受ければいいだけだよね
タイムアウトもselectで容易に実装できる

100%デッドロックするとか言ってるけどそれはGo超初学者が使った時の話かな？
仮にデッドロックしても検知機構働いてちゃんと落ちるし何が言いたいのか

**デフォルトの名無しさん** · 2022/09/06(火) 10:57:52.38

>>588
その時代のことはよく知らないので
気になって調べてみたがwikipediaによると
2クロックで実行するという実装になっていた模様
なのでその時代に関しては128ビット幅のレジスタを使えるというアドバンテージしかなかったとのこと

**デフォルトの名無しさん** · 2022/09/06(火) 11:23:36.25

>>591
通信プロトコルとhttpサーバー/クライアントの実装が区別できないおバカさん乙w
そんなんでよくGoなんて使えるな

**デフォルトの名無しさん** · 2022/09/06(火) 14:37:15.63

今回は実装の話だからサーバー上なら今どきは非同期で実装で合ってると思うよ

**デフォルトの名無しさん** · 2022/09/06(火) 16:35:51.33

>>596
文脈読めないおバカさんその2乙w

**デフォルトの名無しさん** · 2022/09/06(火) 16:56:04.53

>>593
その通りだな、安易に実装できるものを標準で欲しがる理論がわからんわ
多くの言語のfutureなんてデータの結果受信同期待ちが起こるだけだし、goのcontext.WithTimeoutは
他の言語では全く実装できていないfutureのプラス機能のようなもので、goはより進んでいると言える
一方promise的なもの、つまり複数のgoroutineを束ねて制御したい人は、欲しい人もいるかもしれないが
goで書いたpipeline処理は手動で書くからこそきめ細かい制御が出来るので、無作為にこれとこれを並列、
これとこれを非同期だけど同期的に実行にしたいとか、効率を考えたらこの流れを組み替えられることには
ほとんど意味もないね。
例えばJSでPromise.allとかすべてを非同期並列に実行して成功の可否で分岐したいなんて、同じ状態が
goroutineとチャネル待ち受けで出来てしまうわけで、それを仰々しいライブラリにする意味が分からん