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/02/11(木) 02:00:07.60

ジェネリクス結局どうなるんだよ

**デフォルトの名無しさん** · 2021/02/11(木) 03:54:00.93

議論の末リジェクトされたって結構前に見たけども

**デフォルトの名無しさん** · 2021/02/11(木) 06:20:02.21

あったら便利かも知れないけど、無くても不便を感じてないんだよな
多分、普段に書いてる案件の方向性の違いじゃないかな
ライブラリ書きな人は欲しがるのかも

**デフォルトの名無しさん** · 2021/02/11(木) 06:24:20.93

Webアプリだと必要なケースはほぼないかな
複雑なデータ構造を扱う分野とか数値計算なら必要だろうね

**デフォルトの名無しさん** · 2021/02/11(木) 07:33:17.81

複雑なデータ構造というより、多様なクラスじゃないか？
クラスが異なるが構造は同じ、といった場合に処理を使い回すための機能だから
たとえばList<Animals>とか

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

https://github.com/golang/go/issues/43651
spec: add generic programming using type parameters #43651
Labels: Proposal Proposal-Accepted Proposal-FinalCommentPeriod

アクセプトされたぞ

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

あと議論の末リジェクトされたのはエラーのキャッチでは？

https://github.com/golang/go/issues/43777
proposal: Go 2: catch error handler #43777

**デフォルトの名無しさん** · 2021/02/11(木) 10:26:29.66

>>375
おお！承認されたのか
ところで、go2はいつくるの？

**デフォルトの名無しさん** · 2021/02/11(木) 11:34:18.35

https://blog.golang.org/generics-proposal

v1.18β（今年末）にはジェネリクスが入ってる予定だそうだから
そこからしばらくexperimental feature扱いになるとして
だいたいv1.20（再来年頭）かそこらでexperimentalじゃなくなってv2.0にするんじゃないか

まあこれは一番順調に行ったらって予想だけど

**デフォルトの名無しさん** · 2021/02/11(木) 12:43:54.91

>>375
ファイナルフュージョン承認！

**デフォルトの名無しさん** · 2021/02/11(木) 13:01:17.98

実装難しそうだから相当先だろうな
特殊化をコンパイル時にやるのか実行時にやるのかすら決まってないみたいだし

**デフォルトの名無しさん** · 2021/02/11(木) 14:10:14.32

Javaのジェネリクス導入時みたいに、総称型コレクションの利用で警告を出すような真似はしないで欲しい

**デフォルトの名無しさん** · 2021/02/11(木) 14:18:10.77

なんで Java ではデフォルトで「raw型の使用を無視」にしとかないで、探して無視に指定するまでうるさく警告を出すことにしたんだろう

**デフォルトの名無しさん** · 2021/02/12(金) 03:53:22.35

結局仕様はほぼJavaと同じか

**デフォルトの名無しさん** · 2021/02/12(金) 13:19:24.35

エラーキャッチリジェクトかよ・・

**デフォルトの名無しさん** · 2021/02/12(金) 19:55:13.35

issue の本文で
func xxx() xxx, error
とか
nill
とか、go 使ってないような奴なのは見え見えだし、
妥当じゃないか？

**デフォルトの名無しさん** · 2021/02/13(土) 01:19:56.35

ジェネリック馬鹿を排除できるだけでもgoを採用する意味あるわ。

**デフォルトの名無しさん** · 2021/02/13(土) 02:05:58.45

実務でgoやってみたいけど今は未経験の募集あまりないな

**デフォルトの名無しさん** · 2021/02/13(土) 02:18:54.12

ジェネリクス反対派って結局何がしたかったんだろう
訳がわからん
言語の設計者でもないのに

**デフォルトの名無しさん** · 2021/02/13(土) 03:56:17.09

>>386
お薬かな

**デフォルトの名無しさん** · 2021/02/13(土) 05:14:35.81

Java ではジェネリクス過激派による強制で多いに迷惑したから

**デフォルトの名無しさん** · 2021/02/13(土) 08:17:20.01

>>383
Javaと同じってどこが？

**デフォルトの名無しさん** · 2021/02/13(土) 09:26:28.23

正直、意味があるのか俺には理解できない
他の言語は継承による拡張なので共変反変が意味を持つ
でも go は継承による関係じゃなくて、インターフェースを具備しているかどうか
元々がインターフェースさえ合致していれば可換なのだから型パラメータには意味がない
そう思ってしまう

どうしても型パラメータが必要な用例、それを目立つように挙げて貰いたい

**デフォルトの名無しさん** · 2021/02/13(土) 10:56:01.28

Goで便利なのはsort関数とかmap関数なんかではないの？
今まで型ごとに書くしかなかったんだし。

**デフォルトの名無しさん** · 2021/02/13(土) 12:32:44.33

まずmapはインターフェースをキーとしても値としても使えるから問題にならない
ソートもsort.Interfaceを具備したコレクションでソートするから、Swapとかのための比較可能な値を返すメソッドをインターフェースで持てば良い

構造体はただの入れ物に過ぎないよね

**デフォルトの名無しさん** · 2021/02/13(土) 12:40:39.64

インターフェースで構造体の多態性を確保してるから、それが既に型パラメータ以上の柔軟さを持ってる
なんでインターフェースよりも性質的に劣ってる型パラメータを導入しなきゃなんないの？
頭のいい人が、それでも導入が必要だと判断したのだから、そこには理由があるはず
でも頭が悪いから、俺ではissueで見つけられなかった

**デフォルトの名無しさん** · 2021/02/13(土) 12:54:38.86

>>394
インターフェイスを使ってしまうと毎回型チェックしないといかんし、コンパイル時に縛りもかけられんでしょ。
テストで網羅するといっても、ユーザに使ってもらうライブラリなんかではそうもいかん。
静的解析でもうまくいかんこともあるし、柔軟性を持ちたいのではなくて、コンパイル言語として担保したいんじゃないか？
俺は今まで型ごとに関数作ってたけど、インターフェイスでなんとかしてたって事？それも極端だな。

**デフォルトの名無しさん** · 2021/02/13(土) 13:03:01.32

>>396
というかインターフェースを型パラメータみたいな物として使っていて問題なかったと言ってるんだよ
機構として使い回すために、その機構に使いたかったらインターフェースを実装する
ソートの機構が使いたかったらsort.Interfaceを実装するでしょ

**デフォルトの名無しさん** · 2021/02/13(土) 13:27:48.18

>>396
そもそも何で型チェック？
メソッドの挙動やらが違うのに同じインターフェースを使ってるのか？
Javaとかの型パラメータでも、まさか中でキャストして使ってるのか？

偶然にインターフェースを実装してしまったケースなんて想定しても仕方ないと思う
それは設計ミスだから
区別用にダミーのメソッド生やしとけば？

**デフォルトの名無しさん** · 2021/02/13(土) 13:30:40.12

goは組み込みで要素が型付けされた動的配列と連想配列を持ってるから、他のコレクションはあまり必要ないんだよね
それらでカバーできないようなケースってそもそも大抵は特殊な状況なんで、汎用的なコレクションではなくアプリの要請に合わせて独自に作るのが自然

**デフォルトの名無しさん** · 2021/02/13(土) 13:45:02.72

んな意味不明なジェネリクスより
>>251 のバグを直して欲しいんだよな

**デフォルトの名無しさん** · 2021/02/13(土) 13:54:07.96

>>397
ジェネリクスはロジックを使い回すのためだけにあるわけではないと思うよ。
Sortableなんてinterfaceを実装した配列を引数に受ける関数の戻り値の型は何になる？
Sortableの配列が帰ってきても無意味でしょ。

>>398
中でキャストするとかは意味不明じゃないか。
ジェネリクスがない頃のObjectの配列を受けざるをえないメソッドはまた違っただろうけど。
ダミーのメソッドとか完全に意味不明。

**デフォルトの名無しさん** · 2021/02/13(土) 14:07:47.74

>>401
Sortableの配列を返すので正しい
文意からソート結果だろ？

君が型チェックしなきゃならんとか意味不明な事を言い出すからエスパーしたんだよさせるなよ
インターフェースならメソッドを呼ぶだけだから型チェックなんて話は出てこない
型チェックするってことは実体に変換しなきゃならんという話だろ

そうでない場合に考えられるケースとして、偶然に同じインターフェースを実装してしまった構造体を、偶然に渡してしまうコーディングミスを考えているとエスパーしてあげた
そんな阿呆な設計をしてるなら、引数としてるインターフェースにダミーのメソッドを生やしとけば、別のインターフェースになるから誤って渡すミスは無くなる
エスパーさせるなよ

**デフォルトの名無しさん** · 2021/02/13(土) 14:21:47.27

>>402
ソート可能なインターフェイスを受けてソート可能なインターフェイスが帰ってきても何も得しない。

[T Sortable]な関数の返り値は[]Tで十分でしょ。
結果がもう一度ソート可能かなんか必要な情報でない。

intがSortableだとして、返り値が[]Sortableだと、結果は型チェックしないとだよね。
[]intが直接帰ってきた方が効率的だし、無駄なコードではないよね。
やってることも自明。

mapとかflattenなんかなんかはジェネリクス使えないと使い物にならんと思うが。

エスパーするならジェネリクスの使いみちをエスパーしなよ。

**デフォルトの名無しさん** · 2021/02/13(土) 14:23:26.25

単一の引数だけなら>>395のようにインターフェースで代用できるけど
複数の引数や戻り値の型を合わせたいという場合は型引数が使いたいよね。

**デフォルトの名無しさん** · 2021/02/13(土) 14:34:17.23

>>398
キャストしないといけないの理解できてないあたり、型パラメータとインターフェースでの実装の違い理解してなさそう

**デフォルトの名無しさん** · 2021/02/13(土) 15:24:34.05

>>404
複数の別のインターフェースを引数に持たせれば問題ないでしょ
それぞれが型パラメータとして機能するんだから

戻り値も同じ………いや、戻り値に関しては一概には言えないのか
でも実体ポインタを返すメソッドは>>251のバグに引っ掛かるんで使いたくない
→ 戻り値の実体ポインタはインターフェースを備えてるならば、本来は反変でアップキャストされてインターフェースを返しているとも判断されるべき
このバグで多態が機能しなくなるから使いたくない
具体的にはシグネチャが違うため、変種をコレクションに混在して格納できない

ジェネリクスを導入して個別に実体ポインタを返せるようにした時に同じ現象になるはず
このメソッドを持つジェネリクスな構造体は、それぞれ可換でないので多態が適用できない
コレクションに混在させられない

インターフェースを返す設計ならば、それらは実体は異なっても多態が機能してコレクションに混在格納できる
よって、インターフェースを返す方が設計として抽象度に優れている

以上の論旨から、ジェネリクスはインターフェースの下位互換だとしか見えない

**デフォルトの名無しさん** · 2021/02/13(土) 15:35:29.60

>>406
違くて、2つの引数があるときにその型が同じであってほしい場合とかね。

**デフォルトの名無しさん** · 2021/02/13(土) 15:42:03.45

>>407
その場合には同じインターフェースの二つの引数を持つことによって問題がある事例について具体的に指摘してくれ
型が同じことは保証されてるぞ

**デフォルトの名無しさん** · 2021/02/13(土) 15:44:29.17

>>406
インターフェイスはインターフェイスで使えば良くて、ジェネリクスで効率的にできたり型を自明にできる部分はジェネリクスを使えばよいでしょ。
今でもコードジェネレータなんかで作ってる部分もあるだろうし。

どちらかがあれば原理的にどちらかが不要なのと、
どちらかがあれば片方は作ってはいけないのは別。

Sortとか、mapの[T,U]のKeyのみ、Valueのみを([]T,[]U)と、配列として返す関数なんか書こうと思ったらジェネリクスが無いと型チェックの嵐でしょ。
確かにキャストではないけど、型チェックもノーコストではないよ。

ジェネリクスのある言語使った事無いんじゃないの？

>>403のケースなんかはどうするん？型チェックすんの？

**デフォルトの名無しさん** · 2021/02/13(土) 15:45:29.07

>>408
map[T]Uを受けて、[]Tと[]Uを返す関数。

**デフォルトの名無しさん** · 2021/02/13(土) 15:51:17.90

とか顔真っ赤にして主張してきたけど、具体的にちょっと面倒な事例に自分で気づいてしまった

new() が厄介だな
new の代わりにインスタンスを生成する factory 一時クラスを外から渡してやれば解決するんだけど面倒ではある

**デフォルトの名無しさん** · 2021/02/13(土) 15:56:48.27

>>408
結局は返り値の話に帰着するのかもしれないけど (T, T) -> T な関数が欲しいとかね。

**デフォルトの名無しさん** · 2021/02/13(土) 16:10:36.47

返り値に関係なかったら、Tとそれに対するfunc(x T)を受ける関数とかかなぁ。

**デフォルトの名無しさん** · 2021/02/13(土) 16:10:51.14

>>410
納得した

メソッド引数のシグネチャが異なるものを一本化して書けるわけか
確かにインターフェースじゃmap[T]Uを引数とした共通メソッドは書けない
T,Uがインターフェースだとしても、それぞれのインターフェースの組ごとにメソッドが必要になるから

**デフォルトの名無しさん** · 2021/02/13(土) 16:12:52.49

>>414
伝わってよかった。逆もしかり。
[]Tと[]Uを渡してmap[T]Uを返してくれる関数も。
Pythonでいうとzip関数的な。

**デフォルトの名無しさん** · 2021/02/13(土) 17:03:51.51

>>415
JavaだとProxyを使って何でも解決するという黒魔術的解決手段があるのが恐ろしい
デバッグ用だよねとか思ってると struts とかwebフレームワークのソース読んだ時に、インタセプターとかで普通に使われていて更にビビる

**デフォルトの名無しさん** · 2021/02/13(土) 17:45:13.81

>>416
Springの十八番だな。
ただ、ああいう方法だと結局、ランタイムで死ぬかどうかをテストで担保するしかないって方向性に行きがち。
あとパフォーマンスももちろん遅い。
今回のジェネリクスがどう実装されるかが一番気になるけど、俺的には素直に関数たくさん作って欲しい。

**デフォルトの名無しさん** · 2021/02/14(日) 01:42:02.77

これメソッドには型パラメータ無理なの？

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

>>400
どう考えてもバグじゃないと思う。Goのinterfaceとstructの関係はembedしなければほぼ静的方チェックありの
ダックタイピングだから「そのメソッド実装がインタフェースAを実装している」と思い込んでるのは自分であって
実際にはJavaのようなimplementではないです。もっと言うなら、ルックアップが行われるのは、実行時であり
コンパイルは厳密な型チェックが行われます

**デフォルトの名無しさん** · 2021/02/15(月) 07:00:31.98

>>419
んじゃ、言語拡張要望と言い直そう
メソッドの戻り値がインターフェースでの戻り値の型に反変できるなら、インターフェースを具備していると判定して欲しい、と

**デフォルトの名無しさん** · 2021/02/15(月) 07:12:07.78

ポインタじゃなくてインターフェースを返すのが正しいのでは？
何故ポインタを返す
インターフェースのポインタにはなんの意味もない

**デフォルトの名無しさん** · 2021/02/15(月) 07:45:45.18

>>421
いや、インターフェースのポインタじゃなくて、構造体ポインタ
構造体ポインタ*SubがインターフェースISubを具備しているのは代入させて確認

んでISubを返すメソッドを持つ別のインターフェースを具備させようとした時に、戻り値としてISubではなく、ISubに代入可能な*Subを返させると、シグネチャ不一致でエラー
ISub を期待しているのに *Sub を返していると

インターフェースを具備しているかの判定でも、反変を考慮してくれないだろうか、という要望
そうすればインターフェース対応でキャストして返すメソッドと構造体固有のメソッドの二本を作らなくて済むから

作れよ、と言われちゃうか

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

>>421
シグネチャが合わないコンパイルエラーの時だけ、戻り値の型が互換(反変可能)かで追加チェックさせればいいから、パフォーマンスが極端に悪くなることはないはず
という見立て

**デフォルトの名無しさん** · 2021/02/15(月) 14:32:51.97

>>421
インタフェースを返すのが理論的にも実装にも正しいけど、インターフェースのポインタは埋め込みを
するときにコンパイラが使う。あんまりこれをやるモジュールは（メモリサイズが大きくなるから？）
標準ライブラリ以外見ないけど。
>>423
「 ISub を期待」というのは分からなくも無いけど、実行時じゃなければ分からないチェックを
コンパイルの速度と、言語の厳格性を犠牲にして、（かなり）保守的な言語がやると思えないですね

**デフォルトの名無しさん** · 2021/02/17(水) 21:45:03.79

Go 1.16 is released
https://blog.golang.org/go1.16

**デフォルトの名無しさん** · 2021/02/18(木) 00:00:24.35

今回の目玉は embed で、あとは modules がデフォルト利用になったくらいか
96% って、どこから来た数字なんだろ？

**デフォルトの名無しさん** · 2021/02/18(木) 01:11:43.46

ioutilオワコンになったのか

**デフォルトの名無しさん** · 2021/02/18(木) 01:58:45.29

え、これすごくない？
ファイル内容のバイナリを変数に設定できるのか
クソ便利そう

**デフォルトの名無しさん** · 2021/02/18(木) 02:18:54.53

凄くはないがまた変なものを入れたなあ

**デフォルトの名無しさん** · 2021/02/18(木) 08:15:16.68

そんなに変なもの？
結構ニーズあったじゃん。

**デフォルトの名無しさん** · 2021/02/18(木) 10:42:52.64

embed例を交えながら詳しく懇切丁寧に説明してくれ

**デフォルトの名無しさん** · 2021/02/18(木) 10:59:32.89

>>431
WebUIを持ったアプリの画像なんかのアセットをバイナリ一つで配布したいとか。

**デフォルトの名無しさん** · 2021/02/18(木) 19:44:54.68

それはしゅごい

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

それって凄いことなの？逆に今までできなかったの？

**デフォルトの名無しさん** · 2021/02/19(金) 02:06:27.21

外部ライブラリで出来てたから、そんなにインパクトはない。むしろNotifyContextの方が意味ありそう
こういう事は他言語だと非常にやりづらい

**デフォルトの名無しさん** · 2021/02/19(金) 02:54:55.96

NotifyContext例を交えながら詳しく懇切丁寧に説明してくれ

**デフォルトの名無しさん** · 2021/02/19(金) 02:57:11.30

自分で調べろや

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

android アプリを調べようと、go android 常駐アプリで検索したんだけど、go の記事が探しづらい
以前からポケモンが引っ掛かっていた上に、次のandroid11はGoエディションなのか？

**デフォルトの名無しさん** · 2021/02/20(土) 10:48:48.97

1.16 だと、Deprecation of io/ioutil は面倒に感じるなぁ
一杯使っちゃっていて

**デフォルトの名無しさん** · 2021/02/20(土) 12:08:15.81

検索ワードはgolangって言うのはこのスレの常識

**デフォルトの名無しさん** · 2021/02/20(土) 12:48:22.08

そういやgolang.jpってもう活動していないのか
日本のgoコミュニティの総本山たるべきドメイン名を無駄にしやがって

**デフォルトの名無しさん** · 2021/02/20(土) 16:13:03.32

ほんと返すがえすも go は名前がクソい

**デフォルトの名無しさん** · 2021/02/20(土) 17:07:51.09

ほ～ら～　あしもとを見～て　golang

**デフォルトの名無しさん** · 2021/02/21(日) 00:08:47.19

名前よりもマスコットがキモすぎるのが気になってしかたがない

**デフォルトの名無しさん** · 2021/02/21(日) 00:49:16.30

キモネズミ

**デフォルトの名無しさん** · 2021/02/21(日) 03:58:10.72

ヽ( ;ﾟ;ж;ﾟ;)ﾉｺﾞｰﾌｧｯ

**デフォルトの名無しさん** · 2021/02/21(日) 07:48:25.22

俺みたいにゴーファ君を結構可愛いとか思う人間がいるから厄介

**デフォルトの名無しさん** · 2021/02/21(日) 20:35:02.33

JAVAのマスコットよりはまし(´・ω・`)

**デフォルトの名無しさん** · 2021/02/21(日) 22:08:56.40

c#はマスコットいないんだぞ
クラウディアとか藍澤光とかいたけどな

**デフォルトの名無しさん** · 2021/02/21(日) 22:43:47.36

マスコット…冴子先生がCortanaとして復職してくれたなら、Cortanaボタンを非表示にしないのに…

**デフォルトの名無しさん** · 2021/02/22(月) 00:06:54.06

マスコットはD言語がカワイイ。LISPが最キモ。

**デフォルトの名無しさん** · 2021/02/22(月) 00:53:22.82

LISPにマスコットなんてあったのか・・とおもってググってみたら
たしかにこれはエグい
キモすぎ

**デフォルトの名無しさん** · 2021/02/22(月) 18:22:17.90

なんか gui ライブラリで調べるといろいろ出てきてよくわからん
マルチプラットフォームな gui って何がええんや？
Qt は golang で使ってる人おるんかえ？

**デフォルトの名無しさん** · 2021/02/22(月) 18:24:31.58

GoでGUIアプリを作っている人はほぼ存在しない

**デフォルトの名無しさん** · 2021/02/22(月) 18:48:30.06

>>454
ありがとう、そうなんか
主にバックエンドで使われてる感じなんかな

https://i.imgur.com/pGBnPCA.png

ふむう

**デフォルトの名無しさん** · 2021/02/22(月) 20:26:35.06

ローカルHTTPD建てて、ブラウザからAPIで操作するアプリは提供してる

**デフォルトの名無しさん** · 2021/02/23(火) 15:36:36.73

>>455
ウチはElectronでGUI作ってバックグラウンドにGo使うてる

**デフォルトの名無しさん** · 2021/02/23(火) 16:06:31.74

>>457
面白そうだね
オレオレGUIツールだと.netが楽すぎるのでそっちで書いちゃうけどGOで書くのも楽しそうだ

**デフォルトの名無しさん** · 2021/02/23(火) 16:23:00.26

GUIは俺は普通にブラウザ起こしてるな。
IE使われると辛いけど。

**デフォルトの名無しさん** · 2021/02/23(火) 17:19:08.91

簡単なguiツール作るならlorcaオススメ

**デフォルトの名無しさん** · 2021/02/23(火) 20:02:44.99

for (大分類) {
　for (中分類) {
　　for (小分類) {

　　　wg := sync.WaitGroup{}
　　　cpus := runtime.NumCPU()
　　　errCh := make(chan error, cpus)
　　　defer close(errCh)

　　　for (アイテム) {
　　　　wg.Add(1)

　　　　go func() {
　　　　　defer wg.Done()
　　　　　errCh <- 他の関数()
　　　　}()
　　　}

　　　err := <-errCh
　　　if err != nil {
　　　　return だめです
　　　}

　　　wg.Wait()
　　}
　}
}

こんなコードでwaitしっぱなしになるんだけど
なぜなんでしょうか(´・ω・｀)
途中の即時関数にwgのポインタ（&wg）渡すのもやってみたけど、
結果変わらなかった

**デフォルトの名無しさん** · 2021/02/23(火) 21:17:47.85

>>461
・errCh <- 他の関数() はバッファが一杯の場合ブロックする
・err := <-errCh はブロックする
goのchannelは初心者が使うと極めてデッドロックを引き起こしやすいので、まずはchannel使わずに正しく動作するものを作れるようになってから手を出すことを強くお勧めする

**デフォルトの名無しさん** · 2021/02/23(火) 21:36:09.19

>>462
ありがとうございます
全体としては物はもうできていて、上記の処理は大量にファイルを出力するため重く
速度改善としてgoroutineを入れようと試みてました。
まあファイルシステムのi/oがボトルネックだとそんなに変わらないかもしれませんが…

**デフォルトの名無しさん** · 2021/02/23(火) 22:03:06.71

エラー判定をgoroutineと同じ階層で判定することで返ってくるようになりました
一応オチとしてめも
速度改善はならず

**デフォルトの名無しさん** · 2021/02/23(火) 22:38:49.04

>>461
ぱっと見しただけで検討しないで書くけど
errCh の受付数はcpuの数
errChの読み込みが一回しかしてないからアイテム数が受付数を越えたら書き込みがブロックされてwgがDoneされない
DoneされないからWaitは抜けてこない
のでデッドロックということでは？

**デフォルトの名無しさん** · 2021/02/23(火) 22:41:20.70

>>465
ご指摘のとおりでした
なのでgoroutineと同じループの中でerrChを取るようにしたら動作しました

wg作る位置も動かないからだんだんスコープ狭めていったんですが
一番外のforの外で作って動きました

**デフォルトの名無しさん** · 2021/02/23(火) 23:35:24.39

それみんな絶対最初ハマるよな

**デフォルトの名無しさん** · 2021/02/26(金) 08:25:09.52

Goのグラフィックって、標準だとこんなに低レベル処理なパッケージしかないのか……
JavaScriptで言うならImageDataしかない感じ
誰かのライブラリ使わないと線を引くだけでも大変

**デフォルトの名無しさん** · 2021/02/26(金) 10:33:50.46

Golang でグラフィックやろうと思う時点で変

**デフォルトの名無しさん** · 2021/02/26(金) 12:53:20.65

イメージを生成するサービスを考えてたん