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(水) 02:58:16.10

>>388
RustはResult型やOption型によってチェーンでエラーが扱われている

**デフォルトの名無しさん** · 2022/06/15(水) 05:30:30.87

goはそもそもエラーを扱う気概にかける言語だからどうしょうもない
毎回いちいちエラーコード返すのが作法とか何時の時代だよって感じだ

**デフォルトの名無しさん** · 2022/06/15(水) 08:21:25.23

>>390
「例外」がないからGo言語はイケてないとか言ってるヤツが本当にイケてない件
という記事があるから、それに対して反論してからどうぞ

**デフォルトの名無しさん** · 2022/06/15(水) 08:25:08.71

>>388
即時評価だね0点
百歩譲ってfilterやmapはエラー扱えなくてもいいとしても、foreachでエラーを考慮しないのはダメでしょ

**デフォルトの名無しさん** · 2022/06/15(水) 08:41:01.67

Rustも例外が無くエラーを返す点でGoと全く同じだが
OptionやResultといった代数的データ型で返すため抽象度の高い取り扱い及び記述がむしろシンプルさと利便性を両立させている
例外を無くした同じ方針なのにまるで原始時代への戻りと未来への発展の差を感じさせる異なる結果となった

**デフォルトの名無しさん** · 2022/06/15(水) 10:21:02.38

例外はgotoと同じだぞ
現代のネットワークやデータベースといった外部依存が沢山あってエラーがありふれる世界にはそぐわないからGoの値で返す方針は正しいよ

**デフォルトの名無しさん** · 2022/06/15(水) 10:33:53.80

Goにあと20年のキャリア賭けてみても大丈夫かね。
未経験可の案件あるから飛び込んでみようと思うんだが…
40ちょいだからあと20年は戦えると嬉しいんだが。

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

>>394
Web系のエラー処理はオールオアナッシングが基本であまり細かい個別のケアが必要ないから、むしろ例外向きなんだよ

**デフォルトの名無しさん** · 2022/06/15(水) 12:52:09.46

>>392
遅延評価とは反復を使い込んで消費する関数を呼ぶまで効果がない事です。どこをどう見たら即時評価だっていってますか？
明らかにチェーン生成で遅延評価です。
func Of[T any](ss []T) OfSlice[T] {
　　return OfSlice[T]{ss}
}

それと上記ライブラリにはforeachなんてファンクションはありません。Rustのforeachが副作用を伴う操作が出来てしまうが過去の互換性を
維持するための現在の仕様のことを見聞きして言っていますか？通常多くの言語や高階関数操作が出来るライブラリでmapとforeachの違いは
値を返すかどうかの違いでありエラーを返せるかどうかではありません。またRustがtry_for_eachが存在するのもあくまでも利便性のための
例外であり、普通は特に高階関数操作中のエラーが起こることこそが例外でダメなコード設計です。

もしコード中でコレクションに含まれるデータにより例外エラーを伴うようなコードを乱造しているのであれば”大きく”反省してください。
それとも全く分かってないのに言葉遊びしている？印象を受けます。「foreachでエラーを考慮しないのでダメ」の理由を示してください

**デフォルトの名無しさん** · 2022/06/15(水) 13:27:56.57

>>397
rustのitertools::foreachはそもそも遅延評価じゃないし、過去の互換のために残されているのはその通り。ドキュメントに明記されている
遅延評価じゃなく積極的な評価だから例外が考慮できるといえるがrustの真価は高階関数操作が共通的であれば最適化されること。goが同様の操作を最適化するかどうかは知らん

**デフォルトの名無しさん** · 2022/06/15(水) 14:22:43.40

GoはそもそもGCがあってランタイムが重たい高水準言語で、ローカル変数でも必要ならヒープに確保するし、
GCどころかヒープすらなくても動くRustとは最適化の文脈が違いすぎて・・・

**デフォルトの名無しさん** · 2022/06/15(水) 14:31:21.29

アホか、レジスタ数が限られてる現代未来において必要ならローカル変数なんかヒープやスタックに確保するのは当たり前だ。
そもそもマルチタスクOSで動く今のプログラムは普通に変数はヒープの間を行ったり来たり
ランタイムが重いんじゃなく、ランタイム大きい。最適化の度合いも近代的な言語で大手企業が支援あれば大差ない。
そんな事やってるからRustが嫌われるんだぞ、馬鹿野郎

**デフォルトの名無しさん** · 2022/06/15(水) 14:37:28.29

Rustは低レベルなシステムプログラミングに使えることが目的な特殊な言語なので

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

>>397
ストリーム系APIでいう遅延評価というのは一般にいくつかのレベルがある
例 : items.a().b()
1. 最終的に結果を列挙しようとする段階でaとbの操作を実行する。実行順序は、aの操作をitemsの全ての要素に対して実行した後にbの操作を全ての要素に対して実行する。
2. 可能な限り列挙を繰り返さない。可能であれば、1要素毎にaとbの操作を実行し、次の要素に進む。一時バッファを使用しない。
3. 実際に要素が必要になるまでitemsの各要素を生成しない。つまり無限に続くシーケンスの実装が可能。

例えばシーケンスの順序を逆転させるような操作は一度全てを列挙しないといけなかったりするから、普通はこれらのハイブリッドな実装となる。
>>388で実現されてるのはこのレベル1までだね。

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

>>397
見落としてるだけだと思うけど、
>>388にはEachがあるよ。エラーを扱えない欠陥品だけど。

**デフォルトの名無しさん** · 2022/06/15(水) 18:44:38.49

半分禁じ手に近いけど、deferでrecoverするという手も無くはない
あれは日和ったと見るべきか

**デフォルトの名無しさん** · 2022/06/15(水) 19:45:11.38

>>402
遅延評価と「無限に続くシーケンスの実装」はまた別問題だ。ほとんどのプログラムはfilterやmapも有限長だけで十分機能する。
Pythonのコルーチェンyield中断と同じく、それを基にしたRubyの.lazyや、さらに進んだC#のLINQなどは無限長の操作を可能にするが
Rustの無限長イテレーターはRangeやstd::iter::repeatにおいて無限長を扱えるだけであり、yieldはまだ実験的。
というか迷惑だからRustスレか言語比較してるスレでやって攻撃的な人格疲労しろよ

**402** · 2022/06/15(水) 19:52:07.91

>>405
俺はRust信者じゃないぞ？
十分機能するかどうかは個人の感想の問題だが、いちいちリストのコピーが発生するから非機能面では十分に問題になりうる

**デフォルトの名無しさん** · 2022/06/15(水) 20:33:08.01

>>406
そうか？チョットでも知ってればGoはyieldなんてキーワードはサポートしてないので安易な無限長をサポートするわけない。
最初の何も見ずforeach言ってるRustバカと一緒で、コレクションに含まれる高階関数操作で例外を考慮する状況がなぜ正しいのか説明できていない。
それだったらまだ蛇足的に挙げた無限長が扱えない事のほうが欠点だ、ほとんどの状況は高階関数系で例外なんてforeachでもEachでも考慮しない
上のライブラリはチェーン連鎖でコピーが発生するのはその通りだが、例えばfilterにmapをつなげて最後にcollectするような操作は上記の遅延評価や
無限リスト、そして例外とは何の関係もない。言語的な宗教戦争をやってるバカようにしか見えない、とてつもなく迷惑この上ない行為だ

**デフォルトの名無しさん** · 2022/06/15(水) 21:34:23.56

>>407
無限リストを扱うための前提として要素毎のストリーミング処理ができることは必須だから全然関係なくないぞ
なんか勘違いしてるようだが、俺はGoを貶しているのではなくただ>>388のライブラリがヘボいと言っているだけだ
別にyieldがなくたって今のGoで無限リストは実現できるよ

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

Goならyieldみたいな妙なことしなくてもgoroutine内でループしてチャネルで送りつければいいだけだもんな

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

妙でない==基本的な機能の中で説明できる
yieldなんてgoto並みに不自然じゃん

**デフォルトの名無しさん** · 2022/06/15(水) 22:48:49.45

>>395
Go一本に掛けるの厳しくないか。

**デフォルトの名無しさん** · 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の用途なら挿入順でイテレートできるようにするためにかかるコストよりも
利便性が優先されるからじゃないかな