TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼
くだすれPython(超初心者用) その44【Ruby禁止】
Git 16
C言語をやりたいんですが
Xamarin Part6
【GNU】スクリプト言語 Guile【scheme】
Androidプログラミング質問スレ revision49
SVG波形ライブラリ
【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ55【php,py,pl,rb】
☆★Java質問･相談スレッド183★★
MVVMについて語ろう

Go language part 3


1 ：2019/10/17 ～ 最終レス ：2020/06/13
Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。

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

日本語訳
http://golang.jp

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

2 ：
>>1乙
テンプレが古すぎるんで作ってみたがどうだろ


公式
https://golang.org

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

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

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

3 ：
golang.jpは外して良いね

4 ：
golang.jp は、エイベルの古川昇部長が、社内で始めた翻訳プロジェクトだろ？
最近は、活動してないのか？

改訂2版 基礎からわかる Go言語、古川昇(エイベル)、2015

5 ：
その人もうやめてるでしょ

6 ：
先週から仕事でGoやることになったんだが、この言語辛すぎないか・・・？
ジェネリクスないしエラーが辛い。ジェネリクスは2.0で入るらしいが。
Goの作法だとエラーハンドリング忘れて次の処理を書けるリスクが常に孕んでてて書いてて全然安心できない。
あと詳細なエラー情報見ようとするとcustomErr,ok:=err.(CustomError)みたいにしないと情報とれないの危なすぎでしょ。
なんでカスタムエラー型認められていないの？

7 ：
>>6
認められていない訳じゃない
しかし、カスタムなエラー型だと正常時にnilが帰ってきた時に
if err!=nil {} がtrue判断を食らうという厄介なバグがある
これは型付きnilというバグだが、仕様と言い張ってる模様
仕様なら、the predeclared identifier nil, which has no typeの記述とか直せや！

8 ：
>>6
エラー処理を忘れるうっかりさんは例外だってキャッチ忘れるだろな
そして、エラー処理は1.13でほんの気持ちだけ改修入ってるからチェック
Is, As

9 ：
O2

10 ：
>>7 認められてないというよりか風潮といった感じか
カスタムエラーがstructじゃなくてinterfaceならいけるんじゃない？
まあどのみち使用しているライブラリがerror返してるからどうしようもないんだけどな
俺はMySQLのエラー番号が知りたいだけなのにどうして危険な操作を強いられるんだ

>>8 まず俺はGoのエラーと例外を引き合いに出してはいない(例外は糞だが)
例えば関数の戻り値がT,errorのような場合でerrorじゃないときだけTの戻り値にアクセスできるような仕組みが欲しい
ScalaのEitherやRustのResultのようなやつな
今はジェネリクスないからそういう実装はできないだろうけど
そもそも職場の制約で.1.13は使えないが、IsもAsも対してかわらんなって印象だわ。
ライブラリの実装者が中で返すエラーの型を変えた場合、IsやAsしててもコンパイルエラーにならず適切なエラー処理ができずに実行されてしまう。
戻り値の型できちんとカスタムエラー型を明示してくれてればコンパイルエラーで気づけるんだけどな


今さっき聞いたんだけど、2.0で入る予定のエラーハンドリング周りのサポート、error型のみが対象らしいんだってな。
2.0にはいると本当にカスタムエラーの道が閉ざされてしまいそうだけど本当にそれでええんやろか

11 ：
エラー処理の観点から見るとジェネリクスないのはもう相当きついね
関数型脳は捨てるしかない

12 ：
まあRustも関数型言語かというと違うけどな。標準ライブラリにはモナドないし。
ジェネリクスが必要なものに関しては今使えないから仕方がない面はあるとは思う。

ただカスタムエラー型が実質使えない状態になってるのは辛いなあとは思う

13 ：
モナドあってもdo記法相当ないときついからね

14 ：
exe でかいな・・・

15 ：
う、うん…

16 ：
2MBは静的リンクされてる実行ファイルなら普通よ
C系のリンカーの出力だとままある
動的リンクされてDLLとかアセンブリとかSOをロードする実行ファイルとは違う
ロードが速いはずというメリットもある

17 ：
せやな
この特性でインスタンスの起動が早くてクラウドだと重宝するね
反面WASMとかだと辛いという話は聞いている

18 ：
そもそもC/C++自体がすでに第一選択の言語じゃなくて、応答性やパフォーマンスの問題で消去法で選ばれる言語だし、
Goはそれで弾かれる側の言語なんで無理無理

Goが選択肢に入るような要件ならC++は選択肢に入らないし、逆もまた然り

19 ：
しかし、C++は他に選択肢が無いというよりアセンブラより生産性が高いという消去法で選択される言語
C++よりも生産性が高いと思う人間、例えばGoogleとか俺にとっては消去法での乗り換えが充分に考えられる

20 ：
あ、もうちょい書き足りなかった
つまり、ベターなアセンブラの地位をC/C++から奪おうという狙いの言語、という位置付けだと考えるよ

21 ：
草

22 ：
笑っていればいいさ、20年前にJavaが将来のメジャー言語になると言ったら馬鹿にされるのは必至だったし

23 ：
まあ、linuxカーネルがCで書かれる限り、Cの牙城を崩すのは夢物語なのは間違いない

24 ：
1999年ならjavaはすでにメジャー言語でしたけどね

25 ：
Dと比べてどうなん？

26 ：
var hoge uintptr = 123 動く(1)
hoge := uintptr(123) 動く(2)
hoge uintptr = 123 動かない(3)
hoge uintptr := 123 動かない(4)

やっぱり面倒なんだよね
良い方法ないですか
あと(2)があまり使われないのはなぜ？

27 ：
>>24
ほほう、EclipseもstrutsもJITもない1.2の時代でメジャーとな？

28 ：
君は20年後も笑われてると思う

29 ：
使ったこと無いから的外れかもしれないけど、uintptrなんてunsafeな箇所くらいでしか使わないと思う(アーキテクチャ依存だからという理由
そんなuintptrを簡単にという意図がわからないので、解説plz

30 ：
根拠も何もなく笑って誤魔化す人に笑われても痛くも痒くもないね
そこでどうぞ笑っていてくださいな

31 ：
Cの整数リテラルに付けるサフィックスみたいな？
1234LL とか 1234ULL

32 ：
>>27
当時のTIOBE IndexでC、C++に次ぐ3位ですけど

33 ：
>>32
ぐう、認めざるを得ない

34 ：
全然関係ない話
公式のドキュメントのフォントがChromeとかで汚いと悩んでたんだけど、実はGoogleのRobotoフォント入れれば良いんだな

35 ：
そんなのuser.cssでいくらでも好きなようにできるじゃん

36 ：
:= と = の使い分けが構文的に破綻してるように観える

37 ：
var s []byte = "abc"
string(s) // OK
s.String() // undefined

var b bytes.Buffer
string(b) // cannot convert to string
b.String() // OK

なんかこの辺もいまいち

38 ：
a) var hoge bytes.Buffer
b) hoge := bytes.Buffer{}
c) hoge := new(bytes.Buffer)

これは全部同じか？

39 ：
cはポインタじゃね？

40 ：
&xxxxx{}の方が直接的で字数も短いからnewって使ったことも無かった
何のためにあるの？

41 ：
ウメは所詮ウメ

42 ：
>>35
なんかしばらくしたら元に戻っちゃったんで、user.cssに戻した
面倒なんだよー

43 ：
chrome拡張でuser.css使えばいいだけじゃん

44 ：
errorはインターフェースだからswitchで処理するんじゃないの？キャスト使うの？

45 ：
今頃書き方が気に入らないとか変な奴が増えてきたな

46 ：
errorがつらすぎるError()stringだけで表現しきれないよ

47 ：
たまにgoやると、そのたびにテンプレートリテラルがないことを忘れててショックを受ける

48 ：
Go って GAE とか GCP 以外ではどんなところで使われてますか

49 ：
>>48
https://github.com/golang/go/wiki#online-services-that-work-with-go

50 ：
LLで書かれていたserver-sideの置き換え

51 ：
>>48
ありがたくGogsを使わせていただいてます

52 ：
>>48
ありがたくDockerを使わせていただいています。

53 ：
>>48
android本体のビルドシステム

54 ：
{ "name": "Tanaka", "age": 26 }
{ "name": "Tanaka"}
{ "age": 26 }
{}

みたいに中身が入ってるか不確定なjsonlファイルを上手くcsvやtsvに変換する方法ってありますか？

55 ：
普通にjson.Unmarshal()するだけで、mapになるそうだから
入っていないキーは入っていないと分かるのとちがう？

設定ファイルとか使うコード書いたことないから受け売りなんだけど

56 ：
いまいちカッコ悪いが、
各フィールドをinterface{}で受けて、有無をnil判定するのはどうか

type Person struct {
Name interface{} `json:"name"`
Age interface{} `json:"age"`
}
func encodeField(v interface{}) string {
if v == nil { return "" }; return fmt.Sprint(v)
}
func main() {
var persons []*Person
json.Unmarshal([]byte(`[{"name": "Tanaka", "age": 26},
{"name": "Tanaka"},{"age": 26}, {}]`), &persons)
w := csv.NewWriter(os.Stdout)
for _, person := range persons {
records := []string{encodeField(person.Name),encodeField(person.Age)}
w.Write(records)
}
w.Flush()
}

【出力】
Tanaka,26
Tanaka,
,26
,

57 ：
LTSVに
https://play.golang.org/p/RHu8P0fJO8O

Golang初めて1週間未満なのでいろいろあれかもしれんが

58 ：
書いた後にアレだが、 >>55 のやり方のほうが良い

var persons []map[string]interface{}

59 ：
どうぞ
ttps://play.golang.org/p/JD9lfvYmddM

60 ：
ポインタにしてしまうのはどうだろう

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

61 ：
Goってjqみたいな機能無いのか
jsonの全パターン書くの辛くないか？

{ "name": "Tanaka", "age": 26 }
だけで残りの3パターンも補完できれば汎用性のあるものができそうだが

62 ：
>>61
>jsonの全パターン
何を言ってるのか分かりません

63 ：
まあjq使ったほうが遥かに早いわな

64 ：
>>62
{ "name": "Tanaka", "age": 26 }
{ "name": "Tanaka"}
{ "age": 26 }
{}

みたいに全部定義するのがめんどいってことでしょ

65 ：
>>64
定義って、それはテストデータじゃない
テストデータ書かないでサンプル書くの？

とかすっとぼけて書いたが、誰かjsonの形式の定義が必要なサンプルコードを書いたりしたか？という話
そもそもが内容が不定なjsonを解読するって話だから、皆さんそれを読むサンプルコードを書いてる
つまり、レス主はそれらのサンプルコードを読んでないんじゃね？

66 ：
Unmarshal()の引数に[]interface{}の変数のポインタを渡すと、マップとスライスで構成されたjsonの中身がエンコードされるという前提知識で話してるのに
キーをフィールドとして事前定義しなきゃならん、構造体のスライスへのポインタを渡す形式の呼び方での話を持ち出されても困るんだ
んでも、構造体を切ることをパターンと言っているのではない可能性もあって、一応確認

67 ：
【質問】
goroutineはデーモンスレッドみたいにプロセスが死ぬと終了します
だから後始末をしたい場合、子にはcontext.WithCancelで終了を通知、受け取ったら後始末
そして、親はsync.WaitGroupで完了待ちしています

んでも、もっとうまい方法ってないものかな？面倒

Javaだとスレッドをinterruptして、子はInterruptExeption拾って後始末して、親はjoinして待つじゃない
主にInterruptExeptionをキャッチするコードを書くだけで済む
もしも親から狙ったgoroutineに特定のpanicを起こせるなら、recoverで拾えるかなーと…

68 ：
暗黙で thread safe になるからじゃね？

69 ：
Most Popular Programming Languages 1965 - 2019
https://www.youtube.com/watch?v=Og847HVwRSI

70 ：
Go 10周年

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

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

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

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

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

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

75 ：
ローソンやめて・・・

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

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

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

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

80 ：
go.dev
pkg.go.dev

デヴ乙

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

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

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

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

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

86 ：
ドメインの管理者は…

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

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

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

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

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

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

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

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

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

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

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

98 ：
>>94
go.mod に

replace internal/config => ./internal/config

と書いておくと

import "internal/config"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Valueは使ったこと無い

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

124 ：
>>122
WaitGroupのソースを参照

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

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

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

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

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

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

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

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

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

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

132 ：
誤検知じゃないかも

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

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

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

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

137 ：
ごめんnet/http一択

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

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

140 ：
>>139
お、ｲｲﾈ!

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

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

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

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

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

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

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

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

148 ：
おんぶに抱っこやんけ

149 ：
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)
}

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

151 ：
まぁ、こんなんかなぁ…

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

152 ：
reflection ならこうかな

import "reflect"

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

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

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

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

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


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

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

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

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

158 ：
ごめん、完全誤爆

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

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

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

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

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

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

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

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

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

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

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

165 ：
Java

166 ：
Java 原人、生きていたのか

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

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

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

170 ：
ジェネリクスはGo教において諸悪の根源とされる「利用しようとする前に利用される方を設計する行為」の最たるものだからなあ

171 ：
自分としてはgolangの形式で動的にリンクできるライブラリ手法が欲しいな
dllみたいなcgoなライブラリじゃなくgolangネイティブな形で
interface定義とインスタンスをロードするビルダだけ静的リンクするスタイルを想定
これがあるとDIとかプラグインが捗るから

知らないだけで存在してたりする？
それともdotnetのactivexみたいにdllに皮かぶせれば行けたりする？

172 ：
ドラフトに挙がっている Go の generics(contract ベース)が採用されれば、

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

inteface{} を使わなくてもよくなるんじゃないか、って期待してる。
まぁ、最終的にどうなるかは分からんけど…

173 ：
ジェネリクスは大体ライブラリとかそっちの方が実装してて普通は使うだけ
他の言語でジェネリクスないときはいちいち型キャストと型チェックしてたから
そういうのが無くなって嬉しかったんだけどなあ

174 ：
goでapiサーバーを構築したいんだけど、参考になるサイトとかないですか？

175 ：
本買え

176 ：
状態を変化させるAPIだと、API作るよりCORSとかCSRF周りの勉強がめんどくさい

177 ：
WebAPIサーバーなんて、Qiitaとかそこらへんに転がってるような「GoでWeb APIを作ってみた」
程度の簡単なものが実際に本当にプロダクションで運用されてるもんだ。
ただしその前方や足元にはALBやらKubernetesやらがあって、信頼性やスケーラビリティはGoではなくそういったクラウドインフラの層で担保するんだよ。
Goをプロダクション運用したいなら、GoよりAWSの知識の方がずっと重要だ。

178 ：
>>177
アホ

179 ：
標準パッケージのjsonのUnmarshal
なんでReaderインターフェースでなくてバイト配列を引数にしたんだろ？
DecoderはSAXみたいなトークナイザだしなぁ

180 ：
>>177
趣味のサービスかもしれんのに、何を先走ってるんだか？
少なくとも商売始めようという人間が便所の落書きで質問しないと思う

181 ：
だったらQiitaのコピペ記事で十分だな

182 ：
>>179
いやNewDecoder(r).Decodeでいいだろ

183 ：
>>182
え、そうなの？とやってみたらできたわ
https://play.golang.org/p/thP_FXceuPm
勘違いしていた

184 ：
一見落着

185 ：
goルーチンってプログラム終了前に全部終了させる必要ありますか？

186 ：
>>185
必要かと言えば、必要はない
goroutineが終わらなくてもプロセスは終わる

でも、goroutineのdeferルーチンは呼ばれない
https://play.golang.org/p/Tt1Hbxzbr8v

つまり後始末とかはされない
後始末したければ、
1. context使って終了を通知
2. WaitGroup使ってgoroutineの終了を待つ

187 ：
ありがとう

188 ：
golangはgoroutineでNAMESPACEを適切にコントロールする手段がないのでDockerコンテナを記述するには適していない、という記事を読んだんだけど
これって対策とかロードマップとか何か打ち出されてない？

189 ：
>>188
記事はどこ？

190 ：
>>189
2017だから結構古い話
https://www.publickey1.jp/blog/17/rustdockerrailcarrust.html
OracleがDockerコンテナランタイムの実装言語としてgoじゃなくRUSTを採用した理由
んで、goroutine関係って改修ってされてる話って見たことなかったんで、これってどうなってるのと

191 ：
記事読んでみたけど、問題はnamespaceそのものじゃなくてnative threadへのアクセスじゃないのかな。

192 ：
言語選択ネタは基本的に使いたいものを正当化するためのゴリ押しになりがちだから話半分に聞いておくのが正しい態度

193 ：
根本的な原因はそうなんだろうけど、クリアするハードルは名前空間なのかなと
まあ、自分はDockerコンテナ自身には今のところ手を出す気はないアプリ作者だけど、ちょっと気になっただけなんだ
元からgolangはデバイスドライバとかの低レベルのシステム開発は対象としてないように見える(主観)ことから、それと同様に不要な機能としてガン無視なのかな？
それならそれで文句がある訳じゃない

194 ：
いつぞやの「味見」の兄チャンか？

195 ：
えーと、多分そう
ツール書くのにperl awkからjava c#経由して今はgolangが便利すぎて引っ越してきた

196 ：
過去ログ見たら別の人
自分はmodulesが安定しねーっ、と嘆いていたクチ

197 ：
おまえか！

198 ：
https://i.imgur.com/LvXV7fl.jpg

199 ：
プログラミング言語ごとの年収
https://pbs.twimg.com/media/EOSS8tqU4AAY75v.png

200 ：
今のところGoはAWSやGCPを極めた人が使うイメージだな
年収が高いのもそのためだろう
Goはドカタグラミングにも最適だから、もし今後も順調に普及していけば平均年収は大幅に下がりそう

201 ：
覚えなきゃならない独特で特殊なことがインターフェースの概念くらいで、構文は平凡以下の厳選されたものしかないから学習ハードル低いよな
自分はc言語とJavaとJavaScriptを経験してるから、一週間でほぼ使えるようになった

202 ：
下手すると何も特に勉強しなくてもただ人の書いたコードながめるだけで
「ああこんな感じか？」って雰囲気だけでそれなりのコードかけるようになっちゃう言語

203 ：
goはシンタックスシュガー多めで、初学者が見よう見まねで学習すると嵌りやすい印象。

204 ：
ほとんど使う局面がないstruct実体はでっかい落とし穴
実体配列rangeで回して更新されねーっと悩む初心者のいかに多いことか

205 ：
糖衣構文？なんかあったっけ？

206 ：
>>204
ヌルポで落ちまくるよりは遥かにマシだわ
むしろfor rangeで要素のポインタを取れるようにしてほしい

207 ：
落ちるなら、そちらのほうが万倍はマシでしょ
落ちなくて値が更新されないという恐怖

208 ：
誰も staticcheck 使ってないのか……

209 ：
golangのシンタックスシュガーは思いつく限りだと
１． := での型推論による変数宣言の代替
２． レシーバがポインタ型の場合に構造体実体でメソッドを呼び出すと、ポインタに変換して呼び出す
C言語からの後方互換性を意識するなら -> は廃止しなけりゃいいのに、中途半端
モダンな言語と同じにポインタを参照と呼び替えて、実体が欲しけりゃunsafeでやれと

210 ：
学習時に2は一貫性なくて嫌だった

211 ：
３． {フィールド:値, ...} 形式の構造体生成式
・・・これは構文だしシンタックスシュガーなのか微妙

シンタックスシュガー多めという意見は、どういう観点で構文をシンタックスシュガーだと判断しているのか俺にはサッパリわからない
むしろラムダ式(本来の無名関数という意味ではなく -> で書く記法)というシンタックスシュガーすらないgolangはむしろシンタックスシュガー少なすぎ（でもそこがシビれ

212 ：
シンタックスシュガーといえば、&Hoge{ ... }で構造体を初期化しつつポインタを取れるのに、&1はダメなのがウザい

213 ：
シンタックスシュガーというか、なんか一貫性に欠ける略記法みたいなのが多いような

214 ：
多いような、と言われてもなぁ
略記法と言っても、_ とか [::2] とかしかぐらいしか思い浮かばないんで、具体的に

215 ：
switch w := v.(type) はかなりエイリアン感あるな
Goに存在する数少ない型推論と言えるものの一つ

216 ：
Dockerの本社いい所にあるね
現役シリコンバレーエンジニアが教えるGo入門 + 応用でビットコインのシストレFintechアプリの開発
https://www.youtube.com/watch?v=WkEWDXogjR8
https://duckduckgo.com/bang_lite.html
!yt giants homerun boat

217 ：
一貫性に欠ける記述に思い至った
スライスとマップだけ生成すると実体ではなくてポインタを返す
やっぱり、構造体も生成するとポインタを返してほしかった
要らんよな実体

218 ：
要らないというのはちょっと正確性に欠けてた
普通のロジックを書く場合には要らない

DLL呼び出しとか、バイナリファイル書き出しとか、外部I/Fとして任意のアラインメントでのバイト列に直列化するパッケージがあって、内部では全て参照と言う名のポインタを扱うようにしてくれていたら何も問題は無かった
構造体ポインタでスライス作って、構造体のアドレスを入れて、という書き方を説明するためには、アドレスについて教えなけりゃならない
それを理由として新人研修の言語教育の候補リストから落としたんだった

219 ：
すべてポインタてJavaか

220 ：
構造体がポインタじゃないのなんでだろ
結局全部ポインタにしがち
イミュータブルな操作に値レシーバ使うことと整合させるため？

221 ：
・構造体配列のアクセスがゲロ遅い
・GCに負担がかかる
・エスケープ解析が困難
・C/C++との相互運用時に>>218のような変換が必要になりクソ非効率だし実装も面倒
・nilを受け入れないことを保証できない

222 ：
CL 187317 for the current proof-of-concept implementation.
https://go-review.googlesource.com/c/go/+/187317

223 ：
>>221
より良きアセンブラとしてC言語からの代替という目的だと、性能に対しての多少のコーディングしづらさはトレードオフの許容範囲ってことか
こりゃ、どうにもならないなー
>>208さんの言うように静的解析でガードするのが正解なんだな

224 ：
Cと同じものが欲しいならCを使ってれば良いんだよ

225 ：
正論

226 ：
GCが欲しかったんだよ

227 ：
静的解析でgolangci-lint導入してみた
そしたら gosimple が大量に felse == じゃなく ! 使えと
うるせー！年寄りには ! は見辛くて見逃すんだよ！！
どこだよ、オフする設定方法

228 ：
felse てｗ

229 ：
フォールス

230 ：
TYPOした鬱だし

231 ：
だっさ

232 ：
静的解析の余計な判定をオフする方法がわかったんで書いとく
// nolint:gosimple
とか行の後とか前行に書くとそこだけオフされる
設定ファイルでオフすると設定ファイルを公開する手間が増える
コードに書いておく方がベターだと思った

233 ：
素直に ! 使えｗ

234 ：
>>232
色変えろ🎵

235 ：
GO2になるのいつや？

236 ：
https://blog.golang.org/toward-go2
Go 1.20がGo 2.0になるらしいから順調にいけば2023年

237 ：
ひとことでいうと
この言語は名前がだめ

238 ：
goでググるな
golangでググれ

239 ：
cとかdよりは……

240 ：
一時期Cの関数を検索したかっただけなのにphpのばっかり出て来たときは辟易した

241 ：
一時期旧日本海軍の軍艦の画像を検索したかっただけなのになぜか
萌え絵のおっぱいおねーさんばっかりでてくる、みたいな状況か

242 ：
JULIAが最悪

243 ：
ｗｗｗ

244 ：
MFCのCStringもヤバい

245 ：
ご覧～

246 ：
The Go Programming Language Specification
Version of July 31, 2019
https://golang.org/ref/spec

Goプログラミング言語仕様
Version of September 4, 2012
このサイトの更新が滞っており、情報が古くなっておりますのでご注意ください。
このドキュメントは、http://golang.org/ref/specの翻訳です。
http://golang.jp/go_spec

247 ：
php界隈みたいに翻訳してくれる神様降臨してほしい！

248 ：
頑張ってくれた先人には申し訳ないけど
古い情報がトップに出てくるのは悪影響しか無い気もする

249 ：
どこの言語も同じだよな
特にモジュール関係はどの言語もひどい有様で初心者が皆困惑して言語から離れる
一度使用固めたら不都合でも10年は同じものを使って欲しいｗ

250 ：
今発売されているGoの入門書でモジュール対応してるものってあるの？

251 ：
モジュールと言われても用語としての範囲が膨大すぎて意味が伝わらない

252 ：
みんなのGo買ったけど初心者向けじゃなくて読んでないんですが
本当に初心者向けの本ってありませんか？

253 ：
本じゃないけど
Golang tutorial
https://golangbot.com/learn-golang-series/

254 ：
>>252
今いい本はないと思う

255 ：
みんなのGoってオンラインで無料で全部読めるやつ？

256 ：
>>252
改訂2版 みんなのGo言語、2019/8/1
この本は、各言語の「Effective 何々」に当たる本

改訂2版 基礎からわかる Go言語、古川昇(エイベル)、2015
この本が初心者向けの文法書

>>246
に書いてある、翻訳プロジェクト、公式サイトの日本語訳
http://golang.jp/
は、エイベルの古川部長と社員が書いていた

257 ：
ガチの初心者がGoなんか使って何するのか、嫌味じゃなくて興味がある
Goは言語だけできても全く何の役にも立たないと思うが、
本来のGoのコンセプトの通りに、ペーペーにGoだけ覚えさせてアプリケーションコードだけ書かせるような組織が日本にも存在する時代になったのだろうか

258 ：
サーバー側は、Ruby → Node.js, Go
今世紀最大の起業家、Vagrant の作者・Mitchell Hashimoto なんか、まさにそう。
今や、Go の重鎮
Ruby on Rails, Sinatra などで、サーバー側を一通り作った人が、Go へ行く。
そういうキャリアパスでは「みんなのGo言語」は、良い本

259 ：
>>257
>Goは言語だけできても全く何の役にも立たないと思うが、
Goに限らず汎用言語はみんなそうだろ
標準ライブラリが充実してて言語の構成要素が少ないGoを
最初の言語として選ぶのは悪くない選択だと思うぞ
C/Java/C#/JavaScriptらと比べるとずっと簡単

260 ：
だからこそモジュールのバージョン管理が大事なんだと思う

261 ：
基礎からわかる Go言語もずぶの素人には難しいと言うか無理だろこれは

262 ：
関数の引数で []*xxx と []xxx があるんですが、どっちを使ったらいいんでしょうか

263 ：
間違ってたらコンパイルエラー出るから、コンパイルエラーが出ないほう
呼んだ先の関数の引数の定義をよーく読め

でも、実際に渡している方の部分を見て書いてる可能性もあるか……
インターフェースの配列を受け取る関数だとすると、どちらでもコンパイルエラーは起こらない
ぶっちゃけ、その場合はどちらでも構わないことが多い

[]xxxxは、xxxxがインターフェースでなく構造体だったなら、十中八九はバグだと思う
バグでなく意図的に使うケースもありはするけど………………

264 ：
>>259
もちろんライブラリやフレームワークの学習は前提だけど、
仮にプログラミング初学者がGo勉強して基本的なCRUDアプリを作れるようになったとして仕事あるか？
極端な話、初学者がSpringとかASP.NETとかRailsとか覚えたら、
サーバーを起動する方法もその上でアプリを動かす方法も知らなくても仕事はいくらでもあるわけだよ
一方Go名指しの求人って、ほぼ例外なく、複数言語が使えてAWSもわかるフルスタックな人が期待されてると思うんだよな
もちろんGoが使えたらプログラミングの素質はあるだろうってことでの採用はありうけど、
そうやって入った環境では多分Goを書かせてはもらえないだろう

265 ：
なんかポインタとsliceが糞だなあ

266 ：
containsメソッドすらないとか頭おかしい

267 ：
>>264
同意するかは別にして言いたいことは理解した
そういう内容なら「Goは言語だけできても全く何の役にも立たないぞ」じゃなくて
「初学者がGoだけ習得しても仕事はないぞ」って書けばいいんじゃないかな

268 ：
>>266
https://play.golang.org/p/fZ3EJyfPYWg
(メソッドじゃないけど)

やはり reflection は遅いな…… 早く >>222 の contracts を正式採用してほしい

269 ：
Goは標準ライブラリが洗練されてない感じがする

270 ：
go言語って糞じゃね馬鹿じゃね

271 ：
結局みんなと同じようにRuby on RailsとかPHPやっとけばいいんじゃねえのか
人と違うことしてる俺様かっこいいみたいなデスクトップのLinux使ってよく分からないエラー出ながら使ってる奴とか
そういうことじゃねえのかポインタとかスライスとか糞
[]xxxと[]*xxxをAPIのレスポンスで返したら同じjsonが返ってくるとか糞
普通ポインタの配列なんだからアドレスの羅列が返ってくるんじゃねえんか
マジ糞言語

272 ：
スクリプト言語ならpythonじゃないの今は

273 ：
goはあちらこちら洗練されてない。存在としては好きなんだがなぁ。

274 ：
洗練されているプログラミング言語ってあるのか？

275 ：
矛盾が少なくて必要最小限の仕様しかない、という意味ならC
だから未だに現役なわけで
俺はJavaScriptが好きだけど
JSもCと同様Alt-JSが大量に発生したものの殺しきれなかった、という意味ではある程度洗練はしている
言語としての問題は typeof(null)==="object" 位

276 ：
やっぱgoに使い慣れている人でも糞だと思ってるんだな

277 ：
＞[]xxxと[]*xxxをAPIのレスポンスで返したら同じjsonが返ってくるとか糞
ちょっと意味がわからないけど、要するにポインタレシーバでのインターフェースで実体も受け取れるという話じゃないかと思うんで同意
すんごくブッ飛んでるよなあれは……

278 ：
JavaScriptも嫌いじゃないけど、ほぼほぼ毎年仕様が追加されていて着いていけない
prototypeで書いてもいいよね？bind使っててもいいよね？ダメ？

279 ：
goは何がだめといって、まず名前が駄目

280 ：
公式サイトですらgolangだもんな……

C言語よりは検索性に優れてるよ！w
甲乙じゃなくて丙丁つけがたい争い

281 ：
go とか　[] とか　[]* とか　すごく検索しづらい

282 ：
>>278
エアプかよ
さすがにbindがNGは今時ないと思うぞ
まあそうやって駄目な理由を探しているようではずっとエアプのままだろうよ
goが洗練されていないのは当たり前、新しい言語だからだ
何だかんだでJavaScriptは25年、Cなんて50年近いのだから、必要な仕様はとっくに入っている
JavaScriptでも、今追加されている仕様はそもそも「あってもなくてもいいもの」でしかない
それに比べて、まだgoは根本的な部分で仕様変更が為されている段階だろ
この意味では、今現在のgoをプログラミング初心者が触るのは間違っているとは言えると思うけど
お前も含めて

283 ：
糞じゃね言って同意って言われるのが終わってる
否定してほしくて敢えて過激なこと言ってるのに

284 ：
Goが気持ちいいのは、意識高い先人達が築き上げてきた無駄に複雑な数多の概念を「Goだから」で一蹴できるところ
例えばテストコードの assert that 系のDSL
誰もが薄々糞だと気付いていたが、意識高い空気がそれを許さなかった
それを堂々と「こんな糞は要らんかったんや！ifでええんや！」と言えるお墨付きが貰えた
Goが数々の欠点にも関わらず言語として好まれた本当の理由は、そういうカタルシスにあると思うわ

285 ：
>>283
構ってちゃんはR
また、そういう態度はWebを駄目にするからマジでR

286 ：
>>284
それは一理ある
公式でも言っているとおり、Goは敢えてガラガラポンしている
多分、いわゆる「お作法」に辟易している若くて元気のいい奴に受けているのだと思う
だから「結果的に再発明になってもいい」と思える奴等には良いプラットフォームだろう
(なお俺はassertなんて使わないことは一応付け加えておく)

287 ：
みんなgoとかgolangって書いてるけど実際はGoなんだよね

288 ：
Goだけで全て完結して欲しい割りとマジで

289 ：
Hiromi Go

290 ：
文字関連のライブラリとかかなり雑と言うか古臭く感じる
cから発展したともとれるが嫌な感じだな
uint64を文字列にするのもいまだにググって調べてる

291 ：
毎回ググって調べてる奴の方が雑…というか鈍くさい

292 ：
>>284
俺みたいな老害Cプログラマがマウント取りまくれる言語仕様なんだよね
例外とかいらん！オブジェクト指向もいらん！
スクリプト言語のおしゃれ感もいらん！

293 ：
interfaceとgoroutineはオシャレだと思うぞ。あとはダサダサだけどw

294 ：
selectの非同期待ち受けって、素敵だと思うの
もじもじ……

295 ：
goroutine周りは記述が簡便で初心者も手を出しやすい雰囲気を醸し出してるのに、実際には低レベルで罠が多いんだよなあ
これだけ徹底的な低能仕様なのにデッドロックに対する安全機構のようなものが何もないのはいかがなものか
せめてpromise的なのくらいは欲しい

296 ：
context を使えばいいじゃない

297 ：
Goの非同期機能の公式の説明で共有メモリは危険だとかドヤ顔で講釈垂れてる割には
ちょっとchannelの扱いをミスると簡単にデッドロックするんだよな
Goの設計のセンスは基本的には素晴らしいと思うけど、
非同期処理の難しさに関してはGoをもってしても効果的な解決法を見つけられなかったのは残念だな

298 ：
日本人がROKUを作るしかないん？

299 ：
わー、おもしろーい（棒

300 ：
rokuなもんにならんぞ(´・ω・｀)

301 ：
おっさんが多いスレッド

302 ：
Raku？

303 ：
golang.jpが壊れて治らないから諦めてwebarchive行くことにした

304 ：
あのサイト更新しないなら迷惑だから手放して欲しい

305 ：
golangが完全に終焉するとき
名前がgoneにかわる

306 ：
golang-jp.netみたいな日本向けドメイン取って誰かが新しいサイト作って

307 ：
アフィリエイトで広告踏みますのでよろしくおねがいします

308 ：
gone lang

309 ：
Ghosn lang

310 ：
go(rust)lang

311 ：
goとrustは目指す目的が違いすぎて、並べて書く意味がなさすぎ

312 ：
go 1.14

313 ：
ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

314 ：
1.14のissueって昨日まで20個以上残ってたと思ったけど、あれどうしたのかな

315 ：
release blocker issueは2個くらいだったし
それ以外は次バージョンに延期でしょ

316 ：
>>297
とりあえずブロックするって方向はそんなに悪くはないと思う。
あとはブロックされてリークしたgoルーチンの回収をどうするか。

317 ：
プログラミング言語人気ランキング2020、2位に「大躍進」したあの言語
https://active.nikkeibp.co.jp/atcl/act/19/00124/022700001/

318 ：
>>317
なにこのクソ統計

319 ：
「つまらないアンケートに答える層が使っている言語」の統計
FORTRANより下に主流の言語があるのがなかなか

320 ：
C/C++いまだに多いけどどういう人が投票してるんだろう
統計でデタラメな誘導するのはやめて欲しいよ

321 ：
お前らが見慣れてるような言語ランキングだって相当なバイアスがかかってるだろう
日本の実情としてはまあ納得できるランキングだと思うけどな
むしろこの面子でGoが意外と健闘してるのは驚き
C/C++が多いのは、業務システム分野では互いに競合する言語が比較的多いのに対して、組み込みや制御の分野の中では代替が事実上存在しないからだろうね

322 ：
Rubyは始まりも、オワコンなのよ
そうよ、Perlと共にお墓に向かってるの
どんなときでも時代はPHP♪
homubrewもrubyを切り捨てた現実を受け入れなさい！

323 ：
FORTRANがあるということは製造業なのかな
それも主に自動車産業

324 ：
アセンブリも多すぎ

325 ：
>>317
4位SQLてw

326 ：
まあ、職業プログラマーでSQL使わない奴なんてまず居ないだろから

327 ：
今の現場、DBが完全にDynamoDB（KvS）に移行したぞ
リレーショナルデータベース使わなくなった

328 ：
いくらサービスのOLTP系のDBがDynamoDBオンリーでも、会社なら業務系のDBとかデータ分析用のDWHとかあるしWebエンジニアでもたまにはそういうところ触ることもあるだろ?
お前の狭い業務では使わなくなった、の間違いだ

329 ：
どうでもええわｗ

330 ：
それにしても使えば使うほどクソさが見えてきて
嫌悪しかでてこない言語だなgolangは

331 ：
なんでそんなこと言うの？

332 ：
>それにしても使えば使うほどクソさが見えてきて
これはほぼどの言語にも当てはまらなくはない
>嫌悪しかでてこない言語だなgolangは
個人の主観です

333 ：
Kotlinは使えば使うほど良いなと思う
サーバーサイドもKotlinの世界になればいいのだ

334 ：
ちょっと鮮度が落ちた話だけど Let's Encrypt が幾つかの証明書を無効化する羽目に
その原因がgolangあるあるの、実体配列ループでコピーしたオブジェクト書き換えてたバグらしい
実体配列ってクソだな

335 ：
何で参照を渡していたのか不思議…
数行下では値渡しにしているのに

336 ：
>>334
大人しくpython使ってればこんなことには

337 ：
pythonのほうでも、旧アマ driveを便利に使えるようにする一番有名だった
3rd partyツールが、関数に渡す引数の扱いを間違えて別の人のファイルが
見えるようになったりしてたけどね
旧driveの容量無制限と3rd partyへのAPI解放をやめさせた遠因

338 ：
>>333
goとcとphpしかやったことないんだけど、Kotlinええの？

339 ：
>>333
Javaランタイムで動かす別言語だと思ってたが、サーバでは使えんの？
そもそもgolangスレで発言した意図がわかんない
Javaスレに行けば？

340 ：
コンテナ時代にJavaはなあ
Java系はそのエコシステムの中だけで完結するからこそ意味があるんだよ
そもそもJavaプラットフォームは十分にポータブルで、コンテナのような低レイヤの抽象化を必要としない
Javaをコンテナに閉じ込めて動かすのはJavaの全盛期を知る者としては屈辱だよ

341 ：
WSLは許せるのか

342 ：
Javaの欠点はメモリを食い過ぎること
本当にこれだけだと思う

343 ：
javaの欠点はメソッド名が長すぎ
何をするにも面倒臭い
アレとアレをつなげてコレとコレをつなげてやっとこさHellow World

344 ：
Javaとかいて邪魔と読みます。くらいに要らない子

345 ：
Java馬鹿にしてるやついるけど

if err != nil をコピペしまくる言語よりかはダサくないよ（笑）

346 ：
JavaをバカにしていいのはC#とかの直系親族かなー
でも御先祖様だから敬わないと
golangから見てそれこそカブる部分が少ないんで他所の御家庭

でもVBさんちは何とかしてほしいと思ってしまう自分を許して

347 ：
コピペって(笑)、インテリセンスとかスニペットが無い世界の人は大変だな

348 ：
Javaがバカにされるのはそれを使っているプログラマのせいじゃないかと思う。
企業需要が大きいから促成栽培のドカタが量産されたという。

純粋に言語として評価したら、CやC++の問題点をよく研究している印象なんだがな。

349 ：
ダサいと感じるかどうかは人それぞれだが
エラーハンドリングのボイラープレートが
どうしようもなく多いのは事実だよね

Go2に期待してたんだがな

350 ：
Goのやり方の是非はともかく、例外がいつどこから飛んでくるかわからない「漠然とした不安」がないのはいい
あの不安は少なからず脳の働きを阻害して生産性を下げてると思うわ

351 ：
書く量が多くなるとかそれぐらいは別にいいんだけどさぁー
どうせコピペするだけだし(笑)
最初にエラーハンドリングはそこまで要らないなと思って書いてたコード群が
後で扱うデータの仕様変更があってエラーハンドリングが必要になったときに
ガッポリその部分覆ってまとめてエラー扱うってのが一切できないんだよな
こうなってしまうと全部のコードリファクタしないといけないしなんなら
個別のロジックまで追いかけて問題ないかチェックしないといけなくなる
こういうところがgoはクソなんだよな

352 ：
> 最初にエラーハンドリングはそこまで要らないなと思って書いてたコード群が

単に見通しが甘いだけなんじゃないか

353 ：
Cでlongjump使いまくってたタイプじゃね？

354 ：
>>352
だから何？
お前が見通してくれるわけじゃないなら黙ってろよ

355 ：
顔真っ赤だぞｗ

356 ：
由緒正しい2chの流れだな

357 ：
>後で扱うデータの仕様変更があってエラーハンドリングが必要になったときに
>ガッポリその部分覆ってまとめてエラー扱うってのが一切できないんだよな

これ自体が例外ありきの発想のように思う

358 ：
Goだと極一部の簡単な関数を除けば基本的にerrを返すから、後でerr発生箇所が増えても影響は関数一つだけだろう
それが問題になるようなアホみたいに長い関数を書いてるならそれ以前の問題だな

359 ：
errorを返すように関数を変えたなら
call siteをすべて変更しなきゃいけないってのは仕方がない
それは考え方の違いだから将来的にも修正されることは無いと思われる

ただcall siteで単にエラーをpropagateするだけなのに
毎度毎度`if err != nil`書かせるのは頭悪いしノイズ比が高すぎる

開発陣も問題だと思ってるからどうにか改善しようとしてるけど
下の提案はダメになったからどんなに早くてもあと数年は現状維持だろうね
https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
https://go.googlesource.com/proposal/+/master/design/32437-try-builtin.md

360 ：
vscode で if err!=nil のブロックをデフォルトで折り畳んでくれたら、おれは嬉しい

361 ：
err返すくせに型に現れないのは正直ゴミ

362 ：
またお前か

363 ：
またお前かって初めてこのスレに書き込んだんだが
そういって一生ゴミ仕様から目を背け続けろな

364 ：
わかったよ、ゴミ

365 ：
errさんイライラwwwwwwwwwwwwwwwwww

366 ：
errさんはPHPしか触ってこなかったから気にしないんだよ

367 ：
Cだともっと酷いよ？
戻りでエラー返すと本来の戻り値が潰れるから
&errorとかいう独自定義のエラー用構造体を引数に毎回渡す
これに比べたら天国

368 ：
Goは標準ライブラリが豊富っていうけどどこらへんが豊富なの？
Goは並行処理が得意なのに並列処理が得意とか実際に触ってるわけでもないのに書く人多いから豊富ってのも嘘なんじゃないかと思ってる

369 ：
そうだよ嘘だよ。じゃね～さよなら

370 ：
>>367
GetLastError
エラーを取得するには関数を使います

371 ：
GetLastError() って Windows OS のみ？

372 ：
Cだと戻り値でデータ返したりエラーコード返したりやりたい放題で一貫性が無さすぎ
Javaとかはtry catch地獄
Cでレジスタで戻り値返さずに複数値返せる設計にしてれば標準となって皆幸福だったのに

373 ：
最近のは(小さい)構造体なら返せるやろ
デカいのは無駄だし
mallocしたのだと解放が面倒だが

374 ：
>>372
ハードウェアの構造無視しすぎ。
それでみな幸せならとっくにそうなっとるわ。
cでもスタックの使い方の規約なんて昔と相当変わってる。

375 ：
スレ違い

376 ：
>>370
Windowsの作法やん
それにグローバルなエラー情報とか論外

377 ：
>>374
ん、その昔の段階で戻り値の返し方で言語仕様的に一工夫してくれてたらという正直ムチャ振りなレスだったんだけど

378 ：
Goって複数の戻り値はスタックにおいてるのかね？
その辺どうなってるんだろう

379 ：
コンパイル時にサイズが決まるならスタックに積んで返すのは難しくないだろう。
今どきCでも構造体を返したりできるし。

380 ：
老人介護用言語すぎてストレスしかない
なんで今の御時世にこんな微妙な言語使わなければならんのだ
ポインタ意識したりするよりドメイン層の設計に時間を割いたほうがマシだわ
はぁ…

381 ：
無理して使わんでもええがな

382 ：
どの言語にも言えるけど
全ては実験台でしかない

383 ：
権限だけ持ってる考えなしの馬鹿が採用を決めたせいで無理して使うしかないんだわ
トラップ多くてその調査のせいで学習コスト跳ね上がるし
並列処理簡単って動かすだけならそりゃ簡単だろうが…ってレベルの完成度の低さで
CPUフルで使い切るような事やらせようと思ったら面倒さも管理も段違いの面倒さ…

愚痴はまぁともかく、structって脳死して全部ポインタで扱うほうがいいんけ？
というかstructに実装持たせるような意識なんて投げ捨てて旧石器時代を目指すほうが良い言語？

384 ：
あくまで関数が主体であり、structはオブジェクト指向的な実体というより、単なる文脈と考えればいい
Rustも同様の考え方だし、C#なんかも最近はそういう方向へ進みつつある
善し悪しはともかく最近の流行りではある

385 ：
>>383
基本的にはちょっと楽なCだからね
まともなC使いは第一引数にオブジェクトのポインタわたしてたし
継承も構造体使って同じことしてた
むしろC使いは理想的な言語を作ってくれた！と思ってる

386 ：
>>383
CPUフルに使いきるなら素直に別プロセスにして上位レイヤーで分散するよう工夫したほうが結局コスト安く済むような印象がある
まあWeb系じゃないならそうは行かない場合もあるんだろうけど

387 ：
ハイパースレッディング的にCPUを並列化したいならGoなんで使うものじゃないよ

388 ：
simulationライブラリで純粋な関数式プログラミングをする
ttp://x0000.net/topic.aspx?id=3631-0

UIライブラリ (C#, 2D) を作ったよ
ttp://x0000.net/topic.aspx?id=3688-0

連続と離散を統一した！
ttp://x0000.net/topic.aspx?id=3709-0

4Dエンジン
ttp://x0000.net/topic.aspx?id=3677-0

matrixのライブラリ
ttp://x0000.net/topic.aspx?id=3711-0

ある強力なFor関数
ttp://x0000.net/topic.aspx?id=3630-0

SQLライブラリ
ttp://x0000.net/topic.aspx?id=3675-0

389 ：
>>383
コア数分のgoroutineでCPU使ってくれない？なにかそんなに面倒なことあったっけ？

390 ：
golangのポインタ周りはrangeでイラっとしたくらいだわ
他はわかりやすいし使いやすい印象

391 ：
いやいや・・ポインタも構造体の実体からもアクセスがどっちも . とか
トラップすぎて草はえるわ
そりゃさだいたいは問題ないよ、だけどな大体のとこは良いけどたまーに
罠にハマるっていうパターンの問題が一番やっかいな罠になるもんなんだよ
そんな中途半端なことするぐらいならいっそハナから面倒なままにしてくれるか
あるいはしょうっちゅう問題が起きるから常に注意して書く必要がある、ぐらい
のほうがよっぽどマシ
GO言語はこの「だいたいいいけどたまに罠」がクソ多すぎてほんとクソ言語だよ

392 ：
　 /＼＿＿_／＼
／　／　　 　ヽ ::: ＼
|　（●）,　、（●）、　| 　　 ／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ 　 .:::::| 　　 ＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼

393 ：
全部ポインタにしてるわ
現代のアーキテクチャからしたら明らかに遅くなりそうだが
C脳だから全部ポインタw

394 ：
全部ポインタは無駄処理増えてパフォーマンス的に良くないようだけど
そうした方が言語トラップを回避できる可能性が高いって時点でうんこであることは間違いないと思うよ
コードをひと目見てすぐ問題があると判断できないようなトラップが散りばめられてて学習コストが低いとか嘘だわ

インポートも微妙、名前ぶつかりすぎでローカル変数名が半端になっていく
エクスポートの仕様も半端、プロパティとかないから構造体のフィールドは全開放で
扱う側に全責任が委ねられてしまうしパッケージ変数とか公開した日にゃノーガード戦法しかない
その割にリフレクションでの制限だけはクソきつくて非エクスポート関数の参照や値の変更は実質ほぼ不可能
あとエラーもうんこ
goのerrorをバケツリレーしていくような実装って、結局のところJavaでいうところの throws Exception を
全メソッドに書いちゃうようなゴミ実装をより面倒くさい記述にしただけみたいな感じ
エラーの中身が型として読み解けないせいで意識しないといけないスコープが広がりすぎるから超めんどくさい
エラー処理をせずもみ消したいときにtry/catchがいらないみたいな、死ぬほどどうでもいい利点くらいしかひねり出せない

言語の決定権がなく仕方がなく使ってるけど、全てを把握できてて自分以外が触らないような
単機能の小さいツール作るくらいの用途くらいでしか使いたくない言語って感じで、書くほどストレスが溜まっていくぜ…
これを絶賛する人たちが本当に最高だと思ってるのかマジでわからんくなる…

395 ：
今Go使ってる人はなんちゃっての人は少ないからねえ
まともにGoやってますって人の少なさよ

396 ：
はて、ポインタで無駄処理ってのは聞いたことないな
アセンブラのレベルから見ると、実体って概念は配列要素へのアクセスを先頭からの相対位置で行うという、限られた局面でしか現れないもの
あ、自動変数の実現としてスタックを積んでスタックボトムからのオフセットを使用するのは一般的ではあるか
ともかく実体渡しはCとかあの辺りの言語で実装された二次的なもので、あくまでポインタの糖衣構文じゃないの？
俺が最近のCPUを知らないからトンチンカンなのかな？
ベクタ計算がプリミティブに使われない限り、よりマシンに近い記述がポインタだと理解しているんだが

397 ：
せっかくのキャッシュなのに
キャッシュ捨てまくりが発生

398 ：
ちゃんと読んで答えてるっぽい奴居て草
今君は川に流れてるウンコを態々拾いに行ったのだ
ばっちぃから触っちゃ駄目だろ、ちゃんと反省しろよ

399 ：
>>220-221

400 ：
>>399
それが何で遅くなるのか理解して言ってるか？
ポインタが無駄な処理になるからじゃなく、メモリアクセスとメモリ管理を最適化するため
実体配列のニッチな需要があるかぎりは実体は廃止できないという意見
正直、そういう需要なんて切って捨てていいと思う
Javaみたいに

401 ：
Javaはスレッド跨ぐ場合はスレッドごとにコピーした値をキャッシュしたりはしているし
それで起きる問題を回避するための手段も用意されてる
Goがただ面倒くさいゴミ言語って話でJavaを例えに上げるのは理解してなさそうに見えちゃわない？

402 ：
だって Java thread って context switch が遅いんですもの…（仕方ないけど）

403 ：
皆んとこインフラでGo使ってないんか？
クラウドならGo一択だと思ってた

404 ：
Go製のキラーアプリであるDocker
それをRustで書き直すって話無かった？もう公開されてる？
厳密なコンテキスト操作がGoでは実装できないからって
それとも自分の勘違い？

405 ：
Dockerの記述言語なんて使う分には関係ないからキラーアプリとは違うような。

406 ：
コンプライアンスに即した範囲でできるテレワークって事で
最近「他社ゲームのアーキテクチャを調査」ってタスクをやったんだけど
Golangは無いね。Node.jsばっか
個人的にはgo使いたいから、家にいる期間になんか一個作りたいけどなぁ…。

407 ：
ゲーム会社でもコンプライアンスの関係でテレワークできない業務なんかあんの？
少なくともゲーム会社よりはお堅い会社に勤めてるけど、全部在宅で何の問題もないな
コードは主にNode.js(オンライン)とPython(バッチ)で、オンラインについてはGoへの書き直しを進めてる

408 ：
>>407
外注だからね

409 ：
JavaとかScalaで作ってたものをGoに置き換えるみたいな流れは割とある

410 ：
windowsとlinuxで動かさなきゃいけないアプリをJavaで書いてて
全く問題なかったんだけど
実質有償化に伴って他の言語で書き直そうかと思ってるけど
Goってwindows上でも安定して動くのかね？
ちなみに24時間稼働しっぱなしのアプリ

411 ：
そんな君にはC#おすすめ

412 ：
まあC#だろな

413 ：
C#ってlinux上ではmonoとか使うわけでしょ？
流石にないわー

414 ：
>>406
CATSってスマホゲーがサーバーにGoを使ってるらしい
サーバーにちょくちょくアクセスしながら動作してるんだが、めっちゃ速いよ
この辺はスピンアップが爆速な恩恵なのかも

415 ：
>>406
フロントはNodeでバックエンドがGoだと
外からじゃ調べよう無いよね？

416 ：
>>413
ひどい無知

417 ：
>>413
何言ってんのこいつ

418 ：
>>414
個人的興味でちょっと見てみるわ
>>415
そういう調査じゃなくて
スライドシェアとかの公開資料のまとめ
正直引き続き契約延長いただいてありがとうございますというレベル
この状況がまだ続くんなら、流石に家でもほんとに作業するように変わるんじゃないかと思うけどね
または切られるかだな…

419 ：
今からC#勧めるってお前ら悪い奴やな～

420 ：
今のC#知らない人多そう
特定の言語に拘らず積極的に情報収集した方がいいと思うけどね
スレチだからここまで

421 ：
今のC#センスいい言語になってると思うよ、俺も。

422 ：
たまには F# のことも思い出してあげて下さい

423 ：
だが断るっ！

424 ：
流石にJavaやScalaからGo移行とかになるとあまりの言語機能のゴミっぷりに開発者がキレそう
今までハサミつかって紙きってたのに石器渡されるようもんだわ

425 ：
　 /＼＿＿_／＼
／　／　　 　ヽ ::: ＼
|　（●）,　、（●）、　| 　　 ／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ 　 .:::::| 　　 ＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼

426 ：
この言語はCでサーバを書いているようなニッチな要求の仕事を置き換えるんだろうな

なに？そんな仕事があるわけない？
…去年回って来ちゃってたよ、そんな仕事が
ミリ秒縛り要求で数十の機器の管制をするサーバ
当時はgo知らなかったんでgccで書いた

427 ：
リアルタイム性重視なら、GCあるGoは向いてないんじゃ
その用途で置き換えるならRustになりそう

428 ：
Goは半日で理解できたがRustは無理だった

429 ：
鯖は比較的余裕有るけど、クライアント側でGCが痛い子になる事はありそう
Rustは半日では無理だなぁ～、概念は直ぐ理解出来るけど書き方に統一感無さ過ぎてキレそう<'a>&'a *ref

430 ：
Rustは人類には早すぎる

431 ：
禿しく同意

432 ：
Rustはバカ速いとか聞くから覚えたいんだけど
学習コストもバカ高いよなぁ
CとかPascalやっててJavaを始めたときの倍くらい大変な感じがする
C#はJavaを丸パクりで基本構文ができてたから、１日

433 ：
そりゃあif文for文みたいなコードだけなら1日だろうよ

434 ：
rust、利便性のためにライフタイムの省略パターンとか作ったんだろうけれど、逆にわかりづらくなってるわ。

435 ：
>>433
クラスの定義の書き方とかもだよ
Javaでない言語のクラスの書き方は、クラス定義にはメソッドの宣言を書いて、定義の外で実装するスタイルが主流だった(他の言語には無いとは言わないが非主流)
これはC++とかObjectPASCAL、そしてGoもこちらのスタイルではある
C#では、基本的にデフォルト仮想なJavaメソッドに対して、デフォルトは非仮想って程度の差(充分にでかい差ではある、ちなみにジェネリックはまだない時分)
だから、覚えるというより慣れるのに１日
SalesforceのAPECはまた面白くて構文はC#以上にJavaなのにデフォルト非仮想だったかな
よく似た兄弟すぎて、仕事とプライベートそれぞれ違う言語で書いてると混乱する

436 ：
>>435
完全にコーダーの発想だな

437 ：
>>433
ああ、そういえばCとかではエントリがmain関数だったのが、クラスになっているスタイルもJavaで覚えた
そのためC#でもほぼ同じだから、そこで引っ掛かることが無かった
そういう観点であってifとかforなどの構文じゃないよ

438 ：
>>436
笑わせるなよ
学習コストの話なんだからコーダー視点に決まってるだろ

439 ：
キチガイに触ってしまったごめんなさい

440 ：
JavaとC#では技術スタックが全然違うだろう
サーバーの構築から通信方法からフレームワーク等の選定から何から、
そういう足回りを全部すっ飛ばして全部あらかじめ他人に与えられた環境を使って
「さあ、アプリケーションコードを書いてください」ならそら大差ないだろ
俺は436じゃないが「コーダー」ってそういう意味じゃないかな

441 ：
ハゲしくスレ違い

442 ：
出だしが学習コストの話で、人格攻撃やらサーバの構築とか的外れな事を言い出してくるやら
詭弁術だけはお得意なことはよくわかりました

443 ：
ギスギスしててワロ
Goは誰でもある程度のレベルくらいまでなら使いこなせる優しい言語

444 ：
ものすごく当たり前の落とし穴に落ちた

ファクトリから構造体アドレス返してたのをインタフェース返すように変更したらテストでコケた
キャストチェックのテストだったんだけど、レシーバのシグネチャが同じ別のインタフェースがあって、そいつにキャストできちゃった

インタフェースが同じなら同じものとして使えるってことは、そういう問題を想定しとかないとならなかった

445 ：
大きくなってきたんでパッケージを分割
設定とか全体を管理するAパッケージ
httpのリクエストを管理するBパッケージ
webAPIのロジックを管理するCパッケージ
ロジックのインスタンスは設定で作って、リクエストから呼び出して処理してもらう
さて、ここで落とし穴
Cパッケージから設定を参照するためにAパッケージをインポートすると import cycle not arrowed 発生
AパッケージではCパッケージをインポートして、ロジックのファクトリを呼び出してる
インポートの循環の制約とか、それは厳しすぎやしませんかね
第三の上位パッケージを作ればなんとかなるのかなぁ？

446 ：
arrowed ?

447 ：
>>445
Goに限らずモジュール境界はインタフェースで抽象化するもんじゃ？
そうしないとユニットテストつらい

448 ：
> 設定とか全体を管理するパッケージ
インターフェース云々以前に、そんなふわっとしたモジュール強度の低いパッケージが存在することが問題
設定なら設定で分けろ
設定はデータ構造自体がインターフェイスなんだからカプセル化とか要らん

449 ：
>>445
AからC呼び出すっておかしいだろ
設計やり直せ

450 ：
>>449
ロジックのインタフェースの実体を得るファクトリ関数なんだがおかしいのか？

でも、そもそもが設定情報のパッケージにシステムを管理するデータの生成を担わせてる設計が原因臭いとはうすうす
やっぱそこを別パッケージに分離して結合を弱めないとだめだな

451 ：
結局、日和ってロジックのインスタンスはCパッケージにシングルトンとして実装してBから呼ぶことでallowedを回避した
根本的な解決ではないが、動けばいい！(うわっ自分で言ってて恥ずかしい

452 ：
VScodeなのかdelveなのか、デバッガでスライスを見たとき64個までしか見えません
どこの設定を弄れば最後まで見せてもらえるのか、調べてみたけれど分かりません
→ githubのgo-delveとかvscode-goとか
このカスタマイズについて情報があれば教えてください

453 ：
各プラットフォームのランタイムのせいだろうとは思うけど・・・
io パッケージの
func Copy(dst Writer, src Reader) (written int64, err error)
と
type Writer interface {
Write(p []byte) (n int, err error)
}
で戻り値に一貫性がない事に気づいて、ちょっとイラっときた
(io.Writer).Write() では n の合計が len(p) になるまで繰り返さないとダメ？
かと思ったけど、
Write must return a non-nil error if it returns n < len(p).
って書いてあるよ・・・

454 ：
ああっ
The built-in functions len and cap take arguments of various types and return a result of type int.
だからなのか
いいのかそんな仕様で

455 ：
Goではintのサイズと配列の最大長は環境依存だからそれで正しい
そして、CopyはWriteを一発呼ぶだけじゃなくて指定された長さをコピーし終えるまで読み書きを繰り返すように実装するもの
だから配列の最大長とか無関係
やってることが全然違うんだから一貫性もクソもない

456 ：
Rob Pike interview: “Go has become the language of cloud infrastructure”
https://evrone.com/rob-pike-interview

457 ：
>指定された長さ
ダウト
Copy見てきてください
こいつはReaderからバイトストリーム(厳密には意訳)をEOFに達するまでWriterに書き込み、その書き込みバイト数を返します
サイズなんて指定しません
Writerに書き出すソースが固定のスライスではないだけで、Writerに書き出すという目的から見ればWriteと同じでしょ
まあ違うとあえて言うなら、私とあなたは考え方が違うんでしょうね (私は「何をするか」という目的で言ったので)

458 ：
log.Logger の出力でファイル名も出させるようにして気づいたけど、ソースファイルのパスって実行ファイルの中にしっかりと記録されてる？
Loggerでファイル名を指定すると内部でruntime.Caller呼んでスタック情報拾うんだけど
ログにはソースファイルの完全パスがしっかりと出てくる
実行ファイルを別ディレクトリはにコピーして実行しても出るから、実行ファイルの置き場所を利用している訳じゃない
また、runtimeパッケージがソースファイル情報をもってる訳もないからリンカが埋め込んでるんだろうと推測
runtimeパッケージを使う使わないで、リンカが埋め込む埋め込まないを切り替えるなんて器用な真似はさせていないだろうし
だとすると、ソースファイルの情報って全て記録されているはず(stringsで実行ファイルの中を見た訳じゃないけど)
という推測
完全パスで困るのはユーザ名がしっかり出ちゃうことなんだよな
それが嫌ならユーザディレクトリで開発するなという事なのか

459 ：
みんなはGW中は嫁さんとセックスしまくりなの？
独身の俺からすると羨ましいんだけど

460 ：
嫁さんとセクロスなんて1年で飽きるぞ

461 ：
セクロスはRとしかしないな

462 ：
疲れるだけだぞ

463 ：
飽きるか？全然飽きないんだが。
嫁ともっとセクロスしたいわ。

464 ：
　　　　　　　　∧∧　　ミ　＿　ドスッ
　　　　　　　 (　 　,,)┌─┴┴─┐
　　　　　　　/　　　つ.　 終　 了 │
　　　　　～′　/´　└─┬┬─┘
　　　　　　∪ ∪　　　 　 ││　_ε３
　　　　　　　　　　　　　　 ゛゛'゛'゛

465 ：
GoのスレなんだからせめてGopherくんで抜けるかどうかの議論しろよ

466 ：
gopherくんみたいな女いるよな
目がでかくて歯並び悪いやつ　
抜ける

467 ：
常駐しつつ標準入力からのコマンドを受け付ける構成のプログラム書いてる
だけど、デバッグターミナルからの標準入力はサポートされないんだな(vscode-go/
issues/219)
VScodeの問題かと探したのにdelveの問題？

468 ：
ちなみにシグナル使えという話は横に置いといてね
os.Interruptとかのハンドリングはもう入ってる
Windowsでkillしても受け取らないんだこれが

469 ：
「プログラミング言語Go完全入門」の期間限定公開のお知らせ
https://tech.mercari.com/entry/2020/03/17/120137
PDF版もあるよ

470 ：
どうでもいい内容なんだよなーそれ

471 ：
ところどころ抜けてて口頭説明前提の作りで肝心な内容が無い資料公開されてもな

472 ：
>>469
ʕ ◔ϖ◔ʔ
ありがたや
人

473 ：
https://qiita.com/mattn/items/b7889e3c036b408ae8bd

474 ：
https://write.kogus.org/articles/S78LHt

475 ：
言語仕様より標準ライブラリのクックブック的な本が充実して欲しいかな
結局Goのソースやテストコード読まなきゃ使い方がわからないのが多過ぎるし

476 ：
>>475
みんなのGoは、flagパッケージとかの使用例が役に立った
よく言われるように初心者向けではないだろうなとも思った

477 ：
Golang逆引きレシピ（version1.14対応）
って本出してくれ
kindleで5000円までなら買う

478 ：
2.0はいつリリースされますのん？

479 ：
予定は未定

480 ：
開発陣のモチベーションはどうなんだろう。
なんかrubyと同じような臭いが。

481 ：
サーバで使われることが割と一般的なコンパイル言語（Java以外）って
Go以外になんかあったっけ

482 ：
apache は何でコンパイルされてる？

483 ：
C#
海外を含めるならWin鯖除外でも今やGoよりは多いんじゃないか

484 ：
>>482
訂正、サーバでバックエンドとして
C#かー

485 ：
C++

486 ：
Javaじゃね？って言葉を無視するのであれば、Scalaは聞いたことある。

487 ：
コンパイル言語で伸びそうなのはKotlin

488 ：
javaがinnullable化すればいいんだ
いつ達成されるのか

489 ：
凄いスレ違い

490 ：
Goは学習コストが少ないっていう嘘に騙されてるやつとそう信じてる信者が多いのが最大の失敗
コード読むだけじゃ見落とすような罠が簡単につくれるし直感的に分かりづらい仕様と機能不足が多すぎる
書き捨てるだけなら簡単だがチーム開発で採用するには残念すぎる言語

491 ：
　 /＼＿＿_／＼
／　／　　 　ヽ ::: ＼
|　（●）,　、（●）、　| 　　 ／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ 　 .:::::| 　　 ＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼

492 ：
見えない罠が多すぎる言語よりは数段マシなんだよな

493 ：
>>447
ものすごく遅い話なんだけど
そっかー、インタフェース定義とファクトリの実装が同じパッケージにある必然性って全くなかったんだな
io.Reader の実装が到るところにあるように、定義と実装を分離させれば済む話だった

あーでもない、こーでもない
いつの間にかそうリファクタリングしていて、アレ？となった

494 ：
>>490
他と比べたら、って話でしょ

495 ：
>>493
ていうかinterfaceを返すファクトリというもの自体があまりGo的ではない
その辺は思想がJavaなんかと大きく違うところで、Goでは戻り値には具象型を使うのが基本
interfaceは関数の引数に使うもんで、その関数を使う側のパッケージが必要に応じてinterfaceを実装するんだよ
それに従えば結果的にファクトリとinterface定義は別パッケージになる

496 ：
>>495
あ、脊椎で反射的に反論しそうになったけど指摘されてみると全くその通りだね
ファクトリからインタフェースを返すのは悪手だわこれ

497 ：
1.12 の http/request.go に、でっかい落とし穴が
こいつは、1210 行目で ContextType == "multipart/form-data" の処理が未実装
そして、 Chrome は FormData オブジェクトを XMLHttpRequest で send() すると問題のマルチパートで送りつける
よって、FormData は使えない……
他のブラウザだとどうなんだろ？困るな

498 ：
xmlHttpRequest.setRequestHeader( 'Content-Type', 'application/x-www-form-urlencoded' );
じゃダメなん？

499 ：
うーん、コード追ってみたら未実装は間違いでParseMultipartFormを使うらしいけど、わけわかんない
単純にParseFormを置き換えたら、エラーかえしやんの

500 ：
>>498
いや、ブラウザ側の話じゃないから
ブラウザがどんな方法で送ってきても受けられなきゃ駄目でしょ

501 ：
普通、ParseForm が判定して取り込むよね
なんで分離してんの？

502 ：
エラーが起こる第一原因判明
ヘッダにContent-Typeが無いリクエストでParseMultipartFormすると、パースを打ち切るのではなくてエラーを返す
ショボい作りだ

503 ：
request.go の中身を初めて見たけど、エラー処理は雑だし残念すぎるなコレ

504 ：
request.MultipartReader() の方を使ってみたら

505 ：
>>504
ParseMultipartForm 使って、エラーが出ても無視することにした
Content-Type 無いようなリクエストでForm読まないから

506 ：
マルチパートって、要は多段formだっけ

507 ：
なのかな？よく知らない
でも、WebAPIでFormとしてデータを受けるときはParseFormの使用が罠なのは確実
それともbodyを自分で解析するのが定石だったりする？

508 ：
>>502
＞ヘッダにContent-Typeが無いリクエストでParseMultipartFormすると、パースを打ち切るのではなくてエラーを返す
これは正常な処理だよ
Context-Typeが"multipart/form-data" の場合
Context-Type のmultipart/form-dataの後に続くboundaryをキーにしてmultipartをパースするんだから
ParseMultipartFormがContext-Typeからパースに必要なboundaryを取得できなくてエラーになるのはいたって正常なことだよ

509 ：
>>508の補足
Content-Typeが無かったらboundaryが取得できないのにParseMultipartFormでパースしようとするからエラーを返す

510 ：
「この中にformがいっぱい入ってますよ」っていうformなんだよね

511 ：
ヘッダーのContext-Typeで分岐して適切なParseなにがしを呼べってことです。

512 ：
>>511
何のメリットがあって呼ぶ方が判定しなければならないのか、教えてください

513 ：
駄々こねてるようにしか見えんぞ

514 ：
う～ん、Context-Type が指定されていないのに multipart を自動判別して
くれるライブラリとかフレームワークって他所の言語にあったりするのかな…？

515 ：
自動的に判定して分岐できるんだったら、それをライブラリがしないというのは手抜きだろ、と言っている
しかし、例えば文字コードの自動判定ではSJISとUTF-8のどちらでも有効であるマルチバイト文字が存在する
例)"【D"と"縲識"はどちらも E3 80 90 44
このようなケースがある課題では自動処理できないので、ライブラリの外側で何かしらの対応をしてやる必要がある
マルチパートFormという課題でも同じように呼ぶ方が対処してやらなければならない問題があるのだろうと思った
だから、その問題について教えてくださいと書いたんだ
駄々ではないと思うんだが間違っているか？

516 ：
505で書いたように、一見問題がないような対処はできるけど(自分でも手抜きとはわかってる)、問題点の実体が見えてないと対処に漏れが無いという確証が持てないから

517 ：
MIME Type
MIME Encoding

518 ：
それはバウンダリの中身に、
Content-disposition: attachment; filename="xxxxx"
Content-Type: text/plain
なんかが書いてあるからできる動作であって、実はバウンダリの中身はかなり自由。
マルチパートの中にさらにマルチパートを入れるマトリョーシカのようなことをしてもかまわん。仕様上は。
これをきれいに自動でデシリアライズするのは結構難しいと思うけど。
そういう意味では、呼ぶ側が解釈を与えないといかんって割り切りは間違っちゃないんじゃないか？
他のコンパイル言語でどう対応してるのか気になるな。

519 ：
仕事でAWSのAPI Gatewayって機能使った時に
マルチパートフォームデータだけは解釈してくれなかった
クラウドサービスの都合上外部のライブラリ入れるにはソースに同梱するしか無く、
それは嫌だったからバックエンドのLambda（goに対応しているけど仕事で使ったのは非go）で
自前でバウンダリのfrom-toを切り取った上でガン無視してリクエストbodyを拾うだけの処理を書いた記憶があるｗ
完全にスレチだけど

520 ：
>>515
だってContent-Typeに現れるのはその2種類だけとは限らないから全部ライブラリ任せにはできんだろ。

521 ：
ParseMultipartFormの説明で、必要に応じてParseFormを呼び出しますと書いてるのに、
ヘッダにContent-Typeが無ければエラーとするというParseFormにはない条件を入れてしまっているのがおかしいポイントだと思うんだけど

maxMemory引数はデフォルト値を中に持って、オプションとして変更できるようにするのが、こういったライブラリの定石だから(ソケットのタイムアウト時間設定とか)、これは問題点じゃない
いや引数の設計上の問題点だけど

522 ：
>>520
それが、parsePostForm関数ではその二種類しかハンドリングしてないんだよなぁ
ブラウザ側でとんでもない(サーバで汎用的な方法で解析できない)フォームデータを送るならブラウザの問題だろう

FormDataオブジェクトを使うと発生するContent-Typeくらい自動で処理しないライブラリってどうなの？

523 ：
request.parsePostForm() は Content-Type が無ければ application/octet-stream と見なす様だ

func parsePostForm(r *Request) (vs url.Values, err error) {
:

ct := r.Header.Get("Content-Type")
// RFC 7231, section 3.1.1.5 - empty type
// MAY be treated as application/octet-stream
if ct == "" {
ct = "application/octet-stream"
}
ct, _, err = mime.ParseMediaType(ct)
:

524 ：
RFC 7231 HTTP/1.1: Semantics and Content（日本語訳）
https://triple-underscore.github.io/RFC7231-ja.html#section-3.1.1.5
> 実施においては、リソースの所有者は、[生成元サーバが[所与の表現用
> に正しい Content-Type を供する]ように、常に適正に環境設定されてい
> る]とは限らないため、クライアントには、[ペイロードの内容を精査し
> て、指定された型を上書きする]ものもある【例:MIME sniffing】。その
> ようにするクライアントは、不正な結論を導くリスクを負い、追加のセ
> キュリティリスクを公開し得る(例:"特権拡大")。更には、送信者の意図
> をデータ形式を精査して決定するのは、不可能である: 多くのデータ形
> 式は、処理の意味論においてのみ相違するような、複数の MIME 型に合
> 致する。実装者には、そのような "内容 sniff 法" を利用するときは、
> それを不能化する手段を供することが奨励される。

525 ：
>>523
それバージョンいくつ？
1.12だとmultipartReaderでct==""だとエラーを叩き返すんだ
ということは1.12でのバグなのかな？

526 ：
>>525
GitHub リポジトリの develop branch から引っ張ってビルドしたもの
$ go version
go version devel +810c27e9be Wed May 13 11:59:26 2020 +0000

527 ：
あ、それ違う

それはParseForm(1180行あたり)から呼ばれる奴だ
つまりマルチパート非対応

ParseMultipartForm(1294行あたり)から呼ばれるmultipartReader(480行あたり)ではContent-Typeが無いと、やっぱりエラーを叩き返してる

528 ：
つまり現状でも
マルチパート非対応のParseFormでは、ctが無くてもOK
マルチパート対応のParseMultipartFormでは、ctが無ければエラー
という差異が存在している

529 ：
ParseFormだとURLにフォームくっ付けてContent-Typeがないリクエストを想定してるけど
ParseMultipartFormだと、そういう形式のリクエストは認めていないという違いになって現れる

530 ：
意図的にContent-Typeのないような感じのフォームデータは許さないサーバを書いてるから、エラーチェックしないという対応だけでも問題なさそう

531 ：
>>530
content-typeがない場合
Request.Bodyの内容からapplication/x-www-form-urlencodedやmultipart/form-dataなどのデータ形式（content-type相当）を判断する必要がる。
multipart/form-dataに限ってはboundaryをRequest.Body内容から見つけ出す必要がある。
（keyValueを取得するにもboundaryが必要。）
で、ここで問題なのがRequest.BodyはSTDINからの入力でseekが出来ないのでデータ形式判定後に再度Request.Bodyを読み込むために何らかの方法でRequest.Bodyをキャッシュする必要が出てくる。
（multipart/form-dataはファイルもアップロード出来るのでメモリ上でのキャッシュには向かない）
それとhttp.Serverは常駐プロセスになるので、無駄なリソースを使って自動判別して自動でパースするよりcontent-typeで分岐してパースする方が合理的。

532 ：
>>531
としても、ParseForm内で分岐させない理由にはなってないと思っちゃうんだけど、それについては？
分岐させないのは意図的だとして、その理由が引っ掛かる

533 ：
最終的に
func (i *rInst) ParseForm() error {
v := i.request.Header.Get("Content-Type")
if v == "" {
return i.request.ParseForm()
} else {
return i.request.ParseMultipartForm(100 * 1024)
}
}
とすることにした

534 ：
>>532
> としても、ParseForm内で分岐させない理由にはなってないと思っちゃうんだけど、それについては？

そもそもParseFormがリクエストのパース処理を包括したラッパー関数だと何処で勘違いしたの？

なぜそこまで頑なにRequest-MethodとContent-Typeの値で分岐しようとしないの？
（Content-Typeの値の有無だけ確認して分岐したって言うのは無しよ）

>>533のあなたの最終的な実装を見るとあなたはContent-TypeとParseFormとParseMultipartFormを理解して使って無いの、何となく動くからってやっつけで実装したようにしか見えないの。

535 ：
>>533
あなたの最終的な実装を元にして実装するならこんな感じかな（勝ってに拡張しちゃってるけど）
func (i *rInst) ParseForm() error {
var err error
r := i.request
ct := r.Header.Get("Content-Type")
ct, _, err = mime.ParseMediaType(ct)
if err == nil {
switch ct {
case "multipart/form-data":
if r.Method == "POST" {
err = r.ParseMultipartForm(100 * 1024)
} else {
err = errors.New(“invalid request”)
}
case “application/json”:
d := json.NewDecoder(r.Body)
// i.Json = make(map[string]interface{})
i.Json = &BindStructure{}
err = d.Decode(&i.Json)
default:
err = r.ParseForm()
}
}
return err
}

まぁ、頑張って。

536 ：
>>534
>>516

537 ：
> i.Json = &BindStructure{}
の部分は
i.Json = BindStructure{}
の間違えでした。

538 ：
>>535
application/json ってFormを送るブラウザがあるのか？
bodyをjsonとして送ってくるんだな

539 ：
寝ぼけてるぽい、もう一回上げ直し
>>533
あなたの最終的な実装を元にして実装するならこんな感じかな（勝ってに拡張しちゃってるけど）
func (i *rInst) ParseForm() error {
var err error
r := i.request
ct := r.Header.Get("Content-Type")
ct, _, err = mime.ParseMediaType(ct)
if err == nil {
switch ct {
case "multipart/form-data":
if r.Method == "POST" {
err = r.ParseMultipartForm(100 * 1024)
} else {
err = errors.New(“invalid request”)
}
case “application/json”:
d := json.NewDecoder(r.Body)
// i.Json = make(map[string]interface{})
// err = d.Decode(&i.Json)
i.Json = &BindStructure{}
err = d.Decode(i.Json)
default:
err = r.ParseForm()
}
}
return err
}

540 ：
>>535
あ、REST-APIでよく使われる形式なのか
そういうForm使わない呼び出しはサポートしないんで割愛

POST以外のAPIアクセスは事前に拒絶してるから割愛

現状でも問題ないな(手抜き)

541 ：
>>540
いや違う
mime.ParseMultimediaTypeは呼んだ方がいい？
呼んだ方がいいから書いてくれてるんだろうな
追加しておきます
ありがとう

542 ：
スレチになるのでちょっとだけ。
ブラウザが送るって言う解釈とはちょっと違うけどjavascriptで
fetch(url, {
method: 'POST',
headers:{"Content-Type": "application/json"},
body: JSON.stringify(data)
}).then(res => res.json()).then(function(resp) {
// ...
})
みたいにapplication/jsonでリクエストできます。

543 ：
>>539
まって、Content-Typeが無いと mime: no media type になる気がするんだが(コード見ただけだけど)
Context-Type が無かったらParseFormの出番だと思う

544 ：
>>541
> mime.ParseMultimediaTypeは呼んだ方がいい？

// ct に「;」がある場合に「;」より前を取得してるだけなので
// mime.ParseMultimediaType使わずにこれでもいい
if pos := strings.Index(ct. “;”); pos != -1 {
ct = ct[:pos]
}

545 ：
>>542
うん、でもそこはAPIの仕様だから
汎用的なForm解析ならば必要だけど、自分のAPIだと割愛してよいってだけの話

546 ：
> まって、Content-Typeが無いと mime: no media type になる気がするんだが(コード見ただけだけど)

ごめんこっちに置き換えてw
if pos := strings.Index(ct. “;”); pos != -1 {
ct = ct[:pos]
}
iphoneで書いてるからちょっと適当になりましたw

547 ：
func (i *rInst) ParseForm() error {
var err error
r := i.request
ct := r.Header.Get("Content-Type")
if pos := strings.Index(ct. “;”); pos != -1 {
ct = ct[:pos]
}
switch ct {
case "multipart/form-data":
if r.Method == "POST" {
err = r.ParseMultipartForm(100 * 1024)
} else {
err = errors.New(“invalid request”)
}
case “application/json”:
d := json.NewDecoder(r.Body)
// i.Json = make(map[string]interface{})
// err = d.Decode(&i.Json)
i.Json = &BindStructure{}
err = d.Decode(i.Json)
default:
err = r.ParseForm()
}
return err
}

548 ：
現時点で
// SetParseMemory は ParseMultipartForm で指定するメモリサイズを変更します。
func (i *rInst) SetParseMemory(size int64) {
i.size = size
}
// ParseForm() error
func (i *rInst) ParseForm() error {
v := i.request.Header.Get("Content-Type")
if v == "" {
return i.request.ParseForm()
} else {
if pos := strings.Index(v, ";"); pos != -1 {
v = v[:pos]
}
if v == "multipart/form-data" {
return i.request.ParseMultipartForm(i.size)
} else {
return i.request.ParseForm()
}
}
}
とした

549 ：
あ、これでいいのか
// ParseForm() error
func (i *rInst) ParseForm() error {
v := i.request.Header.Get("Content-Type")
if pos := strings.Index(v, ";"); pos != -1 {
v = v[:pos]
}
if v == "multipart/form-data" {
return i.request.ParseMultipartForm(i.size)
} else {
return i.request.ParseForm()
}
}

550 ：
>>545
＞うん、でもそこはAPIの仕様だから
＞汎用的なForm解析ならば必要だけど、自分のAPIだと割愛してよいってだけの話
わかりました。
サンプルがちょっとグダグダになってこめんなさいw
とりあえす頑張ってください。

551 ：
>>549
それでもいいです。

552 ：
結局、application/json のために ParseForm から ParseMultipartForm を追い出してる？
やっぱり自分的には納得いかない

553 ：
archive/zip パッケージの仕様なのか、zip 自体の仕様なのかわからんけど
まーた穴に嵌まった
zip内のトップディレクトリにファイルがある
file1.txt
sub/file2.txt
という構成だったときには
sub/
というzipエントリもReadCloser.File配列に入ってくるのに
トップにファイルがなくて
sub/file2.txt
というように、サブディレクトリ以下にしかファイルが無かったときには
sub/
が入ってきてない(もしくは入らないzipがある)
orz

554 ：
package main
import (
"archive/zip"
"fmt"
)
func main() {
list("jquery-ui-1.12.1.zip")
list("ant-1.10.7-javadoc.jar")
}
func list(name string) {
fmt.Println("----- " + name)
if f, err := zip.OpenReader(name); err == nil {
defer f.Close()
for _, fi := range f.File {
fmt.Println(fi.Name)
}
}
}

555 ：
実行例

----- jquery-ui-1.12.1.zip
jquery-ui-1.12.1/jquery-ui.theme.css
・・・

----- ant-1.10.7-javadoc.jar
META-INF/
・・・

556 ：
Go最近始めたんだけど[]stringって型の書き方が違和感すぎるんだけど理由ってあるの？
他にこの配列の型導入してる言語もしりたい

557 ：
想像に過ぎないんだけど、
[]が後置だとmapも
map[keyType]valueTypeはvalueType[keyType]mapとなるはず
そしてmapをvalueとして持つmap
map[keyType]map[keyType]valueTypeはvalueType[keyType]map[keyType]map
なんか見辛いような、そうでもないような

そもそもmapって、なんで付けなきゃならないんだろ？
keyType付いてたら文脈で分かりそう
連想配列って元からそうだよな

558 ：
>>553
zip自体の仕様みたい
仕方ないからサブディレクトリのファイルが出てきたときに、省略されたディレクトリのエントリもあった事にしてモデルに登録した

559 ：
サーバで http.ResponseWriter への書き込みが WSAECONNABORTED (10053) でエラーになっているとき
http.server.go#1905 で return してるため、1907のc.setState で StateIdle がセットされない
そのため、http.Server の ConnState ハンドラでコネクション数を勘定してると数が合わなくなる
という罠に嵌まった
どうしよう……エラーを検知した時に勘定している数をデクリメントするか？
だって、 return の判定で使われてる shouldReuseConnection って隠蔽されてるから

560 ：
罠にハマりっぱなしだな

561 ：
テストでの罠検出には定評のある人材だから
すごかろう(やけくそ)

562 ：
>>556
英語と同じ語順にした
array of string => []string
Cの場合それを使う構文と宣言を同じにしたせいで
ややこしくなったし
その反面教師だと思う
Cだと使う時も宣言もstring[]なんだよね

563 ：
そもそも、問題のレスポンスでは20MBくらいのmpgファイルがリクエストされてるんだけど
こういったデカイ応答を返す場合って自分が知らない注意点がある？
Content-Length はファイルサイズ(21614145)
Content-Type は application/octet-stream
で送ってる
ブラウザでは動画はちゃんと出てる

564 ：
ブラウザ側では数十msで受信してるから、タイムアウトじゃない

565 ：
う、もしかすると送信するストリームが Content-Length よりも長いという可能性もあるのか
それでブラウザ側から終わった！と切断されてる可能性
面倒極まりないな

566 ：
深く考えずに
レスポンスの書き込みに失敗したらコネクション数をデクリメントする
ことにした
コネクション数が0になるまではWaitGroup.Waitで待ってる作りにしてたんで

567 ：
普通は適当なサイズに分けてチャンクで送る

568 ：
>>567
ResponseWriter の実体って、 chunkWriter ってstruct だから自動的にチャンクで送られるんじゃないの？

569 ：
>>567
うわ、Headerでなんか設定しないと駄目なのか

570 ：
>>567
うーん、HTTP1.1だとTransfer-Encodingにidentityを指定していない場合は強制的にchunkで送られるんじゃないか疑惑
Content-Length不要のお知らせ？

571 ：
>>567
ブラウザでヘッダ見れた
チャンクになってないっぽい
調べてみる
ありがとう

572 ：
一貫してオレの都合よく動くようにできてないと騒いでるだけだな

573 ：
呼び出し順序に則って作らなければ動かないフレームワークってのは
屑って言うんじゃないの？

574 ：
いや、呼び出し順序に従わない場合はエラーにする
ならば仕方ないよそりゃ
OpenしないでReadできないのはおかしい、とか言わないから

575 ：
明記しない制約は常識とは言わないから

576 ：
>>567
Content-Length不要…以前の、設定しなけりゃチャンク送信！
orz
ちなみに、レスポンス書き込みがエラーになるブラウザはChromeとEdge
Firefoxだとエラーにならないのは何故だろう

577 ：
むしろエラーにしてほしい
変な俺様拡張がまかり通ると
そっちに甘えてそれが当たり前になって
文化や規約を企業に乗っ取られてしまう

578 ：
458 に関係しての罠

プロジェクトをユーザ名とは関係しないディレクトリに置いても、まだ駄目だった
C:/Users/ユーザ名/go/pkg/mod/golang.org/x/text@v0.3.2/encoding/japanese/all.go
というように go get したパッケージの置き場から、ユーザ名は露呈する

嫌ならば GOPATH はユーザディレクトリの下に置いてはいけない

579 ：
そりゃ当たり前で気がつかないのがウカツだった…
参照してるパッケージだってコンパイルされるんだもんなぁ

580 ：
雑誌でGoはC++を嫌ったGoogleの技術者が作ったって書かれてたんだけどそうなの？
色んな情報見てきて初めて見たんだけど

581 ：
コンパイルの遅さに嫌気が差したってのは見たこと有るな、尚ソースは無い

582 ：
C++を嫌った技術者が作ったというのは曲解だと思うけど、
1. C++プログラマーだった人たちが新しい言語の研究プロジェクトを始めた
2. 新しい言語を作るにあたってC++のダメな点を洗い出す -> 結果としてC++嫌いになったｗ
という、特に驚くこともない話(C++のダメなところはそこらじゅうに既出ですし)

過去のインタビューでも出てた話だし、カンファレンスでもネタにされてた
https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html
https://www.drdobbs.com/open-source/interview-with-ken-thompson/229502480

583 ：
目的と合ってないから、目的を絞り混んで作った、いわゆるドメイン固有言語って認識
言語は問題解決に向いてる向いてないはあっても、良い悪いってのはそんなに無いよねという持論

584 ：
同意しない
Goが絞り込んでいるのは用途ではなく開発スタイル

585 ：
Go は、Ruby を極端にした感じ

継承より委譲。
継承を無くして、Duck Typing だけにした！

Ruby on Rails をやったら、やっぱり継承・抽象クラスがあると便利！
フレームワークには必要

586 ：
>>585
>>73

587 ：
問題解決力だけで言うとGoが一番高いの？
個人的にはフロントのネイティブ実装を強制されるって意味も含めてJSか、ライブラリの豊富さでPythonとかだと個人的に思うけど

588 ：
場合による

589 ：
pythonってそこまで書きやすいとは思わないなあ
インターフェースがないから
どのオブジェクトが何を実装してるのかわからない
やはりインターフェースは偉大

590 ：
Goはクラウドネイティブ開発に習熟してるがオーバークォリティなことをやりがちな奴が多い
JSは大半はゴミ、たまに凄いのもいる
Pythonは全体的に高学歴で頭良いけど動きゃいいって感じの奴が多い
どんな人間が欲しいか次第じゃないかな

591 ：
pythonは
import Hoge
したら
help(Hoge)
a = Hoge.hoge()
だったら
help(a)

592 ：
場合つまり解決しようという問題による
問題解決能力って何よという話
グラフィカルでない
非同期処理が効果的
ならば少ない労力で実装できるという強みが売りかな
労力に関しては仕様が一頁で網羅できるGoの学習コストの低さが大きい
PythonだとCの知識前提で使うCythonでないとGoには太刀打ちできないというQuiita記事もある
総合力ではPythonの圧勝だろうけど、限定された問題ってのはそういうもの

593 ：
>>590
オーバークォリティか……耳に痛すぎる指摘だ

594 ：
用途によるとしか言いようがない気がする。
どれも銀の弾丸にはならんよ。

595 ：
銀の弾丸は狼男(もしくは悪魔)を倒すという用途に特化されてるんですが・・

596 ：
ブルックスの論文を知ってて言ってたら申し訳ないんだが、ソフトウエアプロジェクトと言うものに対する銀の弾丸は無いって話だよ。

597 ：
オーバークォリティなことをやりがちな奴が多い
ってのは質が良いプロダクトを作るのには向いてないってこと？

598 ：
>>597
いま必要な事以上の事をやりたがってプロジェクトの進捗が遅れるってことだよ。
カップラーメン作りゃ十分なのにスープの出汁とるのに豚骨2日近く煮たり、麺を手打ちし始めるような奴。

599 ：
単体テストやってたら過剰品質だと怒られたんだよな○KI電気SI

600 ：
過ぎたるは猶及ばざるが如し

601 ：
>>599
カバレッジ100%とかを目標にしてたんなら過剰品質だと言われてもしかたがない

602 ：
Web関連の自動化でselenium使いたくて、
Pythonでいいかってなったとこはある。

603 ：
自動テストのコストは成果物を運用しながら継続的に改良していく中でペイしていくもので、SIなら突貫で作って一発動いたらあとは納品して終わりなんだから自動テストは実際要らんわ
Goで書くようなものなんて複雑怪奇な業務ロジックとかじゃなくシンプルな小物だろうし

604 ：
そんな会社まだ生き残ってんだ

605 ：
特に一部上場に多い感触

606 ：
>>592
Qiitaの記事欲しい

てかPython触るぐらいなら機械学習分野もGoに入れ替わってほしいわ
PythonのC/C++バックエンドよりは多少遅くなるけど、クラウドの相性のよさとかライブラリの質考えたらGoのほうがいい(Numpyとかpandasとかはまた別だけど)

自動テストってどのテストを指してるのか分からないけど、テスト書かないのは後戻りできない負債になるよ

607 ：
>>606
https://qiita.com/shimakaze_soft/items/8a493f230eabafe45209

608 ：
事情通に聞いてみたのよ
なんで自動テストしないのか、って
それ始めちゃうと、なんで今までやらなかったのか、そう言われて困るお偉いさんが山ほどいるから、だとさ

609 ：
自社サービスとSIじゃビジネスモデルが全然違うんだから開発手法も違って当たり前
(俺は必ずしもそうだとは思わないが)仮に自動テストによってSIにおいても大幅な工数削減が可能だとして、それに何の意味がある？売上が減るだけじゃないか
お偉いさんの面子だのと人に鬱憤を押しつける悪い癖を自覚し、自分とその周囲の状況、そして問題の本質を正しく理解しよう

610 ：
ﾌｰﾝ

611 ：
ＮＧワード：本質

612 ：
Go は名前がダサい

以上

613 ：
検索で困るもんな

614 ：
C の立場も慮って下さい

615 ：
はじめての C
まぁいやらしい

という定番ネタのあるひとは黙っててください
D 言語は泣いていい

616 ：
構造体の初期化で省略されたフィールドを既定値で初期化する方法を考えてたんだけど、こんなやり方でも構造体を初期化できるんだな（アンチパターンって言われそうだけど）
type Logger struct {
_ struct{}
mutex *sync.Mutex
Prefix string
Writer io.Writer
}
func (l Logger) New() *Logger {
l.mutex = &sync.Mutex{}
if l.Writer == nil {
l.Writer = os.Stdout
}
return &l
}
func main() {
l1 := Logger{}.New()
l2 := Logger{Prefix: "Looger: "}.New()
}

617 ：
https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=composite
webフレームワークのベンチマーク比較
1位にC#の新FW「dragon」ってのが入って話題になってた
これechoが入ってないのが気になるんだけど
流石にdjangoとかに負けると思えんし
どうなってんのこれ

618 ：
drogonな
しかもC++じゃなね？
ttps://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks/C%2B%2B/drogon

619 ：
はい。諸々すみませんでした(´・ω・｀)

echoはなんかあったのかな
使ってるからゴタゴタとかちょっと気になる
iris？だっけ？（うろ覚え）goは前にも消滅したFWあったし

620 ：
aspnetcoreって結構速かったんだな

621 ：
ginはいるね

622 ：
>>620
汎用フレームワークでここまでパフォーマンスいいのはすごいよね

623 ：
MSはaspnetcoreのベンチマークにTechEmpowerを使ってることを公言してるんで眉唾
オーバーフィッティングの可能性がある

624 ：
>>623
ふーん具体的には？

625 ：
具体的にも何も
MSがTechEmpowerのシナリオをaspnetcoreのベンチマークとして使っているのは事実だし、TechEmpowerに対してAzureのクレジットの提供までしてる
https://github.com/aspnet/Benchmarks
https://www.techempower.com/blog/2016/11/
癒着とかズルとかそういうことじゃなくて、ソフトウェアが特定のベンチマークのシナリオに対して過剰に最適化されるというのはよくある話でしょ

626 ：
ケチつけたい人は口だけならなんとでも言えるからね

627 ：
信じる者は救われる

628 ：
学習に使ったのと同じ入力で評価してるわけだからまさにオーバーフィッティングだね
論理的に公平になり得ない
まあ他の上位陣も一緒なんだろうけど

629 ：
お気に入りのフレームワークの順位が低くて悔しい人たち

630 ：
>>607 での Cython との比較でも、Go 側が「並列化してない」という批判がコメントに寄せられてるけど訂正されてないんだよな
つまり足を縛って比較して Python 負けてないよ！と主張している記事

631 ：
qiitaのは、あそこのあるあるで理解しないで書いてるだけだ
意図して縛ってるんじゃなくて、わかってないだけ

632 ：
セットアップとかPythonで書かれてたりすることが多くて、在宅学習でセミナー受講したりしはじめてる

スライスってPythonとかが由来なんだな
でもar[-1]とか、そんなの要るの？という書き方が多いな
覚えるのﾒﾝﾄﾞｸｻ

633 ：
>>632
正直、Go脳と罵られても仕方ないw

634 ：
なぜかVScodeで保存しようとすると、go listが大暴走して動かないようになってしまった
リファクタリング中でぐちゃぐちゃな状態だから臭いけど

635 ：
スクリプト言語としてのGo
https://www.infoq.com/jp/news/2020/06/go-scripting-language/?itm_source=infoq&itm_medium=popular_widget&itm_campaign=popular_content_list&itm_content=

636 ：
無駄に長いURLに意味はあるのか？
https://www.infoq.com/jp/news/2020/06/go-scripting-language/

637 ：
TypeScriptがあるから要らんすね

638 ：
JavaでdirectXやるにはCじゃ無くてGoって聞いて来たんだけどホント？
何から始めたら良い？

639 ：
アホか
お前が自分で言っただけだろ

https://mevius.2ch.sc/test/read.cgi/tech/1586142285/796
796 デフォルトの名無しさん sage 2020/06/12(金) 15:39:27.21ID:6Yfh5mGy(1)
証拠は俺、天下無双さん
他のスレでJavaでdirectXするにはC覚えろみたいに言われたんだけどGOやったら出来る？

640 ：
>>639
ほかスレで案内されたから

【C++】 DirectX初心者質問ｽﾚ Part41 【C】

http://itest.2ch.sc/mevius/test/read.cgi/tech/1521786252/505

0505 デフォルトの名無しさん 2020/06/12 15:46:34

続きはGoスレ

641 ：2020/06/13
その最後の行は
「続きはGoスレへGo!」にするべきだった

次世代言語11[Rust Swift TypeScript Dart]
Visual Studio 2019
ふらっと C#,C♯,C＃（初心者用） Part139
GCは失敗。メモリは自分で管理せよ！ その2
くだすれPython(超初心者用) その43【Ruby禁止】
【最強CUI】PowerShell -Part 2
フリーソフトなどに使われる言語は？
Visual Studio 2019 Part2
推薦図書/必読書のためのスレッド 83
Visual Studio Code / VSCode Part6
--------------------
【画像】キモオタ達でホーム画面見せ合おうぜ
林遣都 40
【Cupitron】キュピトロンを語るスレPart.6
不良は無期停学にするべき
富士重工 スバル73 期間工 プロパー 全員集合
【DOA6】デッドオアアライブ6 配信者スレ part2
=Ⅴ= VAN HALEN =Ⅴ=
男は性欲猿だから女は恋愛するな
ミスチルのHANABIって神曲だね(*´∀｀)
勘違いナルシストレイヤーKryu
【鉄血のオルフェンズ】トド・ミルコネンのおっさん
【滋賀】比良山系 12【武奈ヶ岳】
◆東京のカレー屋について語るスレ12
ユニコーンが最強であることが完全証明された件
【悲報】 女さん 「食事のオーダーで私が『AとB食べたい』と言ったら『了解。AとB、あとCとD下さい』と言う人が苦手。何が嫌かわかる？」
【それでも】100切り 83ホール目【楽しい】
☆決め手のみりん【味醂】と料理酒☆
ＢＣＧワクチン臨床試験へ＝新型コロナに効果か?豪研究所
Ruby 初心者スレッド Part 65
まさに、今何聴いてんの？15曲目
TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼