Go language part 2
GoはGoogleによって開発された言語です。
公式ドキュメント
http://golang.org/doc/
日本語訳
http://golang.jp
※前スレ
Go language part 1
http://mevius.2ch.sc/test/read.cgi/tech/1381374291/
不要なら立て直してね。
一応言い訳すると、スレタイも変わったしそっから長いから普通に二スレ目だと思っとったわ。
もっかい書いとくと、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])とかよしなにしちゃえるんじゃないの？
乙。だがhttp://golang.jp/って推奨されないurlじゃなかったっけ？
最早死んでるんだっけ？
申し訳ない。単純に引用した。
今どこか良い日本語のサイトがあれば、書いてもらえるとありがたい。
あ、これrangeでvals受ける所をvalues受けてる。あとからargsが4文字だからvaluesもvalsにしよう、とか文字数とか調整してはいかんかったな。
> 同意する。Goでデータベース操作の決定版がでないのが物語ってる。
>
> 逆にGAE/goのdatastoreを使うときはGoとの相性の良さを感じる。
> スキーマがGo側に設定することが決まっているから。
再度調べて、また考えて、大体理解した。
RDBはKVSと比較されるからKeyValueではないと勘違いしていたが、実はKeyValueそのものだ。
一方、静的言語は基本的にValueだけの世界で、Keyはコンパイル時に落ちてしまい、リフレクションするしかない。
ここが絶望的に相性が悪い。これはGoの問題ではなく、静的言語一般の問題だ。
だったらもうORMにしてしまえ、ということで、GAE/Goのdatastoreは見る限りそれに近い（と思う）
というか、静的言語でDB操作の決定版って、ORMじゃないと無理だろ。
自前のリフレクションはかなりRるし、そこを隠蔽してくれないと意味がない。
ただ、ORMまで持ち出すのなら「速度の為に」わざわざ静的言語を選ぶ理由がなくなってしまう。
DBで律速するのなら、動的言語でも大して変わらないはずだし、
管理も楽なら、もう動的言語で組んでしまえ、ってことになる。
(型の問題を回避する為にmapを使っても、同様に速度優位性のない無駄なシステムに成り下がってしまう）
意識したことはなかったが、静的言語では「型」を通じてプログラム全体がゆるく密結合してる。
これは「自分のみ」の世界では全く問題ないのだが、
JSON/RDB等「KeyValue前提の他人」と組み合わせる時にはかなり最悪だ。
PHPが糞言語なのは事実として、何だかんだで他を圧倒して生き残っているのには当然理由があり、
この相性問題はかなり大きい。
また、PHPerやJavaScripterが馬鹿にされる割には何とかなってるのにもこれが寄与してる気がする。
Java鹿が「オブジェクト指向で粗結合化(ｷﾘｯ」してるのは割とミクロな粗結合化で、実はあまり意味がない。
今回のようにReadとWriteを丸ごと粗結合化することは静的言語(の優位性を保ったまま)では基本的に出来ない。
動的言語では速度は最初から捨ててて、組みやすさだけを取っており、割り切り感がいい。
この点、Goは若干中途半端なポジションだが、
Go = C+GC+型システム+リフレクションかな？
C++がリフレクションしたらかなり被るね。
プリミティブ以外が入ってる事もほぼ無いだろうし、
型無しのinterfaceから、特定のinterfaceへアサーションした方が幸せになれるだろ。
Stringerであれば良いとか。
リレーショナルデータベースに入れないのであれば、ORMじゃない。
ORMを、単にデータベースにオブジェクトを入れる道具の代名詞にしてるが、全然違う。
DatastoreはRDBではない。
CouchやMongoみたいなオブジェクトを放り込めるDB。そういう部分には向いてなくはない。
「値の集合」は列がないと存在できないし、全ての値の列は同じである必要がある。
だから、マッピングせなならん。
別に、RDBでもID,シーケンス,区分列,値列で持ってメタテーブルみたいにしても良いんだから。
そこがテキトーなのは、単に作り方が雑なだけ。
ちなみに、タグに書いとけば、コンパイル時に抜け落ちる事はないので、それこそreflectで取れる。
カラムの構造がquery毎に違う可能性があるからなんだよね。
結局クエリごとに構造体作るしかない。
つまるところGoとRDBの組み合わせは避けるのがベスト。かも。
queryの結果から構造体をコード生成する方法があると良いんだけど
ファクトリ作りたいんだが、まさか外に転がせと？ひどくね？
とりあえずクラスメソッドをインスタンスnilで呼んでみたがアウトだし。
なんかもう、色々酷い。
この言語は多分、ベタにしか書けないし、それをよしとする言語だ。
Cだと思えばそんなものだとも思えるが、これは逆に言うと、
Cしかやってないか、Cで何も問題を感じない奴が使う言語だね。
確かにこれだとC並みの速度は出るだろうが、これでは開発効率もC並みでしかない。
新しい言語と言うよりは、新しいBetterCの提案、と考えるべきなのか？
というか、これまで20年ほどでだいぶ積み上げたソフトウェア産業の資産、
「ソースコードはどう書けば見やすい/将来に渡ってメンテ出来るか」
をここまでガン無視していいのか？とも思える。潔いと言えば潔いが、どうなのよこれ？
若干意識高い系共によって肥大化した感のあるソフトウェア方法論へのアンチテーゼかよ？
ミニマリズムというか。
最近は一周回ってCを知らない馬鹿も偉そうにしているわけだが、
そいつらにとってはGoは新鮮なのかな？最近の言語とはだいぶ違うから。
ただ、GoはほぼCだぞいろんな意味で。
> queryの結果から構造体をコード生成する方法があると良いんだけど
evalだね。Goには当然ないが。
C#でLINQでevalモドキを作っていたのがあったはずだが、
(心はC++のExpressionTemplateみたいなノリで、
演算子と評価順をデータとして記録しとけば、式程度ならデータ側だけで出来る、というもの）
それと同じノリで上手くいけるか、だね。
フィールドのオフセットさえ決まればそれは構造体なわけで。
ただ一般的にはオフセットはコードに静的に埋め込まれているから、
回避するにはオブジェクト指向の仮想関数テーブル(vtbl)みたいな仕組みが必要になる。
逆に言えば、これさえあれば動的な構造体を簡単に扱えるようになる。
JavaScriptは無駄に速くなっているが、この手の仕組み持っているんじゃないかな？
V8はプロトタイプ毎に型扱いでnewしてるようだし。（正式名称があったが忘れた）
自分の型をポインタで書いたらnilで呼べるだろ。
可変長もそうだし、ちゃんと言語仕様読め
セルフホストされるようになってから長いぞ。
goにクラスの概念はないぞ、ドキュメント読んで勉強し直せ
お、ポインタレシーバならnilで受けられるのか？
しかしまあ、ベタで書くことにした。
というか、どうもその手の「ちょっと綺麗に書くテクニック」を全力で否定するノリのようだし。
なまじ隠蔽出来るから無駄に肥大化するのであって、管理が厳しくなったらパッケージを分けろ、なんだろ、多分。
まあ分からなくもない。
JavaScriptの関数スコープは最初は戸惑ったが、結局のところ関数を小分けにすればいいだけであって、
Cとかはなまじブロックスコープなんてあるから無駄にでかい関数になってしまうのも事実だ。
Nodeのコーディングルールなんて段々短くなってて、どうも今は「関数は10行にしろ」と言っているようだし。
（以前は19行だったと思った。今ググったら15行（多分更新されてないだけ）ってのはあった）
同様に、基本的にパッケージ内にベタで転がしておき、無理ならパッケージを分割、というのも妥当な方法ではある。
そもそもメソッドも（見た目は）ベタで転がってる訳だし。
まあこれはいいとしても、generic的な物がもうちょっとないと、昔の定義のコピペプログラムが必要になってしまう。
この点については何で端折ったのかよく分からんなあ。
C++のテンプレートは暴走気味だし、そういうのを嫌ったのかな？
まあいずれにしても、俺にとってはGoはbetterCとして理解した方がいいというのはかなりはっきりしてきた。
いやまだ終わってないんだなこれがw
道草食いまくってるからだが。
ただ、GoはWebには不向きというか、新規機能追加等で変更を迫られた場合、
PHP/JavaScript等と比べて3-5倍のコード変更が必要になりそうだ。
そしてこの、変更時のコード量がCと比べてほぼ同量だ。だから開発効率はかなり悪い。
パッケージが揃っているからとっつきやすいだけで、
（ライブラリを熟知している）バリバリのC++使いにとっては魅力はほぼ無いだろう。
とはいえ、「とっつきやすいC」という存在価値があるのかもしれない。
というか、C++は取っつきにくすぎる。あれは完全に暴走してる。Linusが毛嫌いしているのも分かる。
とはいえ、Goでプロトタイピングするのは辛いのは分かった。
というか、はっきり言ってろくな言語がないなこれについては。
JavaScriptは非同期のおかげでかつてのgoto文プログラムみたいな構造になってしまうし、
PHPは言語仕様が糞過ぎて思わぬところでバグって引っかかりまくるし。
RubyもPythonも前方宣言必須のゴミ言語だし。
同期JavaScript（マルチスレッドだよ！）が出れば一人勝ちじゃないのかな、と思うが、
あいつらの非同期はもはや宗教だし。
愚、言語がヘボでカラム分からんとDB操作が出来ません
賢、いやいや、アサーションでこう書けば出来るじゃん？
愚、他言語だとこんなので出来るんだけど
賢、じゃ好きなので書けよ、どうぞどうぞ
まとめるとこんな感じ？
ちょっときれいに書くテクニック、が他の言語と違うだけだよ。可変長引数に参照のスライスを渡す、とか、
取り敢えず受けて.(type)でswitchしてcaseに型書いて処理するとか。
ジェネリックに関しては、あれば良いなと思う事もあるが、実際やってみたらrangeで事足りたり、
chanにとにかく突っ込んで、空selectとcase xxx<-xxxchでさらに事足りたりと、便利な読み方はある。
システムコールのselectで複数のファイルハンドル待つ感じ。
>>18
多分ウェブに関して言えば、ちゃんとしてればPHPの工数の4番の1くらいになると思うよ。
ちなみに、JavaScriptでマルチスレッドマルチコアは、クライアントならWebWorkerやら、nodeなサーバならclusterとか色々ある。
構造体の入れたいフィールド(と読み捨てるカラムを放り込む値)の参照を持ったinterfaceのスライス投げるのが一番手早い。
入れたいフィールドのカラムを集めてinterfaceのスライスを返す関数用意しときゃ済むじゃん、ゼロクリアは保証されてるんだから。
ちょっとわかりづらいからサンプルコードある？
過度の抽象化は害しかないって偉い人が言ってた
>>2
hogeって構造体があって、そのxxを取りたいなら、
のargsの、欲しいカラムの場所に&hoge.xを入れるだけ。
構造体を自動精製するんじゃなくて。
リフレクションとアサーションは違うし、そもそもそこまで遅くないぞ。
度を超したクソッぷりにビビる。つーか、お前らマゾなのか？
1回目：type struct 内 ← うーん、まあ静的言語なら仕方ないか
2回目：rows.Scan 内 ← 速度の為なら仕方ないか、、、
3回目：メンバ名は大文字で始めてjsonタグをいちいち書け ← R
PHPやJavaScriptでは1回も書かなくていいんだぜ！
さすがにこれには切れたよマジで。
https://qiita.com/vvakame/items/6719b3c90dfaa8220e44
どうぞどうぞ
Scanには書かんで良いだろ。何読んでんだよ。
Jsonなら、*interface{}で受けて、map[string]interfaceで値とりゃフィールド名出てくんの一回だろ
だから、>>9で、RDBのように行と列が分離してねえんだよって言ってんじゃん。
しかし2chで知りたいことがあればdisれというのはホントだな。
Scanの実装見て喋ってんのかなぁ。
cやcppで書いたらライブラリ使ってももっと地獄じゃん。
動的言語しかやった事無いから辛いと言ってるだけに見える。
まさか３回も書かされるとは思っていなかったから今更ながらxoを試した。
が、これもちょっと冗長だな。
標準で go generate がついている時点で、公式も糞っぷりを認めてる。
ASTとか完全に屋上屋を架してる。
ろくな解がない。
構造体メンバを１回書くところまでは許すとして、
Scanは構造体を受けろ、JSONはlowerCamelスイッチをつけろ、ってとこだね。
3回も書いたのは自分だろ…。
構造体渡したら構造体の(カラム名と同じ(！))メンバに入れてくれる事を望んでるんだろうが、
型がハマらなかったらとか、そもそもクエリでasで別名つけてるかもとか、キャストしたけどasで同名つけてる、とか、クエリ側が勝手な事するリスクを全部解決して構造体に入れる手段を考えてから考えれば良いのに。
まぁmap[string]interfaceが落としどころじゃねえの？フワフワ適当なクエリ投げたいなら。
クエリ自体もGoに書かせたいなら、最早SQLと繋げる意味なかろうて。
> Scanは構造体を受けろ、JSONはlowerCamelスイッチをつけろ、ってとこだね。
ま、↓にでも投げてみたら
ExperienceReports
https://github.com/golang/go/wiki/ExperienceReports
構造体で受けるだけならそうだね。
ただ、毎回リフレクションはかなり厳しいから、うまくキャッシュしてくれるかどうか。
refrectを見る限りシグニチャは発行してくれないっぽいし。
ポインタ演算を禁止しているから、ＣみたいにOffsetofの結果を配列でキャッシュできないのも残念な所だね。
使うときは速度/ソース確認必要といったところか。
今回は速度の味見だし、とりあえずベタで書いた。
ただ2回書きまでは覚悟してたが、3回とはね、、、
まあ俺が煽るから無視してるんだろうが、
煽り抜きでとりあえず>>2と>>25やってみたら？
ベタ書きよりはましだと思うが。
なんかそれでダメな点があればまた教えて欲しい。
さすがにＧｏ歴１週間もないのに投げないよ。背景等もよくわからんし。
てか、同意するなら誰か投げてどうぞ。
てか、Ｇｏ信者はこの言語のどこに惹かれてるんだ？
特に目立ったメリットはないような。
むしろ標準ライブラリにASTついてるのって魅力じゃないんかな。
goはコード生成してなんぼなんじゃないの
日本語でおｋ
おまえには日本語が通じず、話が空回りするから無視してる。
map/リフレクションを使わない理由は俺は既に>>6で言っているし、
それはむしろ一般論だから、他の人もそれをふまえて話をしている。
おまえだけ空回りしてるんだよ。そしてそれが荒らし行為なんだよ。
煽るとか、そういう表面的な行為は大した問題ではないんだよ。
おまえは馬鹿だからそれも分からない。マジでR。
マップでもリフレクションでもないんだが。
俺的に気に入ってる点。
* 構文規約が言語側で確定してるから誰のgoコードでも見やすい。
* コードの管理周り。 正直他の言語でもコード管理は真似してる(ghqをつかって)
* 標準ライブラリが学習教材になってる感じ。
* goaがある。
正直一番最初に使いたい理由になったgoroutineは一番最初に触って以降触ってないな。
色々欠点もあるけど、なんかコード生成によるメタプログラミングを体得すれば解決する問題かも。と思っていてAST周りを学習中
いや、正直、そういう文化なのかな？とちょっと思ってました。
てかなに？今時の若者はASTとかでさくっとコード生成しちゃうもんなの？
俺はlexとかbisonとかは触らずにきてるんだけどさ。
まぁ、やりもせず、パフォーマンス計測もせず、思い込みで「これはリフレクションである」と言われても困るわ。
空回りしてんの俺か？
> てか、Ｇｏ信者はこの言語のどこに惹かれてるんだ？
> 特に目立ったメリットはないような。
ある種のシミュレーションプログラムを作るのに goroutine + channel
で割合と簡単に書けちゃって、32 core 使って並列化したら実行時間が
1/25 程度に抑えられて…といった経験からかな。
https://research.swtch.com/interfaces
go fmtとか、パッケージ管理/ディレクトリ構造が言語に密着とか、確かにいい割り切りっぷりではある。
しかし他挙げてくれた点も、Ｇｏ言語自体ではなくて、エコシステムの話だよな？
いやもちろんエコシステムも重要なんだが。
gorutineはパンダだろ。その意見（最初だけしか使ってない）は割とよく見るよ。
> コード生成によるメタプログラミング
まあＣのマクロやC++のテンプレートよりはましかも。ソースが直接見えるという点で。
用途次第だろ。
そんな恐ろしいもんじゃなくGoコードを構造体に変換できるから
改変がし易いってだけじゃないかな。
正規表現で変更とかよりよっぽど安心できる。
goroutine+channelがはまったケースか。
それなら分かるとして、ただ、そもそもこれがはまるケースがほぼないよな？
ハイジェニックなマクロ展開とか書きやすいしね。
人の話も聞かんと、言葉が理解できないならコードは読むだろうと解説代わり書いて、
Cがわかるなら.sに落として眺めるだろうという期待も裏切り、
何やってるかまったくわからん。
> 正規表現で変更とかよりよっぽど安心できる。
確かに。自前よりは公式解釈済みの構文木をもらえた方が100倍いい。
しかしそれ、渡されましても、、、ってのが普通だと思うが。
てか、これ見せてる言語ってこれまであったっけ？
最近はflycheckみたいなリントも流行ってるみたいだし、見せる方向なのか？
俺にとってgorutineはたしかにパンダだったな。
構文規約が言語側で確定って割と言語仕様よりなんじゃないの。
Go言語の言語仕様は物足りさは感じつつってのはある。
interfaceがGoにおけるキモなんだけど機能不足感があって
関数の引数がなんでも受け入れokな interface{} 型になるとかなり残念になる。
多分interfaceにプロパティをokにしたり
type interfceC =interfaceA | intrefaceB
(interfaceCはinterfaceA か intrefaceBどちらかを満たす 直和型ってやつ)
みたいな定義をokにしたり、シンタックスシュガーだけど
type interfceC =interfaceA & intrefaceB
みたいな定義もokにしたら幸せというかジェネリクスに進化できる気がする
標準ライブラリじゃないけどjsがそんな進化を遂げてる。
http://efcl.info/2016/03/06/ast-first-step/
はまる、はまらないで言ったらやっぱり……いや、もう何も言わないよｗ
rustとか言語ヲタじゃないと触ろうってならないし。
goはCLIツールを作るためのライブラリも揃ってるし
ツール作る系でもおすすめ
呆れるやつ、ASTいじりはいいぞ、気に入ってる点、諸々。
語るに落ちられてバカさらされて、なんでこんな言われなならんのだ。
まじかよ！JavaScriptならevalできるし無限増殖できるぜ！って思ったけど、
俺が思ってたASTのフォーマットとものすごく違ってた。
これ完全に文字ベースだよな。
もうちょっとファンクションベースなものを期待してた。
メトリックスをASTから抜いたツールもあるようだが、これ相当Rるだろ。
http://azu.github.io/slide/JSojisan/#7
まああくまでパースした直後のデータで、だからこそすべての用途に使えるってことなんでしょうな。
ただ、ここからコード生成も相当Rると思うが。
そして長文で語れよ。
interfaceのプロパティってのは何に使うんだ？
俺は一応、Ｇｏのインタフェースシステム「実装してたらその型として使える」はありだと思っている。
平べったいダックタイピングというか、C++のtemplateを野良で転がしているのに近い。
貧弱かどうかって所まではまだ味見できてないから分からない。
直和や直積（でいいのか？）は別名でテンプレート書け、って文化なんだろ多分。
割とベタが好きな言語なんだと思うよＧｏは。
escodegenがこれ食うからいいんだよ
× 別名でテンプレート書け
○ 別名でインタフェース書け
と言いたい。コード生成で頑張るべきなんだろう。
goaはコード生成に頼りまくりのおかげでinterface{}型に出くわすことがなくて幸せ。
interface型は宣言がそうなだけで、実際には型持ってるから、そこまで嫌わんでも良いんじゃないの？
default書くのをサボらなければそうそう死なん。
んなこと言ったら動的言語だって内部的には型を持ってるよ。
問題はintereface{}型が関数パラメータに使われた場合、
Printlnみたいになんでも受け入れ可能って意味ならいいんだけど、
実際にはGoの表現力が不足していて仕方なくってパターンが多い。
動的言語の良いところを取るべくして、ただのvoid*には無い機能をもたせてるんよ。
表現力が足りないと言うより、ではなくて、本来は型にアサーションするんじゃなくて、別の任意のinterfaceにアサーションして便利に使おうね、って感じの思想。
だから、printf渡すだけでも、%sで渡すとStringerとして扱われたり、%+vで中身が見れたり玉虫色の解釈が出来るようになってる。
何でも受け入れ可能だから形無しinterfaceではなくて、こいつの型は提示せんがフォーマット文字列の通りに扱えよ、という意味であの引数。
だから、interfaceは明示的に実装しなくても、満たす関数があれば自動的に実装されるようになってる。
俺が今こうinterfaceを宣言して、そうするとこの構造体には自動的に実装されてるはずだから、俺は与えられた引数を宣言したinterfaceとして扱うってアサーションがかけれる。逆に言えば、俺に処理してほしけりゃこれを実装しとけ、って発想。
後出しジャンケンみたいなジェネリクス。
[]interface{}として渡してて、その1つの指す先が「構造体の要素一つ」であっても、
その要素がScannerを実装してればそれに処理を任せてる。
「構造体の要素一つ」をプリミティブな型で宣言せんと、ちゃんとtype IDColumn int等と宣言して、IDColumnとして構造体の要素を宣言しとけば、IDColumnにScanner実装しとけば[]interface{}の中にその参照突っ込んでもそれが呼ばれる。
type IDColumn int
type xxxRow struct {
ID IDColumn
}
で、
v:=xxxRow{}
って作って、
>>2のargsを例に上げるとargs[0]=&v.ID
ってして、Scanに(args...)で渡した時、0カラム名はIDColumnのScanで処理されて、v.IDに入る。
APIが足りてないとか大嘘。
それだけ。
あとからStringerにして、そいつの中で実行時に死にうるコード書いたら、全くソース変えてない部分で実行時エラーになるんだし。
実質sprintfなんか使えないコードになってしまう。
defaultはエラー処理じゃなくて正常系。
は静的言語のメリットを全くわかってない。
以下を読めばinterface{}型のデメリットが理解できるはずだから読め。
http://sssslide.com/speakerdeck.com/twada/php-conference-2016
リーナスも言ってるでしょ、基本的には去ってもらうこと、これが最も良い解決策。
向上心が有るなら別だが、基本が納得出来ないなら「どうぞ、どうぞ」が一番良い
デメリットと言うより、必要悪だろ。
一切キャストしないCも書けるが
このスライド出す時点でナンセンス。
PHPの変数は暗黙的変換で無残なことになる、数や名前や型の不一致はそれこそ、毎度構造体を作る事によって引き起こされる。
val,ok := アサーション
でokが見れるという点で殆ど対応できる。
Bugクラスが未定義、と言うところもおかしいわな。
interfaceを実装してればそれがなんであれそのinterfaceとして扱えるように、ライブラリ書くだけだろ。
ただの型チェックの防御的プログラミングとは違う。
interfaceとのチェックと、interfaceに任せる事での、そのロジック内での処理と切り離した、interfaceへの責任転嫁に近いが、
interfaceをいかに正しく定義、実装するか自体が問題であって、型は無くて良いよねって言ってるわけじゃない。
ToString()を全ての型が実装してる、と言う発想じゃなくて、
プリミティブはあくまでプリミティブ、Stringerならば、Stringerとして処理できる、という逆の発送。
疑いがあるならば即落とすべき(panic)、
mixedでのリターン(標準)、
クラスが未定義の場合何をするか(defaultでの無視))
と、全くGoのinterfaceでの設計意図と矛盾しないことぐらいわかるだろうにな。
世知辛いわ。
の言ってることが全く理解できないのは俺だけかな？なんだろういくら話してもすれ違い感が半端ない。
誰か翻訳して！
お前が、interface{}を、なんでも渡せるvoid *的な物として考えてるから理解できんのだろうな。
あとからファイル足して、既存コードの動きまで変わる(シグニチャがあってればinterfaceが実装される)言語で、何言ってんだってレベルの話。
どう動作させても最悪、処理対象外データとしてスルーするようにdefault書くのと同じようなもんで。
本気で適当にgeneratorで作った得体のしれないものを関数に渡してるような奴でもあるまいし。
すれ違い感半端ないのわ俺だわ。
何か俺が書いたこと間違ってる？
1.8まではソース大体読んでたが。そんなに読み違えてる？
ソース読んで、設計思想まで理解したやつが「黙れ」って言うならもう黙るわ。
今まで俺が書いてたような内容は標準ライブラリがほぼそのまんまの事してる内容ばっかだよ。
fmt.Printfだけでも一読の価値はあるんだが。
もう好き勝手書いてろと思えてきた。
OOPが暴走気味でデザパタ廚のようなゴミを再生産しているのは事実として、virtualなしはいかんだろ。
それに対しての
> 多分interfaceにプロパティをokにしたり (>>62)
なら全くもって同意だ。というか、JavaScriptはこれができて便利すぎる。
むしろあれがC++に入らないのが不思議だ。
継承や委譲をこねくり回してデザインパターン（ｷﾘｯするよりは、
JavaScriptのようにメソッドも第一級オブジェクトにしてしまって、簡単にvtblを手組できるようにした方が、
「見りゃ分かるだろ」的なソースを作りやすい。多重継承も楽勝で対応できる。
Goは多分行き過ぎたOOPの反省でinterfaceが１階層しかなく、この点はいいが、
せっかく第一級オブジェクトな関数をメソッドに代入できない点が糞だ。
これはinterfaceをプロパティバッグにしてしまえば解決できる。(62の指摘はこれだと認識している）
動的対応がいやなら再代入禁止で2パスコンパイル
(インタフェース解決+オブジェクトコード生成)にすれば対応可能だ。
Goの作者はよほどOOPが嫌いか、ジェネリックなんて不要と思っているのだろう。
Goのinterfaceは静的ダックタイピングのためのものであって、記述コードを減らすためのものではない。
俺はこの点は全く気に入らないね。というかコードを減らす努力がGoには全く見あたらない。
おそらくそれがここ20年のソフトウェア産業の努力の方向だったというのに。
>>87内安価は62ではなく>>56
PHPが糞なのは事実として、のさばるのには理由がある。
GoではPHPを殺せないし、今回のようなWebアプリ(掲示板）ならPHPの方がましだね。
PHP/JavaScriptなら数行で書ける処理を、(前スレ978参照)
型のおかげでベタに3回書くかリフレクション等こねくり回して20-30行書くかが必要で、
それで15%しか変わらないのなら全く割に合わない。
5台クラスタを6台クラスタにすれば済む話でしかなく、物理で殴れ、になる。
しかもPHPは毎回起動/停止するので、メモリリークとか
おかしなリクエストを食わされて落とされた場合のことを考える必要がない。うまくできてる。
(これについてはgoroutineで対応できるが）
そもそもWebアプリなんて型がないとつれーわって規模にもならないし。
ただし単品ではそこそこ速い。今回はSQLiteに引っかかるのでそれが見えないが、
Nodeのデータから推定した結果、Node比-40%、JSON.stringify部分だけなら倍速出ている。
ただしこれならC#やJavaと同程度、C++よりは確実に遅いといったところか。
生産性は悪い。コードを集約する方法が用意されてない。
結果、C++/C#/Java使いがわざわざ乗り換える訴求力はない。速度も生産性も利点がない。
ただしこれらの言語は本当に肥大化しすぎていて、新規に始めるのはかなり辛い。
これらの言語を全く知らないWeb系がコンパイラ系言語を始めるとっかかりとしてはちょうどよく、
その辺が受けている理由か。
言語自体にパワフルさはない。C++にWeb系ライブラリが出そろえば簡単に殺されてもおかしくない。
とはいえ、言語としては確実にJavaより出来のいいC#が完全にJavaより出遅れているし、
これまた糞だと言われているPythonがはびこっているし、
言語の成否は言語自体の出来よりはそれを使う人がいるかどうかが問題であり、
Web系向けの「軽量コンパイラ言語」は確かにないので、離陸できればうまくいくのかもしれん。
とはいえ、Web系は声がでかいだけで、実際のプログラマ人口はJavaの方が圧倒的に多いのも事実だし、
関数型()みたいにポシャっても全く不思議ではないけど。
「これカッターナイフみたい使えねえじゃん！クソカッターかよ！クソだ！
え？挟んで使う？馬鹿じゃねえの？俺はこれが切りたいから刃を立ててるの！
刃物で挟むとかちょっと違うオペレーションじゃん？それって効率悪いし、危ないだろ、考えろよ。
こんなもの、カッターナイフのかわりには成りはしないね！
断然カッターナイフだわ。ほんとクソ」
ってドヤ顔するのを見るのもちょっと面白いな。
56だけどまぁ分かる。今TypeScriptでジェネリクス使いまくってるけど
やはり静的言語に自由度を求めるとジェネリクスがほしい。
でもGoの言語設計ってコード生成しようぜって匂いを感じる。
パッケージ内に生成したコードを置けば自作の型にいくらでも機械的にメソッド追加できる。シンプルな構文でこういう自由度を確保してるのは良く出来てる感ある。
問題はコード生成するコードを書くのが大変ってことなんだよねw
コード生成するコードを書くための仕組みがもっと簡単になればかなり使い勝手が良くなる。
実際ジェネリクス自体コード生成するためのコードをショートカットした技術って感じがする。だからちょっと複雑なことをしようとすると難しかったりする。
コード生成するためのコードは素朴な分そういう頭がこんがらがる感じはないかなと。
だったら、そもそもinterface受ければいいだけじゃん。>>56でやりたいであろう直積も和も、interface側ではなくて、構造体側がどう実装するかでしかないし、
それも各構造体で両方実装するとか、各構造体を埋め込んだ構造体書くだけじゃん。
それは、型のないinterfaceで受けるべきじゃなくて、パブリックな「型のあるinterfaceで受ける関数に」から、プライベートな「型のないinterfaceを受けるが中でアサーションしてる関数に渡して」やるだけじゃねえの？
その設計が面倒なら、ジェネレーターで組み合わせ爆発起こして遊ぶべきなんだろうが、
実際は型付きinterfaceで事足りないか？それ。
> でもGoの言語設計ってコード生成しようぜって匂いを感じる。
俺にはその嗅覚はないが、状況証拠からするとこれはその通りだ。公式ブログ(URL後掲)もあるし。
標準コマンドに go generate とか、最初からASTを見せる気満々とか、iota とか、ちょっと行っちまってる。
そしてパッケージ内に階層がなく、 cat >> で全ていける。コード生成に障害が何もない。
首謀者は一般のプロダクトプログラマではなく、
サポート側のプログラマ（Perlでlinter等の作成とか）だったのかもしれんね。
C++のテンプレートはちょっと行き過ぎてしまっていて、余計に見にくくなってる。
例えば、形式的な無駄関数呼び出しがありまくったりする。
しかしそれらはコンパイラが最適化で抜いてくれるので、彼らはそれでよしとしている。
C++erの最優先はオブジェクトコードであって、ソースコードではないんだな。
無駄に回りくどくなったソースを見せられても困るんだが。
しかし考えてみれば、テンプレートなんて所詮はコピペだから、機械的に吐き出すのは極めて簡単だ。
人間がゴリゴリテンプレートを書くのではなく、
自動コード生成前提で、そのために基本ベタ書き、ってのは逆転の発想だがありだろう。
いや正確に言うと、Cのマクロの基本はコピペ的使い方だから回帰か？
とはいえCのマクロもC++のテンプレートも濫用が過ぎてるのは事実だ。
ベタなコードを自動生成してしまえ、ってのはありだろう。
https://blog.golang.org/generate
https://techblog.haroid.io/go-generate/
https://qiita.com/vvakame/items/6719b3c90dfaa8220e44
これはちょっと回りくどい。go fmt が上書きなんだから、go generate も上書きでいい。
具体的に欲しいのは、MarshalJSONではなく、構造体にJSONタグを追記する機能なのだから。
つまり、
type myStruct struct {
SomeProp int
}
を
type myStruct struct {
SomeProp int `json:"someProp"`
}
に上書き、だ。上書きが怖いのならビルドディレクトリを分ければいいだけでね。
> コード生成するコードを書くための仕組みがもっと簡単になればかなり使い勝手が良くなる。
俺は go generate が別パッケージを呼び出すのが気に入らないね。
とはいえ、自動生成用のコードなんてその場に埋め込まれても困るのも事実だが。
しかしjsonの部分は明らかに糞なんだし、公式で以下のとか用意しとけよなマジで。
元ソース
type myStruct struct { //go:maintain jsonTag -type=lowerCamel
SomeProp int
}
を、
type myStruct struct { //go:maintain jsonTag -type=lowerCamel
SomeProp int `json:"someProp"`
}
にビルドの度に自動的に maintain する、とか。
同一パッケージなら別ファイルで良いんだから。
こりゃ、2にもジェネリクス入るか微妙だな。
欲しい欲しいて声が挙がっても、要らんだろと言われ続けてるのがなんでかわかったわ。
既存機能すら理解してない奴らが欲しいって言ってるのか9割なんだろうな。
新しいソースをジェネレートすんだよ。
>>37
韓国人R
純然たる日本人だよ、たどれる範囲では。
日本語が解りにくいみたいなそういう言いがかりはナンセンス。
そもそも解りにくい日本語を喋れるのは日本人だけだ。
解りにくい○語を話せるのはネイティブ○語話者だけと大きくも言える。
韓国人が日本語の語順が不安定な部分使ってニュアンス出したりとか、逆にきちんと定義されてる言葉の使い分け使って煽れる訳ねえじゃん。
その結果例え解りにくいものになったとしても、あとから学んだ言葉が不得手な場合の解りにくさとは全く違う読みにくさが生まれる。
英語少々喋れても、口喧嘩はできなかったり嫌味が言えないのと同じようなもん。
100〜のスレッドの続きを読む