Go language part 2

あ · 2017/11/11(土) 19:25:26.19

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

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

日本語訳
http://golang.jp

※前スレ
Go language part 1
http://mevius.5ch.net/test/read.cgi/tech/1381374291/

あ · 2017/11/11(土) 19:49:11.79

書き込み待って読んでから8時まで待つべきだったかな。
不要なら立て直してね。
一応言い訳すると、スレタイも変わったしそっから長いから普通に二スレ目だと思っとったわ。

もっかい書いとくと、APIが不足してることはない。

995 あ sage 2017/11/11(土) 19:23:54.10 ID:X8lWnCzG
まあ、要らないカラムが多すぎるだけなら、
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:52:22.20

>>1
乙。だがhttp://golang.jp/って推奨されないurlじゃなかったっけ？

あ · 2017/11/11(土) 19:54:54.11

>>3
最早死んでるんだっけ？
申し訳ない。単純に引用した。
今どこか良い日本語のサイトがあれば、書いてもらえるとありがたい。

あ · 2017/11/11(土) 19:57:12.37

>>2
あ、これrangeでvals受ける所をvalues受けてる。あとからargsが4文字だからvaluesもvalsにしよう、とか文字数とか調整してはいかんかったな。

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

（前スレ）>>984
> 同意する。Goでデータベース操作の決定版がでないのが物語ってる。
>
> 逆にGAE/goのdatastoreを使うときはGoとの相性の良さを感じる。
> スキーマがGo側に設定することが決まっているから。

再度調べて、また考えて、大体理解した。
RDBはKVSと比較されるからKeyValueではないと勘違いしていたが、実はKeyValueそのものだ。
一方、静的言語は基本的にValueだけの世界で、Keyはコンパイル時に落ちてしまい、リフレクションするしかない。
ここが絶望的に相性が悪い。これはGoの問題ではなく、静的言語一般の問題だ。
だったらもうORMにしてしまえ、ということで、GAE/Goのdatastoreは見る限りそれに近い（と思う）

というか、静的言語でDB操作の決定版って、ORMじゃないと無理だろ。
自前のリフレクションはかなり死ねるし、そこを隠蔽してくれないと意味がない。
ただ、ORMまで持ち出すのなら「速度の為に」わざわざ静的言語を選ぶ理由がなくなってしまう。
DBで律速するのなら、動的言語でも大して変わらないはずだし、
管理も楽なら、もう動的言語で組んでしまえ、ってことになる。
(型の問題を回避する為にmapを使っても、同様に速度優位性のない無駄なシステムに成り下がってしまう）

意識したことはなかったが、静的言語では「型」を通じてプログラム全体がゆるく密結合してる。
これは「自分のみ」の世界では全く問題ないのだが、
JSON/RDB等「KeyValue前提の他人」と組み合わせる時にはかなり最悪だ。
PHPが糞言語なのは事実として、何だかんだで他を圧倒して生き残っているのには当然理由があり、
この相性問題はかなり大きい。
また、PHPerやJavaScripterが馬鹿にされる割には何とかなってるのにもこれが寄与してる気がする。
Java鹿が「オブジェクト指向で粗結合化(ｷﾘｯ」してるのは割とミクロな粗結合化で、実はあまり意味がない。
今回のようにReadとWriteを丸ごと粗結合化することは静的言語(の優位性を保ったまま)では基本的に出来ない。
動的言語では速度は最初から捨ててて、組みやすさだけを取っており、割り切り感がいい。

この点、Goは若干中途半端なポジションだが、
Go = C+GC+型システム+リフレクションかな？
C++がリフレクションしたらかなり被るね。

あ · 2017/11/12(日) 00:34:07.92

リフレクションせんでも、アサーションで十分じゃないの？
プリミティブ以外が入ってる事もほぼ無いだろうし、
型無しのinterfaceから、特定のinterfaceへアサーションした方が幸せになれるだろ。
Stringerであれば良いとか。

あ · 2017/11/12(日) 00:42:26.80

まずORMって何か考えれば良いと思うが、Object Relational Mappingだ。
リレーショナルデータベースに入れないのであれば、ORMじゃない。
ORMを、単にデータベースにオブジェクトを入れる道具の代名詞にしてるが、全然違う。

DatastoreはRDBではない。
CouchやMongoみたいなオブジェクトを放り込めるDB。そういう部分には向いてなくはない。

あ · 2017/11/12(日) 00:53:31.35

JsonとRDBを同様にキーバリューと考えてるみたいだが、「RDBは同じ列で構成された行の集合」、Jsonは「「キーで表された値の集合」の集合」であって、キーと列はかなり違う。なぜかと言うと、Jsonは「キーで表された値の集合」単体で成立するが、
「値の集合」は列がないと存在できないし、全ての値の列は同じである必要がある。
だから、マッピングせなならん。
別に、RDBでもID,シーケンス,区分列,値列で持ってメタテーブルみたいにしても良いんだから。

そこがテキトーなのは、単に作り方が雑なだけ。

ちなみに、タグに書いとけば、コンパイル時に抜け落ちる事はないので、それこそreflectで取れる。

**デフォルトの名無しさん** · 2017/11/12(日) 02:15:58.04

GoでRDB使う時に本当にきついのはSELECTとかLEFTJOINとか駆使して
カラムの構造がquery毎に違う可能性があるからなんだよね。
結局クエリごとに構造体作るしかない。
つまるところGoとRDBの組み合わせは避けるのがベスト。かも。

queryの結果から構造体をコード生成する方法があると良いんだけど

**デフォルトの名無しさん** · 2017/11/12(日) 02:48:56.74

てか、staticメソッド無しかよ！これどうなのよ？
ファクトリ作りたいんだが、まさか外に転がせと？ひどくね？
とりあえずクラスメソッドをインスタンスnilで呼んでみたがアウトだし。

なんかもう、色々酷い。
この言語は多分、ベタにしか書けないし、それをよしとする言語だ。
Cだと思えばそんなものだとも思えるが、これは逆に言うと、
Cしかやってないか、Cで何も問題を感じない奴が使う言語だね。
確かにこれだとC並みの速度は出るだろうが、これでは開発効率もC並みでしかない。
新しい言語と言うよりは、新しいBetterCの提案、と考えるべきなのか？

というか、これまで20年ほどでだいぶ積み上げたソフトウェア産業の資産、
「ソースコードはどう書けば見やすい/将来に渡ってメンテ出来るか」
をここまでガン無視していいのか？とも思える。潔いと言えば潔いが、どうなのよこれ？
若干意識高い系共によって肥大化した感のあるソフトウェア方法論へのアンチテーゼかよ？
ミニマリズムというか。

最近は一周回ってCを知らない馬鹿も偉そうにしているわけだが、
そいつらにとってはGoは新鮮なのかな？最近の言語とはだいぶ違うから。
ただ、GoはほぼCだぞいろんな意味で。

**デフォルトの名無しさん** · 2017/11/12(日) 03:04:41.10

>>10
> queryの結果から構造体をコード生成する方法があると良いんだけど
evalだね。Goには当然ないが。

C#でLINQでevalモドキを作っていたのがあったはずだが、
(心はC++のExpressionTemplateみたいなノリで、
演算子と評価順をデータとして記録しとけば、式程度ならデータ側だけで出来る、というもの）
それと同じノリで上手くいけるか、だね。
フィールドのオフセットさえ決まればそれは構造体なわけで。
ただ一般的にはオフセットはコードに静的に埋め込まれているから、
回避するにはオブジェクト指向の仮想関数テーブル(vtbl)みたいな仕組みが必要になる。
逆に言えば、これさえあれば動的な構造体を簡単に扱えるようになる。

JavaScriptは無駄に速くなっているが、この手の仕組み持っているんじゃないかな？
V8はプロトタイプ毎に型扱いでnewしてるようだし。（正式名称があったが忘れた）