Go language part 3

**デフォルトの名無しさん** · 2019/10/17(木) 21:38:04.78

Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。

公式ドキュメント
http://golang.org/doc/

日本語訳
http://golang.jp

※前スレ
Go language part 2
https://mevius.5ch.net/test/read.cgi/tech/1510395926/

**デフォルトの名無しさん** · 2019/11/09(土) 14:40:29.85

Go 10周年

https://blog.golang.org/10years

**デフォルトの名無しさん** · 2019/11/09(土) 14:45:47.99

おめでとう
そして 10年で 3 スレ

**デフォルトの名無しさん** · 2019/11/10(日) 16:35:00.71

>>67
狙ったgoroutineにってのが推奨されてるかはわからんけど、レシーバなり関数のパラメータなりにid持たせて、終了通知channelにそのidを送って受け取った側で処理する、とか

**デフォルトの名無しさん** · 2019/11/12(火) 18:31:22.40

継承、関数オーバーライド、多態性を実装したサンプルをまとめてみた
https://play.golang.org/p/4_p8gXLRJ1j

今後のバージョンアップで機能しなくなったりとか、現状でもマズイ部分って、どれくらいだろうか？

**デフォルトの名無しさん** · 2019/11/12(火) 19:33:54.99

オーバーライドしたスーパークラスのメソッドを呼び出す例が無かったんでちょっと変更
https://play.golang.org/p/XUfFldlrkqT

**デフォルトの名無しさん** · 2019/11/13(水) 13:05:15.15

ローソンやめて・・・

**デフォルトの名無しさん** · 2019/11/14(木) 12:27:37.91

>>73
それは多態になってない
呼出元が直接Sub.Msgを呼んでるだろ

**デフォルトの名無しさん** · 2019/11/14(木) 12:45:55.94

>>76
Inheritance.Msg()じゃないの？

**デフォルトの名無しさん** · 2019/11/15(金) 01:20:51.87

>>76
うん、BaseもSubも同じインターフェースに代入してメソッド呼んでるから、ちゃんと多態になってると思う
それとも俺とかレス主が多態性を勘違いしてる？

**デフォルトの名無しさん** · 2019/11/19(火) 11:45:57.48

新しいサイトのurlゴーデブとか俺をバカにしてんのか？

**デフォルトの名無しさん** · 2019/11/19(火) 13:05:47.04

go.dev
pkg.go.dev

デヴ乙

**デフォルトの名無しさん** · 2019/11/19(火) 19:24:06.45

新しいサイト？
言語仕様ドキュメントが見つからないから、移行ではないよな？
何のためのサイト何だろうコレ

**デフォルトの名無しさん** · 2019/11/19(火) 19:41:52.54

ごーでぶキュレーションサイトなのかな
https://japan.zdnet.com/article/35145511/

**デフォルトの名無しさん** · 2019/11/19(火) 19:55:13.02

ああ、つまり経営者向けの広告サイトなんだな

**デフォルトの名無しさん** · 2019/11/19(火) 20:30:05.61

> https://blog.golang.org/go.dev
> Today we are launching go.dev, a new hub for Go developers, to help answer those questions.
開発者向けのハブサイトだと

**デフォルトの名無しさん** · 2019/11/20(水) 04:14:35.39

デブで経営者向けはないだろｗ
経営者ならスマート

**デフォルトの名無しさん** · 2019/11/20(水) 05:50:27.81

ドメインの管理者は…

**デフォルトの名無しさん** · 2019/11/20(水) 21:31:46.92

>>48
Go言語を採用して開発をしている会社一覧
https://web.archive.org/web/20191120013540/https://qiita.com/muchi/items/018c81c27f637797fcf3

**デフォルトの名無しさん** · 2019/11/21(木) 22:11:47.49

なぜかVScodeでmain.goだけ"fmt"とか全くimportできなくなってしまった
language serverのリスタートもWindowsの再起動も駄目
なんじゃこりゃ、まいったね

**デフォルトの名無しさん** · 2019/11/22(金) 22:15:46.73

>>88
コマンドラインからは叩けるの？
同じ現象なってたわ

**デフォルトの名無しさん** · 2019/11/23(土) 08:06:54.73

>>89
コマンドラインでgolintとか叩いても何も出ないね
今は出なくなってるけど、原因がわからない
ちなみに1.13.1

**デフォルトの名無しさん** · 2019/11/23(土) 12:27:33.32

>>90
俺もvscodeの再起動で治ったけど、module周りはちょいちょい不具合でるなあ。
importの警告がいきなりでてきたり

**デフォルトの名無しさん** · 2019/11/23(土) 14:07:25.44

>>91
また modules か
modules ってどうなるのかな？
godoc が動かない issue も目処が立っていないらしいし

**デフォルトの名無しさん** · 2019/11/23(土) 20:04:06.92

>>92
バグのあるバージョンがミラーに乗っかっちゃったらポイズニングするしかないのとかもなんとかしてほしい。
コンパチがゆえの弊害が出ている気はする。

**デフォルトの名無しさん** · 2019/11/23(土) 20:37:12.05

>>88
import "./internal/config"
とか相対パス参照を止めて完全パスでインポートしたらエラーが消えた
別マシンだと1.12だったからなのか動いてたんだけど、なんだこりや

**デフォルトの名無しさん** · 2019/11/23(土) 21:02:17.64

環境変数 GO111MODULE を off にセットしてみたら

**デフォルトの名無しさん** · 2019/11/23(土) 21:13:40.13

言語自体はそれなりに良いんだが開発状況見てるとと将来が不安。rubyに似てる。

**デフォルトの名無しさん** · 2019/11/23(土) 21:21:33.69

>>96
最初からコンセプトがシンプルだから、rubyとまではならないんじゃないかな。と、思いたい。
あとケツ持ちがでかい

**デフォルトの名無しさん** · 2019/11/23(土) 21:44:02.36

>>94
go.mod に

replace internal/config => ./internal/config

と書いておくと

import "internal/config"

と書ける。 ./internal/config ディレクトリ内にも go.mod を作っておく必要があるけど

**デフォルトの名無しさん** · 2019/11/23(土) 21:57:18.51

>>95
環境変数見てもgo env見ても
GO111MODULE=
と設定されていませんね
Goを始めたのが1.12だったから、そもそも必要なかったし

**デフォルトの名無しさん** · 2019/11/23(土) 22:02:32.31

>>95
ん、off？空指定とは違う挙動になるのかな？

**デフォルトの名無しさん** · 2019/11/23(土) 22:08:43.74

>>98
internal以下のパッケージの全てにgo.modを入れるのはちょっと…

**デフォルトの名無しさん** · 2019/11/23(土) 22:12:34.14

>>100
1.13 からデフォルトは on

**デフォルトの名無しさん** · 2019/11/23(土) 22:13:50.79

シンプルなのはいいんだけど
golintでチェックされる命名規則が嫌すぎる
キャメルでgetJsonDataとかだったか関数定義したら"JSON"と大文字で書けとか怒られた
お前は姑か！

**デフォルトの名無しさん** · 2019/11/23(土) 22:19:49.28

>>102
むしろoffじゃ駄目じゃん、modules 使ってる環境だから
go.exe env GO111MDULE=on
してみた

**デフォルトの名無しさん** · 2019/11/23(土) 22:22:02.56

>>102
あ、書き忘れ
1.13からのデフォルト変更は無しになってautoのままらしい

**デフォルトの名無しさん** · 2019/11/23(土) 22:24:43.43

off にして modules 捨てたらいいんじゃないかな

**デフォルトの名無しさん** · 2019/11/23(土) 22:29:30.47

後は import "hoge-project/internal/config" って書くとか
これなら go.mod を作ったり弄くらなくて済む

**デフォルトの名無しさん** · 2019/11/23(土) 22:40:38.71

>>107
まさにそれ
完全パスで書いたら通る

**デフォルトの名無しさん** · 2019/11/25(月) 21:36:43.85

初心者なんだがcontextの使い道がいまいちわからん。
cancelとかなんかいいサンプルないかな。

**デフォルトの名無しさん** · 2019/11/25(月) 22:24:43.09

>>109
パッケージドキュメントのExampleが、自分としては分かりやすかった
WithCancelしか使ってないけど

あと、go vet がバグっていて親contextのCancel関数があるのに
子供のCancel関数を_で捨てると怒られる
https://github.com/golang/go/issues/29587
暫定的な解決法は一旦変数に取ってから_に代入

**デフォルトの名無しさん** · 2019/11/25(月) 22:34:45.60

>>109
使い方じゃなくて使い道かー
んー、goroutineをポコポコ作る場面で、処理をキャンセルしたい事ってあるけど、作り散らしたgoroutineに通知しないとキャンセルできない
そんなとき自前で仕掛けを作らなくてもcontextを使えばいい
あとは、そういった処理にタイムアウトを実装したい時にも、タイマーが組み込まれてるcontextがある

Valueは使ったこと無い

**デフォルトの名無しさん** · 2019/11/25(月) 22:57:11.50

ありがちなのはsigintしたときにすぐにプログラムを止めずに子のゴルーチンの処理が一区切りついてから止める場合とかかな🤔

**デフォルトの名無しさん** · 2019/11/26(火) 02:26:32.95

改訂2版みんなのGo言語、2019/8/1

買ってきた。
これは、文法以外の開発に関する本

**デフォルトの名無しさん** · 2019/11/26(火) 07:37:44.38

>>112
んだね、自分はちゃんと後始末していることを保証するためにWaitGroupと組み合わせてる

**デフォルトの名無しさん** · 2019/11/26(火) 15:25:52.87

>>111
回答ありがとう
そういうケースって、親がcancelしたら、goroutineはDoneを受信したら終了、って認識なんだけど、それって終了するためにfor、select前提、になるのかな

**デフォルトの名無しさん** · 2019/11/26(火) 15:27:45.16

>>112
それも考えてはみたんだけど、waitgroupか、キャパ付きのerrorChannelで事足りてしまうような。
context難しい。。

**デフォルトの名無しさん** · 2019/11/26(火) 15:32:27.05

>>110
パッケージドキュメントだと、やはり基本的にループ待受なのね

なんかイメージ的に、その文脈から派生した処理を上手いことその派生分だけ切り上げる、みたいな感じだったけど、contextWithCancel使う＝ループ処理がある、なのかな

**デフォルトの名無しさん** · 2019/11/26(火) 18:34:43.56

>>115
そうなる
各goroutineではチャネルを読まないといけない
んでもコード的に汚いから、裏技がないかと>67で質問したけど無いみたい
interrupt panic とか起こせたらなぁ

**デフォルトの名無しさん** · 2019/11/26(火) 20:40:53.47

>>118
なるほど。参考になる。
channel読むの前提ってことは、やっぱり汚くなるよね。
selectで終了待受したいなら、中でさらにgoroutine生成してselectまで進めておく、しかないと
なんかこう、WithCancelで生成したcontext渡してcancelしたらなにも考えることなく終わってほしいなー。

**デフォルトの名無しさん** · 2019/11/26(火) 21:33:38.25

>>114
便乗して更に質問で申し訳ないが聞きたい。waitgroupって、個人的にはworkerの数が決まってるなら使うべき？
wg使わずにキャパシティ付きchannelに放り込む、クロージャでdefer closeしてその後channelをrangeで回す。というのもソースコードではよく見る。

ここら辺なにが正解なのかわからんのよね

**デフォルトの名無しさん** · 2019/11/26(火) 22:53:16.65

>>120
workerの数が決まらないほど、使うべきなんじゃない？
要するに全部のgoroutineが終わったかどうか判断する仕組みだから
ちなみに自分はgoroutineを二段構えで呼んでて、WaitGroupは隠してる
https://github.com/XORveRCOM/util/blob/master/pkg/easywork/easywork.go

**デフォルトの名無しさん** · 2019/11/26(火) 22:57:07.00

workerの数決まっていないでチャンネル使うとキャパシティ以上にワーカーできたとき詰まって死にそう🤔

**デフォルトの名無しさん** · 2019/11/26(火) 23:23:09.81

>>121
回答とサンプルありがとう。
質問の日本語がおかしかった。。
なるほど、こうすればchannelで送受信しなくても逐次的に処理できるということか。

ちなみにworkerの数が決まらないケースって、どんな場面で遭遇する？

常駐してて死なないアプリ以外にあんまり思いつかず

**デフォルトの名無しさん** · 2019/11/26(火) 23:23:41.57

>>122
WaitGroupのソースを参照

**デフォルトの名無しさん** · 2019/11/26(火) 23:29:52.93

>>122
受信側は無限に待ち受ける想定だとどうかな？というか、waitgroupを使わないユースケースがそれぐらいしか思いつかないんだよね

waitgroupが有効なケース、だけどwaitgroupを使わないケースってどんなんがあるのかな。

**デフォルトの名無しさん** · 2019/11/26(火) 23:36:45.35

>>123
常駐じゃなくても並列処理で足並み揃える時とかに使うかな
例えば並列で別のダウンロードさせたり

**デフォルトの名無しさん** · 2019/11/26(火) 23:46:52.62

>>126
そうか、パッと見ダウンロード処理を開始する時にwg.Add(len())すれば、とおもったけど、よく考えたら何をダウンロードするのかを取得する処理自体が並列化してる場合は、ソースみたいに自分でAdd(1)しないと並列化できないね。
とても勉強になった。ありがとう。

**デフォルトの名無しさん** · 2019/11/26(火) 23:59:49.88

>>124
WaitGroupのソース見る限りAddされた数と待っている数を保持していてチャンネルを使っていないっぽいけど…
チャンネルを使うと詰まることあるけどWaitGroupならないんじゃないかな
https://golang.org/src/sync/waitgroup.go?s=574:929

**113** · 2019/12/02(月) 22:40:03.04

>>113
改訂2版みんなのGo言語、2019/8/1

半分ぐらい読んだけど、これは、文法以外の開発に関する本で、

テスト・デザインパターンなど、
各言語の中級者向け「Effective 何々」に相当する本

**デフォルトの名無しさん** · 2019/12/03(火) 08:47:37.15

effective goは無料で読めるけど全然似てない。適当こくでねぇ。

**デフォルトの名無しさん** · 2019/12/05(木) 11:52:28.33

シマンテックのSEPがgolintを誤検知してさくっと削除

**デフォルトの名無しさん** · 2019/12/06(金) 09:12:39.72

誤検知じゃないかも

**デフォルトの名無しさん** · 2019/12/08(日) 01:05:14.90

ジェネリクスとnnbdは入ったの？

**デフォルトの名無しさん** · 2019/12/12(木) 01:16:12.28

>>133
入ってない。
ジェネリクス欲しいよね

**デフォルトの名無しさん** · 2019/12/14(土) 02:29:56.08

ジェネリックよりインターフェースのメソッド名をリファクタリングする機能が欲しい
それとファイル内に閉じたスコープの新設

**デフォルトの名無しさん** · 2019/12/14(土) 12:20:22.72

サクッとwebサーバー建てる時お前らエコー使うだろ？
後輩がジン一択言って譲らんのよ

**デフォルトの名無しさん** · 2019/12/14(土) 12:25:23.49

ごめんnet/http一択

**デフォルトの名無しさん** · 2019/12/14(土) 18:57:44.23

サクッと立てたい時にフレームワークは使わない

**デフォルトの名無しさん** · 2019/12/14(土) 21:25:16.45

さくっと欲しいときは
https://play.golang.org/p/LtYjxcomguJ
を使ってる

**デフォルトの名無しさん** · 2019/12/14(土) 21:32:58.33

>>139
お、ｲｲﾈ!

**デフォルトの名無しさん** · 2019/12/16(月) 01:49:06.93

go初心者です。
田中、佐藤、加藤からランダム(重複なし)で3つ抽出するにはどうすればいいでしょうか？

**デフォルトの名無しさん** · 2019/12/16(月) 01:56:43.58

取り出す数が配列の大きさと同じならシャッフルすれば良さそう
https://golang.org/pkg/math/rand/#Shuffle

**デフォルトの名無しさん** · 2019/12/16(月) 02:11:32.44

>>142
なるほど。
ただ実際は配列の大きさは100個くらいあって取り出す配列は5つなんですよね...

**デフォルトの名無しさん** · 2019/12/16(月) 02:29:03.91

>>143
重複なしならシャッフルして前から5個取れば良さそう

**デフォルトの名無しさん** · 2019/12/16(月) 02:37:03.68

>>144
すみません、前から5個取るにはどうすればいいのでしょうか？

**デフォルトの名無しさん** · 2019/12/16(月) 02:44:37.15

https://play.golang.org/p/RWZYkJYabd2

Playground だと時間が止まってるから常に同じ結果しか表示しないけどね…

**デフォルトの名無しさん** · 2019/12/16(月) 02:50:18.86

>>146
おー！これでいけそうです。
ありがとうございます。

**デフォルトの名無しさん** · 2019/12/16(月) 18:22:41.60

おんぶに抱っこやんけ

**デフォルトの名無しさん** · 2019/12/16(月) 20:24:54.73

interfaceをに包まれた2つ以上の変数が持つ型が一致してるか判定できる構文てある？

こういうのはできないみたいだし…

var x interface{} = int(12)
var y interface{} = int(25)
if (a, ok1), (b, ok2) := x.(int), y.(int); ok1 && ok2 {
fmt.Println(a, b)
}

**デフォルトの名無しさん** · 2019/12/16(月) 20:25:53.67

リフレクション使えば判別出来るのは知ってる

**デフォルトの名無しさん** · 2019/12/16(月) 20:35:08.46

まぁ、こんなんかなぁ…

if a, ok1 := x.(int); ok1 {
if b, ok2 := y.(int); ok2 {
fmt.Println(a, b)
}
}

**デフォルトの名無しさん** · 2019/12/16(月) 20:41:01.13

reflection ならこうかな

import "reflect"

if reflect.ValueOf(x).Type() == reflect.ValueOf(y).Type() {
　fmt.Println(x, y)
}

**デフォルトの名無しさん** · 2019/12/16(月) 23:14:32.24

型アサーション使っていいなら、型スイッチという手段も

**デフォルトの名無しさん** · 2019/12/18(水) 18:41:56.85

golang関係ないんだが、50000番台ポートをlistenで開きまくるアプリ書いてるんだが、テスト実行毎にデバッグexeのパスが変わってWindowsDefenderがブロックしましたダイアログ出してきてウザいよぅ
うちはSEPなんでお呼びじゃないし、更にブロックされてると主張してるがテストコードはガンガン通ってるからブロックしてねーし

ともかく、デバッグexeの一時フォルダを固定する設定ってある？そうすりゃ例外設定書ける

**デフォルトの名無しさん** · 2019/12/19(木) 17:58:01.30

go testの内部処理を追ってどうぞ

https://go.googlesource.com/go/+/refs/heads/master/src/cmd/go/go_test.go

**デフォルトの名無しさん** · 2019/12/19(木) 18:04:48.44

>>155
リンクミス
こっち
https://go.googlesource.com/go/+/refs/heads/master/src/cmd/go/internal/test/

**デフォルトの名無しさん** · 2019/12/21(土) 20:16:12.25

ep8 ー ep7で雑に投げられた謎を雑に処理、端から解決する気無し。既存キャラの大幅劣化に加え、ローズ、紫バァ、暗号破りの新キャラ3人がヘイトの対象に（主にローズ）

ep9 ー ep8の出来事はほぼ無かったことに…。大味極まりないが逆にそれが功を奏し、SWファンからの評価は概ね高い。興収でエンドゲームを超えられるか注目

**デフォルトの名無しさん** · 2019/12/21(土) 20:17:39.18

ごめん、完全誤爆

**デフォルトの名無しさん** · 2019/12/26(木) 23:28:38.63

名前付き引数ってこんな感じでいいの？

https://play.golang.org/p/dckMhAXN5Ve

**デフォルトの名無しさん** · 2019/12/26(木) 23:57:38.99

>>159
知らんのでググって、最初にヒットした奴の方が良いな

具体的にはオプションはそれぞれ対象の構造体ポインタを受けとるシグネチャを持つ関数
そのメソッドのスライスを順に呼ぶと、関数が特定フィールドに値をセットするという作り
まず、その方式だと型switchがいらない
オプションを増やしたければセット用の関数を増やす

他の利点として、設定する関数では他のフィールドも参照できるから、矛盾のある設定を防ぐとか柔軟な設定もできそう

ぱっと見、visitパターンっぽいアイデアに見えた
(個人的な初見の感想なんで深く考えて言ってる訳じゃない
なんだっけ、二重呼び出し？

**デフォルトの名無しさん** · 2019/12/26(木) 23:58:56.08

まぁ、interface{} で良いんじゃないかな

https://play.golang.org/p/MekSknA7SOd

**デフォルトの名無しさん** · 2019/12/27(金) 00:43:24.50

>>160
https://play.golang.org/p/IPFXvijbxKY

**デフォルトの名無しさん** · 2019/12/27(金) 18:28:35.28

ひさしぶりにGO触ったら仕様変更の真っ最中なのね...
暫く冬眠しとくわ　　　　　　　　　　　　　　　　　　　　　　　　　

**デフォルトの名無しさん** · 2019/12/27(金) 18:35:37.18

いつでも仕様変更
ジェネリックス欲しがってる層って、何のクラスタの人なんだろ

**デフォルトの名無しさん** · 2019/12/27(金) 20:14:12.67

Java

**デフォルトの名無しさん** · 2019/12/27(金) 20:24:26.71

Java 原人、生きていたのか

**デフォルトの名無しさん** · 2019/12/28(土) 00:46:09.91

ていうか Java のジェネリクスもおもくそ後付けやん

**デフォルトの名無しさん** · 2019/12/28(土) 13:38:22.34

golangのゆるふわなinterface機構の上でジェネリックスの出番なんてそうそうあるものなのかな？

**デフォルトの名無しさん** · 2019/12/28(土) 13:43:53.42

ちょっと凝ったことをしようとすると interface{} まみれになるところが改善できれば。