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/

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

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

ショボい作りだ

**デフォルトの名無しさん** · 2020/05/16(土) 13:05:20.47

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

**デフォルトの名無しさん** · 2020/05/16(土) 13:11:02.15

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

**デフォルトの名無しさん** · 2020/05/16(土) 13:14:14.23

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

**デフォルトの名無しさん** · 2020/05/16(土) 14:52:00.85

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

**デフォルトの名無しさん** · 2020/05/16(土) 14:59:51.10

なのかな？よく知らない

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

**デフォルトの名無しさん** · 2020/05/16(土) 15:12:59.98

>>502
＞ヘッダにContent-Typeが無いリクエストでParseMultipartFormすると、パースを打ち切るのではなくてエラーを返す

これは正常な処理だよ
Context-Typeが"multipart/form-data" の場合
Context-Type のmultipart/form-dataの後に続くboundaryをキーにしてmultipartをパースするんだから
ParseMultipartFormがContext-Typeからパースに必要なboundaryを取得できなくてエラーになるのはいたって正常なことだよ

**デフォルトの名無しさん** · 2020/05/16(土) 15:26:41.59

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

**デフォルトの名無しさん** · 2020/05/16(土) 15:30:06.54

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

**デフォルトの名無しさん** · 2020/05/16(土) 15:43:30.65

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

**デフォルトの名無しさん** · 2020/05/16(土) 16:52:50.26

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

**デフォルトの名無しさん** · 2020/05/16(土) 17:00:10.79

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

**デフォルトの名無しさん** · 2020/05/16(土) 17:24:44.07

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

**デフォルトの名無しさん** · 2020/05/16(土) 17:34:03.50

自動的に判定して分岐できるんだったら、それをライブラリがしないというのは手抜きだろ、と言っている

しかし、例えば文字コードの自動判定ではSJISとUTF-8のどちらでも有効であるマルチバイト文字が存在する
例)"【D"と"縲識"はどちらも E3 80 90 44

このようなケースがある課題では自動処理できないので、ライブラリの外側で何かしらの対応をしてやる必要がある
マルチパートFormという課題でも同じように呼ぶ方が対処してやらなければならない問題があるのだろうと思った

だから、その問題について教えてくださいと書いたんだ
駄々ではないと思うんだが間違っているか？

**デフォルトの名無しさん** · 2020/05/16(土) 17:40:18.88

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

**デフォルトの名無しさん** · 2020/05/16(土) 17:40:39.14

MIME Type
MIME Encoding

**デフォルトの名無しさん** · 2020/05/16(土) 17:45:07.11

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

**デフォルトの名無しさん** · 2020/05/16(土) 17:51:34.17

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

**デフォルトの名無しさん** · 2020/05/16(土) 17:54:45.69

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

**デフォルトの名無しさん** · 2020/05/16(土) 17:55:54.20

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

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

**デフォルトの名無しさん** · 2020/05/16(土) 18:06:23.99

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

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

**デフォルトの名無しさん** · 2020/05/16(土) 18:13:07.38

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)
:

**デフォルトの名無しさん** · 2020/05/16(土) 18:26:33.81

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 法" を利用するときは、
> それを不能化する手段を供することが奨励される。

**デフォルトの名無しさん** · 2020/05/16(土) 18:28:03.02

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

**デフォルトの名無しさん** · 2020/05/16(土) 18:35:18.02

>>525
GitHub リポジトリの develop branch から引っ張ってビルドしたもの

$ go version
go version devel +810c27e9be Wed May 13 11:59:26 2020 +0000

**デフォルトの名無しさん** · 2020/05/16(土) 18:49:32.90

あ、それ違う

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

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

**デフォルトの名無しさん** · 2020/05/16(土) 18:53:01.16

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

**デフォルトの名無しさん** · 2020/05/16(土) 18:57:51.02

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

**デフォルトの名無しさん** · 2020/05/16(土) 19:07:51.23

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

**デフォルトの名無しさん** · 2020/05/16(土) 19:47:58.26

>>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で分岐してパースする方が合理的。

**デフォルトの名無しさん** · 2020/05/16(土) 21:02:30.65

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

**デフォルトの名無しさん** · 2020/05/16(土) 21:30:32.48

最終的に

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

とすることにした

**デフォルトの名無しさん** · 2020/05/17(日) 07:48:09.08

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

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

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

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

**デフォルトの名無しさん** · 2020/05/17(日) 07:48:39.85

>>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
}

まぁ、頑張って。

**デフォルトの名無しさん** · 2020/05/17(日) 08:01:02.13

>>534
>>516

**デフォルトの名無しさん** · 2020/05/17(日) 08:02:56.61

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

**デフォルトの名無しさん** · 2020/05/17(日) 08:07:59.87

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

**デフォルトの名無しさん** · 2020/05/17(日) 08:10:55.71

寝ぼけてるぽい、もう一回上げ直し
>>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
}

**デフォルトの名無しさん** · 2020/05/17(日) 08:16:05.54

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

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

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

**デフォルトの名無しさん** · 2020/05/17(日) 08:21:16.95

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

**デフォルトの名無しさん** · 2020/05/17(日) 08:26:21.18

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

**デフォルトの名無しさん** · 2020/05/17(日) 08:35:11.77

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

**デフォルトの名無しさん** · 2020/05/17(日) 08:36:58.14

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

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

**デフォルトの名無しさん** · 2020/05/17(日) 08:38:10.44

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

**デフォルトの名無しさん** · 2020/05/17(日) 08:40:22.86

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

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

**デフォルトの名無しさん** · 2020/05/17(日) 08:45:00.28

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
}

**デフォルトの名無しさん** · 2020/05/17(日) 08:51:07.87

現時点で

// 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()
}
}
}

とした

**デフォルトの名無しさん** · 2020/05/17(日) 08:54:49.63

あ、これでいいのか

// 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()
}
}

**デフォルトの名無しさん** · 2020/05/17(日) 08:55:11.84

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

わかりました。

サンプルがちょっとグダグダになってこめんなさいw
とりあえす頑張ってください。

**デフォルトの名無しさん** · 2020/05/17(日) 08:57:15.07

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

**デフォルトの名無しさん** · 2020/05/17(日) 09:00:02.16

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

**デフォルトの名無しさん** · 2020/05/19(火) 00:48:43.53

archive/zip パッケージの仕様なのか、zip 自体の仕様なのかわからんけど
まーた穴に嵌まった

zip内のトップディレクトリにファイルがある
file1.txt
sub/file2.txt
という構成だったときには
sub/
というzipエントリもReadCloser.File配列に入ってくるのに

トップにファイルがなくて
sub/file2.txt
というように、サブディレクトリ以下にしかファイルが無かったときには
sub/
が入ってきてない(もしくは入らないzipがある)

orz

**デフォルトの名無しさん** · 2020/05/19(火) 00:49:54.57

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

**デフォルトの名無しさん** · 2020/05/19(火) 00:52:26.39

実行例

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

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

**デフォルトの名無しさん** · 2020/05/19(火) 04:56:52.36

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

**デフォルトの名無しさん** · 2020/05/19(火) 07:27:40.15

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

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

**デフォルトの名無しさん** · 2020/05/19(火) 09:57:39.34

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

**デフォルトの名無しさん** · 2020/05/19(火) 15:39:15.28

サーバで http.ResponseWriter への書き込みが WSAECONNABORTED (10053) でエラーになっているとき
http.server.go#1905 で return してるため、1907のc.setState で StateIdle がセットされない
そのため、http.Server の ConnState ハンドラでコネクション数を勘定してると数が合わなくなる

という罠に嵌まった
どうしよう……エラーを検知した時に勘定している数をデクリメントするか？
だって、 return の判定で使われてる shouldReuseConnection って隠蔽されてるから

**デフォルトの名無しさん** · 2020/05/19(火) 15:42:09.41

罠にハマりっぱなしだな

**デフォルトの名無しさん** · 2020/05/19(火) 15:46:50.47

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

**デフォルトの名無しさん** · 2020/05/19(火) 15:56:36.95

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

**デフォルトの名無しさん** · 2020/05/19(火) 15:57:44.45

そもそも、問題のレスポンスでは20MBくらいのmpgファイルがリクエストされてるんだけど
こういったデカイ応答を返す場合って自分が知らない注意点がある？

Content-Length はファイルサイズ(21614145)
Content-Type は application/octet-stream
で送ってる
ブラウザでは動画はちゃんと出てる

**デフォルトの名無しさん** · 2020/05/19(火) 16:05:09.36

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

**デフォルトの名無しさん** · 2020/05/19(火) 16:16:50.77

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

**デフォルトの名無しさん** · 2020/05/19(火) 16:50:34.24

深く考えずに
レスポンスの書き込みに失敗したらコネクション数をデクリメントする
ことにした

コネクション数が0になるまではWaitGroup.Waitで待ってる作りにしてたんで

**デフォルトの名無しさん** · 2020/05/19(火) 17:19:44.24

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

**デフォルトの名無しさん** · 2020/05/19(火) 17:35:35.62

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

**デフォルトの名無しさん** · 2020/05/19(火) 17:38:29.19

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

**デフォルトの名無しさん** · 2020/05/19(火) 17:57:05.30

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

**デフォルトの名無しさん** · 2020/05/19(火) 18:02:54.20

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

**デフォルトの名無しさん** · 2020/05/19(火) 18:09:43.56

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

**デフォルトの名無しさん** · 2020/05/19(火) 18:33:39.64

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

**デフォルトの名無しさん** · 2020/05/19(火) 18:35:39.76

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

**デフォルトの名無しさん** · 2020/05/19(火) 18:38:32.19

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

**デフォルトの名無しさん** · 2020/05/19(火) 21:21:52.33

>>567
Content-Length不要…以前の、設定しなけりゃチャンク送信！
orz

ちなみに、レスポンス書き込みがエラーになるブラウザはChromeとEdge
Firefoxだとエラーにならないのは何故だろう

**デフォルトの名無しさん** · 2020/05/19(火) 22:18:59.14

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

**デフォルトの名無しさん** · 2020/05/20(水) 09:29:17.16

458 に関係しての罠

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

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

**デフォルトの名無しさん** · 2020/05/20(水) 09:36:09.90

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

**デフォルトの名無しさん** · 2020/05/25(月) 08:12:24.13

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

**デフォルトの名無しさん** · 2020/05/25(月) 09:08:49.12

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

**デフォルトの名無しさん** · 2020/05/25(月) 10:00:32.41

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

**デフォルトの名無しさん** · 2020/05/25(月) 11:32:33.83

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

**デフォルトの名無しさん** · 2020/05/25(月) 12:20:31.75

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

**デフォルトの名無しさん** · 2020/05/25(月) 13:20:36.16

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

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

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

**デフォルトの名無しさん** · 2020/05/25(月) 13:44:33.12

>>585
>>73

**デフォルトの名無しさん** · 2020/05/25(月) 16:38:07.00

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

**デフォルトの名無しさん** · 2020/05/25(月) 16:41:08.15

場合による

**デフォルトの名無しさん** · 2020/05/25(月) 17:19:57.39

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

**デフォルトの名無しさん** · 2020/05/25(月) 17:29:12.78

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

**デフォルトの名無しさん** · 2020/05/25(月) 17:31:51.89

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

**デフォルトの名無しさん** · 2020/05/25(月) 18:10:55.04

場合つまり解決しようという問題による
問題解決能力って何よという話

グラフィカルでない
非同期処理が効果的
ならば少ない労力で実装できるという強みが売りかな
労力に関しては仕様が一頁で網羅できるGoの学習コストの低さが大きい

PythonだとCの知識前提で使うCythonでないとGoには太刀打ちできないというQuiita記事もある

総合力ではPythonの圧勝だろうけど、限定された問題ってのはそういうもの

**デフォルトの名無しさん** · 2020/05/25(月) 18:27:04.86

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

**デフォルトの名無しさん** · 2020/05/25(月) 19:39:14.90

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

**デフォルトの名無しさん** · 2020/05/25(月) 21:22:07.97

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

**デフォルトの名無しさん** · 2020/05/25(月) 22:09:38.90

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

**デフォルトの名無しさん** · 2020/05/26(火) 06:33:05.73

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

**デフォルトの名無しさん** · 2020/05/26(火) 06:39:27.10

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

**デフォルトの名無しさん** · 2020/05/26(火) 07:21:02.22

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

**デフォルトの名無しさん** · 2020/05/26(火) 07:48:46.09

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

**デフォルトの名無しさん** · 2020/05/26(火) 08:32:48.79

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