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/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ジョブはいくらでも「順次」投げられる。
（同時に投げる必要はない）
並列平行したければ好きなだけ投げ込めばいいだけ。

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

>>721
俺の理解では
awaitは非同期関数でのawait以降のセンテンスをthenメソッドの処理としてasyncを実行する
thenのネストを平らにして、単に簡略に書けるだけの糖衣構文

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

>>724
まー、理解が怪しいんで間違ってたら指摘してくれ
ともかくawaitじゃメインスレッドは停まらない、もしくはメインスレッドではawaitは呼べない(はずじゃなかったか？)、という程度の理解

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

>>722
簡単は正義だろ。
無駄に仕様が膨らんでいるのは、紆余曲折しすぎたからだ。

Promiseが便利だとされているのはPromise.all位で、つまりjoinだが、
今のasync/awaitはこれを直接的に解決する手段を提供してない。
だからここが何とかなれば、async/await以外は廃止方向だと思うぜ。今のままなら。

JSの場合はasync/awaitが見えてたのにPromise導入に踏み切った。
俺はあれは判断を間違えてると思うよ。
JSは仕様を廃止出来ないのだから、ムダ仕様を入れる度にオワコン化していくだけ。

逆に、バージョン管理してて仕様を廃止出来るC#は、実験場にも出来るし、今そうなってる感はあるけど、
本来ならもっと軽量級のGoやRubyで色々やるべきだったよね。
Goも登場時の2009にasync/await持ってればもっとメジャーになってたと思うよ。
goroutineも無いよりはましだけど、その程度でしかないから今こうなわけでさ。

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

>>723
イベントループの存在が前提なのかな。
async/awaitではawaitで待っているTaskが内部でまたawait待ちになった時に
その制御を取得する手段がないから、そのイベントループ自体はasync/awaitとは
異なる機構で実現されてるってことかね。

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

>>724
>>725
idミスってるぞ

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

>>727
そうだね。少なくともC#もJSもそう。ランタイムがある前提。

要は、asyncジョブが終わった時にメインスレッドをたたき起こす仕組みが必要なだけ。
GUIの場合はメインスレッドはイベントループを回ってるから、そこにイベントとして与えるのが一番簡単だし、そうしてるはず。
コンソールアプリだとイベントループはないので、ランタイム側にメインスレッドをたたき起こす仕組みを付加しないといけない。
けど、goでもこれはやれば出来るだけの話だよね。

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

>>716
違うよ。
全然別の部分からresolveされるPromiseをawaitするっていう、コールバック関数をasync/awaitに変換する事ができたりする。
可換なんよ。

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

async/awaitが使われていると、コードのいろんな箇所がどんどんノンブロッキングになっていく傾向がある気がしていて、
多くの人にとってかなり使い心地が良いんだろうな、と思ってる

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

**デフォルトの名無しさん** · 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
なるほどね。