>>154
いや俺はマクロは最小限(見りゃ分かる程度)しか使ってない。
そして自動生成を嫌っているのではなくて、手間が増えるのを嫌っている。

PHP, JavaScript:何も書かなくていい
Go:構造体を書き、タグ付けスクリプトを作成し、go generate してタグを付け、正しくタグがついているか確認 ← やること多過ぎ
Go:構造体を書き、タグを書く ← これのほうがまだまし

>>155
そりゃ公平な評価にはならないよ。俺は既にC言語は十分使える状況なんだから。
そしてPHPとJavaScriptにはC系言語の常識が通用したからさほど苦労しなかったが、
Goはそうではなく、色々引っかかる。
ただこれはGo言語制作陣の意図通りだし、確かにいまさら互換言語を整備する意味はないんだよ。

> それ以外は動的な解決(interface{}を使う)しかなくなり、静的言語としてのメリットを失う。
ちょっとこれは厳しすぎ、というか、若干誤解しているか?
(静的クラス機構による)動的型は型を失うわけではなく、一般的には「静的言語としてのメリットを失う」とはされない。
確かに間接呼び出しになる分だけ遅くはなるのだが、これを言うなら世の中のOOP言語は全部糞になる。
(動的言語の)動的型は毎回辞書引きが必要(map扱い)だから効率が悪いとされている。
Goのinterface{}はこれではない。

ちなみにGoのreflectionもC系とはちょっと感覚が違う。
jsonを吐くのにフィールド名が必要なら、普通はjsonモジュール内でreflectionするはずで、
それならpublic(先頭大文字)でなくとも全部取れるはずなんだよ。だからそれを期待してしまうわけ。
そして、あ、あれ?とれないの?みたいな事になる。
C的常識でGoを組んでると、この辺の予想外のところで引っかかる。いろいろ根本からして違うんだよ。
一方PHPだと、「下手糞がフレームワーク組みやがって」とは感じるけど、何でそうなるのかは分かるんだよ。
あっちはベースを共有してる感がある。
だから今の俺だとPHPの方がGoより生産性が高くなってしまうわけ。
しかしGo言語はC系言語出身者お断り仕様で計画通りなのだから、これはこれでいいんだよ。