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/03(水) 10:49:56.25

depは3年ぐらい前から正式な公式ツールじゃもう無いし、ツールの煩雑性や使い勝手は言語に関係ないよ
PATH変数に気を使うのはC,C++でも一緒、そもそも環境構築すら出来ない失敗をしてんのはあんたか
現場の手順書が無いか

**デフォルトの名無しさん** · 2021/11/03(水) 11:46:43.90

「改訂2版みんなのGo言語」という本を読めば？

学生時代に、Ruby 製のVagrant を作って、
Terraform で有名なHashiCorp を作った、今世紀最大の起業家、
Ruby/Go の神、Mitchell Hashimoto のソースコードも解説している

**デフォルトの名無しさん** · 2021/11/03(水) 12:11:59.17

go.mod に書いとくだけで github やらから直接にライブラリを導入できる点で、環境面では目一杯助かってるわ
Mavenやらpipが組み込まれてる感じだけど、基本機能であることは大きい
Mavenとかpipは別途入れないとならんし、それぞれ本体と別の環境整備しないとならないから

**デフォルトの名無しさん** · 2021/11/03(水) 19:24:54.92

>>622
今更？

**デフォルトの名無しさん** · 2021/11/04(木) 16:01:17.99

趣味で使って面白い?

**デフォルトの名無しさん** · 2021/11/04(木) 16:13:12.12

面白い
GCP無料枠でそこそこ実用性のあるサイト建てたりできるし

**デフォルトの名無しさん** · 2021/11/04(木) 16:27:08.12

なるほど
googleの犬になるか

**デフォルトの名無しさん** · 2021/11/04(木) 19:21:19.80

だってアマとか無料枠ないんだもん
一年目だけってのは、単に初回サービスって言うんだよ

**デフォルトの名無しさん** · 2021/11/05(金) 14:20:53.38

Herokuとか

**デフォルトの名無しさん** · 2021/11/07(日) 15:35:29.83

社会人なら別にEC2使ってもマイナーサービスのサーバ台ぐらい余裕やで。
一ヶ月分の料金なんて、スタバ2回分くらいだろ。

そら安いほうがいいけど。

**デフォルトの名無しさん** · 2021/11/07(日) 22:23:20.41

micro使えば安いけど明らかにメモリが足りないんだよな
おまけに調子に乗ってぶん回すと詰まるし
最低でもmedium程度は欲しいがそうなると結構高くなる

**デフォルトの名無しさん** · 2021/11/07(日) 22:38:38.82

Oracle Cloudは？
コンソールが重くて独自性強いけど起動してしまえばいっしょ

**デフォルトの名無しさん** · 2021/11/07(日) 23:41:21.11

サイト立ててもアクセスが日に数件なんでほとんどマシン回ってないやww

**デフォルトの名無しさん** · 2021/11/08(月) 16:12:42.92

microといえば思い出す、大手のNでスワップしまくりなんも考えてないSEが手配したmicro
しかもWindowsの時の絶望感・・・

**デフォルトの名無しさん** · 2021/11/08(月) 16:32:31.04

んなもん動くか！

とググったら
https://qiita.com/zakky/items/68c4749889717c3cd849
おぅい！！

**デフォルトの名無しさん** · 2021/11/08(月) 16:42:16.76

microでも小さいサービスならメモリ足りるやろ？ goだったら100MBメモリ食うこともありえないくらいやろ
メモリリークでもしてるんじゃないの？
Windowsとか動かしたらそらきついだろうけど。

**デフォルトの名無しさん** · 2021/11/08(月) 17:40:06.67

動くか、と言ったのはWindowsの話
400MB確保できるみたいだから意外と使えるかも？

**デフォルトの名無しさん** · 2021/11/08(月) 18:00:09.69

なんでそんなにWindowsを動かしたいんだ・・・。

**デフォルトの名無しさん** · 2021/11/09(火) 13:54:21.34

>>640
pインスタンスでwindowsを動かすのは普通に多いよ

**デフォルトの名無しさん** · 2021/11/09(火) 17:10:56.19

いや、なんで？という疑問への答えじゃないよな
ぶっちゃけLinuxでSSH接続専用にすれば済むから

**デフォルトの名無しさん** · 2021/11/09(火) 19:48:05.88

GUI系のアプリを動かすんだよ
CAD系のシミュレータとか
windowsにしか存在してないアプリが多い

**デフォルトの名無しさん** · 2021/11/09(火) 23:41:06.97

github.com/fogleman/gg が遅くてちょっと困った。
Webassemblyで普通にcanvasの関数をcallした方が速いなんて。
ebitenはdraw系の関数少ないからなぁ。

**デフォルトの名無しさん** · 2021/11/11(木) 09:52:59.41

Twelve Years of Go
Russ Cox, for the Go team
10 November 2021

**デフォルトの名無しさん** · 2021/11/17(水) 23:16:51.89

gotoの使用は許可されてる？

**デフォルトの名無しさん** · 2021/11/18(木) 06:41:13.91

>>646
普通は使わないが何故か仕様にあるんだから許可されてるんだろ

**デフォルトの名無しさん** · 2021/11/18(木) 17:38:26.56

深いループを抜けるときはgotoを使う

**デフォルトの名無しさん** · 2021/11/18(木) 21:15:03.90

ラベルgotoは、gotoではあっても古い言語で禁忌されているgotoではありません。

ダイクストラのgoto文論争はBASICはもちろんですが、1968年に“Go To Statement Considered Harmful”
（Go To 文は有害とみなされる）において行番号へ飛ぶような言語が多かったために起こった論争です。
C言語も古くからありましたが、こちらもあまり使われなくなりました。なによりもgoto以前に
setjmp, longjmpという、関数の間でのジャンプ出来るようなC標準ライブラリが存在したために
より強く禁忌されたといえるでしょう。のちにStructured ProgrammingからO-OProgrammingへ移り変わる
につれて行番号は何もなく、文の構造の厳格性や動的ディスパッチなどが整備されたため、必要性が薄れました。

現在あるラベルgotoとは、ループの中に飛び込むgotoなどではなく、二重のループ中のbreakなどで
脱出経路を明確化するなど、例えばコンピュータサイエンスの分野ではHaskellにおいてはモナドを利用して
例外や非決定性計算行うなど、引数付きgotoとも呼ばれる。

**デフォルトの名無しさん** · 2021/11/19(金) 09:01:28.58

Inline指定出来ないので関数呼び出しのコスト低減くらいしか用途が思いつかない
そこまでシビアな実装滅多に無いから基本的に使わない

**デフォルトの名無しさん** · 2021/11/19(金) 12:21:28.19

確かに関数化すりゃブロック脱出もシンプルにreturnさせりゃいい
となるとgotoは関数呼び出しによるオーバーヘッドの削減だけなのかな？
ナノ秒単位でも削減したいという余程のシビアな要件で使うって話になるけど、関数呼び出しごとにスタックのチェックが入るGoでそんな要件に意味ってあるの？とも思う

**デフォルトの名無しさん** · 2021/11/19(金) 12:34:26.60

というよりもアホ意識高いgoto異端審問官が、文句つけてくるので使わない。

**デフォルトの名無しさん** · 2021/11/19(金) 15:43:47.01

おれにとっては、Golangでgoto使うのは、構文解析器みたいなのを書くときにたまにあるんだけど、共通の処理までジャンプしたいときとか、
for文とかをネストしたときに、いくつか上のブロックまでジャンプしたいときかなあ。これも構文解析したあとの評価器で使うこともある気がする

ようするに最適化とかじゃなくて、ちょっとした大域脱出みたいなノリで使ってる

Go本体のソースコードでもこんな感じgoto使ってるんじゃなかったっけ

**デフォルトの名無しさん** · 2021/11/20(土) 11:05:39.09

俺たちのGO！

**デフォルトの名無しさん** · 2021/11/21(日) 07:26:46.41

IDEはどれがおすすめ？

**デフォルトの名無しさん** · 2021/11/21(日) 07:39:21.64

自分はVSCode

**デフォルトの名無しさん** · 2021/11/21(日) 23:14:16.37

私はEmacs

**デフォルトの名無しさん** · 2021/11/22(月) 06:12:39.00

VSCodeもemacsもIDEではないけどね

**デフォルトの名無しさん** · 2021/11/22(月) 07:05:20.26

バージョン管理からテストまで環境内で完結してるのに仲間外れなのか

**デフォルトの名無しさん** · 2021/11/22(月) 19:08:36.54

emacsは"環境"だから、
emacs > IDE
だよな

ところでIDEの定義って何よ？
高機能エディタと垣根がなくなってきたからそれらを区別する意味があるのかどうか

**デフォルトの名無しさん** · 2021/11/22(月) 19:28:29.86

統合開発環境だから、コンパイルからデバッグ、バージョン管理にデプロイまで揃ってるemacsとかVScodeを入れないとなると、いよいようろんな定義になる
RADとかグラフィカルな開発環境とごっちゃになってるのでは？

**デフォルトの名無しさん** · 2021/11/22(月) 19:36:29.51

エディタ内でデバッガと密接に連携(ブレークポイント設置して値を参照とか)できれば統合してると言ってもいいと思うんだが

**デフォルトの名無しさん** · 2021/11/23(火) 10:50:24.50

mapをrangeステートメントで処理すると毎回順番変わるのな
将来mapの実装を変えた時に要素の順番が変わっても大丈夫なようにあえてランダムにしてるらしい
最初知らなくて嵌った

しかもランダムに返す仕様の方がパフォーマンスをよくしやすいらしい
ensure better balancingって
なるべく偏らないように要素を配置するみたいな意味か

https://stackoverflow.com/questions/55925822/why-are-iterations-over-maps-random/55925880#55925880

**デフォルトの名無しさん** · 2021/11/23(火) 11:47:46.83

> ランダムに返す仕様の方がパフォーマンスをよくしやすい
いや流石にそんなことはないぞ
処理系の実装変更だけでなくマシン毎に結果が違うことも許容することで、パフォーマンス最適化の余地が広がるという意味だ

**デフォルトの名無しさん** · 2021/11/25(木) 20:43:12.75

11月TIOBEプログラミング言語人気ランキング、PHPの下落続く
https://news.mynavi.jp/article/20211109-2181586/

**デフォルトの名無しさん** · 2021/11/26(金) 17:11:22.22

Golangが一番書きやすい

**デフォルトの名無しさん** · 2021/11/26(金) 19:19:32.54

go と defer とチャネルが便利すぎるね
チャネルのキャパシティは未だに悩む

**デフォルトの名無しさん** · 2021/11/26(金) 19:31:07.75

チャネルはクソだろ
Cでいうポインタ関連のミスによる死と同程度くらいにはデッドロックを起こしやすい極めて危険な仕組み

**デフォルトの名無しさん** · 2021/11/26(金) 19:33:40.57

勉強中でよくわかってないんだけど
メインルーチンが死んだらゴルーチンもチャンネルも死ぬんじゃないの？

**デフォルトの名無しさん** · 2021/11/26(金) 19:53:34.58

デッドロックは一番の可能性としてキャパシティを疑う

**デフォルトの名無しさん** · 2021/11/26(金) 21:43:15.55

どんな言語でもスレッドやルーチェンの１つが落ちて無事平穏な言語は少ない。Erlangぐらいかな落ちる前提なのは

**デフォルトの名無しさん** · 2021/11/26(金) 22:02:31.09

もう新しいデータ来ないのに
私待つわ…いつまでも待つわ…と待ち続けるコードを書けば
当然ながら詰まる

**デフォルトの名無しさん** · 2021/11/26(金) 22:32:30.29

アミン…大統領

**デフォルトの名無しさん** · 2021/11/26(金) 22:54:09.91

未使用の変数がコンパイルエラーになるのは地味に良い

**デフォルトの名無しさん** · 2021/11/27(土) 15:33:06.29

俺もチャネルはどうかと思う
ある意味スレッドより危険

**デフォルトの名無しさん** · 2021/11/27(土) 15:56:47.57

設計間違えたらデッドロックするのはどんな通信でも一緒じゃね？
チャネルを殊更に危険視するの？

**デフォルトの名無しさん** · 2021/11/27(土) 16:07:17.64

>>676
デッドロックしやすい仕様なのは事実だし、危険だからといってその使用を回避できる標準的な代替手段が存在しない
他の言語ではだいたいpromise/future、fork-join、actorがあるからよほど変なことしなきゃデッドロックなんか滅多に起きないよ

**デフォルトの名無しさん** · 2021/11/27(土) 16:10:29.89

そうなんだ？　イケてないの？
Googleさんはなんでそんな方式を採用してしまったのやら

**デフォルトの名無しさん** · 2021/11/27(土) 16:43:12.87

>>678
デザインパターンみたいなものを極力廃して、小さな標準的なツールセットだけでモノ作れるようにするという思想は一貫している
しかしスレッド関連のデザインパターンというのは基本的に死なないためにあえて制約を設けているのであって、
Goの思想が逆に敷居を高くする方向に作用してしまったということだ

**デフォルトの名無しさん** · 2021/11/27(土) 16:49:44.44

CSPモデルに沿った実装がしやすいとは聞く。
CSPモデルができていればそれがデッドロックを起こすかどうか静的に検証できるはず。

**デフォルトの名無しさん** · 2021/11/27(土) 16:50:07.92

ほえー、そうなんだ
実際のところ、他の人がgoroutineとか使ったやつを -race 付きで実行すると警告出まくるやつばっかだったよ

Goの強みは並行処理だと思ってたのに、他の言語のことはよく知らんけどもそんな有様じゃ強みだなんて言えないなあ

**681** · 2021/11/27(土) 16:53:59.99

なんかID変わっちゃってたけど、おれは >>678 ね
>>679 に向けて返信した

**デフォルトの名無しさん** · 2021/11/27(土) 17:22:55.75

CSPモデル
ttp://www.usingcsp.com/cspbook.pdf

**681** · 2021/11/27(土) 18:04:43.03

すまん、せっかくCSPを紹介してくれるなら、もっと初心者向けのやつない？
興味はある

**デフォルトの名無しさん** · 2021/11/27(土) 18:14:49.72

これとか。
https://staff.aist.go.jp/y-isobe/topse/vic/slides/csp-isobe-2012-03.pdf

**デフォルトの名無しさん** · 2021/11/27(土) 18:28:08.91

>>678
ここに玉にディスりにくるRust坊、ほんと性格悪いな

**デフォルトの名無しさん** · 2021/11/27(土) 19:03:33.53

設計が間違えてチャネルで無限ブロックするならタイムアウトをつけるべきだし、Rustもチャネルで
無限ブロックするしほかの多くの言語も（スレッド）チャネルの受信でブロックする
チャネルとは違うがErlangメッセージパッシングだって似たようなもの

**デフォルトの名無しさん** · 2021/11/27(土) 19:14:15.48

>>687
そういうことを言ってるんじゃないのよ
>>677にも書いたけど標準的な安全な代替手段が存在しないことが問題

**デフォルトの名無しさん** · 2021/11/27(土) 19:53:13.18

Rustなんてスレッド実装が固まってから五年も経ってないお子ちゃま

**デフォルトの名無しさん** · 2021/11/27(土) 19:53:53.46

スレッドとかだとバッドパーツが一通り手間揃ってて
こういうのはやめましょうってのがほぼデザインパターン化されてるから
コードレビューでつぶせたり
処理を追うとわかったりする

**デフォルトの名無しさん** · 2021/11/27(土) 19:54:52.94

>>683,685
CSPモデルのasync/awaitに対する優位性って何？
見た目何もない気がするが。
(ちなJSではなくC#のスレッドプールに対するasync/await想定でよろしく)

**デフォルトの名無しさん** · 2021/11/27(土) 20:00:12.03

もともと危険なthread/mutexには安全なwrapperがあるのにgoのchannelにはそれが無いから、ってことかな？

**デフォルトの名無しさん** · 2021/11/27(土) 20:12:14.69

>>688
平行性のある現代的なプログラミング言語ではデットロックは言語仕様の問題ではなく、食事する哲学者の問題と
同じく制限された個数のチャネルで送られたデータが受け取られていないのに、送信できるようにはなりません。

これがレース競合を起こさないための標準的で安全な手段であり、グローバル変数や変数共有をgoroutine介して
同期ミューテックスもない操作すれば当然警告が出るでしょう。

そもそもgoroutineでのチャネルブロックはデットロックではなく、待機ブロックです。その証拠にSIGINTなどの
シグナルでは待機ブロックでも抜けるはずです。本来のデットロックなら応答しないかゾンビになります
もちろんスレッド（あるいは軽量スレッド）間でチャネルを介してのみデータを共有できるプログラミング言語も
存在しますが、goは親スコープにある変数などを操作できるように利便性のトレードオフ設計であり、より現実的で
効率的だとも言えるでしょう
また制限された個数でないチャネルの場合は送信に受信側処理速度が追い付かない場合、キューイングされて
無限にメモリーが圧迫される危険性があります。

非同期系の言語で使用されるpromiseや、未来値のプレスホルダーを参照するfutureでデットロックが起きないのは
当たり前です。前者は非同期であり並列/並行ではありません、後者は終了時まで待って値を受け渡すだけです。
fork-joinは何が言いたいのかわかりません、actorプログラミングモデルや純関数言語ならその通りですが
共有したいデータが多くの言語でチャネルやパッシングを介してのみなので競合は起こらないでしょうが
いつまで待っても到着しない受信側は、永遠に待ち続けるのは変わりません。

「そういう事をいってるんじゃない」
ま、こういう問題を一切合切、無難に解決してくれる標準的な手段を手続き言語に求めるのは分からなくも
ないですが、最終的にデットロック（あるいは待機ブロックで無限待ち）したらどうするか記述するような
フォールトトレラント処理が欲しいわけでもないのでしょうが、個数が限られている場合のレース競合対策の
ルールなので言語的ではなく、哲学的にどうにもならないと思いますが

**デフォルトの名無しさん** · 2021/11/27(土) 20:52:19.87

>>693
何も分かってないなら書き込むなよ

**デフォルトの名無しさん** · 2021/11/27(土) 21:01:18.61

>>693
それお前が今書いたん？
ググってもヒットしないが、そうとも思えないから原典があるのならそっちのURLくれ。

横だが「そういうことを言ってるんじゃないのよ」ってのは、単に、
生でスレッド処理を弄らせてデッドロックの危険を避ける色々な仕掛けを正しく準備しろ、というのなら、
フレームワーク等でその辺の仕掛けを全部用意してしまって、その上でジョブをキューイング出来るようにするだけの方が
処理性能も同じで手間がかからない分だけ合理的だろ、という話だよ。

Web系でSessionや認証周りは全部フレームワークに丸投げするべき、と言われているのと同じ。
スレッド周りでどうせ色々やらないといけないなら、最初からフレームワークに丸投げした方が合理的なんだよ。
だから、レイヤーが低い記述が出来るのなら、その手間に見合うだけの価値がないと意味無いんだけど、それがないでしょ、って話。
平行並列周りの研究をしてていじくり回したいだけの人＝そのプログラムがその時動けばいいだけの人
にとっては言語が直接サポートしてるのは便利だけど、
製品としてガッツリ動かす為には結局色々全部必要なら、職業プログラマにとってはまるで意味無いよね、という話。

**デフォルトの名無しさん** · 2021/11/27(土) 21:15:45.01

>>691
静的に検証ができるっとことだろうな

**デフォルトの名無しさん** · 2021/11/27(土) 21:26:58.69

>>696
何の検証？デッドロック？
async/awaitはデッドロックはしないぞ。
(永遠にジョブが終わらずに待たされてるように見えるだけ。メインスレッドは動き続けるし、GUIも動く)

**デフォルトの名無しさん** · 2021/11/27(土) 21:42:40.45

一生懸命にRust坊が荒らしてるｗｗ

**デフォルトの名無しさん** · 2021/11/27(土) 22:37:45.64

いやこれはMSのC#おじさんだね、チャネルの話ならまだ良いがGolangの設計にありえないasync/awaitとフレームワークを交えながら意味不明なことを呟き続ける。
普通にデッドロックするしフレームワークってなんやねん（笑）Web系なんて共有すべきデータが無いんだからシコシコ糞コード書いてろよ？
おまえの競争相手はJavaとかPHPとかRailsだから、そっちに噛みついてこい、C#なのかRustなのかどうでも良いけど頭おかしいことは確か

**デフォルトの名無しさん** · 2021/11/27(土) 22:51:09.81

>>697
そういう意味ではモデルの記述力か。
async/awaitは動作モデルを単純化することで安全性を保証できるようになったけど
食事する哲学者問題みたいなものを記述することができない。

**デフォルトの名無しさん** · 2021/11/27(土) 22:58:09.67

async/awaitみたいな使い方ができないのはヤダヤダってことなんだろうな

**デフォルトの名無しさん** · 2021/11/27(土) 23:25:17.01

>>688
どの手段も場合毎に安全では無いし、それ故に画一的な標準的手段にはなり得ないから、それだけバリエーションがあるんよ。
Goはそのあたり多様性をネグって「こういう場合はこういう事に気をつけようねぇ！！」という脳筋的解決を図ってるの。
愚直だけどシンプルよ。

**デフォルトの名無しさん** · 2021/11/27(土) 23:26:48.32

Taskをスレッドプール使ってやりくりするより、はるかに早いんよな…goroutine。

**デフォルトの名無しさん** · 2021/11/27(土) 23:31:12.50

若い人にC#じゃなくてGoにしましょう言われたんかな？可哀想だから代替えとしてこういうのもありますよ
https://hackernoon.com/asyncawait-in-golang-an-introductory-guide-ol1e34sg
https://github.com/Joker666/AsyncGoDemo
https://github.com/StudioSol/async

**デフォルトの名無しさん** · 2021/11/27(土) 23:40:22.05

>>704
お、こういう情報の提供はありがたい。

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

むしろ定年間際な俺みたいなCで育った奴の方にウケてないのか？

**681** · 2021/11/28(日) 00:22:11.00

Go以外の並行処理のことはよくしらんけど、「Go言語による並行処理」を一通り読んでからは、並行処理でバグることへったよ
他の並行処理モデルだともっとうまいこといけるんか？

**デフォルトの名無しさん** · 2021/11/28(日) 07:47:32.52

別の言語じゃ主にメモリを共有して排他処理して使ってる
ガバガバだけどミスには寛容なのでわりかし安心ではある
Goでもガバガバにキャパシティ増やしとけばそんなにデッドロックしないと思うんだけど
デフォルトだと一個でもキューされてると次の送信がwaitになる優しくない仕様を問題視してるんじゃないかな？

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

>>700
> 食事する哲学者問題
これを記述出来たとして、何が嬉しいんだ？

並列は結局のところ、処理能力の増大を目指してる。
シングルスレッドに無限大の処理能力があれば、誰も並列なんて使わない。
現実的にはこれはないから、様々な方策を用いて何とかするわけだ。

そこで、ジョブを他CPUに投げれれば事足りますね、で単純化したのがasync/awaitで、実際確かにこれで済む。
マルチスレッドの諸問題と解決策等、プログラミング界で経験値がたまった結果の、現段階の最適解だ。
これを実装してなくてどうする？と思うが。

スレッド周りの問題をいじくり回したい研究者には向いてるのだろうけど、それだけだよね。
やりたければ他言語でも生スレッドは使えるから、いくらでも出来るけど。
逆にGoroutineではチャネル接続タイプしか記述出来ないから、そこを越えた研究には向かないよ。
とはいえ現段階ではチャネル接続の優位性が覆る事はなさそうだが。

多分な、
・チャネル接続にすればマルチスレッドの諸問題が解決するかも？
という見積もりが外れただけなのだと思うよ。だからGoはメジャーになり損ねた。

なおJSは逆に、
・シングルスレッドに無限大の処理能力があれば、誰も並列なんて使わない。
　→ならシングルスレッドの処理能力を無限大にすればよくね？引っかかってるところ全部I/Oだろ
でI/Oをすべて切り離して非同期にした結果、これが大当たりして、あらゆる所に蔓延ってる。
当時メジャーでなかったクロージャの利便性を知らしめたとか、GUIにはプロトタイプが向いてたとか、他にも色々あるけど、
根本の言語設計が素晴らしかったから結果的にでも大当たりしたのは事実だよ。

**デフォルトの名無しさん** · 2021/11/28(日) 09:40:53.84

>>708
というより、本来チャネルよりも適した抽象化がある場合でもチャネル使わなきゃいけないことが問題じゃないかな
たとえばpromiseで一つの値を返せたらいいだけのケースでチャネル使っちゃうと、
そこに処理は単一の結果の生成をもって完了するというセマンティクスは全く残らないわけよ
で誤って値を2回取り出そうとしたらデッドロックだ

**デフォルトの名無しさん** · 2021/11/28(日) 09:52:08.42

ていうかgoでもロックとか
サードパーティのロックフリーキューのライブラリは使えんじゃね？
しらんけど

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

>>710
ちなみにPromiseも俺は不要だと思ってるんだけど、
Promiseが無いと書けない何かってあるか？
C#はPromise見えてたけど採用しなかったし、実際async/awaitで足りてる感じだし。

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

>>712
async/awaitで使用されるTaskはpromiseの一種だよ

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

>>713
それはJSerの言う「Promiseが有ったからこそのasyncだ」という言い訳だろ。
Promiseという界面を露出させなくても問題ないと踏んでasync/awaitだけにしたのがC#。
勿論それ以前にC#だと生スレッドも使えるから最悪何とでもなるという保険はあったにしても。

C#erも同種の言い訳、つまりthread→backgroundWorker→Task→asyncと進化したのであって、
これがなかったら無理だった、という事を言うけど、これもやっぱり無理筋で、
2000年時点で「技術的に」asyncが実装出来なかった理由は見あたらない。
結局、思いつけなかっただけだと思うんだよね。

実際、2000年当時のCPUでも今のasync/awaitのコードは動くだろうし、
今現在Task界面も露出する意味無いだろ。
2000年当時にC#がいきなりasync/await実装してデビューしてたら神だったと思うよ。

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

>>714
async/await自体もpromiseの実装だよ
https://ja.m.wikipedia.org/wiki/Future_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3
なおasync/awaitで事足りるpromiseのユースケースにおいては、Goではチャネルなんか使わず普通にgoroutine内で同期処理すればいいので、今の話題とは無関係

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

>>715
それはPromise中心主義的な考えであって、
実際async/awaitの理解にはPromiseの理解は不要だろ。
「そこで一旦止まって、非同期Jobが終わり次第、次を実行」で済むのだから。

実装でPromise型にするのも一つの手だけど、forkでも実装出来るのだし、(むしろforkの方が簡単）
> async/await自体もpromiseの実装だよ
これは買いかぶりすぎで、async/awaitとPromiseは直接の関係も必然性もないよ。

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

>>715
そういえば脱線を嫌ってるのか？なら戻しておくと、

Goはgoroutineで並列平行をお気楽に書けるようにしたが、
並列は今のところasync/awaitで決まりなので、目論見は外れた。
平行は…async/awaitではなさそうだし、まあチャネルだろうし、goroutineかも？

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

>>715
716（脱線側）補足

× > async/await自体もpromiseの実装だよ
○ async/awaitの実装の一つがpromise

async/awaitはただの記法であって、その実装にpromise方式も使える。
つまりasync/awaitの方が上位概念だよ。同一レイヤーではない。

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

>>714
Taskなしのasync/awaitだけじゃ並列処理できないんじゃないの？

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

>>719
何で？
Jobを投げ込むのにTask型を使ってるだけで、要は関数のエントリポイントが有ればいいだけだし、実際JSはそうだろ。

> async function asyncCall() {
>
console.log('calling');
>
const result = await resolveAfter2Seconds();

> console.log(result);
>
// expected output: "resolved"

> }
>

asyncCall();
> https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/async_function

async/awaitが保証してるのは、
・async関数は非同期で実行される --- (A)
・awaitでメインスレッドは一旦処理が返る。その後、async関数が終わり次第続きを実行する。
であって、(A)をスレッドプールから実行するようにしたのがC#で、並列されるし、
そうしてないだけ、つまり非同期を同期的に書けるようにしただけなのがJSだろ。
だから逆に、JSでも(A)をWorkerスレッドに振るようにしたら並列するようになるだけだよ。

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

awaitで待っている側はその間止まっているわけだから並行処理ではあっても並列処理じゃないでしょ。
まぁTask.WaitAllのように複数同時に投げられるようにするならそれでもいいだろうけど。

**デフォルトの名無しさん** · 2021/11/28(日) 12:21:57.96

async/await ってPromiseの糖衣構文にしか見えなくて大いに疑問が(知らないだけ？
糖衣構文で言語仕様を膨らませて、こんなに簡潔に書けるようになりました！とかもう子供かと
言語仕様が増えても出来ることが簡潔に書ける以外で変わらないんじゃ劣化してるだろ

簡潔にと言われるたびに信用を下げる

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

>>721
それは君のawaitの理解が間違ってる。
書いたとおり、awaitで「メインスレッドは一旦処理が返る」から、GUIも反応するんだよ。

メインスレッドはasync/awaitでは止まらない。
awaitでイベントループ(メッセージポンプ)に返されるだけ。
その後asyncが終了したら、awaitの続きから実行される。
この実装の一つとして、Promiseがある。でも動かすだけならforkで実装した方が多分簡単。

メインスレッドは止まってないのだから、asyncジョブはいくらでも「順次」投げられる。
（同時に投げる必要はない）
並列平行したければ好きなだけ投げ込めばいいだけ。