翻訳者からのメモ：
主に著者の性格のために、この記事を翻訳することにしました。 TJはNode.jsとそのインフラストラクチャの開発に多大な努力を払いました。彼はexpress 、 jade 、 mocha 、 stylusなどのプロジェクトの著者であり、npmの550のリポジトリの著者です。 また、人々のグループがこの名前で隠されているという理論もあります。
JavaScriptとGoのコミュニティは近い将来に変化を期待しています。
国を離れるNode.js
それを楽しむのをやめるのに十分な長さのNode.jsと戦った。これが私の公式の別れだ！ さらに重要なことは、私のプロジェクトをサポートできる人を探していることです！
Nodeはいくつかの点で素晴らしい仕事をしていますが、残念なことに、これは私が今興味を持っているものに適したツールではありません。 私はまだサイトでそれを使用する予定ですが、私のプロジェクトのいずれかをサポートしたい場合は、お知らせください。 Githubに自分の名前、npmへのリンク、プロジェクトの名前をコメントとして残してください。 いつものように、既存のAPIに大きな変更を加えないでください。新しいプロジェクトを作成する方が簡単です。
また、 コアをサポートし続けます。
聖杯
私はいつもCが好きでしたが、 Cで働いていた人は誰でも、この言語は楽しくてもエラーが発生しやすいことを知っています。 今では、この言語を毎日のツールとして選択することを正当化することは非常に困難です。 私はいつもそのシンプルさを賞賛していましたが、この場合、大量の定型コードがなければ遠くまで行くことは困難です。
分散システムの操作に専念すればするほど、使いやすさと信頼性よりもパフォーマンスを好むNodeの方向性にイライラします。 先週、 Goでかなり大規模な分散システムを書き直しました。 より信頼性が高く、高速であり、保守が容易であり、より多くのテストカバレッジがあります。同期コードを使用する方が簡単で快適です。
Goは「聖杯」であると言っているわけではありません。完璧ではありませんが、私にとって、現在存在する言語の中で、 Goは素晴らしい選択です。 時間が経つにつれて、 RustやJuliaなどの次世代言語が使用され成熟するようになると、優れたソリューションの数が増えると確信しています。
個人的には、 Goは言語開発の速度に最も感銘を受けました。 開発者が2.0に向けてどのように努力しているかを見るのは非常に印象的であり、聞いたように、後方互換性を破ることを恐れていません。
修正：ニュースレターを誤って読んだようです。近い将来、重大な変更は予定されていません。
そうだとすればクールだと思います。後方互換性を拒否することは言語の開発に役立つと思いますが、私は巨大なシステムをサポートするソフトウェア会社ではありません
なぜ行くの？
Nodeは依然として優れたツールであり、すべてが好きなら心配する必要はありません。 しかし、疑問がある場合は、怠laになりすぎて周りを見回して、他に何があるかを確認しないでください-実稼働で使用して最初の数時間でGoに夢中になりました。
繰り返しになりますが、 Goは世界で最高の言語であるとは主張していません。使用を開始する必要があります。また、 Goがプロファイリングとデバッグのために提供するツールは正常に機能し、コミュニティはドキュメント、フォーマット、速度測定、およびAPI設計について十分に理解している
Goを初めて知ったとき、主にNodeで超モジュール方式に慣れ、Rubyで標準ライブラリが腐敗したのを見て、標準ライブラリはひどく思えました。 この言語でさらに作業を始めたとき、stdlib Goのほとんどがソフトウェア開発で重要な役割を果たしていることに気付きました：圧縮、JSON、バッファーI / O、文字列操作など。 これらのAPIのほとんどはよく考えられており、強力です。 主に標準ライブラリのみを使用して、プログラム全体を作成できます。
サードパーティのGoライブラリ
多くのGoライブラリは同じように見えますが、私がこれまでに取り組んできたサードパーティコードのほとんどはかなり良い品質です。
Goライブラリには単一のリポジトリがないため、同じ名前の5つまたは6つの異なるパッケージを見つけることができますが、混乱を招くこともありますが、これには便利な側面もあります。最適なソリューションを選択するには、それぞれを慎重に確認する必要があります。 Nodeにはredis、mongodb-native、zeromqなどの一般的なモジュールがあるため、これが最適なオプションであると想定して検索を停止できます。
行くかノードか？
分散プロジェクトで多くの作業をしている場合、並列化のためのGoのプリミティブは表現力豊かで便利なように思えます。 Nodeでジェネレーターを使用して同様のことを行うこともできますが、私の意見では、ジェネレーターは途中までしか許可しません。 スタックエラーの個別の処理とレポートがない場合、非常に平均的な結果が得られます。 また、うまく機能する既製のソリューションがある場合、コミュニティが何かを生むのに3年も待たない
私の意見では、エラー処理はGoでより良く実装されています。 Nodeを使用すると、私たちが犯すすべてのミスに対して決定を下すことができますが、 Nodeのパフォーマンスが悪い点がいくつかあります。
- コールバックが重複している可能性があります
- コールバックコールは途中で失われる可能性があります
- 一般に、他のスレッドからエラーが発生している可能性があります
- 「エラー」タイプのいくつかのイベントがエミッタハンドラに届く場合があります
- 間違いを見つけなければ、すべてが地獄に行く
- 多くの場合、エラーの処理方法は不明です。
- エラーハンドラが冗長すぎる
- コールバックは吸う
Goでは 、コードが実行されると実行されます。ステートメントを再度実行することはできません。 Nodeでは、そうではありません。 ライブラリが偶発的にコールバックを数回起動するか、ハンドラーを誤ってクリーンアップする瞬間まで、コードの実行が終了したように思えるかもしれません。これにより、コードが再度実行されます。 これに対処するのは簡単ではありません。特にコードがすでに実稼働している場合、その理由は何ですか？ 他の言語はあなたをそれほど苦しませません
将来のノード
Nodeが大丈夫であり、多くの人々が作業に取り組んでおり、潜在的な可能性があることを今でも願っています。 Joyentとチームはユーザビリティに焦点を当てるべきだと思います。アプリケーションのデバッグ、リファクタリング、開発が困難な場合、パフォーマンスは何の意味もありません。
4〜5年後の
“Error: getaddrinfo EADDRINFO”
ようなエラーの存在は、優先順位付けを示しています。 システムのコアの開発に努力を集中すれば、このような些細なことをスキップできることは明らかですが、ユーザーは繰り返しそのことを思い出し、結果は表示されません。 私たちは通常、「エリート」から主張する人々から回答を得ており、今ではすべてが完璧ですが、実際にはすべてが異なっています。
ストリームは壊れており、コールバックを操作するのは不便であり、エラーメッセージは曖昧でわかりにくいものであり、ツールは熱心ではなく、コミュニティの合意もありますが、Goの機能にはまだ程遠い状態です。 上記のすべてを考慮すると、 Node ：サイト、おそらくプロトタイプまたはAPIを引き続き使用する一連のタスクがあります。 Nodeがその主要な問題を修正できる場合、有用なままである可能性は十分にありますが、ユーザビリティよりもパフォーマンスを優先するという議論は、より速く、より便利なソリューションがあるため、あまりうまくいきません。
私は個人的に誰かを傷つけようとはしていません。多くの本当に才能のある人々がNodeで 、またはNodeで働いていますが、これはもう興味がありません。 私はこのコミュニティで素晴らしい時間を過ごし、かなりの数のクールな人々に会いました。
この物語の教訓はこうです。バブルの中に住んでいるのではなく、周りを見回して他に何があるのかを見てください。おそらくプログラミングが好きになるでしょう。 周りには多くの素晴らしい解決策がありますが、私の間違いは、それらを試してみるのに時間がかかりすぎたことです。