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(日) 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
なるほどね。

**デフォルトの名無しさん** · 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が文字通りメインスレッドで待つからって話ではなく？