[過去ﾛｸﾞ] Go language part 2 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
6(1): デフォルトの名無しさん [sage] 2017/11/11(土) 23:47:05 ID:LLMRc4SD(1) AAS
（前スレ）>>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++がリフレクションしたらかなり被るね。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.224s*