[翻译]Goが嫌いなのは君が取るに足らない人だからだ.


グーグルがGoをテーマに発表したとき、自信を持たなかったことはない.とても頭のいい人がグーグルでとても苦手な(big)問題をするときに使う言語なので、はっきり言えません.いつでも最善を尽くす人が使う言葉ですが、Goは好きではありません.あなたは些細な人で、些細な問題を解決しています.君はもう起きられない(あるいは頭がいい)人だから、きっと好きになるよ.
これを見たら2つの数の中の大きさを出力するのがこんなに簡単だとは思いませんが、
std::cout << max(b(), c())
だから君は些細なことだ.こんなふうに編むんだよ
t1 := b()
if t2 := c(); t1 < t2 {
  t1 = t2
}
fmt.Print( t1 )
だいぶよくなったのではないでしょうか.以前は生産性を破壊するだけだったセミコロンも今は追加しなくてもいいです.私はこれが好きではありません.あなたが些細な人だからです.optionalparameterと書いたときはそうだったはずです.
a = p ? p->a : 0;
そうするはずだ.
a = p && p->a
こんな私を見るたびに悲しくなる実際にそうする
a = 0
if p != nil {
  a = p->a
}
毒性がもっといいでしょう?3つの演算子attributeなどは必要ないと保証します.君のような弱い人は複雑すぎる.[君には複雑すぎる]?:を作った人は君よりよく知っているマクロやテンプレートも必要ありません.それをそうすればGoと抽象化され、髪が白くなります.max()ですか.笑わせるな.必要な(あるいはあなたのわずかな知能に耐えられる)資料構造は配列とラベルだけです.実際にどのようなハッシュ関数が使われているか心配しないでください.どうせ書く関数が分からなくても修正できません.一般的な(実際に)ハッシュ関数は完璧な結果を与えるが、これは世界中で知られているが、なぜ心配して買うのだろうか.あなたができるレベルであれば、どんなハッシュ関数もよくスクロールします.
それ以外に他の資料構造が必要だと思う場合は、1987年にcollectionsに符号化された時期を思い出す準備をしてください.でもマクロ以外はだからCは必ず別々にしなければなりません本当に問題が解決できない人なら、typecastは何でもないのではないでしょうか.
ああ忘れた目立たない資料の構造を小さくしない限り、typecastは適用されないので、そんなことはしないでください.
あなたが望むrangeに従って関数の過負荷を行いますか?あなたは本当にたくさんの期待を持っていますね.そんな必要はありません.あなたよりずっと頭のいい人は、プログラミングをするとき、そんなに複雑な機能が必要なことはあり得ないと結論しました.これは同じ名前ですが、typeargumentによって異なる関数ですか?まともな話をしようあなたには難しすぎるでしょう.typeはこれをコンパイルしません
func add ( a int, b int ) int {
    return a + b
}

func add ( a string, b string ) string { // ERROR!!
    return a + "+" + b
}
(はい、これは意味のない例です.しかし、関数のオーバーロードが意味がないことを説明したいだけです!)
そうだこれも落ちたオブジェクトメソッドを呼び出すには、誰も知らない機能が必要になる場合があります.みんながその時に使うように関数に過負荷をかけましたしかし、文法は上の空論より簡単で、明瞭で、一貫している.そうです.
type Int int
func (a Int) add ( b Int ) Int {
    return a + b
}

type String string
func (a String) add ( b String ) String {
    return a + "+" + b
}

func test () {
    var a Int = 0
    b := a.add( 10 )
    var c String = "aa"
    d := c.add( "cc" )
}
これはよくなる(やってみよう)それだけでなく、よく知っているGoC++Javaなどの未開化の言語の何倍もあります.私はあなたがそのわずかなIQでこの優雅さを受け入れることを期待していませんが.C#はどこですか?話がうまい.interfaceはとても重要で、それからくだらない話です.interfaceGoについてしかし、interfaceを単独で発表することはできません.宣言しないでください.あなたには難しいです.神は、単純なinterfaceimplements WriterというWriterを体現できないと言った.もちろんそうはいかない.方法はここで一つ一つ散漫に現れ、時には方法がinterfaceではなくreturn typeinterfaceと一致しないため、わけのわからないところで間違いに遭遇したほうがいい.これこそ偉大な考え方だ.
コンパイラは、signatureが正常に実装されているかどうかを直接検証する必要はありません.プログラマーは自分でやることができますが、どうしてそんなことをしますか.重大な問題を解決するときも、コンパイル時間を節約しなければならない.interfaceですか.君は笑うつもりか.誰がそんなことを書くの?そんなものを独りよがりにしている以上、virtual functionで体現しましょう.あなたのIQも高くないやつです.コンパイラで書いたより、キーボードを叩いたほうがいいのではないでしょうか.そしてinterfaceが好きなのはバブルです
最後に大文字と小文字を話しましょう質問に答えられないときは、virtual functionをタイプするのも負担なので、頭のいい人は変数名を大文字に書くという結論を下しました.大文字exportの場合、生産性は少なくとも30%向上します.もちろん、exportと書きたくなければ、一つ一つ名前を変えるのを忘れないでしょう.単語を1つ消すより簡単ではないでしょうか.それに、あなたという人はコードスタイルを守ることができるかどうか全く信じられない人なので、いっそ言葉からスタイルを守るように強制したほうがいいです.かっことセミコロンも同じです.
いずれにしても、夢と希望に満ちたpublicの世界で、無事に生きてほしい.ご健康を祈ります.
.
.
.
△この文章はYou Don't Like Google's Go Because You Are Smallを翻訳したものです.Goに文句を言う文章はwww.golang.sucksにもっと掲載されています.