>>114
宗教戦争は結局自転車置き場の議論と同種で、馬鹿が無理に参加するからだ。
その点ではC++の割り切り、「ソースコードに過度の美を求めず、オブジェクトコードで勝負」ってのは正しいと思うし、
go fmt ってのもありだと思うが。

Goがまずい点は、後発なのに誰にも合わせる気がない点だ。
UpperCamelはC++以来(だと思う）既に30年「クラス」として使われてきており、他言語も全てそうなのに、
「public」と勝手に規定してしまった。このためにjsonがUpperCamelになってしまうわけだが、
これまた世の中JSONで回り始めて10年以上経ち、大体lowerCamelが使われている状況で、スイッチもつける気無いだろ。
略号は全部大文字？それは言われなくても大体そうだし、違反してたとしてもソース改変して再テストする価値はない。
そんなにマメにソースを改変したければ、ユニットテストではなく、形式検証ツールを提供するべきなんだよ。

> でも、どの言語もコモディ化で割と似たような言語仕様になる中、
結局ソフトウェア技術も成熟しつつあるってことだよ。
どう書くべきか、何をやってはいけないのか大体わかってきた。

> 独自性があって、素敵だとも思う。
ないね。独自性ってのはHaskellの「全面遅延評価」みたいなのを言うんだよ。
俺はHaskellが1990製だと知って驚いたが、それ程の独自性があれば20年後に話題になる可能性もあるということ。
Goには独自性なんて無い。一度廃れれば終わる言語だ。
「新機能」といえる物が全くないだろ。むしろ「ちょうどいい頃合」を目指している言語だ。
悪く言えば、全てにおいて中途半端でしかない。

> phpなんか、片っ端から言語仕様足しまくってるし。動的言語のくせにinterface入れてみたりとか。
PHPはミクロな点でゴミだが、マクロな点には多分ほぼ問題がない。（というほど試してないが、今のところそう感じる）
具体的に言うと、引数の順が統一されてなかったり、引数にすべきものを別名関数にしてたりとか、
そういう「1行内」の部分でいちいち引っかかり、ストレスが溜まるものの、
Goみたいに「言語仕様的に3回書かないと無理」みたいな構造的問題は（多分）ない。