Go language part 5

**デフォルトの名無しさん** · 2022/02/27(日) 07:43:20.04

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

公式
https://golang.org

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

公式外パッケージドキュメント
https://godoc.org

ブラウザ上で試し書き
https://play.golang.org

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

**デフォルトの名無しさん** · 2022/06/15(水) 23:39:49.40

>>405
それは君の理解が間違っている

> Rustの無限長イテレーターはRangeやstd::iter::repeatにおいて無限長を扱えるだけであり、

その部分が完全にウソ
Rustのイテレータは誰もが自由に任意の無限長イテレータを作成可能
そしてその無限長イテレータに対して任意の別のイテレータを好きなだけチェーンさせて動作可能

これはRustのイテレータが中間生成物(リストや配列やベクタ)を作成しないため可能となっている
Goで整備するときもここが重要なポイントとなってくる

**デフォルトの名無しさん** · 2022/06/16(木) 00:21:02.73

無限リストって実際に無限長の何かを使うことは滅多になくて、あくまで遅延リストとして適切に実装されているかどうかの判定基準なんだよね
無限長リストを扱える構造になっていることは、メモリに乗らない巨大なファイルを一行ずつ読むような、文字通りストリーミング処理が必要な状況で非常に有用なんだよ

**デフォルトの名無しさん** · 2022/06/16(木) 01:51:06.21

結局2種類のうちどちらを選ぶか、だけの問題
(A) 遅延処理
　・メソッドチェーン時の中間生成配列などを無くせる
　・無限長も扱える
　・無駄がなく有利
(B) 即時処理
　・メソッドチェーン時の中間生成配列などが必ず必要となる
　・無限長を扱えない
　・(A)よりも不利

RubyのlazyやRustのイテレータはもちろん(A)タイプ
Goでも欲しいのは(A)
(B)タイプのものは検討する必要がない

**デフォルトの名無しさん** · 2022/06/16(木) 02:11:04.77

Go 2のProposalを見ると

https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md
> We do not expect approaches like the C++ STL iterator types to become widely used. In Go that sort of idea is more naturally expressed using an interface type. In C++ terms, using an interface type for an iterator can be seen as carrying an abstraction penalty, in that run-time efficiency will be less than C++ approaches that in effect inline all code; we believe that Go programmers will continue to find that sort of penalty to be acceptable.

って書いてあるけどまあGoはそういう言語で、そこまで最適化にこだわる言語じゃない
最適化にこだわるひとはRustとかC++とか使うべき

**デフォルトの名無しさん** · 2022/06/16(木) 08:44:05.77

>>415
これは遅延リストを否定しているのではない
C++のようなゼロオーバーヘッドは目指さないよ、もしイテレータを抽象化するなら実行時のオーバーヘッドを受け入れて普通にInterface使う想定だよと言っていて、
将来的に>>414の(A)のスタイルのイテレータを導入する可能性は下記の通り肯定している
> As we get more container types, we may develop a standard Iterator interface. That may in turn lead to pressure to modify the language to add some mechanism for using an Iterator with the range clause. That is very speculative, though.

**デフォルトの名無しさん** · 2022/06/16(木) 10:46:03.49

>>411
JavaとPHpだけじゃ不安なんだ

**デフォルトの名無しさん** · 2022/06/16(木) 11:54:55.58

>>417
PHPてw

**デフォルトの名無しさん** · 2022/06/16(木) 17:42:32.41

>>416
つまり将来Go3になる頃には>>414の(A)がGoでも出来るようになる可能性が残されていると

**デフォルトの名無しさん** · 2022/06/16(木) 19:30:57.98

>>417
なんだ、プログラミングは経験者か。
ならGo未経験案件でも収入大幅に減らないならスキル増やすつもりで行っていいかと思うけど。

>>418
案件多いのはPHPなんだぜ涙

**デフォルトの名無しさん** · 2022/06/16(木) 21:18:25.47

>>419
単なるデザインパターンだから今のGoでもできる
イテレータのinterfaceが標準化されてないだけ

**デフォルトの名無しさん** · 2022/06/17(金) 03:52:06.95

>>421
本当に出来るならばなぜGoではやらないの？
速いし便利だしコードも分かりやすくなることが多いため色んな言語で使われているのに

**デフォルトの名無しさん** · 2022/06/17(金) 11:18:37.95

>>422
標準無視のコードで俺スゲーしたい系の人はRustに行っちゃうからだろうね

**デフォルトの名無しさん** · 2022/06/17(金) 11:32:30.80

イテレータを使うようにしたら、こんなふうになるのかな？
https://github.com/Soft/iter
いちいち関数呼び出しすることになるから普段使いにしようとするとパフォーマンス悪くなりそう

**デフォルトの名無しさん** · 2022/06/17(金) 11:45:45.87

もっと最適化されるようになったら良いけどね

**デフォルトの名無しさん** · 2022/06/17(金) 12:50:08.27

RustのイテレータがCのfor文と同じ速度が出るのも最適化された設計と実装によるものだもんね
あとはGo開発陣のやる気次第

**デフォルトの名無しさん** · 2022/06/17(金) 12:53:28.19

>>424
これはダメだね
パフォーマンス以前に、イテレータを閉じる方法がないからファイルをストリーミング処理するようなユースケースに対応できない
ちゃんと言語機能の背景を考慮せずにRustを猿真似しちゃった失敗作だね

**デフォルトの名無しさん** · 2022/06/17(金) 13:28:49.58

何をどう見ても許されてないしロシアが核持ってなかったら、
集団的自衛権をもとに連合軍が作られてプーチン政権が倒されるか、ロシアも同盟を集めて世界大戦に発展してるよ

**デフォルトの名無しさん** · 2022/06/17(金) 13:29:03.78

なんかスレ間違えたわ

**デフォルトの名無しさん** · 2022/06/17(金) 15:44:02.84

いやだいじょうぶだ、つづけろ

**デフォルトの名無しさん** · 2022/06/17(金) 19:22:44.65

>>409
その通り。Goで中間コンテナを作らないようなGeneric版高階関数ライブラリを作ろうと思うと、yieldのような中断じゃなく確かにチャネルの受け渡しになる。
それでfilter->map->collectのようなRust的な中間コンテナを作らないようなコードを書くことになると、中間の加工データの受け渡しはチャネルになるので、Rustで
そのままでは安易に並列化できずにrayonライブラリなどを使うより、遥かに簡単にスケールできる並列化まで踏み込む可能性がある。
これをGoogleはパイプライン処理と呼んでいるが、421の言うように1.18はイテレータの標準化とコレクションの操作の一般化を変更に含めなかっただけ
やる気というか現代のソフトウェア開発は、世に出たら0から255まで揃ってる訳ではなく、小まめな段階リリースだから

**デフォルトの名無しさん** · 2022/06/18(土) 15:13:54.54

おじさんがくるとこうなるのね
本当にこの世から消えて欲しい

**デフォルトの名無しさん** · 2022/06/22(水) 23:33:10.33

この世から消えて欲しいチュウニおじさん

**デフォルトの名無しさん** · 2022/06/26(日) 19:36:20.90

モックって何使ってる？
gomock, testfy, mockery
オススメは？

**デフォルトの名無しさん** · 2022/06/26(日) 19:37:58.18

いらない
インターフェース埋め込みで十分

**デフォルトの名無しさん** · 2022/06/26(日) 21:04:51.85

>>435に一票
Goでモックフレームワークが欲しくなるようなら設計と開発スタイルがおかしい

**デフォルトの名無しさん** · 2022/06/26(日) 21:48:32.78

カバレッジ100%目指さないの？
共通ライブラリのエラーのパスとか

**デフォルトの名無しさん** · 2022/06/26(日) 23:06:38.35

別におすすめじゃないけどgomock使ってる
gomockはinterface{}だらけで静的型チェックが効かないからたまにイラッとする

**デフォルトの名無しさん** · 2022/06/26(日) 23:08:45.74

間違えた
gomockじゃなくてtestifyだ

**デフォルトの名無しさん** · 2022/06/27(月) 08:35:06.00

がーん、週明けで確認したらGCPでホストしているサービス二個ともが、のきなみサーバーエラー500で動いてない
Memorystore の障害なのか？これは

**デフォルトの名無しさん** · 2022/06/27(月) 08:37:17.96

Firestoreのクエリ結果をキャッシュしてるから確かに使ってる

**デフォルトの名無しさん** · 2022/06/27(月) 08:40:10.32

あ、よく考えたらGoスレではスレ違いな話題だったスマン
ホストしてるのはGoだけど

**デフォルトの名無しさん** · 2022/07/02(土) 23:20:51.48

質問
xxxx_test.go は go test だけで、go build からは無視されるとかって本当？
だとすると package xxxx_test とかパッケージを分けるのって意味がない？

**デフォルトの名無しさん** · 2022/07/02(土) 23:36:14.32

あー、テストで xxxx をインポートしてる別パッケージをインポートしたいときに、xxxx からじゃ循環参照としてコンパイルできないから意味はあるのか

**デフォルトの名無しさん** · 2022/07/02(土) 23:50:10.91

ごくまれに package xxxx_test を作ったほうが簡単に解決できることもあるね

**デフォルトの名無しさん** · 2022/07/03(日) 08:48:25.27

*bufio.Scanner とか *os.File といった、interface じゃなく struct な戻り値を返す標準関数で、scanner.Scan() とかの戻り値による分岐をカバレッジしたい

標準関数は関数ポインタによるフックに変更して、モックで差し替えられるようにしたんだけど、関数ポインタのシグネチャが struct を返す形なんで、上記の scanner.Scan() とかを差し替えられない

そこで bufio.NewScanner() を直接に使うのではなく、scanner を interface で返すラッパー関数を作って、そのラッパー関数ポインタをモックで置き換えさせることを考えたりしてるんだけど
…やり過ぎ？(そもそもこの説明で分かるかな？)

**デフォルトの名無しさん** · 2022/07/03(日) 08:55:03.83

そもそも例外なケースのカバレッジのために、そんなクソ複雑なメカニズムを入れるのは、保守性を下げてしまうから本末転倒だろうか？

**デフォルトの名無しさん** · 2022/07/03(日) 11:51:42.83

Go的には、差し替えが必要なんだったらScannerを直接使わずに最小限のアドホックなinterfaceを定義し、
それを関数の引数に受け取るかstructのメンバに持たせるのが筋

**デフォルトの名無しさん** · 2022/07/03(日) 13:48:43.92

>>448
うん、そんな感じ
https://pastebin.pl/view/d979ea5b
該当部分を抜粋
しかし無駄に複雑なコードかなぁと
そこまでする意義はあるのかないのか

**デフォルトの名無しさん** · 2022/07/03(日) 13:59:46.67

>>449
これだけ複雑なのに、os.Open() と s.Err() がエラーを返すパスを通せるだけというのは、
コードの保守性悪化に見合うメリットたりえるのか
そう感じてしまって悩んでる
これが Java ならクラスローダーでプロキシインスタンスに差し替えるという手段で対象コードには手を触れなくて済むから…

**デフォルトの名無しさん** · 2022/07/03(日) 15:10:23.33

>>450
そのへんはGo云々というより設計センスの問題だな
textLinesがhookを持つのではなく、LoadFromの引数にfilenameの代わりにiScannerを渡して、その実装を提供するのは呼び出す側の責任にした方が良いと思う
filenameを受け取る便利関数を提供したいなら、それとは別にLoadFromFileNameみたいな関数作ってFileやScannerをインスタンス化してLoadFromに投げればいい
そうすればインスタンス化の部分とそれを使う部分とでテストケースを分離できるでしょ

**デフォルトの名無しさん** · 2022/07/03(日) 23:23:15.49

そうだな、設計の話だなあ
コードがそこそこの規模になるんだったらとりあえずDI的なことをやったほうがいいよ

**デフォルトの名無しさん** · 2022/07/10(日) 17:20:12.05

普通に自前でScanner作れよ
大して難しい話じゃないだろ

**デフォルトの名無しさん** · 2022/07/11(月) 19:28:21.15

構造体のコンストラクタのコードを見ると必ず構造体のポインタを返していますが、ポインタにするメリットと値を返したときのデメリットを教えて頂きたいです

**デフォルトの名無しさん** · 2022/07/11(月) 20:06:52.63

>>454
受け渡しの際に毎回コピーするのではなく同一のインスタンスを引き回すことを想定している場合、
それを利用者に主張するために値ではなくポインタを返すことが多い
ポインタで受け取ったものをわざわざデリファレンスしてコピーなんて普通あまりしないからね
構造体をオブジェクト指向言語におけるミュータブルなクラスのように使っていると、コピーされると意図せぬ挙動になりやすい

**デフォルトの名無しさん** · 2022/07/12(火) 09:01:35.03

>>453
>>449 見れば分かるがファイル名を受け取ってos.Openして得たFileからScannerを作ってるわけで、これをどうやって差し替えるかという話

**デフォルトの名無しさん** · 2022/07/12(火) 09:02:55.76

>>453
だから、ScannerではなくNewScanner関数をどう差し替えるかという話

**デフォルトの名無しさん** · 2022/07/12(火) 09:14:17.91

>>455
よく分かりました
ありがとうございます

**デフォルトの名無しさん** · 2022/07/15(金) 23:35:22.96

コンパイルするファイル内に設定値も全部入れたいんだけど、
その場合は設定値だけのファイルを読み込むことって可能ですか？
関数にしてmapで返す感じしかないですか？

**デフォルトの名無しさん** · 2022/07/16(土) 13:38:45.14

jsonファイルをgo-assetsとかgo:embedで組み込んで、それをjson.Unmarshal()で構造化データとして使えばいいと思うよ

**デフォルトの名無しさん** · 2022/07/16(土) 14:06:11.73

個人的には設定はビルド時に埋め込むならソース内にjson風にハードコードする派
設定ファイル嫌い

**デフォルトの名無しさん** · 2022/07/17(日) 05:50:18.02

てめーの好き嫌いなんか知ったことじゃない

**デフォルトの名無しさん** · 2022/07/17(日) 08:32:38.03

組み込みjsonをデフォルトとして、カスタム設定ファイルは外部のjsonにする
デフォルトから取り込んでカスタムで上書き
これでjsonからの取り込み部分を一本化できるのでバグを防止できる
ハードコードしてると取り込み部分が共有できない (json文字列を返す関数でもいいんだけど

**デフォルトの名無しさん** · 2022/07/17(日) 09:17:16.84

>>463
組み込み設定は構造体をハードコードし、カスタム設定ファイルはそれをjson等で上書きすればいいだけ
どうせ上書きされるのは極一部の項目だけなんだから、大部分はコンパイル時のチェックによりバグを防止できる

**デフォルトの名無しさん** · 2022/07/17(日) 19:27:05.51

>>464
と、思っちゃうよな
構造体定義して、初期化で初期値書き込んで、それとは別にカスタム設定取り込みコードを書く
対して、構造体定義して、設定取り込みコードを書く
すると設定取り込みには普通にバリデートも書くから初期化での値バグが起きない

**デフォルトの名無しさん** · 2022/07/17(日) 19:36:44.11

>>464
まあ、好きずきの話に近いことは近い
ハードコードした設定値をバリデーターにかけてチェックさせる作りなら解決できなくもない
でも取り込みの各段階でバリデーションしていったほうがミスりにくいと俺は思うから

**デフォルトの名無しさん** · 2022/07/17(日) 19:43:13.12

そんなにバグが怖いならそもそもそんな柔軟な設定ファイル要る？というところを見直すべきでは
汎用的なOSSでも作ってるんでない限り、設定なんぞ環境変数で十分
あとは全部ハードコードすればバリデーションなんか要らん

**デフォルトの名無しさん** · 2022/07/18(月) 09:02:04.30

バグが怖いというより、適切なアナウンスかな
設定のどこが、どう不味いのか

**デフォルトの名無しさん** · 2022/07/18(月) 16:09:24.37

Viperを使え

**デフォルトの名無しさん** · 2022/07/21(木) 22:26:13.75

フレームワークのginでWebアプリ作りたいなと思ってるんですけど、ginの勉強にいい教材ありますか？
Pythonでツール作ったことあるくらいで、Goの基礎は一通りやったくらいのスキルです。

日本語ドキュメント見てもいまいちピンときてません
https://gin-gonic.com/ja/

**デフォルトの名無しさん** · 2022/07/21(木) 22:30:02.68

gin自体が良くないからいい教材なんか無い
Goはnet/httpパッケージを使うんだよ

**デフォルトの名無しさん** · 2022/07/21(木) 23:21:18.30

そうだったのか。。

**デフォルトの名無しさん** · 2022/07/22(金) 02:56:37.89

いやGinでいいだろ
今どきnet/httpだけでWebアプリ作ってるとこなんてねーよ
Gin+Vueとかで作ってみな
5chにいる玄人()のおっさんに惑わされんな

**デフォルトの名無しさん** · 2022/07/22(金) 03:45:47.87

俺はchiがおすすめ

**デフォルトの名無しさん** · 2022/07/22(金) 12:01:47.88

最近いじってないけど
Echoは少数派なの？

**デフォルトの名無しさん** · 2022/07/22(金) 13:57:48.11

>>473
さんきゅー！

**デフォルトの名無しさん** · 2022/07/22(金) 14:20:09.64

gin、chi、echoどれも薄っぺらいんだから対して変わらない
どれでもええわ

**デフォルトの名無しさん** · 2022/07/23(土) 09:09:18.33

echo はcontext の扱いが良くない

**デフォルトの名無しさん** · 2022/07/29(金) 12:06:04.77

Fiberこそ至高

**デフォルトの名無しさん** · 2022/07/29(金) 12:08:16.31

月額報酬が最も高い開発言語ランキング 3位は「Python」、2位は「Go」、1位は？フリーエンジニア向け仕事仲介サービス調べ

**デフォルトの名無しさん** · 2022/07/30(土) 02:29:49.54

URLを貼らないあたり仕事できなさそう

**デフォルトの名無しさん** · 2022/07/30(土) 05:26:38.23

Goは単価高いけどGoだけ出来ればいいってわけじゃないからなぁ

ECSとかTerraformみたいなクラウド技術も使えて当然だよね？って雰囲気が全体的にある

**デフォルトの名無しさん** · 2022/07/30(土) 17:20:05.92

Goのmapをfor分で回すと順序が不定というのはなんでそうなったの？

**デフォルトの名無しさん** · 2022/07/30(土) 17:42:37.40

>>483
将来的な最適化の余地を確保するため。
大抵の言語では、標準のハッシュ表はその内容が変更されない限りは順序が変わらないような実装がなされていることが多い。
しかし、プログラマにそれを期待したコードを書かれてしまうと、内容が変わらなくても順序が変わりうるような実装に将来的に変更したときに既存のコードが破壊される可能性がある。
Goはそれを避けるために順番を意図的にシャッフルしている。
例えば、将来的にはGCがmapのメモリレイアウトを自動的に最適化するかもしれない。仮にそうなればプログラマが内容を変更したつもりがなくても順番が変わるだろう。

**デフォルトの名無しさん** · 2022/07/30(土) 18:14:58.42

>>484
なるほど
意図的にやってるのか・・・

**デフォルトの名無しさん** · 2022/07/30(土) 23:59:57.16

Rubyとかは逆に不定じゃなくしたよね。いつだったかのタイミングで。

あれは変な判断だと思ったなぁ。

**デフォルトの名無しさん** · 2022/07/31(日) 00:35:32.67

Rubyの連想配列(Hash)にはshiftっていう変テコなメソッドがあるせいかなあ

**デフォルトの名無しさん** · 2022/07/31(日) 00:47:08.11

RubyやPythonの用途なら挿入順でイテレートできるようにするためにかかるコストよりも
利便性が優先されるからじゃないかな

**デフォルトの名無しさん** · 2022/07/31(日) 02:02:03.13

ですな。

**デフォルトの名無しさん** · 2022/08/03(水) 10:05:50.52

Go 1.19 is released!
https://go.dev/blog/go1.19

もう出た
今verは早かったな

**デフォルトの名無しさん** · 2022/08/03(水) 12:30:49.23

Pythonはordered dictがいつの間にか標準dictになってたな
便利だからいいけど

**デフォルトの名無しさん** · 2022/08/09(火) 14:19:29.00

最近の言語仕様書はDeepLすら受け付けない英文なのはどうにかしてくれんかな
ほかにもインターフェース関係の解説でいつの間にか話に出てきてないFileインターフェースが混じってきたり
絶対にレビューしてないよな

なお1.17を読んでる(1.18 からはジェネリクスで更に混迷が進んでる)

**デフォルトの名無しさん** · 2022/08/18(木) 10:59:30.64

ふと

channel はチャンネルと読んでる？チャネルと読んでる？

**デフォルトの名無しさん** · 2022/08/18(木) 12:00:31.81

チャネル

**デフォルトの名無しさん** · 2022/08/18(木) 12:23:20.11

正確な発音はチャノォ

**デフォルトの名無しさん** · 2022/08/18(木) 13:07:53.85

んゅにぇぅな？

**デフォルトの名無しさん** · 2022/08/18(木) 14:36:09.80

茶野ぉ？

**デフォルトの名無しさん** · 2022/08/18(木) 16:47:44.68

チャノルなぞ使わん！
男は黙って共有＆mutex

**デフォルトの名無しさん** · 2022/08/20(土) 04:18:43.73

>>473
ginのルーティングが糞なのは直ってるの？

**デフォルトの名無しさん** · 2022/08/20(土) 08:17:30.29

実際goをつかいはじめのころはチャンネルの仕様とか使いかたとか調べるのが面倒で
勝手しったるmutexばっかりつかっていた

**デフォルトの名無しさん** · 2022/08/20(土) 08:27:18.78

よーわからんし、echoで問題ないから使ってる

**デフォルトの名無しさん** · 2022/08/20(土) 11:47:33.07

俺もecho

**デフォルトの名無しさん** · 2022/08/20(土) 23:47:54.29

gin → beego → echo → chi イマココ

**デフォルトの名無しさん** · 2022/08/30(火) 15:48:26.25

言語仕様書の1.17を底本として翻訳してるんだけど、文書的に酷い(～;～の使いすぎが特に…)し、構成的にもクソだなぁ
underlying type に関係した性質なんて文書全体を読まんと把握できないわ

メソッド式の話では、ポインタによるレシーバーのメソッドは値による呼び出しは出来ないとか書いてあるけど、レシーバー宣言が値だろうがポインタだろうが、現行じゃ問題なく呼べるようになってる(更には値でセレクタ呼んでもポインタで呼んでも動く
つまりどこかで仕様が拡張されてるのに、仕様書は更新されてないっぽい疑惑

**デフォルトの名無しさん** · 2022/08/30(火) 15:50:42.61

仕様書なんて熟読しなくても、フィーリングで書いて動いちゃうから、今まで気にしたこともなかったし
気にしなくても動くんだからいいじゃない？とも思いはする

**デフォルトの名無しさん** · 2022/08/30(火) 22:31:49.83

そんないいかげんな感覚で思い付きどんどん拡張したその結果が今のC++のていたらくだ！！
反省しなさい！

**デフォルトの名無しさん** · 2022/08/31(水) 00:35:38.08

C++があんなことになったのはむしろ、C++プログラマたるもの仕様書くらい熟読しているだろうと開発陣が高を括ってきた結果だろう

**デフォルトの名無しさん** · 2022/08/31(水) 10:19:04.29

あんなブ厚いARMを読むなんて苦行が過ぎる
悟りに至りかねない危険な行為だ

**デフォルトの名無しさん** · 2022/08/31(水) 12:04:18.42

あるえー？
仕様書で終了ステートメントに続くステートメントに関する記述が無いんで、Playgroundでmainの最初にreturnを書いたらコンパイルエラーにならんかったし実行時エラーも起きない
到達不能ステートメントはチェックされないんだな

**デフォルトの名無しさん** · 2022/08/31(水) 12:08:28.43

そもそも規格化されてる言語じゃないし、コミュニティが用意した言語仕様書にそこまで大きな意味はないんじゃないの？
仮に処理系と内容が違っててもどっちのバグなのか第三者にはわからないこともあるだろう

**デフォルトの名無しさん** · 2022/08/31(水) 14:11:42.15

いかにも仕事が雑なグーグルらしい雑な仕様の言語