Go language part 1

**デフォルトの名無しさん** · 2013/10/10(木) 12:04:51.78

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

**デフォルトの名無しさん** · 2017/11/11(土) 13:21:37.63

>>975
それだとDBのレコード個別にコードが必要になる。
だから当然困るし、当然同じように困っている人も居て、ググると出てくる。
https://stackoverflow.com/questions/17840963/create-a-map-in-golang-from-database-rows
それでsqlxなのだが、見る限りこれ裸のGoでも出来るのではないかと思って試していたわけ。

newしている意味はない、というか見ての通り今は文法もあやしいので、
動くコードを探してそこからスタートしてる。

ただそもそもsqlでレコードをいちいち走査することもないから、やりたいのはまさにsqlxのこれで、

> pp := []Place{}
> err = db.Select(&pp, "SELECT * FROM place WHERE telcode > ?", 50)
> http://jmoiron.github.io/sqlx/ より抜粋

何故これが標準でないのかがよく分からない。
(ついでに言えば三項演算子がないのも変だと思うが。)

とはいえ、自前でsqlxバリの環境を整えるなら結局リフレクションしか（多分）なく、
これが静的言語の限界というか当然で、それならsqlxを使った方が多分マシ。
楽して速い言語かと期待していたが、正直プログラミングレベルはCと大して変わらないし、
1970年代で止まっている言語と揶揄されるのも分かる。
C+GC+型システムと考えた方がいいのかなこれは。

**デフォルトの名無しさん** · 2017/11/11(土) 13:33:59.14

phpと同じ感覚でgoでdatabase使おうとすると死ぬよね。
結局go側とsql側のスキーマ二重管理になるから、そのままphpと同じノリで使えない。動的言語と静的言語の差だね。

じゃあどうするかというとsql側のスキーマからgoの構造体をコード生成する。
xo とか使う。

http://tdoc.info/blog/2016/07/06/xo.html

**デフォルトの名無しさん** · 2017/11/11(土) 13:51:58.52

>>977
自動コード生成ツールか。まあPHPとGoを同時使用するのならありでしょうな。
ただまあ、俺の場合はそうではなく、Go内で二重管理するのが気に入らない。

俺が試しているのは掲示板なんだが、PHPの場合は結局、

echo json_encode(fetch_all($db,"SELECT * FROM threads;")); // fetch_allは全読み関数

だからリード側はDBの型依存が全くない。（何が入っていても中身を全部吐き出すだけ）
結果、新規機能追加の場合はライト側の変更だけでよく、変更は1箇所で済む。
Goだとリード側も変更が必要になるのが気に入らない。
だから構造体に押し込んで、リードもライトもその構造体ベースでやれれば変更は1箇所で済む、
ということを考えているのだが、これはSQLの構造上厳しそうだ。
今sqlx読んでいるが多分無理だね。

**デフォルトの名無しさん** · 2017/11/11(土) 14:03:02.50

まぁでも、それだったら無理して go を使わなくてもいいんじゃ

**デフォルトの名無しさん** · 2017/11/11(土) 14:14:23.09

>>979
だよね。静的言語を使う限りどうしようもない。
スキーマ設定をどこに置くかという問題だと思うが。
goの構造体からsqlのスキーマを作る
or
sqlのスキーマからgoの構造体を作る

の二択しかない。リフレクションを駆使して動的にスキーマ解決したいって
結局実行時エラーの可能性が出るだけだし。

**デフォルトの名無しさん** · 2017/11/11(土) 14:27:57.90

>>979
今回は味見なんだよ。
だから糞でもとりあえずコードを書いてどれくらい速いか試すよ。
とはいえ、RawBytesとか用意して最下層のコピーもケチるくらいだから、完全にノリがCだね。
これで遅いわけがないが、結局は管理コストとの兼ね合いだろうね。
俺はC出身だから付いていけるけど、今時ではないよなこれは。

俺はPHPでも十分速いと思っている。
というか、SQLiteのラッパとしてしか使う気がないから、せいぜい100行程度しか実行しないし、
言語間の差異はほぼ無く、DBの性能が見えるだけだと思っている。
でもまあ、さんざん「PHPは糞だ」という奴が居るから味見中な訳だ。
選択肢が増えること自体は悪いことではないし。

Node.jsは既に味見終了して、データセットが小さい時はPHPよりは速い結果が出た。
しかし大きい時はPHPよりも遅くなった。これはclusterしてないのでシングルスレッドの限界かと思っている。
ただ、Nodeの場合は単一プロセスだからメモリ側にキャッシュ出来、これだと当然ぶっちぎりで速いので、
現実的にはこれかな、といった感じ。

で、Goはどうなの？ってのが今。興味あるのなら以下にどうぞ。
https://meguca.org/g/2724701
Haskellerが現れたので引っ張り込む方向で考えてる。
君らがGoのを書いてくれるのならこちらも助かるし歓迎する。

あ · 2017/11/11(土) 14:53:58.14

Cでこれ書いたら絶望的にめんどくさくない？
そもそもSQLサーバができることはSQLサーバに任せてストアドにするか、
データベース自体Goで書くか、なんかそうしないと、
インピーダンス差がでかすぎるのに2重管理しない、は無理じゃない？
2重管理が絶対的な悪ではないと思うけど。

**デフォルトの名無しさん** · 2017/11/11(土) 15:20:24.76

>>982
誰もCで書くとは言ってないが、仮にCで書くとして、
ライブラリが揃っていれば、大して苦労しないと思うよ。
Goとは大差ないだろう。

ほぼローカルで動作してしまうのでGCがないと苦労するってこともないし、
型システムも100行程度のプログラムならウザイくらいで大してメリットないし。

動的言語の場合は既に言われているようにスキーマ管理が一元化出来る
（正確にはやらなくてもそのまま動くだけだが）
分だけ書く量は少なくて済む。
プロトタイピングには動的言語の方が向いてる。

なお今回の場合はGoがCに劣ることもないので、わざわざCで書き直すメリットはない。
(GCをほぼ使わないから速度低下もないし)

**デフォルトの名無しさん** · 2017/11/11(土) 15:36:08.28

>>983
>動的言語の場合は既に言われているようにスキーマ管理が一元化出来る
>（正確にはやらなくてもそのまま動くだけだが）
> 分だけ書く量は少なくて済む。
> プロトタイピングには動的言語の方が向いてる。

同意する。Goでデータベース操作の決定版がでないのが物語ってる。

逆にGAE/goのdatastoreを使うときはGoとの相性の良さを感じる。
スキーマがGo側に設定することが決まっているから。

あ · 2017/11/11(土) 15:56:16.25

>>983
まー、確かに。
正直すぐ死ぬプログラムならメモリ管理もしない()という選択肢もあるわけだしな。
外の世界と相性の悪い言語だと言うことは確か。
形が適当なjsonとかとも同様にいちいちキャストがしちめんどくさいし。
c#で言うdynamicみたいな型がありゃ良いなとは思うが、コンパイル時に解決してる事を善とするので無いのは仕方ない。向いてないわ。

**デフォルトの名無しさん** · 2017/11/11(土) 16:18:54.52

というか、これはAPIが足りてないんだね。
（以下コードは文法があやふやなので参考程度で）

database/sqlはScanを使うのが定番のようだが、Scanではargsの可変長指定しかないのがいけない。
だから構造体の中身を確認するのにリフレクションが必要になってしまう。

type Thread struct {
no int
time int
body string
}
th := Thread{}
rows, err := db.Query("SELECT * from threads;")
err = rows.Scan(&th.no, &th.time, &th.body) // ここでばらすから中身を知らないといけない

とりあえずScanが構造体を受け、その構造体にScannerインタフェースを実装する方式なら、
リフレクションは回避出来るし、おそらく最高速度で動く。
ただ、このためのAPIがない。

err = rows.Scan(&th) // ばらさずに構造体を与える
func (th Thread) Scan(src interface{}) err // 各構造体でばらす。手間は増えるが最速のはず

DBを生で叩いたことがないから知らないが、DBからの出力が既に配列なのか？
或いは同様のことはポインタ配列で受ければいいので割り切ったか。(972参照）

>>984
GAE/Goはググってみたがよく分からん。
ただ今回はCREATE TABLE部分も自前で持つ為、スキーマ管理はGo側でも「本来は」出来る。
SQLの構造上、CREATE TABLE と　INSERT はほぼ同じなのでPHP等ではSQL文字列を共有出来る。
だから1箇所にしか書かずに済んでた。ところがGoはリード側も必要だからぐぬぬ、ってなってる。

**デフォルトの名無しさん** · 2017/11/11(土) 16:29:51.83

>>985
お前他スレも荒らしてた荒らしだろ。

この程度のプログラムで「メモリ管理(ｷﾘｯ」とか言っちゃう時点でお前はCを知らないし、
お前みたいな馬鹿にはCは無理だ。
それで何故Cに話を振る？だれもCで実装しようともしてないのに。

普通にCが出来る奴なら鯖でDB読んでJSON返すだけのプログラムでリークはしないし、
リークしないように管理する（程のこともないが）に苦労することもない。
そもそもそれはGoで書いた時にGCがどこで動くか見えていれば分かるはず。
君はそこにも達していない。

**デフォルトの名無しさん** · 2017/11/11(土) 17:10:37.92

うめようず

**デフォルトの名無しさん** · 2017/11/11(土) 17:56:09.07

というか void* がないのね。
これではどうやっても fetch_all で隠蔽出来そうにない。
まあ void* なんて認めたら型システムは崩壊するから致し方無しか。

そしていきなりunsafeに手を出そうかと考えているわけだが、
これって Offsetofがあるって事は基本的にはマーシャル用なのかな？

あ · 2017/11/11(土) 18:53:30.76

>>987
荒らしじゃないよ。
真面目に話してるが、仮定に対して仮定したら切れるって意味わからん。

あ · 2017/11/11(土) 18:58:21.35

>>987
まさか、
>>981の、ノリがC、C出身だからついてける、に対して
「ならCで書けば？でもめんどくさいと思うけど。」って嫌味だって気づいてないんだろうか？
可哀想な人ってどこにでも居るんだな。

Gcが動くタイミングに関しては、多分もう少しマシなレベルで知ってると思うけど。

そもそも、CでDBから取得してどうの、と言う話で、何を使うかどう取得するかすら決まってないのに、リークしないようにメモリ管理するなんて絵空事は言えんだろ。
全部インハウスライブラリならわかるけどさ。
メモリ管理しない、は思いつきでも言えるわ(笑)

あ · 2017/11/11(土) 18:59:31.42

嫌味が荒らしになるとは、ネットは京都より平和な場所になったんだなぁ。

あ · 2017/11/11(土) 19:03:39.05

よく読んだら>>979で同じ事言われてるのにドヤ顔で返事してるし、本気でそうなんだろうな。

void* をどう使いたいかによるだろうが、それこそ*interface{}じゃねえの？と思ってしまう。

**デフォルトの名無しさん** · 2017/11/11(土) 19:16:58.98

次スレよろ

あ · 2017/11/11(土) 19:23:54.10

まあ、要らないカラムが多すぎるだけなら、
row,err:=sql.Queryで、
column,err:=row.Columns()
vals:=Make([]sql.RawBytes,len(column))
args:=Make([]interface,len(column))
for i:= range values {
　args[i]=&vals[i]
}

でvalsとargsつくって、
Scanに(args...)で渡せば、
使うときにvals[i]をstring(vals[i])とかよしなにしちゃえるんじゃないの？

**デフォルトの名無しさん** · 2017/11/11(土) 19:26:08.40

>>991
日本語でおｋ

君と話が噛み合わないのは、君が勝手に読み違えているから。
それは君の日本語能力が不十分だから。
だから君は荒らしなんだよ。
俺は他スレで君が同様に空回りしてるのを見たことがある、というだけ。

君には荒らすつもりはないのだろう、それは事実としても、
日本語能力が足りない奴がレスすること自体が荒らし行為なんだよ。
馬鹿なら馬鹿なりに何度でも読み返せばいいだけなんだがな。

韓国人ならマジで死んでくれ。

>>994
おｋ。>>46見る限り次スレはpart6(このスレがpart5相当）でいいか？
8時まで待って異議なしなら俺が建ててみる。
異議ありならその人が建てて。

あ · 2017/11/11(土) 19:26:19.52

Go language part 2
http://mevius.5ch.net/test/read.cgi/tech/1510395926/

あんまり立てないから間違ってたらごめん。

あ · 2017/11/11(土) 19:26:34.95

>>996
ごめん、勢いで建てた。

あ · 2017/11/11(土) 19:27:10.90

>>996
バカはバカなりに何度も読み返してくれれば、嫌味にも気がついだだろうに。悲しいなぁ。

あ · 2017/11/11(土) 19:34:53.44

まあ、可変長受ける関数に実体を指すinterfaceの参照のスライスを...で渡せるのはと割と便利。

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 1493日 7時間 30分 2秒