X
Go language part 3
レス数が1000を超えています。これ以上書き込みはできません。
0004デフォルトの名無しさん
垢版 |
2019/10/18(金) 00:00:29.03ID:DhnYyybT
golang.jp は、エイベルの古川昇部長が、社内で始めた翻訳プロジェクトだろ？
最近は、活動してないのか？

改訂2版 基礎からわかる Go言語、古川昇(エイベル)、2015
0006デフォルトの名無しさん
垢版 |
2019/10/18(金) 13:53:47.66ID:wgxHvfCr
先週から仕事でGoやることになったんだが、この言語辛すぎないか・・・？
ジェネリクスないしエラーが辛い。ジェネリクスは2.0で入るらしいが。
Goの作法だとエラーハンドリング忘れて次の処理を書けるリスクが常に孕んでてて書いてて全然安心できない。
あと詳細なエラー情報見ようとするとcustomErr,ok:=err.(CustomError)みたいにしないと情報とれないの危なすぎでしょ。
なんでカスタムエラー型認められていないの？
0007デフォルトの名無しさん
垢版 |
2019/10/18(金) 14:25:55.97ID:I27oYfOd
>>6
認められていない訳じゃない
しかし、カスタムなエラー型だと正常時にnilが帰ってきた時に
if err!=nil {} がtrue判断を食らうという厄介なバグがある
これは型付きnilというバグだが、仕様と言い張ってる模様
仕様なら、the predeclared identifier nil, which has no typeの記述とか直せや！
0008デフォルトの名無しさん
垢版 |
2019/10/18(金) 14:31:17.21ID:I27oYfOd
>>6
エラー処理を忘れるうっかりさんは例外だってキャッチ忘れるだろな

そして、エラー処理は1.13でほんの気持ちだけ改修入ってるからチェック
Is, As
0009デフォルトの名無しさん
垢版 |
2019/10/18(金) 14:39:41.03ID:W6xTwO6R
O2
0010デフォルトの名無しさん
垢版 |
2019/10/18(金) 15:49:30.94ID:wgxHvfCr
>>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にはいると本当にカスタムエラーの道が閉ざされてしまいそうだけど本当にそれでええんやろか
0011デフォルトの名無しさん
垢版 |
2019/10/18(金) 16:01:34.41ID:uhy/qlU/
エラー処理の観点から見るとジェネリクスないのはもう相当きついね
関数型脳は捨てるしかない
0012デフォルトの名無しさん
垢版 |
2019/10/18(金) 19:57:12.19ID:wgxHvfCr
まあRustも関数型言語かというと違うけどな。標準ライブラリにはモナドないし。
ジェネリクスが必要なものに関しては今使えないから仕方がない面はあるとは思う。

ただカスタムエラー型が実質使えない状態になってるのは辛いなあとは思う
0014デフォルトの名無しさん
垢版 |
2019/10/19(土) 15:58:08.27ID:g7gJ/kc1
exe でかいな・・・
0016デフォルトの名無しさん
垢版 |
2019/10/19(土) 19:56:56.88ID:N1S9xfvx
2MBは静的リンクされてる実行ファイルなら普通よ
C系のリンカーの出力だとままある
動的リンクされてDLLとかアセンブリとかSOをロードする実行ファイルとは違う
ロードが速いはずというメリットもある
0017デフォルトの名無しさん
垢版 |
2019/10/19(土) 22:13:55.22ID:x3sKZMaG
せやな
この特性でインスタンスの起動が早くてクラウドだと重宝するね
反面WASMとかだと辛いという話は聞いている
0018デフォルトの名無しさん
垢版 |
2019/10/20(日) 10:01:30.26ID:Xl2t0ZNf
そもそもC/C++自体がすでに第一選択の言語じゃなくて、応答性やパフォーマンスの問題で消去法で選ばれる言語だし、
Goはそれで弾かれる側の言語なんで無理無理

Goが選択肢に入るような要件ならC++は選択肢に入らないし、逆もまた然り
0019デフォルトの名無しさん
垢版 |
2019/10/20(日) 10:16:19.34ID:kaRRw6/p
しかし、C++は他に選択肢が無いというよりアセンブラより生産性が高いという消去法で選択される言語
C++よりも生産性が高いと思う人間、例えばGoogleとか俺にとっては消去法での乗り換えが充分に考えられる
0020デフォルトの名無しさん
垢版 |
2019/10/20(日) 10:22:02.89ID:kaRRw6/p
あ、もうちょい書き足りなかった
つまり、ベターなアセンブラの地位をC/C++から奪おうという狙いの言語、という位置付けだと考えるよ
0021デフォルトの名無しさん
垢版 |
2019/10/20(日) 10:26:38.82ID:7X6GOXnL
草
0022デフォルトの名無しさん
垢版 |
2019/10/20(日) 10:33:11.87ID:kaRRw6/p
笑っていればいいさ、20年前にJavaが将来のメジャー言語になると言ったら馬鹿にされるのは必至だったし
0023デフォルトの名無しさん
垢版 |
2019/10/20(日) 10:35:44.03ID:kaRRw6/p
まあ、linuxカーネルがCで書かれる限り、Cの牙城を崩すのは夢物語なのは間違いない
0025デフォルトの名無しさん
垢版 |
2019/10/20(日) 11:07:37.88ID:ZaJFVv7X
Dと比べてどうなん？
0026デフォルトの名無しさん
垢版 |
2019/10/20(日) 11:10:32.44ID:LrxuqhUZ
var hoge uintptr = 123 動く(1)
hoge := uintptr(123) 動く(2)
hoge uintptr = 123 動かない(3)
hoge uintptr := 123 動かない(4)

やっぱり面倒なんだよね
良い方法ないですか
あと(2)があまり使われないのはなぜ？
0028デフォルトの名無しさん
垢版 |
2019/10/20(日) 11:21:45.78ID:7X6GOXnL
君は20年後も笑われてると思う
0029デフォルトの名無しさん
垢版 |
2019/10/20(日) 11:28:13.14ID:kaRRw6/p
使ったこと無いから的外れかもしれないけど、uintptrなんてunsafeな箇所くらいでしか使わないと思う(アーキテクチャ依存だからという理由
そんなuintptrを簡単にという意図がわからないので、解説plz
0030デフォルトの名無しさん
垢版 |
2019/10/20(日) 11:30:47.40ID:kaRRw6/p
根拠も何もなく笑って誤魔化す人に笑われても痛くも痒くもないね
そこでどうぞ笑っていてくださいな
0034デフォルトの名無しさん
垢版 |
2019/10/21(月) 12:27:44.92ID:Z5rpRU3u
全然関係ない話
公式のドキュメントのフォントがChromeとかで汚いと悩んでたんだけど、実はGoogleのRobotoフォント入れれば良いんだな
0036デフォルトの名無しさん
垢版 |
2019/10/22(火) 09:57:44.29ID:fxbuxtP/
:= と = の使い分けが構文的に破綻してるように観える
0037デフォルトの名無しさん
垢版 |
2019/10/22(火) 10:07:36.95ID:fxbuxtP/
var s []byte = "abc"
string(s) // OK
s.String() // undefined

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

なんかこの辺もいまいち
0038デフォルトの名無しさん
垢版 |
2019/10/22(火) 16:48:11.86ID:fxbuxtP/
a) var hoge bytes.Buffer
b) hoge := bytes.Buffer{}
c) hoge := new(bytes.Buffer)

これは全部同じか？
0039デフォルトの名無しさん
垢版 |
2019/10/22(火) 17:34:11.07ID:NAxd+6Yh
cはポインタじゃね？
0040デフォルトの名無しさん
垢版 |
2019/10/22(火) 18:45:07.15ID:ZD3zuEp7
&xxxxx{}の方が直接的で字数も短いからnewって使ったことも無かった
何のためにあるの？
0044デフォルトの名無しさん
垢版 |
2019/10/23(水) 00:31:32.72ID:JxOFlXnS
errorはインターフェースだからswitchで処理するんじゃないの？キャスト使うの？
0047デフォルトの名無しさん
垢版 |
2019/10/23(水) 15:38:46.69ID:v5l3MvUt
たまにgoやると、そのたびにテンプレートリテラルがないことを忘れててショックを受ける
0048デフォルトの名無しさん
垢版 |
2019/10/23(水) 15:45:39.64ID:JzA6/vMp
Go って GAE とか GCP 以外ではどんなところで使われてますか
0054デフォルトの名無しさん
垢版 |
2019/10/26(土) 14:34:34.62ID:Js8CxMBL
{ "name": "Tanaka", "age": 26 }
{ "name": "Tanaka"}
{ "age": 26 }
{}

みたいに中身が入ってるか不確定なjsonlファイルを上手くcsvやtsvに変換する方法ってありますか？
0055デフォルトの名無しさん
垢版 |
2019/10/26(土) 17:57:54.28ID:cnCbS4wm
普通にjson.Unmarshal()するだけで、mapになるそうだから
入っていないキーは入っていないと分かるのとちがう？

設定ファイルとか使うコード書いたことないから受け売りなんだけど
0056デフォルトの名無しさん
垢版 |
2019/10/26(土) 18:26:00.14ID:WK67sdAG
いまいちカッコ悪いが、
各フィールドを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
,
005856
垢版 |
2019/10/26(土) 19:00:33.37ID:WK67sdAG
書いた後にアレだが、 >>55 のやり方のほうが良い

var persons []map[string]interface{}
0061デフォルトの名無しさん
垢版 |
2019/10/26(土) 20:04:05.89ID:7Zdb+SPq
Goってjqみたいな機能無いのか
jsonの全パターン書くの辛くないか？

{ "name": "Tanaka", "age": 26 }
だけで残りの3パターンも補完できれば汎用性のあるものができそうだが
0064デフォルトの名無しさん
垢版 |
2019/10/26(土) 22:55:14.57ID:qV3xsUXN
>>62
{ "name": "Tanaka", "age": 26 }
{ "name": "Tanaka"}
{ "age": 26 }
{}

みたいに全部定義するのがめんどいってことでしょ
0065デフォルトの名無しさん
垢版 |
2019/10/26(土) 23:02:23.77ID:cnCbS4wm
>>64
定義って、それはテストデータじゃない
テストデータ書かないでサンプル書くの？

とかすっとぼけて書いたが、誰かjsonの形式の定義が必要なサンプルコードを書いたりしたか？という話
そもそもが内容が不定なjsonを解読するって話だから、皆さんそれを読むサンプルコードを書いてる
つまり、レス主はそれらのサンプルコードを読んでないんじゃね？
0066デフォルトの名無しさん
垢版 |
2019/10/27(日) 09:49:43.92ID:rf1sTekf
Unmarshal()の引数に[]interface{}の変数のポインタを渡すと、マップとスライスで構成されたjsonの中身がエンコードされるという前提知識で話してるのに
キーをフィールドとして事前定義しなきゃならん、構造体のスライスへのポインタを渡す形式の呼び方での話を持ち出されても困るんだ
んでも、構造体を切ることをパターンと言っているのではない可能性もあって、一応確認
0067デフォルトの名無しさん
垢版 |
2019/10/27(日) 16:02:57.62ID:rf1sTekf
【質問】
goroutineはデーモンスレッドみたいにプロセスが死ぬと終了します
だから後始末をしたい場合、子にはcontext.WithCancelで終了を通知、受け取ったら後始末
そして、親はsync.WaitGroupで完了待ちしています

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

Javaだとスレッドをinterruptして、子はInterruptExeption拾って後始末して、親はjoinして待つじゃない
主にInterruptExeptionをキャッチするコードを書くだけで済む
もしも親から狙ったgoroutineに特定のpanicを起こせるなら、recoverで拾えるかなーと…
0068デフォルトの名無しさん
垢版 |
2019/10/27(日) 17:24:05.16ID:IkTaChA0
暗黙で thread safe になるからじゃね？
0071デフォルトの名無しさん
垢版 |
2019/11/09(土) 14:45:47.99ID:BZG37V3w
おめでとう
そして 10年で 3 スレ
0072デフォルトの名無しさん
垢版 |
2019/11/10(日) 16:35:00.71ID:AlAC5EvK
>>67
狙ったgoroutineにってのが推奨されてるかはわからんけど、レシーバなり関数のパラメータなりにid持たせて、終了通知channelにそのidを送って受け取った側で処理する、とか
0075デフォルトの名無しさん
垢版 |
2019/11/13(水) 13:05:15.15ID:OceCV+VL
ローソンやめて・・・
0078デフォルトの名無しさん
垢版 |
2019/11/15(金) 01:20:51.87ID:mVgFykxZ
>>76
うん、BaseもSubも同じインターフェースに代入してメソッド呼んでるから、ちゃんと多態になってると思う
それとも俺とかレス主が多態性を勘違いしてる？
0079デフォルトの名無しさん
垢版 |
2019/11/19(火) 11:45:57.48ID:yN0S2651
新しいサイトのurlゴーデブとか俺をバカにしてんのか？
0081デフォルトの名無しさん
垢版 |
2019/11/19(火) 19:24:06.45ID:FmtuL8lJ
新しいサイト？
言語仕様ドキュメントが見つからないから、移行ではないよな？
何のためのサイト何だろうコレ
0085デフォルトの名無しさん
垢版 |
2019/11/20(水) 04:14:35.39ID:MuZ0V3fT
デブで経営者向けはないだろｗ
経営者ならスマート
0088デフォルトの名無しさん
垢版 |
2019/11/21(木) 22:11:47.49ID:zCme0Fkr
なぜかVScodeでmain.goだけ"fmt"とか全くimportできなくなってしまった
language serverのリスタートもWindowsの再起動も駄目
なんじゃこりゃ、まいったね
0090デフォルトの名無しさん
垢版 |
2019/11/23(土) 08:06:54.73ID:5HHeTBXj
>>89
コマンドラインでgolintとか叩いても何も出ないね
今は出なくなってるけど、原因がわからない
ちなみに1.13.1
0091デフォルトの名無しさん
垢版 |
2019/11/23(土) 12:27:33.32ID:1tA3t0n1
>>90
俺もvscodeの再起動で治ったけど、module周りはちょいちょい不具合でるなあ。
importの警告がいきなりでてきたり
0092デフォルトの名無しさん
垢版 |
2019/11/23(土) 14:07:25.44ID:5HHeTBXj
>>91
また modules か
modules ってどうなるのかな？
godoc が動かない issue も目処が立っていないらしいし
0093デフォルトの名無しさん
垢版 |
2019/11/23(土) 20:04:06.92ID:1tA3t0n1
>>92
バグのあるバージョンがミラーに乗っかっちゃったらポイズニングするしかないのとかもなんとかしてほしい。
コンパチがゆえの弊害が出ている気はする。
0094デフォルトの名無しさん
垢版 |
2019/11/23(土) 20:37:12.05ID:5HHeTBXj
>>88
import "./internal/config"
とか相対パス参照を止めて完全パスでインポートしたらエラーが消えた
別マシンだと1.12だったからなのか動いてたんだけど、なんだこりや
0096デフォルトの名無しさん
垢版 |
2019/11/23(土) 21:13:40.13ID:pGKd1Nh3
言語自体はそれなりに良いんだが開発状況見てるとと将来が不安。rubyに似てる。
0097デフォルトの名無しさん
垢版 |
2019/11/23(土) 21:21:33.69ID:3Nj772W5
>>96
最初からコンセプトがシンプルだから、rubyとまではならないんじゃないかな。と、思いたい。
あとケツ持ちがでかい
0098デフォルトの名無しさん
垢版 |
2019/11/23(土) 21:44:02.36ID:zPKhdy+L
>>94
go.mod に

replace internal/config => ./internal/config

と書いておくと

import "internal/config"

と書ける。 ./internal/config ディレクトリ内にも go.mod を作っておく必要があるけど
0099デフォルトの名無しさん
垢版 |
2019/11/23(土) 21:57:18.51ID:5HHeTBXj
>>95
環境変数見てもgo env見ても
GO111MODULE=
と設定されていませんね
Goを始めたのが1.12だったから、そもそも必要なかったし
0103デフォルトの名無しさん
垢版 |
2019/11/23(土) 22:13:50.79ID:5HHeTBXj
シンプルなのはいいんだけど
golintでチェックされる命名規則が嫌すぎる
キャメルでgetJsonDataとかだったか関数定義したら"JSON"と大文字で書けとか怒られた
お前は姑か！
0107デフォルトの名無しさん
垢版 |
2019/11/23(土) 22:29:30.47ID:zPKhdy+L
後は import "hoge-project/internal/config" って書くとか
これなら go.mod を作ったり弄くらなくて済む
0109デフォルトの名無しさん
垢版 |
2019/11/25(月) 21:36:43.85ID:aLYZ9MFJ
初心者なんだがcontextの使い道がいまいちわからん。
cancelとかなんかいいサンプルないかな。
0110デフォルトの名無しさん
垢版 |
2019/11/25(月) 22:24:43.09ID:ELiIkdft
>>109
パッケージドキュメントのExampleが、自分としては分かりやすかった
WithCancelしか使ってないけど

あと、go vet がバグっていて親contextのCancel関数があるのに
子供のCancel関数を_で捨てると怒られる
https://github.com/golang/go/issues/29587
暫定的な解決法は一旦変数に取ってから_に代入
0111デフォルトの名無しさん
垢版 |
2019/11/25(月) 22:34:45.60ID:ELiIkdft
>>109
使い方じゃなくて使い道かー
んー、goroutineをポコポコ作る場面で、処理をキャンセルしたい事ってあるけど、作り散らしたgoroutineに通知しないとキャンセルできない
そんなとき自前で仕掛けを作らなくてもcontextを使えばいい
あとは、そういった処理にタイムアウトを実装したい時にも、タイマーが組み込まれてるcontextがある

Valueは使ったこと無い
0112デフォルトの名無しさん
垢版 |
2019/11/25(月) 22:57:11.50ID:0VXwuJZP
ありがちなのはsigintしたときにすぐにプログラムを止めずに子のゴルーチンの処理が一区切りついてから止める場合とかかな🤔
0113デフォルトの名無しさん
垢版 |
2019/11/26(火) 02:26:32.95ID:RC9c8z2p
改訂2版 みんなのGo言語、2019/8/1

買ってきた。
これは、文法以外の開発に関する本
0115デフォルトの名無しさん
垢版 |
2019/11/26(火) 15:25:52.87ID:+MieSoC5
>>111
回答ありがとう
そういうケースって、親がcancelしたら、goroutineはDoneを受信したら終了、って認識なんだけど、それって終了するためにfor、select前提、になるのかな
0116デフォルトの名無しさん
垢版 |
2019/11/26(火) 15:27:45.16ID:+MieSoC5
>>112
それも考えてはみたんだけど、waitgroupか、キャパ付きのerrorChannelで事足りてしまうような。
context難しい。。
0117デフォルトの名無しさん
垢版 |
2019/11/26(火) 15:32:27.05ID:+MieSoC5
>>110
パッケージドキュメントだと、やはり基本的にループ待受なのね

なんかイメージ的に、その文脈から派生した処理を上手いことその派生分だけ切り上げる、みたいな感じだったけど、contextWithCancel使う＝ループ処理がある、なのかな
0118デフォルトの名無しさん
垢版 |
2019/11/26(火) 18:34:43.56ID:8XlTLgEr
>>115
そうなる
各goroutineではチャネルを読まないといけない
んでもコード的に汚いから、裏技がないかと>67で質問したけど無いみたい
interrupt panic とか起こせたらなぁ
0119デフォルトの名無しさん
垢版 |
2019/11/26(火) 20:40:53.47ID:+MieSoC5
>>118
なるほど。参考になる。
channel読むの前提ってことは、やっぱり汚くなるよね。
selectで終了待受したいなら、中でさらにgoroutine生成してselectまで進めておく、しかないと
なんかこう、WithCancelで生成したcontext渡してcancelしたらなにも考えることなく終わってほしいなー。
0120デフォルトの名無しさん
垢版 |
2019/11/26(火) 21:33:38.25ID:+iLBHaU9
>>114
便乗して更に質問で申し訳ないが聞きたい。waitgroupって、個人的にはworkerの数が決まってるなら使うべき？
wg使わずにキャパシティ付きchannelに放り込む、クロージャでdefer closeしてその後channelをrangeで回す。というのもソースコードではよく見る。

ここら辺なにが正解なのかわからんのよね
0122デフォルトの名無しさん
垢版 |
2019/11/26(火) 22:57:07.00ID:eptCat3v
workerの数決まっていないでチャンネル使うとキャパシティ以上にワーカーできたとき詰まって死にそう🤔
0123デフォルトの名無しさん
垢版 |
2019/11/26(火) 23:23:09.81ID:Gw3sx8bp
>>121
回答とサンプルありがとう。
質問の日本語がおかしかった。。
なるほど、こうすればchannelで送受信しなくても逐次的に処理できるということか。

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

常駐してて死なないアプリ以外にあんまり思いつかず
0125デフォルトの名無しさん
垢版 |
2019/11/26(火) 23:29:52.93ID:Gw3sx8bp
>>122
受信側は無限に待ち受ける想定だとどうかな？というか、waitgroupを使わないユースケースがそれぐらいしか思いつかないんだよね

waitgroupが有効なケース、だけどwaitgroupを使わないケースってどんなんがあるのかな。
0126デフォルトの名無しさん
垢版 |
2019/11/26(火) 23:36:45.35ID:wNKG8xXd
>>123
常駐じゃなくても並列処理で足並み揃える時とかに使うかな
例えば並列で別のダウンロードさせたり
0127デフォルトの名無しさん
垢版 |
2019/11/26(火) 23:46:52.62ID:+iLBHaU9
>>126
そうか、パッと見ダウンロード処理を開始する時にwg.Add(len())すれば、とおもったけど、よく考えたら何をダウンロードするのかを取得する処理自体が並列化してる場合は、ソースみたいに自分でAdd(1)しないと並列化できないね。
とても勉強になった。ありがとう。
0129113
垢版 |
2019/12/02(月) 22:40:03.04ID:H5nAExhM
>>113
改訂2版 みんなのGo言語、2019/8/1

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

テスト・デザインパターンなど、
各言語の中級者向け「Effective 何々」に相当する本
0130デフォルトの名無しさん
垢版 |
2019/12/03(火) 08:47:37.15ID:+IyagjW2
effective goは無料で読めるけど全然似てない。適当こくでねぇ。
0133デフォルトの名無しさん
垢版 |
2019/12/08(日) 01:05:14.90ID:XpO05MF4
ジェネリクスとnnbdは入ったの？
0134デフォルトの名無しさん
垢版 |
2019/12/12(木) 01:16:12.28ID:8N8BhmJA
>>133
入ってない。
ジェネリクス欲しいよね
0135デフォルトの名無しさん
垢版 |
2019/12/14(土) 02:29:56.08ID:yWRsmPzk
ジェネリックよりインターフェースのメソッド名をリファクタリングする機能が欲しい
それとファイル内に閉じたスコープの新設
0136デフォルトの名無しさん
垢版 |
2019/12/14(土) 12:20:22.72ID:txh4qI7o
サクッとwebサーバー建てる時お前らエコー使うだろ？
後輩がジン一択言って譲らんのよ
0138デフォルトの名無しさん
垢版 |
2019/12/14(土) 18:57:44.23ID:SoAE2obC
サクッと立てたい時にフレームワークは使わない
0141デフォルトの名無しさん
垢版 |
2019/12/16(月) 01:49:06.93ID:tdYdVSGI
go初心者です。
田中、佐藤、加藤からランダム(重複なし)で3つ抽出するにはどうすればいいでしょうか？
0143デフォルトの名無しさん
垢版 |
2019/12/16(月) 02:11:32.44ID:tdYdVSGI
>>142
なるほど。
ただ実際は配列の大きさは100個くらいあって取り出す配列は5つなんですよね...
0149デフォルトの名無しさん
垢版 |
2019/12/16(月) 20:24:54.73ID:4cesp02J
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)
}
0151デフォルトの名無しさん
垢版 |
2019/12/16(月) 20:35:08.46ID:F1oitXIE
まぁ、こんなんかなぁ…

if a, ok1 := x.(int); ok1 {
if b, ok2 := y.(int); ok2 {
fmt.Println(a, b)
}
}
0152デフォルトの名無しさん
垢版 |
2019/12/16(月) 20:41:01.13ID:F1oitXIE
reflection ならこうかな

import "reflect"

if reflect.ValueOf(x).Type() == reflect.ValueOf(y).Type() {
　fmt.Println(x, y)
}
0154デフォルトの名無しさん
垢版 |
2019/12/18(水) 18:41:56.85ID:q6G7SevV
golang関係ないんだが、50000番台ポートをlistenで開きまくるアプリ書いてるんだが、テスト実行毎にデバッグexeのパスが変わってWindowsDefenderがブロックしましたダイアログ出してきてウザいよぅ
うちはSEPなんでお呼びじゃないし、更にブロックされてると主張してるがテストコードはガンガン通ってるからブロックしてねーし

ともかく、デバッグexeの一時フォルダを固定する設定ってある？そうすりゃ例外設定書ける
0157デフォルトの名無しさん
垢版 |
2019/12/21(土) 20:16:12.25ID:YQ48l2e3
ep8 ー ep7で雑に投げられた謎を雑に処理、端から解決する気無し。既存キャラの大幅劣化に加え、ローズ、紫バァ、暗号破りの新キャラ3人がヘイトの対象に（主にローズ）

ep9 ー ep8の出来事はほぼ無かったことに…。大味極まりないが逆にそれが功を奏し、SWファンからの評価は概ね高い。興収でエンドゲームを超えられるか注目
0160デフォルトの名無しさん
垢版 |
2019/12/26(木) 23:57:38.99ID:oc05wxay
>>159
知らんのでググって、最初にヒットした奴の方が良いな

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

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

ぱっと見、visitパターンっぽいアイデアに見えた
(個人的な初見の感想なんで深く考えて言ってる訳じゃない
なんだっけ、二重呼び出し？
0163デフォルトの名無しさん
垢版 |
2019/12/27(金) 18:28:35.28ID:Ppw19SXV
ひさしぶりにGO触ったら仕様変更の真っ最中なのね...
暫く冬眠しとくわ　　　　　　　　　　　　　　　　　　　　　　　　　
0164デフォルトの名無しさん
垢版 |
2019/12/27(金) 18:35:37.18ID:DR+ZCW3w
いつでも仕様変更
ジェネリックス欲しがってる層って、何のクラスタの人なんだろ
0165デフォルトの名無しさん
垢版 |
2019/12/27(金) 20:14:12.67ID:MjAsf7uH
Java
0168デフォルトの名無しさん
垢版 |
2019/12/28(土) 13:38:22.34ID:bI9Nn/0L
golangのゆるふわなinterface機構の上でジェネリックスの出番なんてそうそうあるものなのかな？
0169デフォルトの名無しさん
垢版 |
2019/12/28(土) 13:43:53.42ID:c5TG1bir
ちょっと凝ったことをしようとすると interface{} まみれになるところが改善できれば。
0170デフォルトの名無しさん
垢版 |
2019/12/28(土) 13:46:40.71ID:FraGl0GS
ジェネリクスはGo教において諸悪の根源とされる「利用しようとする前に利用される方を設計する行為」の最たるものだからなあ
0171デフォルトの名無しさん
垢版 |
2019/12/28(土) 14:04:34.89ID:bI9Nn/0L
自分としてはgolangの形式で動的にリンクできるライブラリ手法が欲しいな
dllみたいなcgoなライブラリじゃなくgolangネイティブな形で
interface定義とインスタンスをロードするビルダだけ静的リンクするスタイルを想定
これがあるとDIとかプラグインが捗るから

知らないだけで存在してたりする？
それともdotnetのactivexみたいにdllに皮かぶせれば行けたりする？
0172デフォルトの名無しさん
垢版 |
2019/12/28(土) 15:05:05.51ID:R0mqAcCR
ドラフトに挙がっている Go の generics(contract ベース)が採用されれば、

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

inteface{} を使わなくてもよくなるんじゃないか、って期待してる。
まぁ、最終的にどうなるかは分からんけど…
0173デフォルトの名無しさん
垢版 |
2019/12/28(土) 18:09:17.61ID:euZyKjoi
ジェネリクスは大体ライブラリとかそっちの方が実装してて普通は使うだけ
他の言語でジェネリクスないときはいちいち型キャストと型チェックしてたから
そういうのが無くなって嬉しかったんだけどなあ
0174デフォルトの名無しさん
垢版 |
2019/12/28(土) 18:18:35.27ID:7CupGRjm
goでapiサーバーを構築したいんだけど、参考になるサイトとかないですか？
0177デフォルトの名無しさん
垢版 |
2019/12/29(日) 14:50:10.22ID:J2Lmqp1K
WebAPIサーバーなんて、Qiitaとかそこらへんに転がってるような「GoでWeb APIを作ってみた」
程度の簡単なものが実際に本当にプロダクションで運用されてるもんだ。
ただしその前方や足元にはALBやらKubernetesやらがあって、信頼性やスケーラビリティはGoではなくそういったクラウドインフラの層で担保するんだよ。
Goをプロダクション運用したいなら、GoよりAWSの知識の方がずっと重要だ。
0179デフォルトの名無しさん
垢版 |
2019/12/30(月) 09:38:05.31ID:QVGDKUrk
標準パッケージのjsonのUnmarshal
なんでReaderインターフェースでなくてバイト配列を引数にしたんだろ？
DecoderはSAXみたいなトークナイザだしなぁ
0180デフォルトの名無しさん
垢版 |
2019/12/30(月) 09:50:44.52ID:QVGDKUrk
>>177
趣味のサービスかもしれんのに、何を先走ってるんだか？
少なくとも商売始めようという人間が便所の落書きで質問しないと思う
0186デフォルトの名無しさん
垢版 |
2020/01/02(木) 02:53:52.42ID:YsIrUWNq
>>185
必要かと言えば、必要はない
goroutineが終わらなくてもプロセスは終わる

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

つまり後始末とかはされない
後始末したければ、
1. context使って終了を通知
2. WaitGroup使ってgoroutineの終了を待つ
0188デフォルトの名無しさん
垢版 |
2020/01/08(水) 00:07:12.80ID:xIk/A1LK
golangはgoroutineでNAMESPACEを適切にコントロールする手段がないのでDockerコンテナを記述するには適していない、という記事を読んだんだけど
これって対策とかロードマップとか何か打ち出されてない？
0189デフォルトの名無しさん
垢版 |
2020/01/12(日) 02:20:29.72ID:/FVSphLE
>>188
記事はどこ？
0191デフォルトの名無しさん
垢版 |
2020/01/12(日) 10:07:33.12ID:EKUpo6h1
記事読んでみたけど、問題はnamespaceそのものじゃなくてnative threadへのアクセスじゃないのかな。
0192デフォルトの名無しさん
垢版 |
2020/01/12(日) 10:35:25.29ID:F6k+/xNL
言語選択ネタは基本的に使いたいものを正当化するためのゴリ押しになりがちだから話半分に聞いておくのが正しい態度
0193デフォルトの名無しさん
垢版 |
2020/01/12(日) 10:41:45.99ID:K4o7W11h
根本的な原因はそうなんだろうけど、クリアするハードルは名前空間なのかなと
まあ、自分はDockerコンテナ自身には今のところ手を出す気はないアプリ作者だけど、ちょっと気になっただけなんだ
元からgolangはデバイスドライバとかの低レベルのシステム開発は対象としてないように見える(主観)ことから、それと同様に不要な機能としてガン無視なのかな？
それならそれで文句がある訳じゃない
0195デフォルトの名無しさん
垢版 |
2020/01/12(日) 11:45:59.65ID:K4o7W11h
えーと、多分そう
ツール書くのにperl awkからjava c#経由して今はgolangが便利すぎて引っ越してきた
0197デフォルトの名無しさん
垢版 |
2020/01/12(日) 12:49:08.86ID:1tVaWxzz
おまえか！
0200デフォルトの名無しさん
垢版 |
2020/01/15(水) 23:43:56.51ID:A/ClkkqP
今のところGoはAWSやGCPを極めた人が使うイメージだな
年収が高いのもそのためだろう
Goはドカタグラミングにも最適だから、もし今後も順調に普及していけば平均年収は大幅に下がりそう
0201デフォルトの名無しさん
垢版 |
2020/01/16(木) 08:41:54.42ID:FflLw5gy
覚えなきゃならない独特で特殊なことがインターフェースの概念くらいで、構文は平凡以下の厳選されたものしかないから学習ハードル低いよな
自分はc言語とJavaとJavaScriptを経験してるから、一週間でほぼ使えるようになった
0202デフォルトの名無しさん
垢版 |
2020/01/16(木) 19:01:13.36ID:aiRikJgB
下手すると何も特に勉強しなくてもただ人の書いたコードながめるだけで
「ああこんな感じか？」って雰囲気だけでそれなりのコードかけるようになっちゃう言語
0203デフォルトの名無しさん
垢版 |
2020/01/16(木) 21:24:12.96ID:u+AvDfAm
goはシンタックスシュガー多めで、初学者が見よう見まねで学習すると嵌りやすい印象。
0204デフォルトの名無しさん
垢版 |
2020/01/16(木) 21:59:12.79ID:TiSttWiL
ほとんど使う局面がないstruct実体はでっかい落とし穴
実体配列rangeで回して更新されねーっと悩む初心者のいかに多いことか
0206デフォルトの名無しさん
垢版 |
2020/01/16(木) 22:19:59.62ID:rwq+tT6g
>>204
ヌルポで落ちまくるよりは遥かにマシだわ
むしろfor rangeで要素のポインタを取れるようにしてほしい
0207デフォルトの名無しさん
垢版 |
2020/01/16(木) 22:45:35.06ID:TiSttWiL
落ちるなら、そちらのほうが万倍はマシでしょ
落ちなくて値が更新されないという恐怖
0209デフォルトの名無しさん
垢版 |
2020/01/18(土) 11:13:25.73ID:8BJKylNj
golangのシンタックスシュガーは思いつく限りだと
１． := での型推論による変数宣言の代替
２． レシーバがポインタ型の場合に構造体実体でメソッドを呼び出すと、ポインタに変換して呼び出す

C言語からの後方互換性を意識するなら -> は廃止しなけりゃいいのに、中途半端
モダンな言語と同じにポインタを参照と呼び替えて、実体が欲しけりゃunsafeでやれと
0211デフォルトの名無しさん
垢版 |
2020/01/18(土) 11:30:13.71ID:8BJKylNj
３． {フィールド:値, ...} 形式の構造体生成式
・・・これは構文だしシンタックスシュガーなのか微妙

シンタックスシュガー多めという意見は、どういう観点で構文をシンタックスシュガーだと判断しているのか俺にはサッパリわからない
むしろラムダ式(本来の無名関数という意味ではなく -> で書く記法)というシンタックスシュガーすらないgolangはむしろシンタックスシュガー少なすぎ（でもそこがシビれ
0212デフォルトの名無しさん
垢版 |
2020/01/18(土) 13:18:44.40ID:AhPxC9uw
シンタックスシュガーといえば、&Hoge{ ... }で構造体を初期化しつつポインタを取れるのに、&1はダメなのがウザい
0213デフォルトの名無しさん
垢版 |
2020/01/18(土) 13:46:22.20ID:4nVoSga0
シンタックスシュガーというか、なんか一貫性に欠ける略記法みたいなのが多いような
0214デフォルトの名無しさん
垢版 |
2020/01/18(土) 14:10:48.57ID:8BJKylNj
多いような、と言われてもなぁ
略記法と言っても、_ とか [::2] とかしかぐらいしか思い浮かばないんで、具体的に
0215デフォルトの名無しさん
垢版 |
2020/01/18(土) 15:16:24.10ID:6ictA0Lc
switch w := v.(type) はかなりエイリアン感あるな
Goに存在する数少ない型推論と言えるものの一つ
0217デフォルトの名無しさん
垢版 |
2020/01/19(日) 10:59:57.18ID:FsFcJUwr
一貫性に欠ける記述に思い至った
スライスとマップだけ生成すると実体ではなくてポインタを返す
やっぱり、構造体も生成するとポインタを返してほしかった
要らんよな実体
0218デフォルトの名無しさん
垢版 |
2020/01/19(日) 11:18:53.24ID:FsFcJUwr
要らないというのはちょっと正確性に欠けてた
普通のロジックを書く場合には要らない

DLL呼び出しとか、バイナリファイル書き出しとか、外部I/Fとして任意のアラインメントでのバイト列に直列化するパッケージがあって、内部では全て参照と言う名のポインタを扱うようにしてくれていたら何も問題は無かった
構造体ポインタでスライス作って、構造体のアドレスを入れて、という書き方を説明するためには、アドレスについて教えなけりゃならない
それを理由として新人研修の言語教育の候補リストから落としたんだった
0220デフォルトの名無しさん
垢版 |
2020/01/19(日) 21:41:47.53ID:K0reTlt5
構造体がポインタじゃないのなんでだろ
結局全部ポインタにしがち
イミュータブルな操作に値レシーバ使うことと整合させるため？
0221デフォルトの名無しさん
垢版 |
2020/01/20(月) 00:17:10.01ID:4Ml4H1E5
・構造体配列のアクセスがゲロ遅い
・GCに負担がかかる
・エスケープ解析が困難
・C/C++との相互運用時に>>218のような変換が必要になりクソ非効率だし実装も面倒
・nilを受け入れないことを保証できない
0223デフォルトの名無しさん
垢版 |
2020/01/20(月) 11:55:50.46ID:eiih9B9I
>>221
より良きアセンブラとしてC言語からの代替という目的だと、性能に対しての多少のコーディングしづらさはトレードオフの許容範囲ってことか
こりゃ、どうにもならないなー
>>208さんの言うように静的解析でガードするのが正解なんだな
0224デフォルトの名無しさん
垢版 |
2020/01/20(月) 13:14:26.10ID:0GX6odYx
Cと同じものが欲しいならCを使ってれば良いんだよ
0226デフォルトの名無しさん
垢版 |
2020/01/20(月) 15:43:03.96ID:lA6Ihl1+
GCが欲しかったんだよ
0227デフォルトの名無しさん
垢版 |
2020/01/20(月) 18:15:01.52ID:LSsGv7mq
静的解析でgolangci-lint導入してみた

そしたら gosimple が大量に felse == じゃなく ! 使えと
うるせー！年寄りには ! は見辛くて見逃すんだよ！！
どこだよ、オフする設定方法
0232デフォルトの名無しさん
垢版 |
2020/01/21(火) 19:27:40.22ID:o0UeX6qu
静的解析の余計な判定をオフする方法がわかったんで書いとく

// nolint:gosimple
とか行の後とか前行に書くとそこだけオフされる
設定ファイルでオフすると設定ファイルを公開する手間が増える
コードに書いておく方がベターだと思った
0240デフォルトの名無しさん
垢版 |
2020/01/24(金) 11:30:28.77ID:ytRnz1Ft
一時期Cの関数を検索したかっただけなのにphpのばっかり出て来たときは辟易した
0241デフォルトの名無しさん
垢版 |
2020/01/24(金) 16:05:17.82ID:UzV8rxSa
一時期旧日本海軍の軍艦の画像を検索したかっただけなのになぜか
萌え絵のおっぱいおねーさんばっかりでてくる、みたいな状況か
0242デフォルトの名無しさん
垢版 |
2020/01/24(金) 16:06:50.05ID:D9pKpEah
JULIAが最悪
0248デフォルトの名無しさん
垢版 |
2020/02/02(日) 01:44:28.81ID:EdXZobHi
頑張ってくれた先人には申し訳ないけど
古い情報がトップに出てくるのは悪影響しか無い気もする
0249デフォルトの名無しさん
垢版 |
2020/02/02(日) 19:09:21.25ID:iIujTevh
どこの言語も同じだよな

特にモジュール関係はどの言語もひどい有様で初心者が皆困惑して言語から離れる

一度使用固めたら不都合でも10年は同じものを使って欲しいｗ
0252デフォルトの名無しさん
垢版 |
2020/02/02(日) 22:01:03.97ID:N57GyRxf
みんなのGo買ったけど初心者向けじゃなくて読んでないんですが
本当に初心者向けの本ってありませんか？
0255デフォルトの名無しさん
垢版 |
2020/02/03(月) 12:03:18.74ID:62FLJlST
みんなのGoってオンラインで無料で全部読めるやつ？
0256デフォルトの名無しさん
垢版 |
2020/02/03(月) 12:29:31.57ID:YoBHNt10
>>252
改訂2版 みんなのGo言語、2019/8/1
この本は、各言語の「Effective 何々」に当たる本

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

>>246
に書いてある、翻訳プロジェクト、公式サイトの日本語訳
http://golang.jp/
は、エイベルの古川部長と社員が書いていた
0257デフォルトの名無しさん
垢版 |
2020/02/03(月) 13:10:43.80ID:gvFxJnFo
ガチの初心者がGoなんか使って何するのか、嫌味じゃなくて興味がある
Goは言語だけできても全く何の役にも立たないと思うが、
本来のGoのコンセプトの通りに、ペーペーにGoだけ覚えさせてアプリケーションコードだけ書かせるような組織が日本にも存在する時代になったのだろうか
0258256
垢版 |
2020/02/03(月) 16:01:19.93ID:YoBHNt10
サーバー側は、Ruby → Node.js, Go

今世紀最大の起業家、Vagrant の作者・Mitchell Hashimoto なんか、まさにそう。
今や、Go の重鎮

Ruby on Rails, Sinatra などで、サーバー側を一通り作った人が、Go へ行く。
そういうキャリアパスでは「みんなのGo言語」は、良い本
0259デフォルトの名無しさん
垢版 |
2020/02/03(月) 18:05:01.17ID:XimuQ1Xy
>>257
>Goは言語だけできても全く何の役にも立たないと思うが、

Goに限らず汎用言語はみんなそうだろ
標準ライブラリが充実してて言語の構成要素が少ないGoを
最初の言語として選ぶのは悪くない選択だと思うぞ
C/Java/C#/JavaScriptらと比べるとずっと簡単
0262デフォルトの名無しさん
垢版 |
2020/02/03(月) 19:53:53.66ID:fumIbgov
関数の引数で []*xxx と []xxx があるんですが、どっちを使ったらいいんでしょうか
0263デフォルトの名無しさん
垢版 |
2020/02/03(月) 20:45:13.09ID:eCgFnDlS
間違ってたらコンパイルエラー出るから、コンパイルエラーが出ないほう
呼んだ先の関数の引数の定義をよーく読め

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

[]xxxxは、xxxxがインターフェースでなく構造体だったなら、十中八九はバグだと思う
バグでなく意図的に使うケースもありはするけど………………
0264デフォルトの名無しさん
垢版 |
2020/02/03(月) 21:09:34.89ID:gvFxJnFo
>>259
もちろんライブラリやフレームワークの学習は前提だけど、
仮にプログラミング初学者がGo勉強して基本的なCRUDアプリを作れるようになったとして仕事あるか？
極端な話、初学者がSpringとかASP.NETとかRailsとか覚えたら、
サーバーを起動する方法もその上でアプリを動かす方法も知らなくても仕事はいくらでもあるわけだよ
一方Go名指しの求人って、ほぼ例外なく、複数言語が使えてAWSもわかるフルスタックな人が期待されてると思うんだよな
もちろんGoが使えたらプログラミングの素質はあるだろうってことでの採用はありうけど、
そうやって入った環境では多分Goを書かせてはもらえないだろう
0267デフォルトの名無しさん
垢版 |
2020/02/03(月) 22:08:48.44ID:XimuQ1Xy
>>264
同意するかは別にして言いたいことは理解した
そういう内容なら「Goは言語だけできても全く何の役にも立たないぞ」じゃなくて
「初学者がGoだけ習得しても仕事はないぞ」って書けばいいんじゃないかな
0271デフォルトの名無しさん
垢版 |
2020/02/04(火) 21:32:43.59ID:U30pp8jN
結局みんなと同じようにRuby on RailsとかPHPやっとけばいいんじゃねえのか
人と違うことしてる俺様かっこいいみたいなデスクトップのLinux使ってよく分からないエラー出ながら使ってる奴とか
そういうことじゃねえのかポインタとかスライスとか糞
[]xxxと[]*xxxをAPIのレスポンスで返したら同じjsonが返ってくるとか糞
普通ポインタの配列なんだからアドレスの羅列が返ってくるんじゃねえんか
マジ糞言語
0275デフォルトの名無しさん
垢版 |
2020/02/04(火) 22:39:33.05ID:Bi0juC3i
矛盾が少なくて必要最小限の仕様しかない、という意味ならC
だから未だに現役なわけで
俺はJavaScriptが好きだけど
JSもCと同様Alt-JSが大量に発生したものの殺しきれなかった、という意味ではある程度洗練はしている
言語としての問題は typeof(null)==="object" 位
0277デフォルトの名無しさん
垢版 |
2020/02/05(水) 00:01:28.88ID:+M89QQ88
＞[]xxxと[]*xxxをAPIのレスポンスで返したら同じjsonが返ってくるとか糞
ちょっと意味がわからないけど、要するにポインタレシーバでのインターフェースで実体も受け取れるという話じゃないかと思うんで同意
すんごくブッ飛んでるよなあれは……
0278デフォルトの名無しさん
垢版 |
2020/02/05(水) 00:11:37.94ID:+M89QQ88
JavaScriptも嫌いじゃないけど、ほぼほぼ毎年仕様が追加されていて着いていけない
prototypeで書いてもいいよね？bind使っててもいいよね？ダメ？
0280デフォルトの名無しさん
垢版 |
2020/02/05(水) 01:28:31.42ID:+M89QQ88
公式サイトですらgolangだもんな……

C言語よりは検索性に優れてるよ！w
甲乙じゃなくて丙丁つけがたい争い
0282デフォルトの名無しさん
垢版 |
2020/02/05(水) 09:21:05.78ID:jAnPlWtF
>>278
エアプかよ
さすがにbindがNGは今時ないと思うぞ

まあそうやって駄目な理由を探しているようではずっとエアプのままだろうよ
goが洗練されていないのは当たり前、新しい言語だからだ
何だかんだでJavaScriptは25年、Cなんて50年近いのだから、必要な仕様はとっくに入っている
JavaScriptでも、今追加されている仕様はそもそも「あってもなくてもいいもの」でしかない

それに比べて、まだgoは根本的な部分で仕様変更が為されている段階だろ
この意味では、今現在のgoをプログラミング初心者が触るのは間違っているとは言えると思うけど
お前も含めて
0283デフォルトの名無しさん
垢版 |
2020/02/05(水) 09:26:08.48ID:xGO7LiGl
糞じゃね言って同意って言われるのが終わってる
否定してほしくて敢えて過激なこと言ってるのに
0284デフォルトの名無しさん
垢版 |
2020/02/05(水) 11:25:45.04ID:xJPwpbdq
Goが気持ちいいのは、意識高い先人達が築き上げてきた無駄に複雑な数多の概念を「Goだから」で一蹴できるところ
例えばテストコードの assert that 系のDSL
誰もが薄々糞だと気付いていたが、意識高い空気がそれを許さなかった
それを堂々と「こんな糞は要らんかったんや！ifでええんや！」と言えるお墨付きが貰えた
Goが数々の欠点にも関わらず言語として好まれた本当の理由は、そういうカタルシスにあると思うわ
0286デフォルトの名無しさん
垢版 |
2020/02/05(水) 11:38:29.79ID:jAnPlWtF
>>284
それは一理ある
公式でも言っているとおり、Goは敢えてガラガラポンしている
多分、いわゆる「お作法」に辟易している若くて元気のいい奴に受けているのだと思う
だから「結果的に再発明になってもいい」と思える奴等には良いプラットフォームだろう

(なお俺はassertなんて使わないことは一応付け加えておく)
0290デフォルトの名無しさん
垢版 |
2020/02/05(水) 14:30:53.97ID:qmME163k
文字関連のライブラリとかかなり雑と言うか古臭く感じる
cから発展したともとれるが嫌な感じだな

uint64を文字列にするのもいまだにググって調べてる
0292デフォルトの名無しさん
垢版 |
2020/02/13(木) 21:15:58.79ID:T5TlK5HS
>>284
俺みたいな老害Cプログラマがマウント取りまくれる言語仕様なんだよね
例外とかいらん！オブジェクト指向もいらん！
スクリプト言語のおしゃれ感もいらん！
0295デフォルトの名無しさん
垢版 |
2020/02/13(木) 23:49:11.45ID:TfOBxj3E
goroutine周りは記述が簡便で初心者も手を出しやすい雰囲気を醸し出してるのに、実際には低レベルで罠が多いんだよなあ
これだけ徹底的な低能仕様なのにデッドロックに対する安全機構のようなものが何もないのはいかがなものか
せめてpromise的なのくらいは欲しい
0297デフォルトの名無しさん
垢版 |
2020/02/13(木) 23:59:19.40ID:WnzNNrEx
Goの非同期機能の公式の説明で共有メモリは危険だとかドヤ顔で講釈垂れてる割には
ちょっとchannelの扱いをミスると簡単にデッドロックするんだよな
Goの設計のセンスは基本的には素晴らしいと思うけど、
非同期処理の難しさに関してはGoをもってしても効果的な解決法を見つけられなかったのは残念だな
0316デフォルトの名無しさん
垢版 |
2020/02/27(木) 01:35:23.22ID:G3iz3let
>>297
とりあえずブロックするって方向はそんなに悪くはないと思う。
あとはブロックされてリークしたgoルーチンの回収をどうするか。
0319デフォルトの名無しさん
垢版 |
2020/03/03(火) 06:54:36.36ID:FZdU/a7Y
「つまらないアンケートに答える層が使っている言語」の統計
FORTRANより下に主流の言語があるのがなかなか
0320デフォルトの名無しさん
垢版 |
2020/03/03(火) 15:18:27.96ID:XIdDQCX/
C/C++いまだに多いけどどういう人が投票してるんだろう
統計でデタラメな誘導するのはやめて欲しいよ
0321デフォルトの名無しさん
垢版 |
2020/03/03(火) 15:55:28.64ID:2rm+3KZn
お前らが見慣れてるような言語ランキングだって相当なバイアスがかかってるだろう
日本の実情としてはまあ納得できるランキングだと思うけどな
むしろこの面子でGoが意外と健闘してるのは驚き
C/C++が多いのは、業務システム分野では互いに競合する言語が比較的多いのに対して、組み込みや制御の分野の中では代替が事実上存在しないからだろうね
0322デフォルトの名無しさん
垢版 |
2020/03/03(火) 17:03:27.84ID:dzRX5ub5
Rubyは始まりも、オワコンなのよ
そうよ、Perlと共にお墓に向かってるの
どんなときでも時代はPHP♪
homubrewもrubyを切り捨てた現実を受け入れなさい！
0327デフォルトの名無しさん
垢版 |
2020/03/07(土) 22:21:25.44ID:NtlWTdSr
今の現場、DBが完全にDynamoDB（KvS）に移行したぞ
リレーショナルデータベース使わなくなった
0328デフォルトの名無しさん
垢版 |
2020/03/08(日) 02:34:50.44ID:4UY9QB9Z
いくらサービスのOLTP系のDBがDynamoDBオンリーでも、会社なら業務系のDBとかデータ分析用のDWHとかあるしWebエンジニアでもたまにはそういうところ触ることもあるだろ?
お前の狭い業務では使わなくなった、の間違いだ
0330デフォルトの名無しさん
垢版 |
2020/03/08(日) 04:52:01.22ID:upYPFzc2
それにしても使えば使うほどクソさが見えてきて
嫌悪しかでてこない言語だなgolangは
0332デフォルトの名無しさん
垢版 |
2020/03/08(日) 13:05:02.79ID:Y2NtS7Rm
>それにしても使えば使うほどクソさが見えてきて
これはほぼどの言語にも当てはまらなくはない

>嫌悪しかでてこない言語だなgolangは
個人の主観です
0333デフォルトの名無しさん
垢版 |
2020/03/12(木) 09:34:07.31ID:Ebv8j1sh
Kotlinは使えば使うほど良いなと思う
サーバーサイドもKotlinの世界になればいいのだ
0334デフォルトの名無しさん
垢版 |
2020/03/12(木) 12:44:20.39ID:anpcnzvY
ちょっと鮮度が落ちた話だけど Let's Encrypt が幾つかの証明書を無効化する羽目に
その原因がgolangあるあるの、実体配列ループでコピーしたオブジェクト書き換えてたバグらしい
実体配列ってクソだな
0337デフォルトの名無しさん
垢版 |
2020/03/13(金) 05:59:29.90ID:Rzi4PTPR
pythonのほうでも、旧アマ driveを便利に使えるようにする一番有名だった
3rd partyツールが、関数に渡す引数の扱いを間違えて別の人のファイルが
見えるようになったりしてたけどね
旧driveの容量無制限と3rd partyへのAPI解放をやめさせた遠因
0338デフォルトの名無しさん
垢版 |
2020/03/14(土) 11:58:15.74ID:uur41bNT
>>333
goとcとphpしかやったことないんだけど、Kotlinええの？
0339デフォルトの名無しさん
垢版 |
2020/03/14(土) 12:17:59.41ID:QJEYt0Xf
>>333
Javaランタイムで動かす別言語だと思ってたが、サーバでは使えんの？
そもそもgolangスレで発言した意図がわかんない
Javaスレに行けば？
0340デフォルトの名無しさん
垢版 |
2020/03/14(土) 14:12:55.38ID:vQxdnG1j
コンテナ時代にJavaはなあ
Java系はそのエコシステムの中だけで完結するからこそ意味があるんだよ
そもそもJavaプラットフォームは十分にポータブルで、コンテナのような低レイヤの抽象化を必要としない
Javaをコンテナに閉じ込めて動かすのはJavaの全盛期を知る者としては屈辱だよ
0341デフォルトの名無しさん
垢版 |
2020/03/14(土) 14:50:10.22ID:XTUayws2
WSLは許せるのか
0343デフォルトの名無しさん
垢版 |
2020/03/15(日) 08:43:01.20ID:8J0oZhmC
javaの欠点はメソッド名が長すぎ
何をするにも面倒臭い
アレとアレをつなげてコレとコレをつなげてやっとこさHellow World
0345デフォルトの名無しさん
垢版 |
2020/03/27(金) 23:34:18.93ID:D2Bp07zH
Java馬鹿にしてるやついるけど

if err != nil をコピペしまくる言語よりかはダサくないよ（笑）
0346デフォルトの名無しさん
垢版 |
2020/03/28(土) 00:54:18.47ID:FwiSGISO
JavaをバカにしていいのはC#とかの直系親族かなー
でも御先祖様だから敬わないと
golangから見てそれこそカブる部分が少ないんで他所の御家庭

でもVBさんちは何とかしてほしいと思ってしまう自分を許して
0348デフォルトの名無しさん
垢版 |
2020/03/28(土) 13:55:52.36ID:0D5kTPqj
Javaがバカにされるのはそれを使っているプログラマのせいじゃないかと思う。
企業需要が大きいから促成栽培のドカタが量産されたという。

純粋に言語として評価したら、CやC++の問題点をよく研究している印象なんだがな。
0349デフォルトの名無しさん
垢版 |
2020/03/28(土) 14:41:47.75ID:+WXFsbEZ
ダサいと感じるかどうかは人それぞれだが
エラーハンドリングのボイラープレートが
どうしようもなく多いのは事実だよね

Go2に期待してたんだがな
0350デフォルトの名無しさん
垢版 |
2020/03/28(土) 14:51:39.39ID:rPoOVFdT
Goのやり方の是非はともかく、例外がいつどこから飛んでくるかわからない「漠然とした不安」がないのはいい
あの不安は少なからず脳の働きを阻害して生産性を下げてると思うわ
0351デフォルトの名無しさん
垢版 |
2020/03/28(土) 18:25:33.89ID:1J/Yumyc
書く量が多くなるとかそれぐらいは別にいいんだけどさぁー
どうせコピペするだけだし(笑)
最初にエラーハンドリングはそこまで要らないなと思って書いてたコード群が
後で扱うデータの仕様変更があってエラーハンドリングが必要になったときに
ガッポリその部分覆ってまとめてエラー扱うってのが一切できないんだよな
こうなってしまうと全部のコードリファクタしないといけないしなんなら
個別のロジックまで追いかけて問題ないかチェックしないといけなくなる
こういうところがgoはクソなんだよな
0352デフォルトの名無しさん
垢版 |
2020/03/28(土) 18:48:45.17ID:Agae4kCA
> 最初にエラーハンドリングはそこまで要らないなと思って書いてたコード群が

単に見通しが甘いだけなんじゃないか
0354デフォルトの名無しさん
垢版 |
2020/03/29(日) 01:28:26.45ID:vMR/aJN9
>>352
だから何？
お前が見通してくれるわけじゃないなら黙ってろよ
0357デフォルトの名無しさん
垢版 |
2020/03/29(日) 09:36:10.09ID:ryRl/n6a
>後で扱うデータの仕様変更があってエラーハンドリングが必要になったときに
>ガッポリその部分覆ってまとめてエラー扱うってのが一切できないんだよな

これ自体が例外ありきの発想のように思う
0358デフォルトの名無しさん
垢版 |
2020/03/29(日) 09:50:09.28ID:DYy7qpQK
Goだと極一部の簡単な関数を除けば基本的にerrを返すから、後でerr発生箇所が増えても影響は関数一つだけだろう
それが問題になるようなアホみたいに長い関数を書いてるならそれ以前の問題だな
0359デフォルトの名無しさん
垢版 |
2020/03/29(日) 10:32:30.34ID:a0L6N7lT
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
0360デフォルトの名無しさん
垢版 |
2020/03/29(日) 12:46:52.07ID:+4DfA9hG
vscode で if err!=nil のブロックをデフォルトで折り畳んでくれたら、おれは嬉しい
0361デフォルトの名無しさん
垢版 |
2020/03/30(月) 01:14:32.45ID:QPHAwv8T
err返すくせに型に現れないのは正直ゴミ
0363デフォルトの名無しさん
垢版 |
2020/03/30(月) 03:48:40.78ID:QPHAwv8T
またお前かって初めてこのスレに書き込んだんだが
そういって一生ゴミ仕様から目を背け続けろな
0366デフォルトの名無しさん
垢版 |
2020/03/30(月) 11:27:55.23ID:LyRXd+nE
errさんはPHPしか触ってこなかったから気にしないんだよ
0367デフォルトの名無しさん
垢版 |
2020/04/01(水) 02:09:08.12ID:aJRtEUWu
Cだともっと酷いよ？
戻りでエラー返すと本来の戻り値が潰れるから
&errorとかいう独自定義のエラー用構造体を引数に毎回渡す
これに比べたら天国
0368デフォルトの名無しさん
垢版 |
2020/04/01(水) 10:12:05.33ID:0Fs3VJge
Goは標準ライブラリが豊富っていうけどどこらへんが豊富なの？
Goは並行処理が得意なのに並列処理が得意とか実際に触ってるわけでもないのに書く人多いから豊富ってのも嘘なんじゃないかと思ってる
0370デフォルトの名無しさん
垢版 |
2020/04/01(水) 10:49:13.13ID:5VJq6KKK
>>367
GetLastError
エラーを取得するには関数を使います
0372デフォルトの名無しさん
垢版 |
2020/04/01(水) 12:24:45.60ID:mttQXJSO
Cだと戻り値でデータ返したりエラーコード返したりやりたい放題で一貫性が無さすぎ
Javaとかはtry catch地獄
Cでレジスタで戻り値返さずに複数値返せる設計にしてれば標準となって皆幸福だったのに
0373デフォルトの名無しさん
垢版 |
2020/04/01(水) 12:30:21.07ID:vhJXsBKc
最近のは(小さい)構造体なら返せるやろ
デカいのは無駄だし
mallocしたのだと解放が面倒だが
0374デフォルトの名無しさん
垢版 |
2020/04/01(水) 14:22:10.98ID:BVkSt5Rw
>>372
ハードウェアの構造無視しすぎ。
それでみな幸せならとっくにそうなっとるわ。
cでもスタックの使い方の規約なんて昔と相当変わってる。
0377デフォルトの名無しさん
垢版 |
2020/04/02(木) 08:03:50.65ID:I1YrR7G1
>>374
ん、その昔の段階で戻り値の返し方で言語仕様的に一工夫してくれてたらという正直ムチャ振りなレスだったんだけど
0378デフォルトの名無しさん
垢版 |
2020/04/02(木) 17:36:34.36ID:iZOXAvDa
Goって複数の戻り値はスタックにおいてるのかね？
その辺どうなってるんだろう
0379デフォルトの名無しさん
垢版 |
2020/04/02(木) 21:18:47.20ID:Fd9E2tX0
コンパイル時にサイズが決まるならスタックに積んで返すのは難しくないだろう。
今どきCでも構造体を返したりできるし。
0380デフォルトの名無しさん
垢版 |
2020/04/14(火) 13:45:39.46ID:/GVdva5P
老人介護用言語すぎてストレスしかない
なんで今の御時世にこんな微妙な言語使わなければならんのだ
ポインタ意識したりするよりドメイン層の設計に時間を割いたほうがマシだわ
はぁ…
0382デフォルトの名無しさん
垢版 |
2020/04/14(火) 13:58:34.65ID:VpWClbHP
どの言語にも言えるけど
全ては実験台でしかない
0383デフォルトの名無しさん
垢版 |
2020/04/14(火) 14:26:34.45ID:/GVdva5P
権限だけ持ってる考えなしの馬鹿が採用を決めたせいで無理して使うしかないんだわ
トラップ多くてその調査のせいで学習コスト跳ね上がるし
並列処理簡単って動かすだけならそりゃ簡単だろうが…ってレベルの完成度の低さで
CPUフルで使い切るような事やらせようと思ったら面倒さも管理も段違いの面倒さ…

愚痴はまぁともかく、structって脳死して全部ポインタで扱うほうがいいんけ？
というかstructに実装持たせるような意識なんて投げ捨てて旧石器時代を目指すほうが良い言語？
0384デフォルトの名無しさん
垢版 |
2020/04/14(火) 14:32:51.20ID:ARe9d0+J
あくまで関数が主体であり、structはオブジェクト指向的な実体というより、単なる文脈と考えればいい
Rustも同様の考え方だし、C#なんかも最近はそういう方向へ進みつつある
善し悪しはともかく最近の流行りではある
0385デフォルトの名無しさん
垢版 |
2020/04/14(火) 14:38:21.41ID:Nk5zmway
>>383
基本的にはちょっと楽なCだからね
まともなC使いは第一引数にオブジェクトのポインタわたしてたし
継承も構造体使って同じことしてた
むしろC使いは理想的な言語を作ってくれた！と思ってる
0386デフォルトの名無しさん
垢版 |
2020/04/14(火) 17:35:01.14ID:pIyDz3cF
>>383
CPUフルに使いきるなら素直に別プロセスにして上位レイヤーで分散するよう工夫したほうが結局コスト安く済むような印象がある
まあWeb系じゃないならそうは行かない場合もあるんだろうけど
0387デフォルトの名無しさん
垢版 |
2020/04/14(火) 17:47:59.69ID:Nk5zmway
ハイパースレッディング的にCPUを並列化したいならGoなんで使うものじゃないよ
0388デフォルトの名無しさん
垢版 |
2020/04/14(火) 17:55:25.26ID:6iFFCKsF
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
0390デフォルトの名無しさん
垢版 |
2020/04/14(火) 22:32:46.86ID:mT2xysIe
golangのポインタ周りはrangeでイラっとしたくらいだわ
他はわかりやすいし使いやすい印象
0391デフォルトの名無しさん
垢版 |
2020/04/15(水) 00:46:12.61ID:cYQn0cTu
いやいや・・ポインタも構造体の実体からもアクセスがどっちも . とか
トラップすぎて草はえるわ
そりゃさだいたいは問題ないよ、だけどな大体のとこは良いけどたまーに
罠にハマるっていうパターンの問題が一番やっかいな罠になるもんなんだよ
そんな中途半端なことするぐらいならいっそハナから面倒なままにしてくれるか
あるいはしょうっちゅう問題が起きるから常に注意して書く必要がある、ぐらい
のほうがよっぽどマシ
GO言語はこの「だいたいいいけどたまに罠」がクソ多すぎてほんとクソ言語だよ
0392デフォルトの名無しさん
垢版 |
2020/04/15(水) 01:09:47.19ID:GWGZY8rP
　 /＼＿＿_／＼
／　／　　 　ヽ ::: ＼
|　（●）,　、（●）、　| 　　 ／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ 　 .:::::| 　　 ＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼
0393デフォルトの名無しさん
垢版 |
2020/04/15(水) 02:17:30.11ID:aGpPkdQy
全部ポインタにしてるわ
現代のアーキテクチャからしたら明らかに遅くなりそうだが
C脳だから全部ポインタw
0394デフォルトの名無しさん
垢版 |
2020/04/15(水) 03:27:51.37ID:j+vnhNUd
全部ポインタは無駄処理増えてパフォーマンス的に良くないようだけど
そうした方が言語トラップを回避できる可能性が高いって時点でうんこであることは間違いないと思うよ
コードをひと目見てすぐ問題があると判断できないようなトラップが散りばめられてて学習コストが低いとか嘘だわ

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

言語の決定権がなく仕方がなく使ってるけど、全てを把握できてて自分以外が触らないような
単機能の小さいツール作るくらいの用途くらいでしか使いたくない言語って感じで、書くほどストレスが溜まっていくぜ…
これを絶賛する人たちが本当に最高だと思ってるのかマジでわからんくなる…
0395デフォルトの名無しさん
垢版 |
2020/04/15(水) 04:05:18.88ID:aGpPkdQy
今Go使ってる人はなんちゃっての人は少ないからねえ
まともにGoやってますって人の少なさよ
0396デフォルトの名無しさん
垢版 |
2020/04/15(水) 07:24:14.59ID:pyZsKR91
はて、ポインタで無駄処理ってのは聞いたことないな

アセンブラのレベルから見ると、実体って概念は配列要素へのアクセスを先頭からの相対位置で行うという、限られた局面でしか現れないもの
あ、自動変数の実現としてスタックを積んでスタックボトムからのオフセットを使用するのは一般的ではあるか
ともかく実体渡しはCとかあの辺りの言語で実装された二次的なもので、あくまでポインタの糖衣構文じゃないの？

俺が最近のCPUを知らないからトンチンカンなのかな？
ベクタ計算がプリミティブに使われない限り、よりマシンに近い記述がポインタだと理解しているんだが
0397デフォルトの名無しさん
垢版 |
2020/04/15(水) 11:39:38.66ID:Y2mip1WI
せっかくのキャッシュなのに
キャッシュ捨てまくりが発生
0398デフォルトの名無しさん
垢版 |
2020/04/15(水) 11:42:52.38ID:002QZQQA
ちゃんと読んで答えてるっぽい奴居て草
今君は川に流れてるウンコを態々拾いに行ったのだ
ばっちぃから触っちゃ駄目だろ、ちゃんと反省しろよ
0400デフォルトの名無しさん
垢版 |
2020/04/15(水) 19:49:21.31ID:pyZsKR91
>>399
それが何で遅くなるのか理解して言ってるか？
ポインタが無駄な処理になるからじゃなく、メモリアクセスとメモリ管理を最適化するため
実体配列のニッチな需要があるかぎりは実体は廃止できないという意見

正直、そういう需要なんて切って捨てていいと思う
Javaみたいに
0401デフォルトの名無しさん
垢版 |
2020/04/17(金) 18:19:15.53ID:fJoVda10
Javaはスレッド跨ぐ場合はスレッドごとにコピーした値をキャッシュしたりはしているし
それで起きる問題を回避するための手段も用意されてる

Goがただ面倒くさいゴミ言語って話でJavaを例えに上げるのは理解してなさそうに見えちゃわない？
0404デフォルトの名無しさん
垢版 |
2020/04/18(土) 08:06:56.22ID:dJZrVSnf
Go製のキラーアプリであるDocker
それをRustで書き直すって話無かった？もう公開されてる？
厳密なコンテキスト操作がGoでは実装できないからって
それとも自分の勘違い？
0405デフォルトの名無しさん
垢版 |
2020/04/18(土) 10:25:08.47ID:xaEKv27U
Dockerの記述言語なんて使う分には関係ないからキラーアプリとは違うような。
0406デフォルトの名無しさん
垢版 |
2020/04/18(土) 17:50:04.38ID:0gvlJnyA
コンプライアンスに即した範囲でできるテレワークって事で
最近「他社ゲームのアーキテクチャを調査」ってタスクをやったんだけど
Golangは無いね。Node.jsばっか
個人的にはgo使いたいから、家にいる期間になんか一個作りたいけどなぁ…。
0407デフォルトの名無しさん
垢版 |
2020/04/18(土) 18:26:19.74ID:ZX/dL4qt
ゲーム会社でもコンプライアンスの関係でテレワークできない業務なんかあんの？
少なくともゲーム会社よりはお堅い会社に勤めてるけど、全部在宅で何の問題もないな
コードは主にNode.js(オンライン)とPython(バッチ)で、オンラインについてはGoへの書き直しを進めてる
0410デフォルトの名無しさん
垢版 |
2020/04/18(土) 19:32:53.45ID:/YIE32O/
windowsとlinuxで動かさなきゃいけないアプリをJavaで書いてて
全く問題なかったんだけど
実質有償化に伴って他の言語で書き直そうかと思ってるけど
Goってwindows上でも安定して動くのかね？
ちなみに24時間稼働しっぱなしのアプリ
0414デフォルトの名無しさん
垢版 |
2020/04/18(土) 20:33:06.29ID:nL76etRG
>>406
CATSってスマホゲーがサーバーにGoを使ってるらしい
サーバーにちょくちょくアクセスしながら動作してるんだが、めっちゃ速いよ
この辺はスピンアップが爆速な恩恵なのかも
0418デフォルトの名無しさん
垢版 |
2020/04/18(土) 21:20:46.34ID:0gvlJnyA
>>414
個人的興味でちょっと見てみるわ

>>415
そういう調査じゃなくて
スライドシェアとかの公開資料のまとめ
正直引き続き契約延長いただいてありがとうございますというレベル
この状況がまだ続くんなら、流石に家でもほんとに作業するように変わるんじゃないかと思うけどね
または切られるかだな…
0420デフォルトの名無しさん
垢版 |
2020/04/18(土) 22:33:18.98ID:7LGZx49d
今のC#知らない人多そう
特定の言語に拘らず積極的に情報収集した方がいいと思うけどね
スレチだからここまで
0424デフォルトの名無しさん
垢版 |
2020/04/22(水) 17:15:41.53ID:2MssAlkL
流石にJavaやScalaからGo移行とかになるとあまりの言語機能のゴミっぷりに開発者がキレそう
今までハサミつかって紙きってたのに石器渡されるようもんだわ
0425デフォルトの名無しさん
垢版 |
2020/04/22(水) 17:57:25.70ID:gFNuxdvi
　 /＼＿＿_／＼
／　／　　 　ヽ ::: ＼
|　（●）,　、（●）、　| 　　 ／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ 　 .:::::| 　　 ＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼
0426デフォルトの名無しさん
垢版 |
2020/04/22(水) 18:22:16.77ID:LU+JwGqd
この言語はCでサーバを書いているようなニッチな要求の仕事を置き換えるんだろうな

なに？そんな仕事があるわけない？
…去年回って来ちゃってたよ、そんな仕事が
ミリ秒縛り要求で数十の機器の管制をするサーバ
当時はgo知らなかったんでgccで書いた
0427デフォルトの名無しさん
垢版 |
2020/04/22(水) 19:29:43.68ID:5I5B70Wh
リアルタイム性重視なら、GCあるGoは向いてないんじゃ
その用途で置き換えるならRustになりそう
0429デフォルトの名無しさん
垢版 |
2020/04/23(木) 00:05:34.25ID:b8mXccsZ
鯖は比較的余裕有るけど、クライアント側でGCが痛い子になる事はありそう
Rustは半日では無理だなぁ〜、概念は直ぐ理解出来るけど書き方に統一感無さ過ぎてキレそう<'a>&'a *ref
0432デフォルトの名無しさん
垢版 |
2020/04/23(木) 08:01:42.02ID:6AabYYA1
Rustはバカ速いとか聞くから覚えたいんだけど
学習コストもバカ高いよなぁ
CとかPascalやっててJavaを始めたときの倍くらい大変な感じがする
C#はJavaを丸パクりで基本構文ができてたから、１日
0434デフォルトの名無しさん
垢版 |
2020/04/23(木) 08:41:47.89ID:Q66hfIcW
rust、利便性のためにライフタイムの省略パターンとか作ったんだろうけれど、逆にわかりづらくなってるわ。
0435デフォルトの名無しさん
垢版 |
2020/04/23(木) 10:29:03.11ID:6AabYYA1
>>433
クラスの定義の書き方とかもだよ
Javaでない言語のクラスの書き方は、クラス定義にはメソッドの宣言を書いて、定義の外で実装するスタイルが主流だった(他の言語には無いとは言わないが非主流)
これはC++とかObjectPASCAL、そしてGoもこちらのスタイルではある

C#では、基本的にデフォルト仮想なJavaメソッドに対して、デフォルトは非仮想って程度の差(充分にでかい差ではある、ちなみにジェネリックはまだない時分)
だから、覚えるというより慣れるのに１日
SalesforceのAPECはまた面白くて構文はC#以上にJavaなのにデフォルト非仮想だったかな
よく似た兄弟すぎて、仕事とプライベートそれぞれ違う言語で書いてると混乱する
0437デフォルトの名無しさん
垢版 |
2020/04/23(木) 10:37:35.02ID:6AabYYA1
>>433
ああ、そういえばCとかではエントリがmain関数だったのが、クラスになっているスタイルもJavaで覚えた
そのためC#でもほぼ同じだから、そこで引っ掛かることが無かった
そういう観点であってifとかforなどの構文じゃないよ
0440デフォルトの名無しさん
垢版 |
2020/04/23(木) 10:55:50.60ID:3P7Oolim
JavaとC#では技術スタックが全然違うだろう
サーバーの構築から通信方法からフレームワーク等の選定から何から、
そういう足回りを全部すっ飛ばして全部あらかじめ他人に与えられた環境を使って
「さあ、アプリケーションコードを書いてください」ならそら大差ないだろ
俺は436じゃないが「コーダー」ってそういう意味じゃないかな
0442デフォルトの名無しさん
垢版 |
2020/04/23(木) 14:11:43.18ID:6AabYYA1
出だしが学習コストの話で、人格攻撃やらサーバの構築とか的外れな事を言い出してくるやら
詭弁術だけはお得意なことはよくわかりました
0443デフォルトの名無しさん
垢版 |
2020/04/25(土) 02:28:33.10ID:wAZrgsxC
ギスギスしててワロ
Goは誰でもある程度のレベルくらいまでなら使いこなせる優しい言語
0444デフォルトの名無しさん
垢版 |
2020/04/26(日) 19:49:45.56ID:xNjL7Ex+
ものすごく当たり前の落とし穴に落ちた

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

インタフェースが同じなら同じものとして使えるってことは、そういう問題を想定しとかないとならなかった
0445デフォルトの名無しさん
垢版 |
2020/04/28(火) 19:31:28.17ID:Ce9HOSET
大きくなってきたんでパッケージを分割

設定とか全体を管理するAパッケージ
httpのリクエストを管理するBパッケージ
webAPIのロジックを管理するCパッケージ
ロジックのインスタンスは設定で作って、リクエストから呼び出して処理してもらう

さて、ここで落とし穴
Cパッケージから設定を参照するためにAパッケージをインポートすると import cycle not arrowed 発生
AパッケージではCパッケージをインポートして、ロジックのファクトリを呼び出してる

インポートの循環の制約とか、それは厳しすぎやしませんかね
第三の上位パッケージを作ればなんとかなるのかなぁ？
0447デフォルトの名無しさん
垢版 |
2020/04/28(火) 20:31:42.46ID:ghSBG3zr
>>445
Goに限らずモジュール境界はインタフェースで抽象化するもんじゃ？
そうしないとユニットテストつらい
0448デフォルトの名無しさん
垢版 |
2020/04/28(火) 20:48:56.59ID:SLRJSTJf
> 設定とか全体を管理するパッケージ
インターフェース云々以前に、そんなふわっとしたモジュール強度の低いパッケージが存在することが問題
設定なら設定で分けろ
設定はデータ構造自体がインターフェイスなんだからカプセル化とか要らん
0450デフォルトの名無しさん
垢版 |
2020/04/28(火) 22:00:57.39ID:Ce9HOSET
>>449
ロジックのインタフェースの実体を得るファクトリ関数なんだがおかしいのか？

でも、そもそもが設定情報のパッケージにシステムを管理するデータの生成を担わせてる設計が原因臭いとはうすうす
やっぱそこを別パッケージに分離して結合を弱めないとだめだな
0451デフォルトの名無しさん
垢版 |
2020/04/28(火) 22:23:30.36ID:Ce9HOSET
結局、日和ってロジックのインスタンスはCパッケージにシングルトンとして実装してBから呼ぶことでallowedを回避した
根本的な解決ではないが、動けばいい！(うわっ自分で言ってて恥ずかしい
0452デフォルトの名無しさん
垢版 |
2020/05/01(金) 06:16:44.51ID:txiwXjh+
VScodeなのかdelveなのか、デバッガでスライスを見たとき64個までしか見えません
どこの設定を弄れば最後まで見せてもらえるのか、調べてみたけれど分かりません
→ githubのgo-delveとかvscode-goとか
このカスタマイズについて情報があれば教えてください
0453デフォルトの名無しさん
垢版 |
2020/05/01(金) 11:36:26.80ID:txiwXjh+
各プラットフォームのランタイムのせいだろうとは思うけど・・・
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).
って書いてあるよ・・・
0454デフォルトの名無しさん
垢版 |
2020/05/01(金) 11:43:36.06ID:txiwXjh+
ああっ
The built-in functions len and cap take arguments of various types and return a result of type int.
だからなのか

いいのかそんな仕様で
0455デフォルトの名無しさん
垢版 |
2020/05/01(金) 12:06:06.92ID:Ia4c8IgS
Goではintのサイズと配列の最大長は環境依存だからそれで正しい
そして、CopyはWriteを一発呼ぶだけじゃなくて指定された長さをコピーし終えるまで読み書きを繰り返すように実装するもの
だから配列の最大長とか無関係
やってることが全然違うんだから一貫性もクソもない
0457デフォルトの名無しさん
垢版 |
2020/05/01(金) 13:10:50.80ID:txiwXjh+
>指定された長さ
ダウト
Copy見てきてください

こいつはReaderからバイトストリーム(厳密には意訳)をEOFに達するまでWriterに書き込み、その書き込みバイト数を返します
サイズなんて指定しません

Writerに書き出すソースが固定のスライスではないだけで、Writerに書き出すという目的から見ればWriteと同じでしょ
まあ違うとあえて言うなら、私とあなたは考え方が違うんでしょうね (私は「何をするか」という目的で言ったので)
0458デフォルトの名無しさん
垢版 |
2020/05/01(金) 23:48:52.57ID:txiwXjh+
log.Logger の出力でファイル名も出させるようにして気づいたけど、ソースファイルのパスって実行ファイルの中にしっかりと記録されてる？

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

完全パスで困るのはユーザ名がしっかり出ちゃうことなんだよな
それが嫌ならユーザディレクトリで開発するなという事なのか
0459デフォルトの名無しさん
垢版 |
2020/05/02(土) 08:59:25.19ID:+Au1iQ6P
みんなはGW中は嫁さんとセックスしまくりなの？
独身の俺からすると羨ましいんだけど
0461デフォルトの名無しさん
垢版 |
2020/05/02(土) 14:11:11.13ID:H63qqmuN
セクロスはセフレとしかしないな
0464デフォルトの名無しさん
垢版 |
2020/05/02(土) 14:26:10.42ID:jSLKT64y
　　　　　　　　∧∧　　ミ　＿　ドスッ
　　　　　　　 (　 　,,)┌─┴┴─┐
　　　　　　　/　　　つ.　 終　 了 │
　　　　　〜′　/´　└─┬┬─┘
　　　　　　∪ ∪　　　 　 ││　_ε３
　　　　　　　　　　　　　　 ゛゛'゛'゛
0467デフォルトの名無しさん
垢版 |
2020/05/02(土) 17:53:36.77ID:+BhrZUVp
常駐しつつ標準入力からのコマンドを受け付ける構成のプログラム書いてる
だけど、デバッグターミナルからの標準入力はサポートされないんだな(vscode-go/
issues/219)
VScodeの問題かと探したのにdelveの問題？
0468デフォルトの名無しさん
垢版 |
2020/05/02(土) 17:56:31.80ID:+BhrZUVp
ちなみにシグナル使えという話は横に置いといてね
os.Interruptとかのハンドリングはもう入ってる
Windowsでkillしても受け取らないんだこれが
0471デフォルトの名無しさん
垢版 |
2020/05/08(金) 09:28:21.26ID:/imhMepR
ところどころ抜けてて口頭説明前提の作りで肝心な内容が無い資料公開されてもな
0472デフォルトの名無しさん
垢版 |
2020/05/08(金) 09:47:37.47ID:oIDbptWL
>>469
ʕ ◔ϖ◔ʔ
ありがたや

人
0475デフォルトの名無しさん
垢版 |
2020/05/08(金) 16:04:03.09ID:SpWQlQbz
言語仕様より標準ライブラリのクックブック的な本が充実して欲しいかな
結局Goのソースやテストコード読まなきゃ使い方がわからないのが多過ぎるし
0476デフォルトの名無しさん
垢版 |
2020/05/08(金) 18:12:47.83ID:QcJ6udj9
>>475
みんなのGoは、flagパッケージとかの使用例が役に立った
よく言われるように初心者向けではないだろうなとも思った
0477デフォルトの名無しさん
垢版 |
2020/05/08(金) 22:59:05.96ID:tAyMPd7a
Golang逆引きレシピ（version1.14対応）

って本出してくれ
kindleで5000円までなら買う
0480デフォルトの名無しさん
垢版 |
2020/05/09(土) 19:27:11.31ID:CUL9xwyE
開発陣のモチベーションはどうなんだろう。
なんかrubyと同じような臭いが。
0481デフォルトの名無しさん
垢版 |
2020/05/10(日) 09:38:46.23ID:XQ0sO87J
サーバで使われることが割と一般的なコンパイル言語（Java以外）って
Go以外になんかあったっけ
0482デフォルトの名無しさん
垢版 |
2020/05/10(日) 11:01:30.61ID:hDQHcieg
apache は何でコンパイルされてる？
0487デフォルトの名無しさん
垢版 |
2020/05/10(日) 15:35:37.07ID:FhPtT+Xo
コンパイル言語で伸びそうなのはKotlin
0490デフォルトの名無しさん
垢版 |
2020/05/13(水) 07:56:28.24ID:p0Yu02SZ
Goは学習コストが少ないっていう嘘に騙されてるやつとそう信じてる信者が多いのが最大の失敗
コード読むだけじゃ見落とすような罠が簡単につくれるし直感的に分かりづらい仕様と機能不足が多すぎる
書き捨てるだけなら簡単だがチーム開発で採用するには残念すぎる言語
0491デフォルトの名無しさん
垢版 |
2020/05/13(水) 08:32:08.19ID:Q3kP6cCa
　 /＼＿＿_／＼
／　／　　 　ヽ ::: ＼
|　（●）,　、（●）、　| 　　 ／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ 　 .:::::| 　　 ＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼
0493デフォルトの名無しさん
垢版 |
2020/05/14(木) 17:27:46.77ID:ljUxN++I
>>447
ものすごく遅い話なんだけど
そっかー、インタフェース定義とファクトリの実装が同じパッケージにある必然性って全くなかったんだな
io.Reader の実装が到るところにあるように、定義と実装を分離させれば済む話だった

あーでもない、こーでもない
いつの間にかそうリファクタリングしていて、アレ？となった
0495デフォルトの名無しさん
垢版 |
2020/05/15(金) 01:28:18.31ID:kU/eypzI
>>493
ていうかinterfaceを返すファクトリというもの自体があまりGo的ではない
その辺は思想がJavaなんかと大きく違うところで、Goでは戻り値には具象型を使うのが基本
interfaceは関数の引数に使うもんで、その関数を使う側のパッケージが必要に応じてinterfaceを実装するんだよ
それに従えば結果的にファクトリとinterface定義は別パッケージになる
0496デフォルトの名無しさん
垢版 |
2020/05/15(金) 05:05:48.78ID:02fpr2+t
>>495
あ、脊椎で反射的に反論しそうになったけど指摘されてみると全くその通りだね
ファクトリからインタフェースを返すのは悪手だわこれ
0497デフォルトの名無しさん
垢版 |
2020/05/16(土) 11:46:57.57ID:e+rgeli+
1.12 の http/request.go に、でっかい落とし穴が

こいつは、1210 行目で ContextType == "multipart/form-data" の処理が未実装

そして、 Chrome は FormData オブジェクトを XMLHttpRequest で send() すると問題のマルチパートで送りつける

よって、FormData は使えない……

他のブラウザだとどうなんだろ？困るな
0498デフォルトの名無しさん
垢版 |
2020/05/16(土) 12:28:15.83ID:bJ5k+aLx
xmlHttpRequest.setRequestHeader( 'Content-Type', 'application/x-www-form-urlencoded' );

じゃダメなん？
0499デフォルトの名無しさん
垢版 |
2020/05/16(土) 12:29:08.12ID:e+rgeli+
うーん、コード追ってみたら未実装は間違いでParseMultipartFormを使うらしいけど、わけわかんない
単純にParseFormを置き換えたら、エラーかえしやんの
0500デフォルトの名無しさん
垢版 |
2020/05/16(土) 12:30:20.91ID:e+rgeli+
>>498
いや、ブラウザ側の話じゃないから
ブラウザがどんな方法で送ってきても受けられなきゃ駄目でしょ
0502デフォルトの名無しさん
垢版 |
2020/05/16(土) 13:02:51.76ID:e+rgeli+
エラーが起こる第一原因判明
ヘッダにContent-Typeが無いリクエストでParseMultipartFormすると、パースを打ち切るのではなくてエラーを返す

ショボい作りだ
0505デフォルトの名無しさん
垢版 |
2020/05/16(土) 13:14:14.23ID:e+rgeli+
>>504
ParseMultipartForm 使って、エラーが出ても無視することにした
Content-Type 無いようなリクエストでForm読まないから
0507デフォルトの名無しさん
垢版 |
2020/05/16(土) 14:59:51.10ID:e+rgeli+
なのかな？よく知らない

でも、WebAPIでFormとしてデータを受けるときはParseFormの使用が罠なのは確実
それともbodyを自分で解析するのが定石だったりする？
0508デフォルトの名無しさん
垢版 |
2020/05/16(土) 15:12:59.98ID:F08ATzLT
>>502
＞ヘッダにContent-Typeが無いリクエストでParseMultipartFormすると、パースを打ち切るのではなくてエラーを返す

これは正常な処理だよ
Context-Typeが"multipart/form-data" の場合
Context-Type のmultipart/form-dataの後に続くboundaryをキーにしてmultipartをパースするんだから
ParseMultipartFormがContext-Typeからパースに必要なboundaryを取得できなくてエラーになるのはいたって正常なことだよ
0509デフォルトの名無しさん
垢版 |
2020/05/16(土) 15:26:41.59ID:F08ATzLT
>>508の補足
Content-Typeが無かったらboundaryが取得できないのにParseMultipartFormでパースしようとするからエラーを返す
0514デフォルトの名無しさん
垢版 |
2020/05/16(土) 17:24:44.07ID:bJ5k+aLx
う〜ん、Context-Type が指定されていないのに multipart を自動判別して
くれるライブラリとかフレームワークって他所の言語にあったりするのかな…？
0515デフォルトの名無しさん
垢版 |
2020/05/16(土) 17:34:03.50ID:e+rgeli+
自動的に判定して分岐できるんだったら、それをライブラリがしないというのは手抜きだろ、と言っている

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

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

だから、その問題について教えてくださいと書いたんだ
駄々ではないと思うんだが間違っているか？
0516デフォルトの名無しさん
垢版 |
2020/05/16(土) 17:40:18.88ID:e+rgeli+
505で書いたように、一見問題がないような対処はできるけど(自分でも手抜きとはわかってる)、問題点の実体が見えてないと対処に漏れが無いという確証が持てないから
0517デフォルトの名無しさん
垢版 |
2020/05/16(土) 17:40:39.14ID:is04b0b3
MIME Type
MIME Encoding
0518デフォルトの名無しさん
垢版 |
2020/05/16(土) 17:45:07.11ID:GaPEU8I0
それはバウンダリの中身に、
Content-disposition: attachment; filename="xxxxx"
Content-Type: text/plain
なんかが書いてあるからできる動作であって、実はバウンダリの中身はかなり自由。
マルチパートの中にさらにマルチパートを入れるマトリョーシカのようなことをしてもかまわん。仕様上は。
これをきれいに自動でデシリアライズするのは結構難しいと思うけど。
そういう意味では、呼ぶ側が解釈を与えないといかんって割り切りは間違っちゃないんじゃないか？
他のコンパイル言語でどう対応してるのか気になるな。
0519デフォルトの名無しさん
垢版 |
2020/05/16(土) 17:51:34.17ID:9I4cSVvN
仕事でAWSのAPI Gatewayって機能使った時に
マルチパートフォームデータだけは解釈してくれなかった
クラウドサービスの都合上外部のライブラリ入れるにはソースに同梱するしか無く、
それは嫌だったからバックエンドのLambda（goに対応しているけど仕事で使ったのは非go）で
自前でバウンダリのfrom-toを切り取った上でガン無視してリクエストbodyを拾うだけの処理を書いた記憶があるｗ
完全にスレチだけど
0520デフォルトの名無しさん
垢版 |
2020/05/16(土) 17:54:45.69ID:4LNE0T1O
>>515
だってContent-Typeに現れるのはその2種類だけとは限らないから全部ライブラリ任せにはできんだろ。
0521デフォルトの名無しさん
垢版 |
2020/05/16(土) 17:55:54.20ID:e+rgeli+
ParseMultipartFormの説明で、必要に応じてParseFormを呼び出しますと書いてるのに、
ヘッダにContent-Typeが無ければエラーとするというParseFormにはない条件を入れてしまっているのがおかしいポイントだと思うんだけど

maxMemory引数はデフォルト値を中に持って、オプションとして変更できるようにするのが、こういったライブラリの定石だから(ソケットのタイムアウト時間設定とか)、これは問題点じゃない
いや引数の設計上の問題点だけど
0522デフォルトの名無しさん
垢版 |
2020/05/16(土) 18:06:23.99ID:e+rgeli+
>>520
それが、parsePostForm関数ではその二種類しかハンドリングしてないんだよなぁ
ブラウザ側でとんでもない(サーバで汎用的な方法で解析できない)フォームデータを送るならブラウザの問題だろう

FormDataオブジェクトを使うと発生するContent-Typeくらい自動で処理しないライブラリってどうなの？
0523デフォルトの名無しさん
垢版 |
2020/05/16(土) 18:13:07.38ID:bJ5k+aLx
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)
:
0524デフォルトの名無しさん
垢版 |
2020/05/16(土) 18:26:33.81ID:bJ5k+aLx
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 法" を利用するときは、
> それを不能化する手段を供することが奨励される。
0525デフォルトの名無しさん
垢版 |
2020/05/16(土) 18:28:03.02ID:e+rgeli+
>>523
それバージョンいくつ？
1.12だとmultipartReaderでct==""だとエラーを叩き返すんだ
ということは1.12でのバグなのかな？
0526デフォルトの名無しさん
垢版 |
2020/05/16(土) 18:35:18.02ID:bJ5k+aLx
>>525
GitHub リポジトリの develop branch から引っ張ってビルドしたもの

$ go version
go version devel +810c27e9be Wed May 13 11:59:26 2020 +0000
0527デフォルトの名無しさん
垢版 |
2020/05/16(土) 18:49:32.90ID:e+rgeli+
あ、それ違う

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

ParseMultipartForm(1294行あたり)から呼ばれるmultipartReader(480行あたり)ではContent-Typeが無いと、やっぱりエラーを叩き返してる
0528デフォルトの名無しさん
垢版 |
2020/05/16(土) 18:53:01.16ID:e+rgeli+
つまり現状でも
マルチパート非対応のParseFormでは、ctが無くてもOK
マルチパート対応のParseMultipartFormでは、ctが無ければエラー
という差異が存在している
0529デフォルトの名無しさん
垢版 |
2020/05/16(土) 18:57:51.02ID:e+rgeli+
ParseFormだとURLにフォームくっ付けてContent-Typeがないリクエストを想定してるけど
ParseMultipartFormだと、そういう形式のリクエストは認めていないという違いになって現れる
0530デフォルトの名無しさん
垢版 |
2020/05/16(土) 19:07:51.23ID:e+rgeli+
意図的にContent-Typeのないような感じのフォームデータは許さないサーバを書いてるから、エラーチェックしないという対応だけでも問題なさそう
0531デフォルトの名無しさん
垢版 |
2020/05/16(土) 19:47:58.26ID:F08ATzLT
>>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で分岐してパースする方が合理的。
0532デフォルトの名無しさん
垢版 |
2020/05/16(土) 21:02:30.65ID:e+rgeli+
>>531
としても、ParseForm内で分岐させない理由にはなってないと思っちゃうんだけど、それについては？
分岐させないのは意図的だとして、その理由が引っ掛かる
0533デフォルトの名無しさん
垢版 |
2020/05/16(土) 21:30:32.48ID:e+rgeli+
最終的に

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

とすることにした
0534デフォルトの名無しさん
垢版 |
2020/05/17(日) 07:48:09.08ID:8deP89zB
>>532
> としても、ParseForm内で分岐させない理由にはなってないと思っちゃうんだけど、それについては？

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

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

>>533のあなたの最終的な実装を見るとあなたはContent-TypeとParseFormとParseMultipartFormを理解して使って無いの、何となく動くからってやっつけで実装したようにしか見えないの。
0535デフォルトの名無しさん
垢版 |
2020/05/17(日) 07:48:39.85ID:8deP89zB
>>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
}

まぁ、頑張って。
0539デフォルトの名無しさん
垢版 |
2020/05/17(日) 08:10:55.71ID:8deP89zB
寝ぼけてるぽい、もう一回上げ直し
>>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
}
0540デフォルトの名無しさん
垢版 |
2020/05/17(日) 08:16:05.54ID:Y3GCZn29
>>535
あ、REST-APIでよく使われる形式なのか
そういうForm使わない呼び出しはサポートしないんで割愛

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

現状でも問題ないな(手抜き)
0541デフォルトの名無しさん
垢版 |
2020/05/17(日) 08:21:16.95ID:Y3GCZn29
>>540
いや違う
mime.ParseMultimediaTypeは呼んだ方がいい？
呼んだ方がいいから書いてくれてるんだろうな
追加しておきます
ありがとう
0542デフォルトの名無しさん
垢版 |
2020/05/17(日) 08:26:21.18ID:8deP89zB
スレチになるのでちょっとだけ。
ブラウザが送るって言う解釈とはちょっと違うけどjavascriptで
fetch(url, {
method: 'POST',
headers:{"Content-Type": "application/json"},
body: JSON.stringify(data)
}).then(res => res.json()).then(function(resp) {
// ...
})
みたいにapplication/jsonでリクエストできます。
0543デフォルトの名無しさん
垢版 |
2020/05/17(日) 08:35:11.77ID:Y3GCZn29
>>539
まって、Content-Typeが無いと mime: no media type になる気がするんだが(コード見ただけだけど)
Context-Type が無かったらParseFormの出番だと思う
0544デフォルトの名無しさん
垢版 |
2020/05/17(日) 08:36:58.14ID:8deP89zB
>>541
> mime.ParseMultimediaTypeは呼んだ方がいい？

// ct に「;」がある場合に「;」より前を取得してるだけなので
// mime.ParseMultimediaType使わずにこれでもいい
if pos := strings.Index(ct. “;”); pos != -1 {
ct = ct[:pos]
}
0545デフォルトの名無しさん
垢版 |
2020/05/17(日) 08:38:10.44ID:Y3GCZn29
>>542
うん、でもそこはAPIの仕様だから
汎用的なForm解析ならば必要だけど、自分のAPIだと割愛してよいってだけの話
0546デフォルトの名無しさん
垢版 |
2020/05/17(日) 08:40:22.86ID:8deP89zB
> まって、Content-Typeが無いと mime: no media type になる気がするんだが(コード見ただけだけど)

ごめんこっちに置き換えてw
if pos := strings.Index(ct. “;”); pos != -1 {
ct = ct[:pos]
}
iphoneで書いてるからちょっと適当になりましたw
0547デフォルトの名無しさん
垢版 |
2020/05/17(日) 08:45:00.28ID:8deP89zB
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
}
0548デフォルトの名無しさん
垢版 |
2020/05/17(日) 08:51:07.87ID:Y3GCZn29
現時点で

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

とした
0549デフォルトの名無しさん
垢版 |
2020/05/17(日) 08:54:49.63ID:Y3GCZn29
あ、これでいいのか

// 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()
}
}
0550デフォルトの名無しさん
垢版 |
2020/05/17(日) 08:55:11.84ID:8deP89zB
>>545
＞うん、でもそこはAPIの仕様だから
＞汎用的なForm解析ならば必要だけど、自分のAPIだと割愛してよいってだけの話

わかりました。

サンプルがちょっとグダグダになってこめんなさいw
とりあえす頑張ってください。
0552デフォルトの名無しさん
垢版 |
2020/05/17(日) 09:00:02.16ID:Y3GCZn29
結局、application/json のために ParseForm から ParseMultipartForm を追い出してる？
やっぱり自分的には納得いかない
0553デフォルトの名無しさん
垢版 |
2020/05/19(火) 00:48:43.53ID:uas/zK5F
archive/zip パッケージの仕様なのか、zip 自体の仕様なのかわからんけど
まーた穴に嵌まった

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

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

orz
0554デフォルトの名無しさん
垢版 |
2020/05/19(火) 00:49:54.57ID:uas/zK5F
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)
}
}
}
0555デフォルトの名無しさん
垢版 |
2020/05/19(火) 00:52:26.39ID:uas/zK5F
実行例

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

----- ant-1.10.7-javadoc.jar
META-INF/
・・・
0556デフォルトの名無しさん
垢版 |
2020/05/19(火) 04:56:52.36ID:eSOcgsmn
Go最近始めたんだけど[]stringって型の書き方が違和感すぎるんだけど理由ってあるの？
他にこの配列の型導入してる言語もしりたい
0557デフォルトの名無しさん
垢版 |
2020/05/19(火) 07:27:40.15ID:uas/zK5F
想像に過ぎないんだけど、
[]が後置だとmapも
map[keyType]valueTypeはvalueType[keyType]mapとなるはず
そしてmapをvalueとして持つmap
map[keyType]map[keyType]valueTypeはvalueType[keyType]map[keyType]map
なんか見辛いような、そうでもないような

そもそもmapって、なんで付けなきゃならないんだろ？
keyType付いてたら文脈で分かりそう
連想配列って元からそうだよな
0558デフォルトの名無しさん
垢版 |
2020/05/19(火) 09:57:39.34ID:uas/zK5F
>>553
zip自体の仕様みたい
仕方ないからサブディレクトリのファイルが出てきたときに、省略されたディレクトリのエントリもあった事にしてモデルに登録した
0559デフォルトの名無しさん
垢版 |
2020/05/19(火) 15:39:15.28ID:uas/zK5F
サーバで http.ResponseWriter への書き込みが WSAECONNABORTED (10053) でエラーになっているとき
http.server.go#1905 で return してるため、1907のc.setState で StateIdle がセットされない
そのため、http.Server の ConnState ハンドラでコネクション数を勘定してると数が合わなくなる

という罠に嵌まった
どうしよう……エラーを検知した時に勘定している数をデクリメントするか？
だって、 return の判定で使われてる shouldReuseConnection って隠蔽されてるから
0562デフォルトの名無しさん
垢版 |
2020/05/19(火) 15:56:36.95ID:UZUeOLhY
>>556
英語と同じ語順にした
array of string => []string
Cの場合それを使う構文と宣言を同じにしたせいで
ややこしくなったし
その反面教師だと思う
Cだと使う時も宣言もstring[]なんだよね
0563デフォルトの名無しさん
垢版 |
2020/05/19(火) 15:57:44.45ID:uas/zK5F
そもそも、問題のレスポンスでは20MBくらいのmpgファイルがリクエストされてるんだけど
こういったデカイ応答を返す場合って自分が知らない注意点がある？

Content-Length はファイルサイズ(21614145)
Content-Type は application/octet-stream
で送ってる
ブラウザでは動画はちゃんと出てる
0565デフォルトの名無しさん
垢版 |
2020/05/19(火) 16:16:50.77ID:uas/zK5F
う、もしかすると送信するストリームが Content-Length よりも長いという可能性もあるのか
それでブラウザ側から終わった！と切断されてる可能性
面倒極まりないな
0566デフォルトの名無しさん
垢版 |
2020/05/19(火) 16:50:34.24ID:uas/zK5F
深く考えずに
レスポンスの書き込みに失敗したらコネクション数をデクリメントする
ことにした

コネクション数が0になるまではWaitGroup.Waitで待ってる作りにしてたんで
0567デフォルトの名無しさん
垢版 |
2020/05/19(火) 17:19:44.24ID:h69Ba80R
普通は適当なサイズに分けてチャンクで送る
0568デフォルトの名無しさん
垢版 |
2020/05/19(火) 17:35:35.62ID:uas/zK5F
>>567
ResponseWriter の実体って、 chunkWriter ってstruct だから自動的にチャンクで送られるんじゃないの？
0570デフォルトの名無しさん
垢版 |
2020/05/19(火) 17:57:05.30ID:uas/zK5F
>>567
うーん、HTTP1.1だとTransfer-Encodingにidentityを指定していない場合は強制的にchunkで送られるんじゃないか疑惑
Content-Length不要のお知らせ？
0573デフォルトの名無しさん
垢版 |
2020/05/19(火) 18:33:39.64ID:uas/zK5F
呼び出し順序に則って作らなければ動かないフレームワークってのは
屑って言うんじゃないの？
0574デフォルトの名無しさん
垢版 |
2020/05/19(火) 18:35:39.76ID:uas/zK5F
いや、呼び出し順序に従わない場合はエラーにする
ならば仕方ないよそりゃ
OpenしないでReadできないのはおかしい、とか言わないから
0576デフォルトの名無しさん
垢版 |
2020/05/19(火) 21:21:52.33ID:uas/zK5F
>>567
Content-Length不要…以前の、設定しなけりゃチャンク送信！
orz

ちなみに、レスポンス書き込みがエラーになるブラウザはChromeとEdge
Firefoxだとエラーにならないのは何故だろう
0577デフォルトの名無しさん
垢版 |
2020/05/19(火) 22:18:59.14ID:sE19LTm8
むしろエラーにしてほしい
変な俺様拡張がまかり通ると
そっちに甘えてそれが当たり前になって
文化や規約を企業に乗っ取られてしまう
0578デフォルトの名無しさん
垢版 |
2020/05/20(水) 09:29:17.16ID:AEWLFsS8
458 に関係しての罠

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

嫌ならば GOPATH はユーザディレクトリの下に置いてはいけない
0579デフォルトの名無しさん
垢版 |
2020/05/20(水) 09:36:09.90ID:AEWLFsS8
そりゃ当たり前で気がつかないのがウカツだった…
参照してるパッケージだってコンパイルされるんだもんなぁ
0580デフォルトの名無しさん
垢版 |
2020/05/25(月) 08:12:24.13ID:Jp/r3UJz
雑誌でGoはC++を嫌ったGoogleの技術者が作ったって書かれてたんだけどそうなの？
色んな情報見てきて初めて見たんだけど
0582デフォルトの名無しさん
垢版 |
2020/05/25(月) 10:00:32.41ID:Qw1nrBQZ
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
0583デフォルトの名無しさん
垢版 |
2020/05/25(月) 11:32:33.83ID:ltgSCU1m
目的と合ってないから、目的を絞り混んで作った、いわゆるドメイン固有言語って認識
言語は問題解決に向いてる向いてないはあっても、良い悪いってのはそんなに無いよねという持論
0585デフォルトの名無しさん
垢版 |
2020/05/25(月) 13:20:36.16ID:gis+qwRr
Go は、Ruby を極端にした感じ

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

Ruby on Rails をやったら、やっぱり継承・抽象クラスがあると便利！
フレームワークには必要
0587デフォルトの名無しさん
垢版 |
2020/05/25(月) 16:38:07.00ID:Jp/r3UJz
問題解決力だけで言うとGoが一番高いの？
個人的にはフロントのネイティブ実装を強制されるって意味も含めてJSか、ライブラリの豊富さでPythonとかだと個人的に思うけど
0589デフォルトの名無しさん
垢版 |
2020/05/25(月) 17:19:57.39ID:quw8Fr75
pythonってそこまで書きやすいとは思わないなあ
インターフェースがないから
どのオブジェクトが何を実装してるのかわからない
やはりインターフェースは偉大
0590デフォルトの名無しさん
垢版 |
2020/05/25(月) 17:29:12.78ID:83qlHvUW
Goはクラウドネイティブ開発に習熟してるがオーバークォリティなことをやりがちな奴が多い
JSは大半はゴミ、たまに凄いのもいる
Pythonは全体的に高学歴で頭良いけど動きゃいいって感じの奴が多い
どんな人間が欲しいか次第じゃないかな
0591デフォルトの名無しさん
垢版 |
2020/05/25(月) 17:31:51.89ID:AueT0Sbh
pythonは
import Hoge
したら
help(Hoge)
a = Hoge.hoge()
だったら
help(a)
0592デフォルトの名無しさん
垢版 |
2020/05/25(月) 18:10:55.04ID:ltgSCU1m
場合つまり解決しようという問題による
問題解決能力って何よという話

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

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

総合力ではPythonの圧勝だろうけど、限定された問題ってのはそういうもの
0594デフォルトの名無しさん
垢版 |
2020/05/25(月) 19:39:14.90ID:UFuP99WV
用途によるとしか言いようがない気がする。
どれも銀の弾丸にはならんよ。
0595デフォルトの名無しさん
垢版 |
2020/05/25(月) 21:22:07.97ID:oQRyx0Ul
銀の弾丸は狼男(もしくは悪魔)を倒すという用途に特化されてるんですが・・
0596デフォルトの名無しさん
垢版 |
2020/05/25(月) 22:09:38.90ID:UFuP99WV
ブルックスの論文を知ってて言ってたら申し訳ないんだが、ソフトウエアプロジェクトと言うものに対する銀の弾丸は無いって話だよ。
0597デフォルトの名無しさん
垢版 |
2020/05/26(火) 06:33:05.73ID:tQI2iyhC
オーバークォリティなことをやりがちな奴が多い
ってのは質が良いプロダクトを作るのには向いてないってこと？
0598デフォルトの名無しさん
垢版 |
2020/05/26(火) 06:39:27.10ID:12NedZz3
>>597
いま必要な事以上の事をやりたがってプロジェクトの進捗が遅れるってことだよ。
カップラーメン作りゃ十分なのにスープの出汁とるのに豚骨2日近く煮たり、麺を手打ちし始めるような奴。
0603デフォルトの名無しさん
垢版 |
2020/05/26(火) 11:43:23.28ID:6ileE2Zc
自動テストのコストは成果物を運用しながら継続的に改良していく中でペイしていくもので、SIなら突貫で作って一発動いたらあとは納品して終わりなんだから自動テストは実際要らんわ
Goで書くようなものなんて複雑怪奇な業務ロジックとかじゃなくシンプルな小物だろうし
0606デフォルトの名無しさん
垢版 |
2020/05/26(火) 12:50:01.40ID:tQI2iyhC
>>592
Qiitaの記事欲しい

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

自動テストってどのテストを指してるのか分からないけど、テスト書かないのは後戻りできない負債になるよ
0608デフォルトの名無しさん
垢版 |
2020/05/26(火) 13:12:24.26ID:uV+m0fgU
事情通に聞いてみたのよ
なんで自動テストしないのか、って
それ始めちゃうと、なんで今までやらなかったのか、そう言われて困るお偉いさんが山ほどいるから、だとさ
0609デフォルトの名無しさん
垢版 |
2020/05/26(火) 13:33:50.23ID:xe35/PQB
自社サービスとSIじゃビジネスモデルが全然違うんだから開発手法も違って当たり前
(俺は必ずしもそうだとは思わないが)仮に自動テストによってSIにおいても大幅な工数削減が可能だとして、それに何の意味がある？売上が減るだけじゃないか
お偉いさんの面子だのと人に鬱憤を押しつける悪い癖を自覚し、自分とその周囲の状況、そして問題の本質を正しく理解しよう
0615デフォルトの名無しさん
垢版 |
2020/05/26(火) 19:44:28.32ID:uV+m0fgU
はじめての C
まぁいやらしい

という定番ネタのあるひとは黙っててください
D 言語は泣いていい
0616デフォルトの名無しさん
垢版 |
2020/05/27(水) 01:44:41.20ID:lDZQxe+h
構造体の初期化で省略されたフィールドを既定値で初期化する方法を考えてたんだけど、こんなやり方でも構造体を初期化できるんだな（アンチパターンって言われそうだけど）
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()
}
0618デフォルトの名無しさん
垢版 |
2020/05/31(日) 22:39:20.95ID:8Mxh+OkW
drogonな
しかもC++じゃなね？
ttps://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks/C%2B%2B/drogon
0619デフォルトの名無しさん
垢版 |
2020/05/31(日) 23:27:34.17ID:MeZ7svrP
はい。諸々すみませんでした(´・ω・｀)

echoはなんかあったのかな
使ってるからゴタゴタとかちょっと気になる
iris？だっけ？（うろ覚え）goは前にも消滅したFWあったし
0623デフォルトの名無しさん
垢版 |
2020/06/01(月) 08:54:16.54ID:glX8U9VC
MSはaspnetcoreのベンチマークにTechEmpowerを使ってることを公言してるんで眉唾
オーバーフィッティングの可能性がある
0625デフォルトの名無しさん
垢版 |
2020/06/01(月) 09:09:20.85ID:glX8U9VC
具体的にも何も
MSがTechEmpowerのシナリオをaspnetcoreのベンチマークとして使っているのは事実だし、TechEmpowerに対してAzureのクレジットの提供までしてる
https://github.com/aspnet/Benchmarks
https://www.techempower.com/blog/2016/11/
癒着とかズルとかそういうことじゃなくて、ソフトウェアが特定のベンチマークのシナリオに対して過剰に最適化されるというのはよくある話でしょ
0628デフォルトの名無しさん
垢版 |
2020/06/01(月) 09:42:56.72ID:XQZordO8
学習に使ったのと同じ入力で評価してるわけだからまさにオーバーフィッティングだね
論理的に公平になり得ない
まあ他の上位陣も一緒なんだろうけど
0630デフォルトの名無しさん
垢版 |
2020/06/01(月) 10:47:32.29ID:XZPQztQU
>>607 での Cython との比較でも、Go 側が「並列化してない」という批判がコメントに寄せられてるけど訂正されてないんだよな
つまり足を縛って比較して Python 負けてないよ！と主張している記事
0631デフォルトの名無しさん
垢版 |
2020/06/01(月) 10:50:08.36ID:C06u/BLG
qiitaのは、あそこのあるあるで理解しないで書いてるだけだ
意図して縛ってるんじゃなくて、わかってないだけ
0632デフォルトの名無しさん
垢版 |
2020/06/04(木) 15:37:13.98ID:Sjg+zlaz
セットアップとかPythonで書かれてたりすることが多くて、在宅学習でセミナー受講したりしはじめてる

スライスってPythonとかが由来なんだな
でもar[-1]とか、そんなの要るの？という書き方が多いな
覚えるのﾒﾝﾄﾞｸｻ
0634デフォルトの名無しさん
垢版 |
2020/06/07(日) 10:34:28.20ID:7hGJT77n
なぜかVScodeで保存しようとすると、go listが大暴走して動かないようになってしまった
リファクタリング中でぐちゃぐちゃな状態だから臭いけど
0638デフォルトの名無しさん
垢版 |
2020/06/12(金) 16:07:02.79ID:6Yfh5mGy
JavaでdirectXやるにはCじゃ無くてGoって聞いて来たんだけどホント？
何から始めたら良い？
0639デフォルトの名無しさん
垢版 |
2020/06/12(金) 16:13:47.97ID:1pXOSbLZ
アホか
お前が自分で言っただけだろ

https://mevius.5ch.net/test/read.cgi/tech/1586142285/796
796 デフォルトの名無しさん sage 2020/06/12(金) 15:39:27.21ID:6Yfh5mGy(1)
証拠は俺、天下無双さん
他のスレでJavaでdirectXするにはC覚えろみたいに言われたんだけどGOやったら出来る？
0642デフォルトの名無しさん
垢版 |
2020/06/17(水) 22:30:52.85ID:86TiijZ7
Go言語のChannelはチャネル、チャンネルのどっちの読み方が正しいの？
チャネルは多いけど最新のGo言語の本ではチャンネルと書いてある
0643デフォルトの名無しさん
垢版 |
2020/06/17(水) 22:52:58.26ID:8/53+M2F
英語の音を無理やりカタカナ語で表現してるだけだから
どっちがっていうと難しくない？
一応発音的にはチャンネルよりチャネルの方が近いと思うけど
日本語的にはチャンネルという読み方の方がなじんでるし
0649デフォルトの名無しさん
垢版 |
2020/06/19(金) 07:17:53.69ID:oFfAVAYE
cmd フォルダなのに main パッケージにしなければならないのはなんとかしてくれ
go build cmd/main.go だと動かない exe が出来るし
go run cmd/main.go だと cannot run non-main package

なんで main パッケージなんてあるんだ？
main() 関数あったらどのパッケージだろうと実行させりゃいいじゃん？
0650デフォルトの名無しさん
垢版 |
2020/06/19(金) 08:23:18.84ID:oFfAVAYE
Javaやらと同じでパッケージの仕様が練られてないんだよな
C#みたいにフォルダ？関係ないね、namespace で書けよ
だと嬉しい
0652デフォルトの名無しさん
垢版 |
2020/06/19(金) 10:18:48.69ID:oFfAVAYE
そりゃmainフォルダにすれば解決なんだけどさ

パッケージがディレクトリのパスでアクセスするimport機構なのに、mainパッケージだけ例外というのがﾓﾆｮる
0653デフォルトの名無しさん
垢版 |
2020/06/19(金) 10:24:08.64ID:oFfAVAYE
単に、mainパッケージだけ例外、というのが残念だという愚痴に過ぎないよ
回避以前に、例外なんだと納得すれば問題はないもんな
0654デフォルトの名無しさん
垢版 |
2020/06/19(金) 17:37:14.13ID:Kn9/9Nuz
pythonでいう__name__ == ‘__main__’を外出しした感覚だと思う
変にCを引きずってるからおかしなことになった
ぶっちゃけかなりわかりにくいと思う
0655デフォルトの名無しさん
垢版 |
2020/06/21(日) 11:24:25.44ID:vfiIwLIM
https://play.golang.org/p/Ido4pfGMpHn
の
if s=="a" {
return a()
} else {
return b()
}
の else 文で
if block ends with a return statement, so drop this else and outdent its block (move short variable declaration to its own line if necessary)
と go-lint が吐き出すんだけど、どう書けばいい？
0660デフォルトの名無しさん
垢版 |
2020/06/21(日) 13:41:52.84ID:vfiIwLIM
セーブ時のフォーマットでは直してくれてない
gofmt呼んでるのかわからない

しかし、if ブロックで return してたなら、確かに else は不要
コーディングスタイルまで口出しするとは、他の書き方許さん理念は極まってるもんだな
0661デフォルトの名無しさん
垢版 |
2020/06/21(日) 14:04:24.81ID:TjPGVxwO
Goのバージョン30ぐらいにはコードを書かなくても全部自動生成してくれるようになるよ
0665デフォルトの名無しさん
垢版 |
2020/06/21(日) 22:40:20.19ID:x1/M2+NK
オーケーGo
クリーンアーキテクチャで掲示板作って

これでモダンな技術の5chが作れる時代が来ます
0666デフォルトの名無しさん
垢版 |
2020/06/22(月) 11:38:02.76ID:Cm+rhTCh
そういや、range キーワードって省略されても構文解析できそうな気がするんだけど、なんか問題あるのかな？
0668デフォルトの名無しさん
垢版 |
2020/06/23(火) 00:55:56.74ID:JUPHg4sS
そうだね、一貫性が無くなるよね。バッドプラクティス度合いで言うと最悪ウンコをLv10としてLv10だな
0670デフォルトの名無しさん
垢版 |
2020/07/05(日) 17:58:02.65ID:3hRtzTvh
すんごい基礎的な疑問

go get した外部パッケージって、呼び出されないソースもコンパイルされてリンクされる？
0672デフォルトの名無しさん
垢版 |
2020/07/05(日) 18:06:42.96ID:3hRtzTvh
>>670
詳しく書くと、例えば
import "github.com/hoge/pkg/util"
したら、util に涛�ﾁてる全ての滑ﾖ数が、呼び出ｂｵしなくてもリャ塔Nされたりすｂ驕H
(更にはmainパッケージとか別のパッケージも)
0674デフォルトの名無しさん
垢版 |
2020/07/05(日) 20:01:56.65ID:0gld4/HX
デカいプロジェクトの時のパッケージ構成ってどうしてる？dddはなんかやり過ぎ感あるし
0675デフォルトの名無しさん
垢版 |
2020/07/08(水) 22:34:33.70ID:tDYsCvpq
気付いてなかったけど、VScodeでgo.modのrequireにカーソル合わせたら、パッケージを最新バージョンにアップデートするかが出てきた
0677デフォルトの名無しさん
垢版 |
2020/07/18(土) 10:23:07.73ID:9EMumvg2
>>655
if e, err := hoge(); err!=nil {
return e.method()
} else {
return err
}
と書きたいのに、外に出せとか
外に出すと今度はerrが定義されてないとか言うから、errをブロック外でvar定義しなきゃならん
頭悪いよなgolint
0683デフォルトの名無しさん
垢版 |
2020/08/02(日) 13:07:30.10ID:scrCUlqp
Go, Kotlin Swiftの文法対応表を作って欲しいぜ
0688デフォルトの名無しさん
垢版 |
2020/08/25(火) 10:24:08.87ID:D0K2qmbJ
すんでで気がついて事なきを得たけど
参考にしたサンプルからコピーしたコードだったんで
context.Background() を、そのまま使ってた
マルチスレッドではWithCancelなどで別々に作ってやらなきゃなんないよな
0691デフォルトの名無しさん
垢版 |
2020/08/31(月) 11:00:12.17ID:4ktuLIOK
ホストがMacなんだけど、dockerでgolang/Fyneを試してみたいんだけど無理かな？
なんかXエラーみたいな感じなの
0692デフォルトの名無しさん
垢版 |
2020/08/31(月) 13:01:38.43ID:rMwNX/5+
iOSはBSDベースなんだから余程アップルが魔改造してなきゃBSDと同様な程度にはサポートされてるだろ？
BSDでリリースされてるかどうか知らないんだが
0693デフォルトの名無しさん
垢版 |
2020/09/04(金) 13:17:23.06ID:y4RkOJ/U
まずgolangに関係のない話
chrome だけかもしれないけど XMLHttpRequest だと単純リクエストなのに CORS に引っ掛かってしまう

で、ここから本題
echo 使ってるんだけど、ハンドラ別に allow なオリジンを切り替えたいんだけど、やり方が分からなかった
orz
0694デフォルトの名無しさん
垢版 |
2020/09/06(日) 14:36:03.50ID:l3n8psbq
a := make([]int, 0)

makeの第一引数って何を渡してるの？
普通のプリミティブじゃないよね
0699デフォルトの名無しさん
垢版 |
2020/09/06(日) 20:33:01.20ID:gGwX7R3F
なんか全体的にそんなところがあるよな。べつに機能的に問題があるというわけじゃないんだが。
0700デフォルトの名無しさん
垢版 |
2020/09/06(日) 21:12:04.30ID:l3n8psbq
"[]int"だとstringだけど、ダブルクォーテーションなしだと何を渡してるんだろうと思って
0701デフォルトの名無しさん
垢版 |
2020/09/06(日) 21:17:56.45ID:uoPkQvi9
確かにもやっとしないでもないね
t := []string
とかで型の変数を作れる訳でもないのにポッと出てくる型指定
0703デフォルトの名無しさん
垢版 |
2020/09/06(日) 21:49:44.73ID:uoPkQvi9
makeは組み込み関数にカウントされてるから、むしろ型を変数として生成できないという縛りなんだな

滅多にmake関数使わないな
チャネルの容量を設定する時くらい
固定長配列なんて作らないし
0705デフォルトの名無しさん
垢版 |
2020/09/07(月) 00:08:24.76ID:tKSaDgWF
makeが関数でrangeが式なの違和感あるんだよな
逆であるべきなのではと思ってしまう
0707デフォルトの名無しさん
垢版 |
2020/09/10(木) 17:49:37.70ID:iYKQgeEI
go: finding dmitri.shuralyov.com/gpu/mtl latest
go: downloading dmitri.shuralyov.com/gpu/mtl v0.0.0-20191203043605-d42048ed14fd
go: extracting dmitri.shuralyov.com/gpu/mtl v0.0.0-20191203043605-d42048ed14fd
build dmitri.shuralyov.com/gpu/mtl: cannot load dmitri.shuralyov.com/gpu/mtl: no Go source files

● 根本原因
dmitri.shuralyov.com が落ちてるんで GCP のビルドが通らない

● 状況
go.sum 見てみるとfirebaseが要求してるパッケージ
したがって firebase を使って GCP でサービスを提供しているすべてに影響するはず

こまるわー
0710デフォルトの名無しさん
垢版 |
2020/09/10(木) 18:56:30.40ID:iYKQgeEI
なんとなくGCPのビルドシステムの問題にも思えてきた
だってGOPATH(~/gopath/pkg)には一式存在してるもん
なんでダウンロード(というか最新版チェックしに行ってる？)できないからってビルドを失敗にすんのよ
0714デフォルトの名無しさん
垢版 |
2020/09/11(金) 00:38:28.29ID:u7dYfbNO
よかった復活した
そしてやはり個人持ちのホストの模様
ホストでしっくりこないならサーバー
Google Domainsでドメイン管理してるからGoogleCloud上にあるのかも
0715デフォルトの名無しさん
垢版 |
2020/09/11(金) 20:06:33.99ID:fDVUo6av
しかし個人のホストからimportするリスクやばいな
Goチームの人だから許されてるのか？
0717デフォルトの名無しさん
垢版 |
2020/09/11(金) 20:20:51.53ID:ICNKkV5S
う、Google Source Repositoryって、もしかして
source.developers.google.com/p/プロジェクト/r/リポジトリ/...
ってパッケージ名になるのか？長
0718デフォルトの名無しさん
垢版 |
2020/09/29(火) 08:17:01.67ID:1HGJd50O
引数を値渡しするか、ポインタ渡しするか
それが問題だ

sliceは値渡しでも良いよね
要素を追加しようとすると結局新しいsliceが必要
ポインタのポインタとかやりたくないし
stringは普通は変化させる時は新しい物を作るから、値渡しで充分
空を表現するには空文字列で良いし

構造体はどうすべきか
全部ポインタ渡し？
0719デフォルトの名無しさん
垢版 |
2020/09/29(火) 08:42:58.32ID:ztORdlGy
>>718
基本的にポインタで渡すべきと思ってる
値を使うには細心の注意が必要になるから

速度的に有利とかいう話はあるけど
スライスなんかは内部にポインタ入ってるし、文字列だってポインタだから、メンバとしてそれらを持ってる構造体を値渡しするのもナンセンスじゃね？
それらのメンバにアクセスしたとたんにページフォルト起こる可能性があるから、速度面での優位は怪しくなるという意味でナンセンスだろうという
値渡しはスタックに積むだろう(それ以外に方法があるのか知らない)から、スタックを圧迫するはずという理屈も加味
0720デフォルトの名無しさん
垢版 |
2020/09/29(火) 09:38:24.05ID:rZRnYPTQ
>>719
いや、サイズが大きいのは基本的に可変長であるスライス、string、mapなのだから、それらだけは内部的にポインタを持って実質的に常にポインタ渡しとなるようにしておけば、常に値渡しでもパフォーマンス的にほぼ問題にならんだろうというのがGoの設計意図だよ
個人的には、同一の実体として振る舞うようなOOのインスタンスに近い性質の構造体はポインタ渡し、単なる値の寄せ集めは値渡しとして使い分ける
0722デフォルトの名無しさん
垢版 |
2020/09/29(火) 16:39:20.25ID:aaxcyAZi
論理アドレス空間ははじめから確保してるんじゃないの？
だったら他の言語と変わらない気が
0723デフォルトの名無しさん
垢版 |
2020/09/29(火) 17:34:34.66ID:ztORdlGy
例えばjavaではStackOverflowErrorになるし、cだと検出すらされない(今は知らない
goでは関数呼び出し時にオーバーフローをチェックして拡張するらしく、初期値は4KBだとか
ほんまかいな？
0724デフォルトの名無しさん
垢版 |
2020/09/29(火) 17:41:44.13ID:ztORdlGy
考えてみれば何万とgoroutine作ってもびくともしないようにするには、それくらいやらなきゃダメだろうから納得すべきか
0726デフォルトの名無しさん
垢版 |
2020/09/29(火) 23:23:58.36ID:UIxEJt2R
>>723
>cだと検出すらされない(今は知らない
今でもOS任せですよ。Windows だと例外としてキャッチできますが。
0727デフォルトの名無しさん
垢版 |
2020/09/30(水) 05:11:09.54ID:/dbaz1tV
Elixir は、10万の小プロセスが、並列で動く

結局、Rust, Elixir は、普及のキャズムを越えられなかったから、
Go の1強になってしまったけど
0728デフォルトの名無しさん
垢版 |
2020/09/30(水) 05:27:53.12ID:s3VbgSNe
かえすがえすも、名前がイケてないのが悔やまれる
もっとマシなネーミングをできなかったのか
0733デフォルトの名無しさん
垢版 |
2020/09/30(水) 20:05:41.54ID:HXdd4xfV
ゴリゴリ書かなきゃいけないという点で面倒くさいけどゴリゴリ書いてしまえるという点で面倒くさくない
0734デフォルトの名無しさん
垢版 |
2020/09/30(水) 20:17:57.84ID:pc2vUBN1
Pythonとかの思い付くまま適当に書いたらシンタックスシュガーでなんとなく動く、それを簡単だと言ってるんだと思う
0735デフォルトの名無しさん
垢版 |
2020/09/30(水) 20:32:41.83ID:pc2vUBN1
PHPとかの方面の人から見ると、面倒で使えないと思うんだろう
node.jsやらと比べて数倍の性能を叩き出すWebAPIをちょちょいと書けてしまうから手放せない
Webアプリなんて、WebAPIとJavaScriptとHTMLがあればすむ話だからPHPとかやる奴こそ面倒なことやってんなーと思う
0736デフォルトの名無しさん
垢版 |
2020/09/30(水) 21:03:01.73ID:zBrjSaD6
>>735
ひと昔前はそれが普通だったからねえ
railsもphpもサーバーがHTMLを組み立てるという思想ありきで生まれたから仕方ない
今その役目は消えたからほぼ全てのフレームワークがオーバースペックになってしまった
0737デフォルトの名無しさん
垢版 |
2020/10/07(水) 08:43:42.09ID:9tAnRZjq
Pythonでマップのインデックスで {(a,b): c} とやってるのを見て、ちょっと羨ましく感じた
Goだとタプルは型じゃないもんな
0738デフォルトの名無しさん
垢版 |
2020/10/09(金) 10:30:34.93ID:fFeZzUQc
エディタは何使ってる？
0739デフォルトの名無しさん
垢版 |
2020/10/09(金) 10:40:12.61ID:cZJOIaI8
VSCode
VSCodeのGoの拡張機能は結構クソだが、Goばかり書くわけじゃないのでGoに最適なエディタはどれかとか興味ない
0740デフォルトの名無しさん
垢版 |
2020/10/09(金) 10:45:34.46ID:fFeZzUQc
>>739 ありがとう。使ってみる。
0741デフォルトの名無しさん
垢版 |
2020/10/09(金) 11:57:27.87ID:CFMMOtfU
>>740
他のエディタ使ってないからVScode特化の話なのかわからないけど

おかしい動きを見せたら、まずコマンドで Restart Language Server
0743デフォルトの名無しさん
垢版 |
2020/10/09(金) 12:20:13.85ID:fFeZzUQc
VSCODE良いね。
Goプログラマーの仲間入りしました。
0745デフォルトの名無しさん
垢版 |
2020/10/13(火) 16:42:37.40ID:UHobSDno
Goは補完が大事だから他の環境はマジで貧弱すぎる
vim拡張とかこれでコード書いてる人いるのか？と感じた
0746デフォルトの名無しさん
垢版 |
2020/10/13(火) 23:14:35.57ID:vh7uCC06
俺は補完は好きじゃなくて逆に鬱陶しく感じてしまう。
タイピングのリズムというか、今xxxという操作/入力しようとしたのに余計なことすんな と思うことしばしば。
0748デフォルトの名無しさん
垢版 |
2020/10/14(水) 10:18:40.21ID:GsUUoEHv
「(」打つと勝手に「)」も入るやつとか
おせっかいに「()」の真ん中にカーソル移動するやつとか
自分でタイプすると hoge()) みたいになってうざい
0750デフォルトの名無しさん
垢版 |
2020/10/14(水) 22:53:52.84ID:Eee7omWn
変えてるに決まってるだろ
0751デフォルトの名無しさん
垢版 |
2020/10/14(水) 22:57:57.74ID:RfMuLTxu
go.modに勝手にgo1.13みたいなものが入ります
やめてほしいですが誰に言えばいいですか？
0753デフォルトの名無しさん
垢版 |
2020/10/15(木) 13:01:09.76ID:AQ4Pln/N
自分で指定すると思ったけど
もしかすると、参照するパッケージに引きずられる可能性があるのか？
パッケージがリンクするランタイムの中で最新になっちゃうとしたらどうしようもないかな
0755デフォルトの名無しさん
垢版 |
2020/10/28(水) 09:08:16.05ID:pr+rUhRZ
俺はコンパイラが無様すぎると思うんだけど、どう思う？

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

インタフェースAを返すメソッドを持つインタフェースB。

そのメソッド実装がインタフェースAを実装しているポインタを返しても、

./prog.go:34:4: cannot use &Base literal (type *Base) as type IBase in assignment:
*Base does not implement IBase (wrong type for Sub method)
have Sub() *Sub
want Sub() ISub

と、インタフェースAを返しているとは認められない。
0757デフォルトの名無しさん
垢版 |
2020/10/28(水) 11:33:48.41ID:Mf8tEr2f
C / C++ のプリプロセッサのマクロって
#define A(X, ...) X A(__VA_ARGS__)
みたいな再帰的な処理出来ないけど
この問題昔から指摘されてるのに
40年経っても1000年経っても解決されないよね
解決しようと思えば出来るのに C++ の拡張とかばっかりやってる
0759デフォルトの名無しさん
垢版 |
2020/10/28(水) 11:52:07.24ID:9TmkPH0P
>>757
「型無しのマクロを使うな。template使え。」という方向だよ。
C++で今さらそんな拡張ありえん。
0760デフォルトの名無しさん
垢版 |
2020/10/28(水) 12:47:58.74ID:Mf8tEr2f
>>758
解決しようとした人は *ｂｙ や python や D を造ってしまいましたね
既存の C/C++ そのものに手を入れるのは中の人以外には無駄な努力に感じます
再帰マクロ専用の ぷりぷりプロセッサを書くのは手かも知れません
あと #include __FILE__ でループしてる人はいるようです
https://qiita.com/alucky0707/items/3599cdcf973382df978b
0762デフォルトの名無しさん
垢版 |
2020/10/29(木) 21:05:36.10ID:K8k/YFeK
>>760
スレ違いだが通りすがりに言っておくと、
マクロにそこまでの機能を求めるのなら、
自前でスクリプト言語(AWK/Perl/Python/Ruby)等でソースの事前処理をmakefileに書いた方がいい。
それだと無限に機能拡張出来る。

だからC++というかmakefileシステムでそれをやる意味はない。
よってまともな奴は誰もマクロの拡張なんかしようとは思わない。
「言語」にそれを持たせる意味がないから。
(言語による垂直統合ではなく、makefileによる水平分業で全く問題ないし、融通も利く）

ただしGoはそれを標準機能で付けてる。
これがどう役に立っているのかは知らん。
(Go generate、AST木が参照出来るので上記のマクロ拡張とは次元が違うが)
0764デフォルトの名無しさん
垢版 |
2020/10/30(金) 09:21:51.84ID:rRvEIPSO
知らないだけかも知れないけど、generate が build と分けられてるのが使いづらく感じる
go.mod に generate のパラメーター書いておくと build で実行するとかじゃダメなのかな
0765デフォルトの名無しさん
垢版 |
2020/10/30(金) 10:57:17.98ID:7MkyV1Cp
Qt良いよね
0766デフォルトの名無しさん
垢版 |
2020/10/30(金) 11:07:56.86ID:SoGDmizs
そもそもプリプロセッサーが何をやっているか考えたら再帰なんかできない事ぐらい分かるやろ
もう相当前のものだしなぁ
逆にC#とかだとCで出来たような事が出来ないから不便だと思った事があるわ
0768デフォルトの名無しさん
垢版 |
2020/10/31(土) 11:21:06.88ID:9I3xwucX
今時も何もgolangではポインタはバリ現役
というか、golang使ったことないんだな哀れ
0769デフォルトの名無しさん
垢版 |
2020/10/31(土) 15:42:09.93ID:rQ5gc14Z
ポインタが散々叩かれて色んな言語で無くしたけど
最近のモダンな言語では復活してきてるのは面白い
0771デフォルトの名無しさん
垢版 |
2020/10/31(土) 16:39:03.74ID:o6XGTKTG
つーか名前をへんてこにして誤魔化すとかじゃなく
リアルにポインタの概念(何かのオブジェクトを指す変数)を消し去ろうとしたら
あらゆるものをコピーでもっといてしかもそれらを常に同期して同じ値になるように
常に維持する仕組みにするしかないがそんな非効率きわまりない言語が実用に値するはずがない
0772デフォルトの名無しさん
垢版 |
2020/10/31(土) 16:55:27.17ID:fxcwqRC2
lisp とかってコピーしてないの？
0773デフォルトの名無しさん
垢版 |
2020/10/31(土) 17:00:05.47ID:rQ5gc14Z
ポインタがない言語ではオブジェクトは参照コピー
プリミティブはコピーというのが最近のスクリプト言語の常識
ただ細かい違いは言語ごとに違ってハマりどころになってる
0776デフォルトの名無しさん
垢版 |
2020/10/31(土) 20:21:41.59ID:yaU57lgN
>>775
Haskellはモナドの裏に隠してる
正確にはランタイムと言った方が近いかもしれないが
ていうかHaskellのイミュータブルな配列でもUArray（UnboxedのU）が提供されてるしポインタ・参照・Boxedからは逃れられんよ
0777デフォルトの名無しさん
垢版 |
2020/10/31(土) 21:01:42.97ID:NOhP3tKc
>>771
>>773
×　最近のスクリプト言語
○　ポインタを使えないほぼ全部の言語
だよ。C#もJavaも同じだ。

ただ実際のところ、これで大して問題にも遭遇しない。
そもそもCですら . なんてゴリゴリ速度チューニング時以外は使わず、 -> と　[]ばかりだ。
そしてC++で参照(&)が導入され、今君が認識しているいわゆる「オブジェクト参照」は全部これになった。

だから俺はあんまりポインタは必要なくて、 -> を . として結果的に -> しか使えないようにした、
最近のほぼ全ての（というかC/C++以外全部、多分Goも含めて)言語の方が正しいと思ってるけど。
Goも制限付きポインタで、C++の&相当でしかなかった気がしたけど、違ったっけ？

なお、ポインタという「概念」を消し去るのは無理だよ。
これを何故か理解出来ない馬鹿が多いのか、Python使いは無駄に吠えてくるけど、
プログラミングを本気でやるつもりなら、その根幹の実装を理解することは避けて通れない。


>>775
erlangは全部インミュータブルで、ループ(for文）すらなく、全部再帰らしいよ。
0779デフォルトの名無しさん
垢版 |
2020/10/31(土) 23:29:32.75ID:NOhP3tKc
>>778
うん知ってる。
ついでに言うとstructが値渡しで、Cで言う . による高速化もつまみ食い出来るようになっている。
ただしこちらも主な使い方ではなく、実際に効果が出る小オブジェクト(確か16バイト以下）で限定使用することが推奨されてる。
その辺はC#は実用言語だから地味に整備してある。
unsafeもその一環でしかない。

だが結局のところ、その辺の小異に目をつぶればC/C++/C#/Java/Python/JavaScript等の現在の主力言語はどれもほぼ同じで、
C/C++だと直接ポインタを扱える、位の違いしかない。
それはつまらないとして、敢えて独自路線を行ったのがGoだが、ポインタ周りは大して独自でもなかった気がした。
Goじゃないと出来ない/他言語でやると凄く苦労する、てのはないよね？
（というかポインタ自体Cの時点で完成してて、その後は精々間違いを自動検出する方向にしか進化出来てない）

多分Goの売りはgoroutineとgenerateなのだと思う。
ただ俺にはgoroutineがそんなに便利とは思えなかったし、そもそもあれコルーチンではなく単なるスレッドだから名前間違えてるだろ、だ。
generateについてはCマクロをゴリゴリしたい奴には非常に有用なのだろうけど、そもそもそんな奴は多数派ではないし、俺もそうじゃない。
ただしAST木が標準で出せるというのはかなりインパクトはある。
とはいえ、AST木では低レベル過ぎて困るので、本当はもっと上のレベルが欲しいのが大半なんじゃないかと思う。

ちなみに最近の言語でも評価が固まってないのは例外周りで、これは各言語によってまるっきり違う。
Goはドベタにerrを値で返す、仕様としてはCモドキだが、現実的には一つの選択肢だとは思う。
格好良くはないが。
0780デフォルトの名無しさん
垢版 |
2020/11/01(日) 07:15:14.81ID:BkYHp1gf
>>779
いや、goroutineはスレッドとは隔絶してるんよ
そしてこの間まで理解してなかったけど
goのスタックフレームつまり自動変数も他の言語とは隔絶
それはgo独自の優位性で、goroutineは初期スタックサイズは今では2kBしかない
そのため、数百万のgoroutineを作成できる
これは巨大なコンテキストを必要とするスレッドでは太刀打ちできない性能なん
0781デフォルトの名無しさん
垢版 |
2020/11/01(日) 08:14:15.41ID:0aiHjqpe
>>780
> goのスタックフレームつまり自動変数も他の言語とは隔絶
どこが？サイズだけならCは調整出来たと思ったけど

> そのため、数百万のgoroutineを作成できる
それは既に結論は出てる。
以下ブログ、俺が読んだ時とはだいぶ趣が異なるが、（当時は確か初期サイズ4KBだったはず）
https://github.com/maxpert/raspchat/releases/tag/v1.0.0-alpha
要は2KBでも十分大きすぎて、Nodeの方が断然まし、ってことになってる。

これは当たり前で、Linuxのkernel領域でのスタックサイズが128Bだったか256Bかに制限されているらしいから、
その気になればLinuxは256B/threadでスレッドを起動出来る。
そしてNodeはシングルスレッドだからスタック領域が余すところなく全部消費される。
これはGoではどうやっても出来ないことだ。
というよりJSのシングルスレッドアーキテクチャは最初からこのc10k問題解決を主眼にしてる。
だからその領域ではそれ用に作られたJSに勝てるはずもなく、実際そうだった、というだけ。

goroutineのサイズをケチってどうこう、って作戦は究極にはJSのシングルスレッドアーキテクチャに行き着く。
だからその方向ではNodeには勝てないのは仕様だよ。
そうじゃなくて、言語サポートがあるからスレッドがお気楽に使え、それがgoroutineです！って方が順当で、
実際そのブログの作者も喜んで使ってみたが、思ってたと違う、、、というのがそのブログだよ。

> そのため、数百万のgoroutineを作成できる
数百万のthreadなんて実際あり得ないし、管理も出来ない。
そこをgoroutineならお気楽に生成/消滅出来るので、これまで「面倒/管理が難しい」等でthread起動しなかったところを、
「これは別スレッドでも動く」というだけの理由でお気楽にすべてgoroutineで切り離して行けば一見超並列出来そうに見える。
ただ、実際それをやったらそこで遭遇している問題、つまりgoroutineは思っているほど軽くない、に遭遇してしまう。
現実的にはthreadなんて論理CPU数の2倍程度あればCPU処理だけなら埋まってしまうからそれ以上起動しても意味がない。
I/Oで引っかかった時のスタックサイズをケチりたいのなら、
JSのように非同期でシングルスレッドにする方が原理的に上だし、実際そうだった、というのがそのブログだ。
0782デフォルトの名無しさん
垢版 |
2020/11/01(日) 09:44:48.65ID:Gkt9gY6r
軽さ速さは環境によって変わる
少コア環境ではM:Nスレッドモデルのgoroutineは有効に機能しない場合がある
少なくともGo開発側はM:Nスレッドモデルに合わせるにはasync/awaitモデルよりスレッド/チャネルモデルの方がいいと判断した

位の話でしょ

goroutineのモチベーションは非同期処理についてG社が持つようなメニーコアかつ分散な環境でスケールするかって話をしないと伝わらないよ
0784デフォルトの名無しさん
垢版 |
2020/11/01(日) 10:42:25.33ID:0aiHjqpe
>>782
逆に言えばそれ以外の環境では他言語に劣るわけだろ。

元々は多分、命名からして、コルーチンをgoroutineで、ということなのだと思う。
コルーチンは通常は本体側と交代で間欠的に動作する前提で書かれているから、スレッドで切り離すことはしない。
ただ、もしそれが本体と並行に動作可能なら、スレッドとして切り離せば、
本体側が動いている間に次のyieldまで動作させられ、コルーチン部分の処理時間を見た目ゼロに出来る。
実際、大半のコルーチンはこれが可能なはずで、これまでは単に面倒/スレッド生成消滅のコストの為にそこまでやらなかっただけ。
だから、スレッドよりもっとお手軽で軽いgoroutineを用意すれば、という訳だ。

OSでの並行はprocessだが、multi processは重すぎるのでアプリ内processとしてthreadが出来た。
それと同様に、thread内の並行として、goroutineという、もう一段軽い物を用意した。


だからここまでのストーリーは辻褄が合っているとして、それがどこに適用出来るかだよ。
CPUが精々数個しかないそこら辺のPCだと、threadだけで埋めきれるので、普通にそれが最適解になる。
threadだけでは埋めきれないほどのCPUがあり、積極的に並行goroutineとして切り出してくれないといけない、
という、いわゆるメニーコアならGoの方が有利になる可能性があるけど、実際この場合はキャッシュコヒーレンシの問題が発生してくる。
勿論チャネルだし、後はオブジェクトの中身も含めてインミュータブル、
つまりErlangの世界まで行けたらこの辺の問題も無くなるけど、Goはそういう感じじゃないでしょ。
そもそもメニーコアの筆頭のXeonPiも死に体だし。(これはGoのせいではないけど)
0785デフォルトの名無しさん
垢版 |
2020/11/01(日) 10:42:50.15ID:0aiHjqpe
だから、>>782の観点だけなら、
Goは素晴らしい実験用言語だったけど、現実的ではなかったね、で終わると思うよ。
実際、Goって使用者は増えてるのか？
Rustは前年度「Rust新規に始めた人数よりCを新規に始めた人数の方が多くなっちまったよオイオイ」とか話題になっていたが。

JSはプログラマに、I/Oを明示的に切り離して高速化することを求め、(実際あの非同期は壮絶にウザイが)現実的にはものすごく機能してる。
Goはプログラマに、並行可能な部分を積極的に切り離すことにより超並行によって高速化を目指している、と捕らえることは出来るが、
実際これは全く上手く行ってないし、今後とも上手く行く気配もないでしょ。
一時期、CUDAよりもXeonPiだ、という時期もあったはずだけど、なんか話題はCUDAに戻ってるしさ。
0788デフォルトの名無しさん
垢版 |
2020/11/01(日) 11:11:59.03ID:MfA1nG9+
yieldが必要なコルーチンとは全く関係なく、昔で言うグリーンスレッドを超低コストで実現してるという方が正しい。
エアプしてる時間があったらスケジューラの動きとか調べてみたらいいよ。
0789デフォルトの名無しさん
垢版 |
2020/11/01(日) 11:12:40.44ID:MfA1nG9+
スレッドプールとかが効いてくるネイティブスレッドではなくて、あくまでグリーンスレッドだからな。
0790デフォルトの名無しさん
垢版 |
2020/11/01(日) 11:13:16.44ID:Gkt9gY6r
>>784
ここで言ってるメニーコア環境がXeon PhiなどではなくXeonやEPYCのようなパッケージのコア数の向上とそれを積んだ大規模分散環境の話だって伝わってないって事は分かった
どこまで適用できるかって話に関してはG社が自分とこに使えればそれでひとまずOKというラインがあるのでそっから先は知った事ではなくて良いのでは？

↑は >>785 にも続く話だけど現実的でないとか上手く行ってないとか結局それが現実的でなく上手くいかないタイプの分野・会社に君がいるだけじゃないの？と思ってしまうよ
0791デフォルトの名無しさん
垢版 |
2020/11/01(日) 11:35:22.25ID:MfA1nG9+
メインスレッドすらグリーンスレッドで、数本立ってるネイティブスレッド上でタスクを持ち回りで実行してるから、await asyncは自動的にされてると思って良いぐらい。
0792デフォルトの名無しさん
垢版 |
2020/11/01(日) 11:45:38.74ID:b3NlQgn4
>>784
コルーチンを指向していたならchannelなんて使わんだろう。
どっちかというと軽量プロセスの方向性。
0793デフォルトの名無しさん
垢版 |
2020/11/01(日) 11:52:11.44ID:0aiHjqpe
>>788
> グリーンスレッド
この言葉は初めて聞いたが、確かにJavaやRubyでは普通に使われてる言葉らしい。意味は確認した。
なるほど、スレッドだと論理CPUを跨げるので、その部分がOS管轄になるから重いのか。

goroutineがグリーンスレッドなら、マルチコアだと全く性能が出ないな。
まあそれはいいとして。

なら、そもそもネーミングが悪いよ。
gogreenthreadとか、まんまの名前の方が良かったよ。
（ただしGoは意図的に他言語に合わせてない部分があるからここもかもしれんが）
確かにthreadではないのは理解した。


>>790
> Xeon PhiなどではなくXeonやEPYCのようなパッケージのコア数の向上とそれを積んだ大規模分散環境の話だ
いやそれは同じだぞ。少なくともプログラミングモデルは変わらないだろ。
実は俺は785投稿した後に、「あ、もしかしてNiagara等（有名なのは京)のCPU内メニースレッドの話か？」と思ってしまったが、
そうじゃないのならそっちも間違ってるぞ。
上記の通り、それだとgoroutineでの性能向上は不可能だ。

そしてグリーンスレッドだというのなら、CPU内メニースレッドには非常にマッチする。
実際Niagaraとか64スレッドだが、正直64スレッドなんて普通のthreadでは埋めきれないし、
それ向けにプログラマが積極的に切り出せ、というのは技術的にはかなり納得する。
だからグリーンスレッドの多用での性能向上を目指した、というのが合ってるんだと思うよ。

その後の話はその通り。
確かに俺にとって有用ではないから俺は使わない、で終わりだ。
やってる連中はそれが役に立つと思ってるからやってるだけ、というのは確かにそりゃそうだ。
0795デフォルトの名無しさん
垢版 |
2020/11/01(日) 12:21:49.13ID:0aiHjqpe
>>791
まあとにかくgreenthreadだというのは理解した。
（仕様を確認したわけではなく、そちらの主張通りの方が色々辻褄が合うからそうなのだと思う）

> await asyncは自動的にされてると思って良いぐらい。
それはgreenthreadの話ではなく、他の普通のマルチスレッド言語は全部そうだよ。
実際、PHPが使いやすいのはこれだし。
むしろJSだけが異端。ただし、俺はあれはそうする意味があったと思っている。


>>792
> コルーチンを指向していたならchannelなんて使わんだろう。
これは間違い。
コルーチンならyieldだけであり、channelでも全く問題なく機能する。

そしてchannelにするのは、(君はおそらく完全なソフトウェアプログラマだから理解出来ないのだろうが)
一般的には共有メモリを使わせず、一番速い同期機構にする為。通常はそれがchannelだとされている。
ただし共有メモリが遅くなるのはキャッシュコヒーレンシがらみであり、
greenthreadなら共有メモリ同期でも全く遅くもならない筈だから、本来は禁止にする必要もないし、チャネル縛りにする必要もない。
（実際Goだと禁止も縛りもされてなかった気はするので、言語的には辻褄は合ってるが）
ただし間欠動作ではない為、mutex等の同期化機構は必要で、それも嫌だというのならチャネルになる。

> どっちかというと軽量プロセスの方向性。
これは俺はそう言ってる。
0796デフォルトの名無しさん
垢版 |
2020/11/01(日) 13:36:21.44ID:0aiHjqpe
>>791
ちなみにgreenスレッドスイッチは何で起動してるか分かるか？

なおgreenthreadについてはありがとう。これだと色々辻褄が合う。
781のブログも、「そもそもgoroutineってそんなに使いたいか？」という疑問があったのだが、
greenthreadでchannel同期なら、実装は単なるFIFO＝リングバッファだから原理的に最速だ。
だから何でもかんでも「goroutineに出来る物はgoroutineにする」という方向性で悪ノリしたくなるのは分かる。
ただ、2KBはオーバースペック過ぎるから、それで頓死するのも分かる。

さてスレッドスイッチ、理想的にはキャッシュミスでgreenthreadスイッチが行われればいいのだが、
現状のx86ではこれは出来ないよな？
そもそも例外はOSに行ってしまうし、キャッシュミス時はそのCPUスレッドはそこでストールしてしまう。
一番近いのはTLBミス例外だが、それもOS行きだ。
ページフォールトしていたらプロセススイッチで終わり、
していなければそのまま処理が返ってきてキャッシュが充足されるまでストールしたまま待たされるはずだが、
そこでCPUが遊んでいる時間を他greenthreadで埋めてしまえ、というのは思想としては分かる。
ランタイム側で「TLBミスからの復帰」だと分かればgreenthreadスイッチ可能だが、
一般的には例外からの復帰はユーザープロセスからは見えないだろうから、おそらくカーネルに手を入れないと無理だ。
それでもやってしまえば面白い。ただ、この場合にgreenthread間でスラッシングした場合は悲惨なことになるが。

というわけで、スレッドスイッチ起動のネタは分かるか？
従来通りタイマなら、面白くもないがまあ、というところ。
greenthreadで最小構成ならスレッドスイッチのコストはPC/SP/Flags復帰分＝関数1回呼び出し分でしかないから、スイッチし放題ではある。
だから豆にスイッチしまくりというのも面白いが、それでもキャッシュミスでのストールは避けられない。
そこでハードウェアサポートがあってキャッシュミス時にgreethreadスイッチが出来れば圧倒的に面白くなるが、
現状のx86だと出来ないよな？
0797デフォルトの名無しさん
垢版 |
2020/11/01(日) 13:38:20.89ID:BkYHp1gf
>>781
goだとスタックを動的に自動拡張するのが味噌
ケチってるんじゃないよ
関数呼び出し時にフレームをチェックして増量する
0799デフォルトの名無しさん
垢版 |
2020/11/01(日) 13:43:22.40ID:b3NlQgn4
>> どっちかというと軽量プロセスの方向性。
>これは俺はそう言ってる。

なんか言っていることがむちゃくちゃ。コルーチンの話はどこ行った？
そもそもchannelはコルーチンじゃ無理だろうて。
0800デフォルトの名無しさん
垢版 |
2020/11/01(日) 13:47:11.06ID:0aiHjqpe
>>797
それはわりとどうでもいいな。
だったらgoroutineの初期値も0であるべきだよ。
スレッド同期に2KBなんて普通は必要ないし。

とは781のブログからなら思うが、要はそんなケチ環境は相手してないって事か。
まあそれもありだな。
0801デフォルトの名無しさん
垢版 |
2020/11/01(日) 13:58:10.45ID:g1rTVVje
>>769
問題はポインタそのものじゃなくて型の要件を満足しない型無しnilだしな。

nilポインタ禁止にすりゃ良かったのに。
0802デフォルトの名無しさん
垢版 |
2020/11/01(日) 13:58:56.68ID:MfA1nG9+
>>793
マルチコアで性能が出ない理由がわからん。
複数コアでタスクが空き次第実行してるから、単一コアのグリーンスレッドとは全然違ってフル回転するぞ。
0803デフォルトの名無しさん
垢版 |
2020/11/01(日) 14:00:05.35ID:MfA1nG9+
>>795
phpはマルチスレッドと言うよりもマルチプロセスだろ。
他のマルチスレッド言語は言語によって全然違うよ。
pythonなんかは最近aioが整備されたじゃん。
select使うかどうかじゃね？
0804デフォルトの名無しさん
垢版 |
2020/11/01(日) 14:01:05.29ID:MfA1nG9+
>>796
コンテキストのスイッチとスケジューラはなかなかなるほど賢いなって思うぐらいのアルゴリズムになってるから、俺が説明するより本家読んできたほうが為になるぞ。
0805デフォルトの名無しさん
垢版 |
2020/11/01(日) 14:06:47.13ID:MfA1nG9+
なんで性能向上が不可能なんだろ。
goroutineがたくさん起動する状態だと、同じような処理がタスクの切れ目でスイッチされることになって、キャッシュのヒット率も低くないし、ブランチ予測もそれなりにあてになる状況だろ。
GILかかる言語でもあるまいし。
0807デフォルトの名無しさん
垢版 |
2020/11/01(日) 16:52:55.99ID:0aiHjqpe
>>806
確認した。（日本語版だけ。英語版は後で読んで少なくとも感想は返す）
スライド若干間違ってる、というかこいつ自身同期分かってねえ感じだが、ソフト屋ならこんなもんだろう。
ただいずれにしろ結論として、「共有メモリは遅いから使うな」で良いし、実際それ以上の理解は現実的に必要ない。

>>805
話がずれているのは俺がgreenthreadの定義を狭く捉えすぎていたからだな。
その記事で言う N : 1 だと思っていた。
これまでの俺のgreenthreadについての書き込みは全てこの定義だ。
だから当然他CPUを掴めないので高速化しようがない。

ただしGoが M:N なのは分かった。
しかしこの場合にCPUを跨ぐ為には当然OSのサポートが必要で、
当然そのスライドでもメッセージをkernelに投げてる。

問題はM:Nだと大して美味しくもないことだよ。
いや、Go界では当然凄く美味しいことになってるんだろうけど、N:1だと使える爆速最小実装がまるで使えない。
なら次段階は通常は「常に同一コアに割り当てるスレッド」をグルーピングしてその間だけでもこれを利用しよう、となるところだが、これもやってない。
勿論こんな事をやると思想に反するからだろうけど。

ただまあ、思想として、スケジューラ周りをランタイムに丸投げして「どんなスケールでも最大効率」を目指してるのは分かった。
とはいっても、メッセージをkernelに投げざるを得ない構造になってるから、改善余地があるとすればスケジューラ程度でしかない。
そして、俺は別段OSのスケジューラが間抜けとも思えないけど。
あれ、CPUが余ってたら振ってくるだけだし、実際演算とかで100%CPU掴む環境ならそれで必要十分だからね。
あるだけよこせならpriorityを上げればいいだけだし。

あと強いて言うならスレッドのスタックサイズが小さく済むことか？
しかしあれ、俺は知らんがthreadがOS管轄ならOS単位でしか指定出来ないものなのか？
それも奇妙だと思うから、普通はシステムコール時に引数与えて指定出来て然るべきであって、
今のLinuxがそうなってなくても当然いつかそうなるものだとも思うけど。
少なくとも.NETはnew Treaadでスレッドの最大サイズを指定出来る。
こいつもランタイムが管理するスレッドかもしれんけどさ。
0810デフォルトの名無しさん
垢版 |
2020/11/01(日) 17:12:55.06ID:MfA1nG9+
>>807
ソフト屋ソフト屋と言ってるが、何屋なんよ。
解ってないと言うか、お前が何か変な想定してると思うぞ。

M:Nで、かつスケジューラがまともな場合、に関しては相当美味しいと言う事が理解できて、スケジューラのソースはgithubにあるはずだが、読んだ？
stealは無差別にstealする訳じゃないぞ。

1コアあるだけよこせだと、IOバウンドな処理の時に勿体ないでしょ。

小さく済むと言うか、バカほど立てられるんよ。
.Netの話はネイティブスレッド。お前ホント理解できてないのな。
0812デフォルトの名無しさん
垢版 |
2020/11/01(日) 17:19:00.38ID:MfA1nG9+
>>807
CPUをまたぐ場合にはOSのサポート、もちょっと違うだろ。
あくまでグリーンスレッドで、ネイティブスレッドじゃねえぞ。
システムコールだったり、アトミックに処理ができるだったりでタスク覗くときにどうなってるよって話じゃねえの？
0814デフォルトの名無しさん
垢版 |
2020/11/01(日) 18:37:50.76ID:0aiHjqpe
>>810
> M:Nで、かつスケジューラがまともな場合、に関しては相当美味しいと言う事が理解できて
俺は別に美味しいとは思ってないぞ。
M:NならOSのスケジューラと大差ない筈だし、
実際ランタイム判断でN:1に出来る状態でもNodeに負けてるだろ。
カッコイイスケジュールをやりきるより、スケジュールなんてしない、の方がシンプルで速いんだよ。
Goは例の「一方ロシアは鉛筆を使った」のアメリカ側をやりきってる感じがある。
とはいえそれもソフトウェア全体の成長の芽の一つだから、やること自体は頑張れ、でしかないが。

> スケジューラのソースはgithubにあるはずだが、読んだ？
読んでねえよ。ただ、読む価値ねえから読まねえよ。遅いスケジューラなんて意味ねえし。

> Netの話はネイティブスレッド
つまり普通のスレッドだろ？ならWindowsはスレッドのスタックサイズを指摘出来ることになる。
Linuxでこれが出来ないとも思えないので、goroutineは軽いんです、なんて利点はなくなると思うが。

>>812
そりゃお前が理解出来てないと思うぞ。
上述の通り、スライドでもメッセージをkernelに投げてるだろ。
そこを同一CPU内にディスパッチされた場合にのみN:1専用超軽量ルーチンで処理するよう、
スレッドスイッチの際に全部張り直す、というのもありだが、実際それやってても大して速くないと思うぞ。

そこは本来はプログラミングモデルを明示的に変えないと駄目なんだよ。
同一CPU内でのみ動作するスレッドであれば、スイッチのコストはほぼゼロだから、がんがん切り出して問題ない。
一方、メッセージにkernelを挟む必要があるのなら、それはそれだけでコストがかかるから、何でもかんでも切り出したら余計遅くなる。
だから本来は goroutine のみではなく、 golight とか、N:1スケジュール専用のgoroutineを用意しないと駄目なんだ。
それがなくて全部goroutineで扱うから全体的に遅くなってしまう。それがブログ主がやった事だよ。
ただこれを分離するのは思想的にやりたくないんだろ？ならそこが限界だよ。
0815デフォルトの名無しさん
垢版 |
2020/11/01(日) 20:10:20.08ID:0aiHjqpe
>>806
さて英文の方も読んだ。

なるほどGCの為にスレッドの動作状況を調整する必要があるから、スケジューラはどのみち内部に必要なのか。
これは俺はCでしかスレッドを使ってないから気づかなかったわ。
ただその後GoはノンストップGC入れたと聞いたから今は要らんだろとも思うが。

Syscallの時にハンドオーバーしたいのは、ぶっちゃけもう一つthreadを立てておけば済む話だよね。
(GOMAXPROCSをCore数ではなく、Core数+αにする。ただしそれに似たような話は書いてあるが）

内容は日本語版と同じだね。そりゃそうだが。
ただ、英語版の方が確かに実装した理由が書いてあったから読み物としては良いが。
0816デフォルトの名無しさん
垢版 |
2020/11/01(日) 20:36:44.54ID:Cb/zzig7
>>814
スケジュールなんかしない、って全然ありえないんじゃないか？それこそ非同期の時代に。
Nodeにはだいたい勝ってるかと。

読んでもないのに読む価値がわかるとは凄いな。

スレッドのスタックサイズが問題ではなくて、ネイティブスレッドか否かが問題なの。アホか？

だから、スレッドではないから、スイッチのコストが全然違うの。
goroutineはスレッドのようなものであって、スレッドではないからそもそも切り替えのコストがほぼない。
だからガンガン切り出していいの。
なんにも聞いてないのな。グリーンスレッド勉強になったんじゃないの？
0817デフォルトの名無しさん
垢版 |
2020/11/01(日) 20:37:48.97ID:Cb/zzig7
>>815
もう一つスレッドを立てるとか言う観点がナンセンス。
何度も言うがgoroutineはスレッドのようだがスレッドではない。
0818デフォルトの名無しさん
垢版 |
2020/11/01(日) 20:48:36.50ID:xkjSw6A1
古いPerlスクリプトをGoogle Compute Engineの無料枠で動かそうとしたら
cpanのDBD:mysqlのmake時のテストで多分メモリエラーで落ちた
いい機会だからgoで作り直すことにしたわ(´・ω・｀)
0819デフォルトの名無しさん
垢版 |
2020/11/01(日) 20:53:11.08ID:0aiHjqpe
一応調べたぞ。

スレッドのスタックサイズは、
.NETのはデフォ1Mで最小値はシステムによるがVista(.NET2.0)なら256KBだそうな。
それより新しいのはよく分からんがこの雰囲気だと64KBか。
https://docs.microsoft.com/ja-jp/dotnet/api/system.threading.thread.-ctor?view=netcore-3.1#System_Threading_Thread__ctor_System_Threading_ThreadStart_System_Int32_
https://docs.microsoft.com/en-us/windows/win32/procthread/thread-stack-size

pthreadはこちらも具体的には書いてないから推測になるが、
oracleが16KB指定してるし、MANPAGEにも書いてあるからここまでは行けるのは確実。
オーバーフロー検出の項目で1ページ以下にも指定出来るとあるから、
スタックサイズは4KBかそれ以下にも指定出来るとも思われるが、断定は出来ない。
https://docs.oracle.com/cd/E19253-01/819-0390/attrib-45427/index.html
https://linuxjm.osdn.jp/html/LDP_man-pages/man3/pthread_attr_setstacksize.3.html
https://linuxjm.osdn.jp/html/glibc-linuxthreads/man3/pthread_attr_init.3.html

いずれも起動時にパラメータでスタックサイズを指定出来る。
0821デフォルトの名無しさん
垢版 |
2020/11/01(日) 21:30:51.41ID:0aiHjqpe
>>816-817
実際Nodeに負けてるのは事実だし、あのブログ読んで技術的に俺は納得してる。
782も納得してるし、他の連中もあの貧弱環境ならそうだな、となると思うが。

ちなみに当たり前だが全ての環境で全敗するわけではないぞ。
俺も数年前に味見でPHP/Node/Goで同じものをPCのXAMPP上で試したが、
GoはNode比2倍、PHP比6倍のパフォーマンスが出た。
（僕のカワイイGoを虐めるな！って感じだから、、これを言ったら満足するか？)


それで俺はPHPで行くことに決定した。
PHPのパフォーマンスで俺には十分だったし、無料鯖は現状PHPのみだからだ。
そしたらGoでやってた奴が「ゴラアふざけんな！」って言ってきたが「知るかボケ」と返した。
あいつはPHPの糞コードがこれ以上世の中に増殖するのが許せなかったらしい。
実は本当はNode無料鯖が大量にあればNodeにしたいのだが、今はそうではない。
よって糞とは分かっているがPHPだ。
ただ、そのGo使いは「Goなんて遅すぎ、Rust行くわ」と言って今はRustでやってるよ。
そりゃパフォーマンスだけで勝負するならRustになるし。

静的なコンパイル言語なんだからスクリプト言語と比べて速いのは当たり前。
それが貧弱環境だと覆るのはアーキが悪いんだよ。
そして何故そうなるのかを色々理解した上で、それぞれが用途に適したものを使えばいいだけ。
今のところ俺がGoを使うことになる芽はない。だからって何だよ、でしかないとは思うけど。

最近のお前らがよく分からんのは、言語べったりで言語と心中しようって奴が多すぎることだ。
お前の使ってる言語が良くても悪くてもお前の成果でもないし、悪口でもないだろ。
ぼくがつかってるげんごすごい＝ぼくすごい、なのはゆとり特有な気がするが、
何故お前らがそうなるのかさっぱり分からん。
0822デフォルトの名無しさん
垢版 |
2020/11/01(日) 21:50:55.32ID:b3NlQgn4
>最近のお前らがよく分からんのは、言語べったりで言語と心中しようって奴が多すぎることだ。

なかなかの妄想力
0824デフォルトの名無しさん
垢版 |
2020/11/01(日) 22:00:10.95ID:Cb/zzig7
>>821
PHPは歯ブラシとしては優秀だからな。
それは認めるわ。

ただ、XAMPPとか無料鯖とか言ってる次元で意味がわからん。
普通自鯖だろ。

ちなみにRustが持て囃されてるのは、早いからではなくて安全だからだぞ。
大量の並行処理をさばくならGoの方を俺は選ぶが。

言語べったりと言うが、このスレはGoのスレなんだし、そもそもお前が他の言語に対して理解がなさすぎて、何でも自己流の解釈するから頭おかしい結論になるんじゃねえか？
0828デフォルトの名無しさん
垢版 |
2020/11/02(月) 08:42:57.13ID:NKtku3y2
スレッドのようなもので、スレッドではないって言ってんのに頭の中スレッドでいっぱいだから理解もできてないし。
何なんだろうなホントに。
0830デフォルトの名無しさん
垢版 |
2020/11/02(月) 12:09:27.63ID:N1CJ+2mz
goroutineのオンリーワンは当分揺るがないだろな
同接数十万以上とかのWebAPI作るならgolangが第一候補
そこまで性能が求められない場合では、保守性からJavaとかNodeみたいな人員調達容易な言語
0833デフォルトの名無しさん
垢版 |
2020/11/02(月) 17:41:48.74ID:O3lt5Om/
Go書けるまともな人相当少ないからかなり美味しいんだよな
世の中の人プログラミング苦手なのか？と思ってしまう
スクリプト言語かいてイキってた人達が沈黙したし
0835デフォルトの名無しさん
垢版 |
2020/11/02(月) 21:24:24.64ID:N3jY4ti2
>>816
君がその程度の理解なのは理解した。
ただそれはGoの思想「何でもかんでもgoroutineに切り出せば自動的に速くなります」なのだろうからGoUserとしては悪くない。
しかし現実にはNodeに負けてる、ってこと。

君らの問題は、何故それが起きるのか理解出来ないことだ。
これは806のスライド作った奴もそうだが、何故遅くなるのか、何故速くなるのか、理解出来てない。
ただ、そう教えてもらったから、という知識しかない。

しかしこれもそんなに酷いことではない。
最近は複雑化したハードウェアに対応する為に、ソフトウェアも複雑化してる。
学生では単純に知識量が追いつかない。
となるといわゆる正しい作法で洗脳する、というのが現実的な解で、
それがJavaでのオブジェクト教、Goの場合はgoroutine教なのだろう。
しかし既に言ったがchannelしか使わないのなら現実的にそれでいいんだよ。理由は分からなくても。
ソフトウェアを資産として捉えた場合、正しい作法で書かれた物が大量にあることが重要であり、
君らがGo流の正しい作法で書くのなら、それはGo界の資産となる。だから貢献してる。
0836デフォルトの名無しさん
垢版 |
2020/11/02(月) 21:25:09.49ID:N3jY4ti2
問題は、その程度の理解なのに限界領域の最速を目指せると勘違いしていることだ。
それは無理なんだよ。ハードウェア上で動いているのだから、ある程度のハードウェアの知識がないといけない。
実際、Nodeに負けてるのも、その理由も、君には理解出来ないんだろ。

なおNodeのはスケジューラとは言わない。ああいうのはキューという。積まれた順に吐いているだけだから。
あれをスケジューラと呼ぶのは、まともなスケジューラ作ってる(つもり)なGoの連中に対しても失礼だ。

ただそこで負けてるのはやっぱりアーキが悪いんだよ。
スケジューラを入れると、一般的にディスパッチの際にその分オーバーヘッドが入る。
だからディスパッチされるジョブが小さければ小さいほどそのオーバーヘッドが大きく見えてしまう。
それは「goroutineで何でもかんでも切り出せ」という思想と矛盾してしまうだろ。
だからNodeに負けた。
0837デフォルトの名無しさん
垢版 |
2020/11/02(月) 21:25:43.73ID:N3jY4ti2
C界で有名な話で、「K&Rのmalloc(30行程度)に勝つ為には5000行のコードが必要だった」というのがある。
https://www.wdic.org/w/TECH/malloc
何もやらないのが一番速いから、シンプルなソフトウェアはそれだけで速い。
OSのスケジューラもほぼキューでしかないはずで、Nodeと同様に「積まれた順に吐くだけ」だけど、
逆に、それでいい領域であればそれ以上のスケジューラを持たせても原理的に勝てない。
それがNodeに負けた理由。

JSのシングルスレッドアーキテクチャというのはかなりトリッキーなアイデアではあるが、
ああ割り切ってしまえば世界がシンプルになるから色々省略出来る。
結果、ソフトウェアが全体的にコンパクトになるから思っている以上に速くなる。
それがNodeに負けた理由。

逆にGoの思想でNodeに勝つ為には、「積まれた順に吐くだけ」な馬鹿キューを上回る為に、
「このgoroutineは『いつ』『どこ』にディスパッチすべきか」をきっちり管理しないといけない。
それは今の「空いてれば取ってきます」程度では全然駄目で、上記mallocの戦いなら今はまだ一合目でしかない。
後10倍くらい複雑化してプロファイラーも整備しなければ「シンプルなだけ」のソフトには速度で勝てない。
(プロファイラーを実装したくなければユーザーが明示的に指定するgolightみたいなのがあればいいのだが、
そういうの無しでやりたければ、プロファイラーが要る)

後君らが見えてないのは、複数のCPUを並列/並行動作させるのは実はものすごくオーバーヘッドがあること。
これはx86だと全部ハードウェアがやってくれるのでソフトウェア上では負担がないのだけど、
それはコードから見えないだけで、実際のCPUは止まりまくってるから実行速度はがた落ちになってる。
それがNodeに負けた理由。シングルスレッド限定だとこのオーバーヘッドがないんだよ。
0838デフォルトの名無しさん
垢版 |
2020/11/02(月) 21:27:00.51ID:N3jY4ti2
>>830
CPUリソースを余すことなく使う、という意味では原理的にNodeの方が上なんだよ。
本体ジョブしかしないんだから。

ただNodeの場合はマルチコアだと束ねて使うしかない。
これも既に行われているはずだけど、この場合はそれぞれのNode間の直接情報交換は無理筋になる。
(やる場合はDB(或いはエミュレーションレイヤ)経由だが、直接RAM上での交換とは速度では全く勝負にならない)
しかし数十万のコネクションを一度に張って、その間で頻繁にやりとりするって何がある？ほぼ無いよね？
チャットはそうだけど、だからこそチャットアプリでNodeに現実的に負けたあのブログは大きいんだよ。
だからGoUserが噛みついてDisclaimerまで付いてGitHubにまで追いつめられちゃって、になってる。

ただし、実は現実的にはネットワーク出力は一つなのだからチャットでも何でもシリアル処理実装で全く問題ない。
よって根本的にはCPU単体速度>=ネットワーク速度なそこらのPC程度だとNodeでも問題の発生しようがなく、対応出来てしまう。
これはレン鯖等も含めて。
そうではなく、ネットワーク速度>>>CPU単体の速度、な環境ではNodeでは全く無理筋だが、これがどこにあるかだよ。
クラスタで中身は束ねたPC程度だとNodeで全く問題は発生しないはずで、実際それがNode鯖を使ってる連中の使い方だろ。

GoはNodeの思想からすれば盛大に屋上屋を架している。
それでパフォーマンスが出れば大したもんだけど、スケジューラがあの程度ならまだまだ遠いよ。
「CPUが十分速い」という大前提が成り立つ限りJSの思想はかなり筋が良いんだ。
ただそれが1995の時点で見切れたのか、単にラッキーなのかは謎だが。
0839デフォルトの名無しさん
垢版 |
2020/11/02(月) 21:28:45.62ID:N3jY4ti2
>>830
と思ったが、オンゲか？
オンゲは確かにNodeでは無理だろう。これは根本的にNode向きではないから。
コネクション単品の処理も重く、コネクション間の情報交換も多い。
逆にコネクション単品が軽いチャット程度だと、goroutineがオーバースペック過ぎてNodeに負けてしまってる。
これはある意味単なる設計ミスで、起動時にもっと小さいスタックサイズを指定出来るようにすれば済む話なのだけど、
それをしないところをみると何か出来ない/したくない理由があるんだろう。
あのブログを出されて噛みつくってのは民度が低くて、スタックサイズを可変にするってのが建設的対応だよ。

ただ、可変スタックサイズなんてやれば出来る話でしかないし、
理由はおそらくスケジューラの性能がその辺だからだろう。
goroutineに切り出すと「スケジューラ」「同期化機構」分だけオーバーヘッドが生じる。
それは「賢いスケジューリング」で取り戻すしかないが、元々軽いgoroutineでは無理がある。
だからある程度重いジョブをgoroutineに切り出すことが必要で、
それ以下の軽いジョブだと到底無理だから消極的に制限してるのだろう。
これだとチャットでNodeに負けた理由も、
またそれでもなおgoroutineのスタックサイズを2KBと巨大なままに保っていることも説明が付く。
実際、データを置かず、再帰も必要な時にしかしないのなら、スタックサイズ2KBなんて埋めようがないし。
0841デフォルトの名無しさん
垢版 |
2020/11/02(月) 21:34:24.83ID:NKtku3y2
>>835
Nodeに負けてるが定量的でないぞ。
お前が書いたNodeのコードに負けてるのであれば、goroutineをどう使えばよいか解ってないお前がポンコツだって事だ。
主観的すぎる。やりなおせ。
0843デフォルトの名無しさん
垢版 |
2020/11/02(月) 22:10:55.63ID:N3jY4ti2
>>841
負けてるのは781のブログだよ。詳しく知りたければ読めよ。
俺は彼の分析には納得してるし、その通りだと思ってる。
だから同じような環境なら間違いなく負けるとも思っている。

お前らって（というよりは最近は他言語もだが）
結局Goが「最速最高」じゃないと文句を必ず言ってくるけど、それはないでしょ。
速度ならC/C++/Rustには負けるし、お手軽さではPHPやJSには負けてる。
だからいちいちそんなところで噛みついてくて欲しくないね。建設的な話が出来ない。
完璧な言語なんてないのだから、己の状況でどれが一番ましか判断してそれを使うしかない。
なら、いろんな言語を客観的に見てないと駄目でしょ。

ただ、スレッドで切り離せるところをgoroutineで積極的に切り離せば解があるのではないか？
という着眼点でGoが動いているのは分かった。
確かにこれは面白いし、実際threadはそういう風に使われることを想定されてない。
だからこれをやりたかった人達はネイティブスレッドには文句たらたらだったのだろう。

ただ問題は、同期自体が凄く重いのと、
現存のハードウェアはそういった大量の軽量スレッドを生かす方向には出来てないことだよ。
Niagaraは比較的向いてるけど、SPARC自体が死んでしまってるし、富岳もARMになってしまったからね。
0844デフォルトの名無しさん
垢版 |
2020/11/02(月) 22:29:00.53ID:N3jY4ti2
と思ったけど、SPARCはOracleが独自改造しまくってたな。
実際OracleみたいなDBサーバーならGoはハードウェア的にもソフトウェア的にも向いてるのかもしれん。
0845デフォルトの名無しさん
垢版 |
2020/11/02(月) 22:39:52.04ID:N3jY4ti2
>>833
>>834
俺から見ればGo使いも十分イキってる馬鹿だけどな。
そしてスクリプト言語使いがイキってるのを止めてる気配も感じないが。特にＪＳ/TS。

ただPHPerは叩かれすぎだとは思う。
0847デフォルトの名無しさん
垢版 |
2020/11/03(火) 00:10:32.82ID:OQJ1TfTq
>>846
そりゃご丁寧にどうも。

ただ、今ここで話した限り、以前の印象「Go使いはC++を使えない馬鹿」ってのを再認識したけどな。
C++も無駄に複雑になって、しかもそれを使いこなすのが目的みたいな勘違い野郎がネット上には増えてるし、
あれはあれでおかしな事になってるが。

ただGoはちょっと立ち位置が悪い。
「端の言語」はとりあえずは生き残れるんだよ。Goはどの面もそこに該当しない。
今なら「最易」枠がPHP/JS/Python。
「最速」枠がC/C++。
「堅牢」枠がJava。
中庸といえば聞こえは良いが、実際に積極的にGoを選ぶ理由がない。
上記の言語はそれなりに糞だと分かってても最○を求めたら他に選択肢がないから選ばれる。
だからのさばってる。

goroutineの思想は確かに面白いが、今はそれを生かせるハードがない。
そしてそのハードを開発させるほど影響力も大きくない。
(ただしGo向けハードウェア開発自体は簡単だから、やる気になればすぐ出来るが)

あとはgenerateだね。
ただしgenerateが向いてるのは下地の言語が全機能を持っている場合であって、(つまりC++)
Goみたいに綺麗に制限されてる言語には向いてないんだな。
0849デフォルトの名無しさん
垢版 |
2020/11/03(火) 01:02:06.59ID:cdE7yZQv
>>843
だからスレッドではない。
同期も重くない。
同期しないためのchannelとselectだよ。
もう少し調べてから書け。
0850デフォルトの名無しさん
垢版 |
2020/11/03(火) 01:05:11.27ID:L2dwgQ1p
>>847
goはバランスをとったのだと思うな。
最易ではphpやpythonに負けるけどそれらよりは速くできる。
最速ではc, c++, rustに負けるけどそれらよりは簡易に利用できる。
堅牢さでは、、、んー、これはjavaに負けてるのかな？rustには負けてそうだけど。

バランスとったから突き詰めたら他のものに負けるのはしょうがない。
0か100じゃないんだからそれでいいと思う。

goの良さはchannelやgoroutineを用いて従来言語よりcsp(communicating sequential processes)を利用しやすくなったところだと思う。
0851デフォルトの名無しさん
垢版 |
2020/11/03(火) 02:20:11.37ID:irabVcQc
疲れてるのに長い文章読む気もおこらんから読んでないが
>>847 だけ読んで俺は基本的に同意の人間なんだが・・
ちなみにわしはC++が一番好みで最初の数行に同意なんだが
複雑すぎるとか難癖つけるやつが多いがC++が今の形に発展したのには理由がある
哲学、美学先行で必要もなくわかりにくくしているわけではない実用が最優先言語なのだ
Go も正直なんでこんな流行してるのか今一理由がわかんない
これ使うくらいなら既存言語を用途にあわせてチョイスすりゃいいじゃん、ともおもうが
まあ小型のプログラムをサクサクと書くには便利な言語だね
ただし、Go は名前がクソ
あとエラーハンドリングはなんとかしろわりとマジで
0852デフォルトの名無しさん
垢版 |
2020/11/03(火) 02:32:57.50ID:ab1rhHuA
　 /＼＿＿_／＼
／　／　　 　ヽ ::: ＼
|　（●）,　、（●）、　| 　　 ／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ 　 .:::::| 　　 ＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐—´´＼
0853デフォルトの名無しさん
垢版 |
2020/11/03(火) 02:34:49.96ID:+BH8gwHp
思うに、go言語に未練あるけどもういじりたくない（または理解できなかった）人なんだろうな
どうにかして貶めたいという固い意志を感じる
0855デフォルトの名無しさん
垢版 |
2020/11/03(火) 07:45:30.12ID:cdE7yZQv
>>850
バランスというより、なんか独自進化じゃないかな。
後出しジャンケンでインターフェイスを実装したことにするとか。

>>851
軽量スレッドなんかは既存言語にはできない事だからな。
0856デフォルトの名無しさん
垢版 |
2020/11/03(火) 12:41:08.52ID:DpLu5A+Z
goroutine はスレッドをダメだこりゃと車輪再発明する暴挙に出た一品
更にスタックが固定じゃ限界があるって考えて魔改造
そこまで無茶苦茶やらかすことで数百万の平行処理を可能とした鬼子
逆を言えば、そこまでしなければ数百万のリクエストは捌けない
デメリットは関数呼び出しからやらかしているためC呼び出しな低レベル処理が書けないという点
WebAPI用途のドメイン固有言語と言ってもいいかもしんない？

到るところでベンチマークが出ていてすら認めたくないのが笑える
https://postd.cc/the-way-of-the-gopher/
0857デフォルトの名無しさん
垢版 |
2020/11/03(火) 14:25:22.75ID:cdE7yZQv
erlangなんかはこういう発想で軽量プロセスにしてるよね。
とはいえCouchDBでしerlang使ってないけど。
0858デフォルトの名無しさん
垢版 |
2020/11/03(火) 19:17:11.84ID:54lsvwds
goは名前とマスコットキャラがダメ
0859デフォルトの名無しさん
垢版 |
2020/11/03(火) 19:57:00.21ID:ggNJ+eTh
サーバーサイドはGo一択でいいんじゃないか？
速いし運用もこれまでのlinuxの知識があれば問題ない
ライブラリも充実してるし
並行処理も便利
これまでforkを駆使して面倒なことしてたけどしなくて良くなった
0861デフォルトの名無しさん
垢版 |
2020/11/03(火) 20:58:25.32ID:p/G0GWsV
>>860
そもそもこいつらが使ってるCassandraなんてまさにGCでフリーズする(笑)はずのJavaなわけで、眉唾な話だな
もうJavaで書けばいいんじゃないかっていう
0862デフォルトの名無しさん
垢版 |
2020/11/03(火) 21:11:05.72ID:OQJ1TfTq
>>850
> csp(communicating sequential processes)
何ぞそれ？と思ってwiki読んだが、「応用」以前はハア？って感じだな。
応用部分は納得出来るが、それはどちらかというとモデリング＆シミュレーションであって、(従来の)プログラミング言語って感じではない。
勿論それ以前の部分はプログラミング言語としてのCSPについて説明してあるはずなのだが、
大半の連中はこれ読んでも俺と同様「何のこっちゃ？」だと思うぜ。

それはさておき、記述しやすいのは事実だから、cspに金脈があるのならいきなりブレークするのだろう。
0863デフォルトの名無しさん
垢版 |
2020/11/03(火) 21:21:56.26ID:OQJ1TfTq
>>851
C++の現状に歴史的経緯と必然性があるのは認める。
しかしそれは新しく始める人にとっては関係ない話なのだから、言い訳にはならないだろ。
C++は（普通のプログラミング言語を目指すなら）ちょっと仕様を整理しないと駄目だよ。
ただC++陣営は「全部入り、仕様の整理は各人がコーディングルールで制限しろ」で多分考えてて、
確かにそれもありではあるのだが。
実際、C++を気に入ってる奴って、「俺がこうしたい」を記述する方法があるからだろうし。
他言語で「それは書けない」に遭遇すると本当にどうしようもないからね。


Goが受けてるのは簡単だからだよ。
PHPは簡単だがパフォーマンスと文法が糞過ぎ。
JSは非同期がウザ過ぎ、あとフニャフニャすぎて駄目。
Goは型もあるし！難しくないし！パフォーマンスも出るし！
となるだけ。俺個人はJSのフニャフニャっぷりが気に入ってるのでそこで止まってるが。
型あり言語出身の奴等が上記フローを流されたら順当にGoに行き着く。最近はTSに行ってるかもだが。
0864デフォルトの名無しさん
垢版 |
2020/11/03(火) 21:22:40.23ID:OQJ1TfTq
あとGoは意図的に「若者の楽園」を目指しているのが、「見た目は」奏効しているかも。
意図的に用語等を他言語と変えていて、既存言語既習者の参入障壁を上げている。
色々あるが今回ならgoroutine、やっぱりあれはgolwp(lightWeightProcessの略)とかが妥当だろ。
それをgoroutineなんて言葉を使うから、thread/lightWeightProcess/co-routine/greenthread等を知っている奴等は余計に混乱する。
ところがこれらを何も知らない若者は全く混乱しない。だから結果的に若者が後れを取らない。

ちゃんと用語を合わせた新規言語（Go以外は全部こうだが）を作った場合、
他言語既習者は文法だけの修得でがんがん進めるのに対し、
新規プログラミング学習者（＝若者）はOOP等の「プログラミングそのもの」の部分で学習に時間がかかり、
早々に頭を抑えられて、結果、「老害」とわめくことになる。

Goのように意図的に既存言語から変更している場合、既存言語を知っている奴等だけが混乱する。
結果的に、既存言語既習者の流入が減り、「老害」が比較的少ない環境＝若者にとって居心地が良い環境になるわけだ。
ただしそれは見た目だけで、実際は人材が枯渇してる。「老害」と共に「老兵」も来なくなるから当たり前だが。
例えば、806のスライド、作ったのは東大の学生のようだが、中身を見る限り、こいつは、
共有メモリを使ったことがないし、それが何なのかも理解してない。
というより多分Goのチャネルしか使ったことがない。
その程度の奴をカンファレンスに呼ばないといけないほど人材がいない。

そしてここで「Goのスケジューラが読むに値するコードだ」と吠えている馬鹿もそう。
その程度のコードをありがたがらないといけないほど全体のレベルが低い。
「空いてりゃ取ってくる」程度のスケジューラなんてすぐ書けるし、
むしろそれすら書けない馬鹿は死ね、なのがC/C++/Rustの世界だと思うが、Goはそうじゃない。
だからこの意味ではGoUserは「イキっている」のを自覚出来てない。
0865デフォルトの名無しさん
垢版 |
2020/11/03(火) 21:23:08.75ID:OQJ1TfTq
ただこれはGoの仕様だ。
実際いちいちグダグダ言われてもモチベーション下がるし、やりたいようにやらせろ、ってのはある。
そこで若者が天才的なコードを連発出来れば素晴らしい楽園が出来上がるわけだが、
実際はプログラミング自体、才能だけで突破出来るものではなく、地道な修練が必要なものだから、
そうは行かなかった、というだけ。（若いだけでは何ともならない）
結果的に「若者の楽園」＝レベルの低い「馬鹿者の楽園」になってる。ただまあ、それもありだと思うけど。
ただそれによって本来はGo界にも存在したはずの「凄いコード」に触れられる機会を逸していることは認識した方がいいとは思うが。

だから「若者」に受けているだけだとは思うが、実際それも分かる。
今のC++の仕様なんて色々複雑になりすぎてるし、あれ見たら引くだろ。使いもしない細かい仕様が多すぎる。
Javaは無駄に清書させられる、C++は意味不明、Rustはコンパイルが通らん、CはGUIには不向き、ならGoになる。
他のスクリプト言語よりは速いし。

伝わるかな？言い方を変えればユース、サッカーのU21みたいなのをプログラミング言語界に意図的に作ってる。
そこでは若者が馬鹿やってる、勿論レベルは低いがフルレギュで戦ってる大人がそれを揶揄するのは野暮ってもの、みたいな。
実際「共有RAM知りません」「空なら取ってくるだけのスケジューラは凄いです」
（この後投稿するが）「なんとNodeはシングルスレッドでした！」とか、グーで殴るぞ、のレベルだろ。
ただそれでもそういう環境の方が合う奴もいるだろうから、本人が選べばいい。
0866デフォルトの名無しさん
垢版 |
2020/11/03(火) 21:23:25.98ID:G4Sy/omH
インメモリなキャッシュと分散データベースでメモリ管理コストが影響する幅は変わるに決まってるし、そうでなくとも実測で改善してるならそれが全てでしょ
ここで比較するならC/C++/Rustみたいな言語で書き切るコストやそれを行える人材を確保するコストに対して、Goのまま書き換えなり他の手段で対処するコストがどうなのかという話だと思うよ
JavaのGCだって今や複数のリリース元から日夜改善されてってる訳で
Go自体は良さがあると思ってるけど他を眉唾だなどと語り貶めす形で話をするのはいい気持ちしないなぁ
0867デフォルトの名無しさん
垢版 |
2020/11/03(火) 21:23:39.46ID:OQJ1TfTq
あと話を聞いてる限り、新規の若者は「全部の文法」を抑えてから次に行こうとする。
本来はこれが一番効率がいいから当たり前なのだが、
C/C++はその点、古い文法＝今では使うべきではない、というのがそのまま残っていて、
何も知らない若者がそれを活用しようとしてるのが散見される。
んで、「そんなん使うなボケ」と言ったら逆ギレされることが多々ある。
ただこれらも新規参入者にとっては落とし穴でしかないから、ウザイのは事実だよ。無いに越したことはない。
これらが存在する理由はレガシー＝互換性だから、新しい言語なら比較的少ないのも事実。勿論Goも。
だからC/C++なんて最速枠でなければとっくに死んでるよ。C/C++は新規を獲得する努力をしてない。
0868デフォルトの名無しさん
垢版 |
2020/11/03(火) 21:54:35.32ID:0gT2OZTN
>それをgoroutineなんて言葉を使うから、thread/lightWeightProcess/co-routine/greenthread等を知っている奴等は余計に混乱する。

名前だけ見てコルーチンみたいなものだろうなんて思い込むうのはおっちょこちょいだろうが
使ってみりゃすぐわかるだろう、普通。
0869デフォルトの名無しさん
垢版 |
2020/11/03(火) 22:02:11.61ID:foawy7GJ
つーか Go の発案者て老人ばっかりじゃなかったっけ？
なんか皆 C++ 嫌い(それもいかにもロートルにありそうな理由)で
それであえてC++的な要素(ジェネリック、継承によるオブジェクトの多態モデル
try..catchスタイルの例外等々)は全部入れないようにしたって話だが
つまり若者向けではなく、モダンなプログラムをやりたいがCではきついので
ちょっとだけモダンになったCっぽいシンプルな言語、みたいなイメージだと思ってた
0870デフォルトの名無しさん
垢版 |
2020/11/03(火) 22:10:57.27ID:OQJ1TfTq
>>869
多分それで合ってるぞ。
それに若者が食いついただけ。
既にC++使えてる奴は全く食いつかないし、食いつく必然性もない。
0872デフォルトの名無しさん
垢版 |
2020/11/03(火) 22:28:43.57ID:XctsM+Su
>>870
たくさん書き込んでるけどもう良いだろ、Rubyスレに帰ろうな
0873デフォルトの名無しさん
垢版 |
2020/11/03(火) 22:33:32.93ID:OQJ1TfTq
>>856
Nodeがシングルスレッドなのは基本中の基本で、そんなのでこんな記事書いてること自体がびっくりだよ。
お前はそれすら知らずにNode使ってたのかよ！(Go界は人材不足だからこんなもんかもしれんが）
そこら辺がWeb系が馬鹿ばかり、と言われる点だと思うよ。これで仕事してることになっちゃってるし。
ただこいつのイベントループの部分の理解も間違ってると思うけど。
イベントループを抜ければスタックは空になる。スタックフレームガーなんて事にはならない。
そして「燃え上がるグラフ」になってるのはお前がそう組んだからで、完全に組み方が悪い。
(燃え上がってるのは「負荷」ではなくて自分が呼んだ「関数ネスト」だから）

ただまあ、組み方が悪かろうが何しようが、動くってのは重要なんだが。
だからこのケース（＝同じ奴＝同じ技術レベルの奴）が組んで動くようになったんだから、Goの方が向いているのは事実だ。
状況からすると、timeoutした場合はおそらく優先処理しないといけなくて、
それを放置して次のリクエストを積んだら余計な手間が発生するのだろう。
そうじゃないと「燃え上がるグラフ」にはならないから。

この点、NodeというかJSのイベントループには優先順位がないから、筆者の言うように「最後まで待たされる」事になる。
だから優先順位を付ける必要がある場合は自前でsetTimeoutをラップしてやる必要があるけど、逆に言えばそれだけだね。
それすら思いつかない人でもGoなら上手く行く、というのもまた重要な点ではあるけど、
781のブログと同様に噛みつかれ、「お前のコードが糞なだけ」と言われた場合、それは事実だと思うよ。
(なおこのケースはI/Oのようなので優先順位付加ではなく自前キューの方がいいが)
0874デフォルトの名無しさん
垢版 |
2020/11/03(火) 22:33:55.31ID:OQJ1TfTq
ただこれは「後付」であって、ここまで解明していればNodeでも対策は簡単に出来るわけだが、
実際はここまで解明するまでに時間がかかる。
AmazonS3がそういった類の、
つまり「timeoutのエラー処理を優先的に処理しないとその後の処理も遅れます？」みたいな特性を持っているとすると、
スペック上からは見えない落とし穴であり、Nodeなら嵌るがGoなら(知らなくても)嵌らない、というのはあり得る。
それはやっぱりNodeのシングルスレッドアーキテクチャの方が世間（他言語）からは特殊で、
Nodeだけ嵌り得る落とし穴も世の中には存在するということ。
こういうのに遭遇したくない場合、Goの方が安牌、というのはその通り。この点はNodeだけが特殊だから。
勿論この人が最初からGo使ってたら一番幸せだったろう、というのもその通り。
0875デフォルトの名無しさん
垢版 |
2020/11/03(火) 22:34:19.61ID:OQJ1TfTq
ただgoroutineって優先順位付けられたっけ？
何かこの人たまたま直ってるだけで、さらに負荷かけたらやっぱだめでした、になるだけの気がするが。
「燃え上がるグラフ」になってるのは「処理が遅い」のではなく「処理時のネストが深い」だからね。
AmazonS3のせいでもなくて、
いわゆる「コールバック地獄」的な組み方＝コールバックを深くネストして『最初の段階』で全部積み上げてしまうから、
後で止まれなくて実はtimeoutしてた時に余計な処理が多々発生してネストが深くなっているだけの気はする。
ただこの手の「不味い組み方」な奴はJSには多いのも事実。もっとフラットに組めよ、と言っても通じないし。
多分彼等にとってはJSの非同期ってのが至極相性が悪くて、
彼等的に非同期を解消する方法がコールバックネストしかないのだと思う。
その点、Goだと最初から同期で書けるので、そういった「糞コード」には(初心者でも)ならない。
この辺はC/C++/Rustだと「お前が糞なだけ」で片づけられるだろうけど、
俺自身は「初心者でも糞コードになりにくい」のは大変良い特性だとは思う。(というよりこの点はJSが糞なだけだが)

というわけで俺のその記事に対する感想は、
goroutineが優先順位付けられた場合：Nodeだけ嵌る落とし穴に命中してご愁傷様でした
goroutineが優先順位付けられなかった場合：初心者JS使いだけが何故か嵌る糞コードになっててご愁傷様でした
だな。多分後者で、初心者でも糞コードになりにくいGoだから救われた、だけの気がする。
(Goが良いというよりはJSの非同期ってのが糞コードの産地になってて、筆者もそうだっただけだが)
0876デフォルトの名無しさん
垢版 |
2020/11/03(火) 22:46:43.82ID:OQJ1TfTq
>>866
ついでだから本家の方読んできた。
まずそもそもReadStatesをそんなにバカスカ更新するようなアーキが必要なのか？という疑問はあるが、
それはさておき。

これは、多数のオブジェクトを「生存したまま」でメモリを埋める、
つまりオンメモリDBのような使い方をするアプリとGCが絶望的に相性が悪くて、それに該当した、ということなのだろう。
これはGoがショボイというよりはGCの限界で、C++/Rustしかねえわな、ということだと思うよ。
JavaでもC#でも同じ結果になる気はする。
だからそういうアプリでGC言語使っちゃ駄目、というのが教訓だと思うよ。
0879デフォルトの名無しさん
垢版 |
2020/11/03(火) 23:52:01.26ID:pWieQE6j
Ruby のコンパイルに、1CPU なら、20分掛かるけど、
4CPUなら、5分で済む

CPUセントリックな処理では、CPU並列処理は意味がある
0880デフォルトの名無しさん
垢版 |
2020/11/04(水) 00:08:44.43ID:BNFfXKWA
>>862
cspは概念・モデリングっつう理解でだいたいいいと思うよ。
昔から並行処理システム関わった奴ならたいていは似たようなモデルは考えてる。
cspはそれを厳密に数学的に記述するって感じ。
極端なこと言えばメッセージでやり取りしましょう、だ。

っで、goはプログラミング言語としてgoroutineとchannelがあるから他の言語より並行処理向き。
go以外なら古くはadaやなんかもそう。タスクにランデブポートっつうのがある。
erlangも似たようなメッセージ機構はあるんじゃなかろうか。

本質的に並行処理ってのは非同期的な処理システムなわけだけど、
非同期ioとコールバック(やシンタックスシュガー)でやるより、独自に動く実行体が複数あってそれらがメッセージ通して協調動作するってシステムの方が好きだ。
0881デフォルトの名無しさん
垢版 |
2020/11/04(水) 00:15:06.09ID:BNFfXKWA
>>876
まぁーやっぱ、gcってよくねーわ。
捨てる前提のプロトタイプにはgcあり言語もよいと思う、ほんで大部分の案件はそれで十分ってのもあっる。
げももっと性能を、、、てやると今なら c/c++/rust の3つしかナイショ。
0882デフォルトの名無しさん
垢版 |
2020/11/04(水) 00:48:58.46ID:thexrnOY
>>880
それアクターモデルだろよ、と思ってwiki確認したら、CSPがモロに書いてあったわ。
ただ、アクターは浮かんでは消え、という印象があるが。
smalltalk信者等、通信したい奴は確かにいるようだが、それがイマイチ何になるのか明確でない。

あと、コード上で通信したいのならGoだが、アクターモデル自体は普通にオブジェクト指向で組めるし、
C++なら（あまりよろしくはないが） >> と << をオーバーロードしてそれっぽく見せることは可能だ。
実際その方がgoroutineより何倍も速く動く。

Erlangは俺も以下を半分くらい読んだ程度しか知らないが、
https://www.ymotongpoo.com/works/lyse-ja/index.html
あれは実用本位で、理論側から出てきたものでは全然無い。
電話交換機筐体を複数並べてスケールアウトした時にも性能が低下しないように作られてる。
だから最初から共有RAMなんて禁止されてる。そして当然メッセージ交換だが、
最初から上記のような疎結合でのメッセージ交換を想定されてるから、
Goみたいな密結合を想定されているものとはちょっと違うが。
0883デフォルトの名無しさん
垢版 |
2020/11/04(水) 00:55:48.53ID:thexrnOY
>>881
ちなみに本家の方はコメントも付いてて、GoUserが吠えてる（事になってる。
ただあの程度で噛みつきと捕らえられるのも厳しい気はするが)

Rust試す前にGoのバージョン上げろよ、というのもそうだが、
キャッシュサーバー使えよ、というのは確かにな、とは思った。
0884デフォルトの名無しさん
垢版 |
2020/11/04(水) 04:35:34.49ID:o5YVwgYf
言葉の端々に今どきの若者は〜みたいなのを感じる
周りから相当クソ扱いされて5chで鬱憤晴らしてるんだろうな
0886デフォルトの名無しさん
垢版 |
2020/11/04(水) 07:42:42.00ID:a9nrTc1S
>>881
実際問題、ここ数年のGC言語で足を引っ張られた事はあんまりないけど。
そういう意味では参照カウンタ方式のPythonなんかは割と効率良いんじゃない？それこそスクリプト言語だけど。
言語としてのスループットを上げたければ、allocはまとめて、freeはもっともっとまとめてやって、必要そうだったらメモリのcompactionかけるほうがスループット上がると思うが。

>>882
Goのどこが密結合？
チャンネルは？
0887デフォルトの名無しさん
垢版 |
2020/11/04(水) 08:59:07.22ID:thexrnOY
>>886
参照カウンタのGCとマーク&スイープのGCは意味合いが全然違う。
それを一緒くたにしてるようでは駄目だよ。

そこら辺がGoスゲーって言ってる奴のレベルが低いところだよ。
それ以外も君は間違いすぎていちいち指摘するのは諦めたけど、
多分もうちょっと勉強した方がいい。

Goは酷い言語でもないけど、凄い言語でもない。
860の本家にRustと冷静に比較しているコメントがあるから読んでくるといい。
0888デフォルトの名無しさん
垢版 |
2020/11/04(水) 10:32:02.91ID:BNFfXKWA
>>882
c++はc++11以降ほんとよくなった。
でももう新規案件ならrustに譲ってもいいかなと思う。
0889デフォルトの名無しさん
垢版 |
2020/11/04(水) 10:57:28.03ID:BNFfXKWA
>>887
広義では参照カウンタもgcじゃん。
gcも色々改良されてるし未だに古典的なマークスイープgcのみってのはあまり無いんじゃろか。
だから案件の多いweb系とかアプリとかの上のレイヤーでgcが問題になるケースはあまり無い。

gcはそれより下のエンジンとかのシステムレイヤーで問題視されることが多い。
で、一応goはc/c++/rust同様のシステム言語のくくりで語られることもあるからその辺から叩かれたりするけど、そうじゃなくて上のレイヤーの言語として使えばいい感じの言語だと思う。
0892デフォルトの名無しさん
垢版 |
2020/11/04(水) 11:56:43.57ID:q9h9Yk1J
>>887
参照カウントに対して、俺がどういう意図で話してるかわかってる？
一緒くたにしてるわけではなくて、参照カウントのメリットってのもきちんとあるんだよ。

勘違いが多すぎるのはお前の方だと思うよ。
グリーンスレッド知らなかったんだっけ？
グリーンスレッドの切り替えにはコストがかかるんだっけ？
全部スレッドの話だよな。

いちいち都合の悪いところをネグってレスつけるのやめろよ。
0893デフォルトの名無しさん
垢版 |
2020/11/04(水) 11:58:46.84ID:5Emk5REP
Go vs Rust、じゃなくてむしろこの2つ以外が要らんのだけど
取り敢えずGoが分からないグリーンスレッド君がRustを理解出来るとは思えない（笑）
0894デフォルトの名無しさん
垢版 |
2020/11/04(水) 12:03:20.78ID:q9h9Yk1J
参照カウント方式には結構なメリットがある。
別スレッドも必要ないし、速度も出る。ストップザ・ワールドも必要ない。
オブジェクトの開放が「かならず」「一定の場所」で行われてデストラクタの動作タイミングを保証できる。
弱参照がきっちりしてればそれこそ循環参照もそれほど恐れることはない。

組み合わせて使うのが良いと思うよ。俺的には。
だからこそ引き合いに出したんだが。
C++好きならshared_ptrあたりから理解が及びそうなもんなんだが。
0897デフォルトの名無しさん
垢版 |
2020/11/04(水) 15:06:50.39ID:q9h9Yk1J
>>896
自動的にメモリを開放してくれて、フラグメントを解消してくれる仕組みは、大雑把に言ってガベージコレクションの仲間に入れるもんじゃない？
0899デフォルトの名無しさん
垢版 |
2020/11/04(水) 18:33:48.20ID:q9h9Yk1J
とりあえずGoのリリースノートを全部読んでから話してほしいな。彼には。
1.14あたりでgoroutineのスケジューラちょっと変わってるし。
0900デフォルトの名無しさん
垢版 |
2020/11/04(水) 22:39:50.46ID:thexrnOY
>>889
> 広義では参照カウンタもgcじゃん。
そう。俺も「参照カウンタのGC」とも言っている。
馬鹿は放置として、君も疑問のようだから回答しておくと、
参照カウンタ方式は「ユーザーが間違ってない」前提が必要で、「ユーザー補助」でしかない。
対してマーク＆スイープは「ユーザーが間違ってても」GCが為されるから、「システム保護」なんだよ。
だから役割が全然違う。少なくとも真面目に24時間365日動作させるつもりなら、単純に交換は出来ない。

これが結局何だかんだでマーク＆スイープから離れられない理由で、
JavaもC#もJSも、勿論Goもマーク＆スイープしてる。
勿論それが重いのはみんな分かってるから、色々工夫してるけど、最終的にはやるしかないから。

だから参照カウンタ方式のGCでマーク＆スイープと同様に「システム保護」を得る為には、
「ユーザーがどんな書き方をしても」解放されることが必要で、
例えば>>896のようなのが有ればいいけど、これで実装してる例ってあったっけ？
（なお循環参照の検出自体は簡単だが、適切に起動する為のイベントがないから、実装時に困るのはそこだと思うが）


> そうじゃなくて上のレイヤーの言語として使えばいい感じの言語だと思う。
そこは今どっかりとC#が根を下ろそうとしている。
C#は俺は良い言語だと思うけど、Javaに食われて死にそうなのがなあ、という見方だったが、
少なくとも俺の予想以上には大健闘していて、生き残るかもしれないなあ、とは思いつつある。
これまではC#もC++もWeb系が手薄だったけど、どっちもガチで整備し始めてるから、それが完了した時にどうなるかだね。
そしたら本当にGoを使う意味が全くなくなる。

逆にRustはCPU負荷無しで「システム保護」出来るわけだから、GC言語を皆殺しにかかってる。
そしてC並に速いのだから、確かに最終兵器ではあるんだよ。盛り上がる理由はそれ。
0902デフォルトの名無しさん
垢版 |
2020/11/05(木) 00:53:39.27ID:iOSFoZGZ
>>900
ユーザーが参照カウントを上げ下げすることなんてほぼないぞ
言語内の仕組みなんだから
C拡張とか書く場合もたいていスコープ抜けたら
それまでの一時変数は全解放するって書き方があるし
他のGCでもそれは同じ
だからほとんど中身の仕組みを意識しなくても良い
むしろそれができないなら実装がしょぼい
0903デフォルトの名無しさん
垢版 |
2020/11/05(木) 01:09:47.48ID:dYXzTkiF
Goが人気出た大きな理由の一つは、過不足がなく比較的高品質な標準ライブラリ
その点でいえばNodeも同じだが、Nodeと違って変なのを噛まさず標準ライブラリを素のまま普通に使うことを美徳とする文化があるのも効いてる
くだらない流行り廃りに惑わされずに決まったものをただ普通に使えばよいというのが近年の複雑化しすぎたWeb界には受けた
Rustはそのへんは全然ダメだね
0904デフォルトの名無しさん
垢版 |
2020/11/05(木) 01:17:10.50ID:x7P4NeVz
またそんな煽りを…
まったくオマイラときたら変な輩を呼び寄せる呪文を唱える
才能に関しては天才的だな
0906デフォルトの名無しさん
垢版 |
2020/11/05(木) 07:24:03.07ID:td0oky8W
RustはRustでC++の標準ライブラリがゴテゴテと九龍城が如く聳え立ってきた反動でもあるので許してやれという気持ちがある
それにしたって初期の標準が貧弱で標準に取り込むまでの右往左往が長すぎるというのも分かるが
0907デフォルトの名無しさん
垢版 |
2020/11/05(木) 09:00:41.20ID:/CgVmiK8
>>906
Rustは去年ようやく並列処理APIが固まったレベルだから、将来性はともかく現時点ではまだヨチヨチ歩きな幼児と見てる
十年後に期待
0908デフォルトの名無しさん
垢版 |
2020/11/05(木) 09:25:14.26ID:gkJnxR7E
Rustは今でも面白いよ。標準ライブラリが貧弱でも大して困らんけ、並列ランタイムだけは標準に入れて欲しかった。
メジャーなtokioとasync-stdの両対応してる場合も有るけど、大抵枝分かれしてて共存も出来ないから無駄なんだよな。
0909デフォルトの名無しさん
垢版 |
2020/11/05(木) 10:34:46.60ID:/CgVmiK8
>>908
Javaで言えば1.0レベルだろ
当時から面白かったんで使ってたけど、実用性は微妙だった。特にファイルIOとコレクション
0910デフォルトの名無しさん
垢版 |
2020/11/05(木) 10:59:39.83ID:OMGYJi8L
参照カウントって、本当に「言語の仕組み」なの？
0912デフォルトの名無しさん
垢版 |
2020/11/05(木) 11:08:21.64ID:+m168BhN
C#が充実したらGoが要らなくなる論は全然わからんな。
一体どういう理屈なんだろうか。
同じサーバサイドでもお互いに分担するエリア全然違うくないか？
というか、全然手薄でもなかったし。C#。
0913デフォルトの名無しさん
垢版 |
2020/11/05(木) 11:27:44.88ID:pymKzIg5
ファットなランタイムに依存しながらも比較的デプロイ時の取り回しが良い
わりと固定されたツールセットで無難に迷わずに使える
まあ近いと言えば近いんじゃないかな
C#をバリバリ使ってるとこだとGoの出番はないだろうし
0914デフォルトの名無しさん
垢版 |
2020/11/05(木) 11:59:24.87ID:/CgVmiK8
C#ならGUIもサービスも書けるし遅くもないから、Windowsアプリを書くなら鉄板の選択肢だよな
どうしても高速化したいとか解析されたくない時だけC++
ただ事前にランタイムのインストールが必要なんで、Linuxとかマルチプラットフォーム展開の敷居がちょっとあるんで、CLIツールとか書いてもGoに比べてデプロイが不便
充分に住み分けされてるからどっちを使う論争は不毛
0915デフォルトの名無しさん
垢版 |
2020/11/05(木) 12:39:02.69ID:+m168BhN
Windowsアプリを作るときの鉄板に関しては異論はないが、C#のデプロイはガッカリ仕様だぞ。
.Net 5でも。
0917デフォルトの名無しさん
垢版 |
2020/11/05(木) 13:22:01.75ID:+m168BhN
>>916
SCDでデプロイしたことあるか？
むちゃくちゃファイル数多いぞ。
SingleBinaryが自己展開ではなく直接アセンブリをロードする形にやっと.Net5でなったけど、そのままだとSingleBinaryと言ってるくせに数ファイル漏れるので、
それも完全にSingleBinaryにするには結局自己展開ファイルにせざるを得ない。

ファイルサイズも結構でかくて、最近は使ってるメソッドのみと言う形でTrimできるようになったけど、誤爆もまだまだあって実用とは言えんし。

ホントにやってみ。期待してただけにすごくガッカリしたから。
0918デフォルトの名無しさん
垢版 |
2020/11/05(木) 14:44:49.50ID:BWbga0la
>>908
Rustは非同期まわりが不安だよな。
0919デフォルトの名無しさん
垢版 |
2020/11/05(木) 17:50:15.36ID:goPbZhqC
>>914
F#とかどうよ
https://qiita.com/cannorin/items/59d79cc9a3b64c761cd4#%E9%96%8B%E7%99%BA%E5%AE%9F%E8%A1%8C%E7%92%B0%E5%A2%83-net-core--vscode

高速な動作, 簡単な配布
・.NET Core は現状で最も高速な .NET 実装の1つで, ベンチマーク上では例えば Go とほぼ同等〜少し速い程度のパフォーマンスを発揮します.
・.NET Core は Go と似たようなスタンドアロンバイナリの生成をサポートしており23, .NET Core ランタイムがインストールされていない Windows / OS X / Linux 環境上で実行可能な状態で配布することができます.
0920デフォルトの名無しさん
垢版 |
2020/11/05(木) 17:54:16.33ID:/CgVmiK8
>>918
まあ、不安ったって迷走してる程度で、根本的にはCの代替として落ち着いていくでしょ
確かどっか大手がコンテナの記述用途でテコ入れするとか

対立煽りしたいらしい奴は、方向性がまるで違うんだからC++のスレにでも行けって感じ
0924デフォルトの名無しさん
垢版 |
2020/11/05(木) 21:13:05.05ID:rDKR4t8H
>>901
>>905
俺が無知なのはさておき、GCを実装してる連中はそこら辺まで調査して選択してる。
Go含めて重鎮が地味にマーク＆スイープを選択するのは、それなりに理由がある。
ただし、マーク＆スイープは、「大量の生存オブジェクト」には不向きで、Discordの件はそれに該当する。
逆に言えばそれが不向きなだけで、「最小限の生存オブジェクトと大量のゴミ」という、
普通の使い方の場合には、マーク＆スイープの方がいいと判断したからそっちを選択してるわけだ。

kotolin-nativeは多分新しいことを試してみたかったんだろうと思うが、
Pythonはおそらく判断をミスっていて、通常向けに最適化するべきだと思う。
(これがPythonが無駄に遅い理由の一つになっているかも）
ただしGC機構についてだけ言えば、Python型なら今回のDiscordみたいなことにはならなかったはずだ。
だからあれはより正確に言えば「『マーク＆スイープ方式の』GCの限界」だな。
0925デフォルトの名無しさん
垢版 |
2020/11/05(木) 21:25:07.21ID:rDKR4t8H
>>903
最後の部分
> 近年の複雑化しすぎたWeb界には受けた
以外には同意だ。
俺は「Web系は複雑化しないところがいい」と見ている。
Web系は馬鹿ばかり、と揶揄されつつも、それでもWebが回ってるのは馬鹿でも回せる構造になってるからだ。
それは水平分業がしっかりしていて、しかもそれを普通に選択する文化だと思う。
例えばPHP、3層構造にするのについて誰も文句言わないだろ。
対して今回のDiscord、あれは指摘されてるとおり、キャッシュサーバーを使っていれば発生しなかった問題だと思う。
そこをなまじ実装力があって自前で実装してしまうからこそ命中する。
実際キャッシュなんて100行程度で書けるから、
不必要な機能も付いてて遅く、さらにブラックボックス的な他ライブラリ等に頼るよりは、
自前で実装する方が気分が楽なんだよ。
(ソースが読めるとしても100行程度で書けるのだから書いた方がまし、という選択になる）

その辺Web系は実装力もないからさっさと外部ライブラリ/フレームワークに頼るのだけど、
結果的にはそれの方が正しいように俺には見えてる。
この文化だと「○○が欲しい」というリクエストも感謝も明確に出てくるのでライブラリも揃う。
C++だと「そんなゴミ要らん自分で書いた方がましじゃボケ」になるからね。
だから遅々として整備は進まないが、それでも徐々には進むから、最終的にはどうなるかだけどね。

Web系が複雑化しているように見えるのは、やたらフレームワーク/ライブラリが乱立するからだと思うが、
それは外部的に見えるから複雑化しているように感じるだけ。
C++等だと内部的にみんなやってるのが出てきてないだけで、確実に重複しまくってて再開発しまくってる。
だから乱立に見えるけども一応外部に出てきて重複開発しないWeb系の方がエコシステムとしては効率がいいと思うよ。
0926デフォルトの名無しさん
垢版 |
2020/11/05(木) 21:34:05.29ID:rDKR4t8H
ちなみにデプロイって何の話してるんだ？
サーバーサイドなら最低限ビルド出来る奴がセットアップするんだから問題なし。
WindowsへのC#のデプロイは何ら問題ない。
Linuxなんてど素人は使ってない。
残るはMacだけど、お前らMac向けにGoでツールとか書いてるの？


ちなみに俺が言ったのは、「楽に書けて、サクッと動いて、そこそこの性能」という事だよ。
君らの分析の方が技術的に真面目で、さらに当たってるからそれで問題はないけど、要は、

PHPだと超超超楽勝だがポンコツ、
(Pythonだと超楽勝だがPHPと同程度の速度しか出ないポンコツ、ただしPHPからは逃れられる)、
Nodeだと楽勝でそこそこ速い、
Go/C#だと楽勝でもないがまあ普通に速い、
それより速いのはC++/Rustだけどこいつらは非現実的、

と今は並ぶでしょ。速度/容易さで並ぶのはC#。
C#の方が断然巨人だから、色々環境は整ってる。
ただしWebではなくWindowsアプリを主眼にしていたから、Web周りは若干周回遅れになってる。
勿論ASP.NETは昔からあったけどね。
サーバサイドでなくとも、要は「中庸」のプログラミング言語が欲しい場合に何が来るかということ。
一応C#は過度に難しくならないように努力してるから、巨大化している割には肥大化してない。
その辺C++とかかなり最悪だし。

ただしそれは「最速」言語の宿命で、
こちらの方が少しでも速いケースがある、という場合にユーザーが最速記述出来ないのは問題だから、
どうしても仕様が肥大化してしまう。速度面で仕様に妥協が出来ないんだ。
だからほぼ確実にRustもこれから肥大化する。

ただGoではC#を馬鹿にするなんて出来ないよ。
お前らの眼中にないASP.NETの方がGoサーバーよりも100倍シェアがある。
https://w3techs.com/technologies/overview/programming_language
0927デフォルトの名無しさん
垢版 |
2020/11/05(木) 21:45:04.52ID:rDKR4t8H
すまん100倍では済まずに 31,666倍(=9.5/0.0003)だった。
言語名を押せば各詳細が出る。

その他の面もC#は既に巨人だからC#からみればGoなんてゴミ同然で、相手されてないよ。
0928デフォルトの名無しさん
垢版 |
2020/11/05(木) 22:10:29.26ID:40Zkap5B
>>923
楽かぁ。
Goのシングルバイナリに慣れてると、結構なガッカリ感だったが、主観的な物言いしてはいかんのかもしれんな、すまん。
0930デフォルトの名無しさん
垢版 |
2020/11/05(木) 22:16:08.14ID:40Zkap5B
>>926
「サーバサイドはできる奴がセットアップするから問題なし、PHPのデプロイが簡単」とか言ってる時点で話についてこれてないから、ちょっと調べてからしっかり喋ってくれ。
少なくともPHPファイルをポン置きするような事は「デプロイ」とすら呼ばん。
C#が眼中に無いのではなくて、ここはGoのスレ。
0931デフォルトの名無しさん
垢版 |
2020/11/05(木) 22:41:27.37ID:BWbga0la
>>919
F#いいよな。
でも ocaml も流行ってないしなぁ。
ocaml は歴史もあるし金融系で使われてたり実績も十分そうなんだけど。
0933デフォルトの名無しさん
垢版 |
2020/11/05(木) 23:47:46.08ID:/6Zmm2qe
C#はビルド速度とNuGetが地味につらい

Goのビルド速度、シンプルな純正テスト環境は大きな利点に思う。小規模開発時には特に。
0934デフォルトの名無しさん
垢版 |
2020/11/06(金) 00:13:18.80ID:5acjwhy7
YouTube で有名な雑食系エンジニア・KENTA は、
初心者が進む道を、サーバー側言語のRuby → Go を王道としてる

この2つ以外は、出てこない

GUI 系は、画面の手直しなどで、工数がかさむ。
C#, dot.net などのWindows 系は、いらない。
Java などの土方系も、いらない。
C/C++ などのポインタ系や、ハードウェアの仕組みなども、いらない。
Elixir, Rust は、普及へのchasm・溝を超えられなかった
0935デフォルトの名無しさん
垢版 |
2020/11/06(金) 11:27:45.34ID:kU46w3PV
そういや Go ってジェネリック入ったの？
0938デフォルトの名無しさん
垢版 |
2020/11/06(金) 16:41:08.49ID:VIMw9dW+
「俺の考えた最強の型システム」合戦になって収集つかなくなって導入しないことが決定した
0943デフォルトの名無しさん
垢版 |
2020/11/07(土) 18:27:21.32ID:WaP+6xrD
どこかのブログで「Goはイテレータを書くのに4つの全く異なる方法がある」って書いてあったけど、これマジ？
0945デフォルトの名無しさん
垢版 |
2020/11/07(土) 21:53:29.96ID:sL9l9w2Z
>>943
イテレータを書く
と言ってる意味がよく分からない
イテレーションはrange句を書くときだけを意味するが、配列もしくはスライス、文字列、マップ、チャネルでそれぞれ受けとるイテレーション変数に違いがあるんで、それで４種と言ってる？
0949デフォルトの名無しさん
垢版 |
2020/11/08(日) 00:40:26.10ID:cr0qwrbo
>>948
1.無名関数をループする関数
2.Nextとかのインターフェースを持ったオブジェクト
3.並列処理でループさせて通信で受ける

これをイテレータねえ？
0950デフォルトの名無しさん
垢版 |
2020/11/08(日) 22:36:26.97ID:aJEtBYMB
>>948
for文だけでカプセル化できてるように思うけど

for i := 0; i < 11; i += 2 {
println(i)
}
println(i) // undefined: i
0952デフォルトの名無しさん
垢版 |
2020/11/12(木) 15:55:37.84ID:x/dKav4D
>>948
こんなことやってる奴って他にいる？
0954デフォルトの名無しさん
垢版 |
2020/11/13(金) 09:51:20.25ID:PXZYfUWY
Goではfor文がイテレータ

自分でイテレータみたいなものを実装する必要はない
0956デフォルトの名無しさん
垢版 |
2020/11/13(金) 14:22:31.00ID:PXZYfUWY
>>955
じゃあイテレータの定義説明して、どうぞ
0957デフォルトの名無しさん
垢版 |
2020/11/13(金) 14:38:40.75ID:/AMzz1sP
イテレータは、既定の順序に従って移動できることと、値を逆参照できることが要件になるだろうな。
0959デフォルトの名無しさん
垢版 |
2020/11/13(金) 15:22:45.15ID:RWm0omqa
覚えたての言葉使って見たかった説に+1
0961デフォルトの名無しさん
垢版 |
2020/11/13(金) 22:47:58.01ID:PGsPGVPV
それはただの繰り返し、
for文の説明にしかなってない。
もう一段の抽象思考が必要。
0963デフォルトの名無しさん
垢版 |
2020/11/13(金) 22:59:31.91ID:YBOwt/E7
>>960
wikipediaの解説くらい読めよ……

イテレータ（英語: iterator）とは、プログラミング言語において配列やそれに類似する集合的データ構造（コレクションあるいはコンテナ）の各要素に対する繰り返し処理の抽象化である。

「連続した要素」である必要は無いし、「一個ずつ舐め」る必要も「処理する」必要も無いぞ。
0964デフォルトの名無しさん
垢版 |
2020/11/13(金) 23:02:04.54ID:5mXtPG+h
>>963
えっ、繰り返し処理って一個ずつ舐める以外の手法ある？
実際なにかするかは別として、絶対舐めるよね？
0966デフォルトの名無しさん
垢版 |
2020/11/13(金) 23:05:54.91ID:PXZYfUWY
舐めるって何だよ（哲学）
0970デフォルトの名無しさん
垢版 |
2020/11/14(土) 09:58:05.81ID:lw/b63Rx
GoFのを定義とするならhasNextとnextでラップして要素持ってるだけなんだよな
流石に古いだけあって些か貧弱
0971デフォルトの名無しさん
垢版 |
2020/11/14(土) 10:52:40.49ID:AxEpuS5V
イテレータにそれ以上の機能は何も無いだろ。
それ以上を求めると、ジェネレータとの釣り合いが取れなくなるんじゃないか？
連続したもなにもなく「次」の値を取り出していくものでしかない気がするが。
0972デフォルトの名無しさん
垢版 |
2020/11/14(土) 12:45:38.46ID:O3AqtiwM
デザイン「パターン」だぞ
それが理解できないならシステムエンジニア向いてないよ
0973デフォルトの名無しさん
垢版 |
2020/11/14(土) 13:04:34.18ID:wV2mISWm
>>964
気に入ったのがあったら舐めるの止めてもいいし、最初の一個だけひたすら舐めてもいい(外部イテレーター限定)。
2バイト文字列とかなら1個飛ばしで舐めるのも普通。
0974デフォルトの名無しさん
垢版 |
2020/11/14(土) 14:24:39.45ID:FDvjC4Tu
>>973
舐める舐めるって気持ち悪いな
まずお前の言う「舐める」というのを具体的にどういうことなのか説明しろよ
0976デフォルトの名無しさん
垢版 |
2020/11/14(土) 15:41:11.60ID:PgJDZZ0r
>>942
ほんまこれ
Go の何が駄目といって「われらがGoはXXは無くしてシンプルに美しい」
とかなんとか自画自賛してるが、実際はむりくりそのクソみたいな
単純機能を組みあわせてクソ面倒な色々なやりくりしないといけないという
まるで前世紀の遺物みたいなシロモノ
あと Go は名前がクソ
0977デフォルトの名無しさん
垢版 |
2020/11/14(土) 15:50:35.31ID:QzputhfI
>名前が糞
同意せざるを得ない
0978デフォルトの名無しさん
垢版 |
2020/11/14(土) 16:11:45.05ID:AxEpuS5V
うーん、全世紀の遺物から、複数の戻り値とか、deferとかみたいなので別方向に進化したものだと思うけどな。
面倒くさいなって思う事もそんなに無くなったが。
後出しジャンケンみたいなインターフェイスはなかなか便利だし他の言語には無いと思うぞ。

まあ名前はひどい。
0979デフォルトの名無しさん
垢版 |
2020/11/14(土) 16:24:50.71ID:OsCdkw/B
インターフェース自体はいいんだよ。
問題は void* のような型消去した interface{} を多用しないとならないところ。
0981デフォルトの名無しさん
垢版 |
2020/11/14(土) 17:29:12.30ID:chyl+IG1
　 /＼＿＿_／＼
／　／　　 　ヽ ::: ＼
|　（●）,　、（●）、　| 　　 ／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ 　 .:::::| 　　 ＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐—´´＼
0982デフォルトの名無しさん
垢版 |
2020/11/14(土) 19:22:52.14ID:O3AqtiwM
思い付きのまま検討とかしないで言うんだけど
interface{} と書くところで {} とできたらどうだろう
0985デフォルトの名無しさん
垢版 |
2020/11/15(日) 08:38:13.89ID:QxfrfD5Z
for {}
0986デフォルトの名無しさん
垢版 |
2020/11/15(日) 13:27:59.77ID:TRv2gWKD
>>980
池沼用言語なのでお察し
ただし、昨今の高機能化(といいつつ実際には複雑化)した他言語へのアンチテーゼではある
0987デフォルトの名無しさん
垢版 |
2020/11/15(日) 14:29:31.55ID:b8fPXan8
ハァ…ハァ… 池沼用言語……？
取り消せよ……!!!　ハァ…　今の言葉……!!!
0988デフォルトの名無しさん
垢版 |
2020/11/15(日) 16:13:52.21ID:h7nWKXR3
　　　　　　　(´･ω･｀)　　ふむふむ・・・なるほどなるほど・・・
　　　　 　／ 　　　　｀ヽ.　　　お薬増やしておきますね
　　　　__/　 ┃)) ＿_i　|
　 　／　ヽ,,⌒)＿__（,,ノ＼
-----
0990デフォルトの名無しさん
垢版 |
2020/11/15(日) 19:05:53.09ID:uPufg4Im
モダンな言語使ってる所だと単価云々より労働環境のメリットの方がデカい
エンジニアファーストだしフルリモート出来るし
単価高くても出社必須・クソスペPC・下請けみたいな所は論外
0991デフォルトの名無しさん
垢版 |
2020/11/15(日) 20:37:01.75ID:TRv2gWKD
>>990
俺はJSを気に入ったから転職しようかとも思ったが、
求人見てデザイナの下請けばっかりだから止めた。(少なくともJSは、でも多分PHPも)
もしGoだとプログラマ主導が多数派なのなら、それはわざわざGoを選ぶ意味にもなり得る。
0992デフォルトの名無しさん
垢版 |
2020/11/15(日) 22:32:47.18ID:wf91lH7q
Goは何故か食わず嫌いが多すぎて人員が集まらないから、余程の高性能案件でないと
0993デフォルトの名無しさん
垢版 |
2020/11/15(日) 23:02:20.54ID:oqZpf0kM
Go案件はメルカリ一派しかまともにやってないから
その周辺の会社に行け
給料もクソ高い
0994デフォルトの名無しさん
垢版 |
2020/11/15(日) 23:28:13.85ID:BAXhy0h1
メルカリって大して儲かってないのに、株価を吊り上げてボロ儲けしてる企業だろ
株主が買った株は役員や社員のステーキ代になることも知らずによく買うよな
ほとんど宗教だな
0995デフォルトの名無しさん
垢版 |
2020/11/15(日) 23:34:27.45ID:TRv2gWKD
>>992
> 何故か
どう考えても妥当。

言語としては劣化版C++でしかないから、C++を既に使える奴が使う意味がなく、C++erからは最初から無視されてる。
これはC#やJavaを既に使える連中もそう。
要は既存言語で満足してる奴が「機能劣化版」でしかないGoを使う意味がない。
逆にC++が嫌いで嫌いで仕方ないが、それでも仕方なくC++使ってた連中が当初飛びついたが、
こいつらは最近はみんなRust行ってるはず。

結果、他言語を知らない、プログラミング初心者しか残ってないでしょ、このスレ見ても。
（ただこれが悪いことだとは言わないが。俺はそういう実験をする言語があってもいいとは思う）
0998デフォルトの名無しさん
垢版 |
2020/11/16(月) 00:12:27.10ID:/d3b4JrP
>>994
上場ゴール目的だったと思うしそれでよかったんじゃね？
そのおかげでエンジニアは金もらえるからありがたい
エンジニアは経験や実績で1000万くらいもらえる
0999デフォルトの名無しさん
垢版 |
2020/11/16(月) 00:31:23.48ID:hWakK6d2
>>998
だったらGAFA並みに成果を出してくれればいいけど、そうでもないからな
使えない奴に金を出してなけりゃいいけどね
1000デフォルトの名無しさん
垢版 |
2020/11/16(月) 00:42:31.53ID:/d3b4JrP
>>999
使えるやつが多いけど
所詮フリマアプリだからな
それにそんなリソース費やすもんか？とは思う
クックパッドと同じ謎さ加減を感じる
10011001
垢版 |
Over 1000Thread
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 395日 3時間 4分 27秒
10021002
垢版 |
Over 1000Thread
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/

▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニューススポーツなんでも実況