Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。
公式ドキュメント
http://golang.org/doc/
日本語訳
http://golang.jp
※前スレ
Go language part 1
http://mevius.5ch.net/test/read.cgi/tech/1381374291/
Go language part 2
■ このスレッドは過去ログ倉庫に格納されています
1あ
2017/11/11(土) 19:25:26.19ID:X8lWnCzG2あ
2017/11/11(土) 19:49:11.79ID:X8lWnCzG 書き込み待って読んでから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])とかよしなにしちゃえるんじゃないの?
不要なら立て直してね。
一応言い訳すると、スレタイも変わったしそっから長いから普通に二スレ目だと思っとったわ。
もっかい書いとくと、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.20ID:proXGFSN
4あ
2017/11/11(土) 19:54:54.11ID:X8lWnCzG5あ
2017/11/11(土) 19:57:12.37ID:X8lWnCzG >>2
あ、これrangeでvals受ける所をvalues受けてる。あとからargsが4文字だからvaluesもvalsにしよう、とか文字数とか調整してはいかんかったな。
あ、これrangeでvals受ける所をvalues受けてる。あとからargsが4文字だからvaluesもvalsにしよう、とか文字数とか調整してはいかんかったな。
2017/11/11(土) 23:47:05.71ID:LLMRc4SD
(前スレ)>>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++がリフレクションしたらかなり被るね。
> 同意する。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++がリフレクションしたらかなり被るね。
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- テレビ朝日 本社から男性が転落し死亡。関連会社社員か 当たった通行人が左肩軽傷 [阿弥陀ヶ峰★]
- 「これいいじゃん!!!」 セブン-イレブンの1620円で買える“1人用クリスマスケーキ”🎂に注目殺到「天才すぎる」 [パンナ・コッタ★]
- テレビ朝日本社から20~30代の関連会社社員とみられる男性が転落し死亡 六本木けやき坂通りの通行人にはけが人なし [少考さん★]
- 高市早苗首相が天理教系企業に“巨額発注” 総額5000万円 本人は「政治団体の活動に必要な支出」と回答 ★2 [Hitzeschleier★]
- 小島瑠璃子さん、代表取締役を務める会社を破産申請 [牛丼★]
- 「残クレ」でマイホーム、国が銀行向け保険 新型住宅ローン普及促す -日経 ★3 [少考さん★]
- 橘こぉた来いや!!!
- 【悲報】ジャップ、日中戦争に賛成が5割弱...軍歌の音が聞こえる... [856698234]
- お前ら(ちぎゅちぎゅの実モデルチーズ牛丼)←これw
- 隣の部屋のデブがこっちにまで聞こえる声量でアクビするのがストレスなんだけどマジで死んでくれないかな
- 【乞食速報】プロクオリティ ビーフカレー 96食 4262円 [268244553]
- 【悲報】小泉防衛大臣、中国のレーダー照射事件をNATO事務総長に報告 [834922174]
