Express 作者 TJ が Node.js に別れを告げ、Go_node.js へ向かう

まず、これは TJ の Farewell Node.js から翻訳された記事です。この記事を読んで私は非常にショックを受けましたが、たとえば、Node.js のパッケージについては同意できないことがあります。 register はその多くの利点の 1 つですが、Go にはこの点が少し欠けています。 私の個人的な限界により、翻訳する際に理解できないことがたくさんあり、著者のブログや stackoverflow にアクセスして質問し、回答を得ることができました。翻訳にはまだ不完全な点が多くありますが、何かご指摘があれば幸いです。

追伸: Node.js の初心者として、TJ の努力に感謝し、良い旅をしたいと思います。

テキスト:

さようなら Node.js

Node.js レルムを離れる

私は長い間本番環境で Node.js と格闘してきましたが、残念ながら、少なくとも当面はその仕事を楽しむことができなくなったので、これが正式な別れとなります。さらに重要なのは、メンテナーが必要です。

Node はいくつかの点で優れていますが、私が最近興味を持っている種類のソフトウェアには適したツールではありません。私は引き続き Web サイトに Node を使用する予定ですが、プロジェクトのメンテナンスに興味がある場合は、Github ユーザー名、npm ユーザー名、プロジェクト名をコメントに残してお知らせください。通常、私が尋ねるのは、既存の API を完全に変更しないでください、ということです。本当に変更したい場合は、新しいプロジェクトを開始する方がよいでしょう。

Koa は私が今後も維持していくプロジェクトです。 (仲間と)

聖杯の物語

私は昔から C が大好きですが、C 開発に携わっている人なら誰でも、C は価値があるものの間違いが発生しやすいことを知っています。日常業務において言語の選択を正当化するのは困難です。なぜなら、それがその仕事にとって最速であるとは限らないからです。シンプルさが常に賞賛される理由でもありますが、大量のテンプレートがなければ、それほど遠くには到達できません。

分散システムの開発に携わるようになると、可用性や堅牢性よりもノードのパフォーマンスが高くなる傾向にますますイライラしてきます。先週、私は比較的大規模な分散システムを Go で書き直して、より堅牢でパフォーマンスが高く、保守が容易になるようにしました。また、同期コードは一般的により洗練されており、開発が容易であるため、テスト可能な範囲がより多くなっています。

Go が聖杯だと言っているわけではありません。完璧ではありませんが、今日存在する多くの言語にとって、Go は私にとって素晴らしい答えです。 Rust や Julia のような「次世代」言語がより多くの分野で成熟し、より優れたソリューションが見つかると私は確信しています。

個人的には、GO 言語の反復速度にとても興奮しています。彼らがバージョン 2.0 に到達しようと熱心に取り組んでいるのを見てとても興奮しました。私が聞いたニュースによれば、彼らは恐れることなくオリジナルの素晴らしいものを打ち破ったそうです。それが本当であれば嬉しいです。それは主に、それが言語にとって本当に良いものであれば、既存のものをすぐに破壊するはずだと私が信じているからです。しかし、私は多くのシステムを実行しているソフトウェア大手でもありません。 :D

編集者: メーリング リストへの投稿の一部は、いつでも重大な変更を加えるつもりはなかったので、私が誤解したに違いありません。 @エネフ

なぜ行くのですか?

Node がうまく機能し、何も心配する必要がない場合でも、Node は依然として優れたツールです。しかし、何か気になることがあれば、枠の外に出て枠の外にあるものを確認することを忘れないでください。Go で製品を構築してから最初の数時間以内に、私はすでに虜になってしまいました。

繰り返しますが、私は Go が絶対的に最高の言語であり、それを使用しなければならないと言っているのではありません。しかし、年齢の割には非常に成熟しており、力強いです。 （私がノードと同じ年齢の頃です）。型リファクタリングは楽しくてシンプルで、Go が提供するジョブとデバッグ ツールは優れており、コミュニティにはドキュメント、形式、ベンチマーク、API 設計に関して非常に強力な規制があります。

Node の極端なモジュール性に慣れすぎており、Ruby の腐った標準ライブラリを経験していたので、最初に Go について聞いたとき、その標準ライブラリはひどいものだと思いました。この言語をさらに深く理解した後、圧縮、json、IO、バッファリングされた IO、文字列操作など、この段階の標準ライブラリのほとんどが非常に必要であることがわかりました。これらの API のほとんどは明確に定義されており、強力です。これらの標準ライブラリを使用するだけで、プログラム全体を簡単に作成できます。

サードパーティの Go パッケージ

Go ライブラリのほとんどは似ており、これまでに使用したサードパーティ コードのほとんどは高品質ですが、JavaScript は範囲内でさまざまなスキル レベルの開発者を惹きつけるため、Node で見つけるのは困難です。

Go パッケージには登録センターがないため、通常は 5 つまたは 6 つの同じパッケージが同時に表示されます。これは時々混乱を引き起こす可能性がありますが、どのパッケージが最適なソリューションであるかを決定するために各パッケージを注意深く検討する必要があるという興味深い副作用があります。通常、ノードごとに「redis」、「mongodb-native」、「zeromq」などの正規パッケージがあるため、そこで立ち止まって、それらが最適なものであると推測するだけになります。

分散作業を行っている場合、Go の優れた同時実行ベース データ型が非常に役立つことがわかります。 Node のジェネレーターを使用して同様のことを実現できますが、私の意見では、ジェネレーターは仕事の半分にすぎません。独立したエラー処理がなければ、レポート スタックは最良の状態でも依然として平凡です。これらのソリューションがうまく機能している場合、コミュニティが再編成されるまで 3 年も待ちたくありません。

私の意見では、Go のエラー処理は優れています。 Node は、すべてのエラーを考慮して何をすべきかを決定する必要があるという意味で優れています。ただし、ノードは次の点で失敗します:

コールバックを繰り返し実行できます

コールバックをまったく行わず、不安定な状態で失われる可能性があります (たとえば、エラー処理コールバックを渡すのを忘れた場合、エラーが発生したときにノードはフィードバックなしでエラーを飲み込んでしまいます)

すぐに使えるエラーが発生する可能性があります

エミッタは複数の間違ったイベントを取得する可能性があります

間違ったイベント処理を忘れると、すべてが台無しになります

何を間違って実行する必要があるのか​​がよくわからない

エラー処理は非常に冗長です

コールバックは最悪です
Go では、コードが終了するとコードも終了し、ステートメント内で再実行することはできません。 Node ではこれは未定義です。ライブラリが誤ってコールバックを複数回呼び出すか、ハンドラーを適切にクリアできずにコードが再度実行されるまで、プログラムは完全に実行されていると考えるかもしれません。実際の運用コードでこれらの理由を見つけるのは非常に困難ですが、なぜわざわざ調べるのでしょうか?他の言語ではこのような苦痛を経験することはありません。

未来のノード

私は Node がうまくいき、多くの人がそれに多額の投資をすることを願っています。Node には確かにそのような可能性があります。 Joyent とチームは使いやすさに重点を置く必要があると思います。アプリケーションが脆弱でデバッグ、リファクタリング、開発が難しい場合、パフォーマンスは意味がありません。

4 ～ 5 年後もこの曖昧なエラー「Error: getaddrinfo EADDRINFO」が発生するという事実は、Node の開発の優先順位がどこにあるのかを示しています。当然のことながら、システムのコアの構築に集中すると、これらのことを見落としがちになります。ユーザーはこの種のことについて、結果が見られないまま何度も意見を述べてきたと思います。私たちが持っているものはすでに完璧であるという主張に対して、通常、少数の反応が得られます。実際にはそうではありません。

ストリームが中断され、コールバックが使いにくく、エラーがわかりにくく、ツールが使いにくい コミュニティの規制はありますが、Go に比べて不足しています。それにもかかわらず、私は Web ページや散在する API やプロトタイプの作成など、特定のタスクに Node を使用し続ける可能性があります。 Node が根本的な問題のいくつかを解決できれば、その存在を維持できる可能性がありますが、より高いパフォーマンスとより高い可用性の両方を備えた代替手段がある場合、可用性よりもパフォーマンスの議論はそれほど大きくはなりません。

Node コミュニティがジェネレーターを採用し、Node の非常にコアな部分に実装し、エラーを適切に伝播することを決定した場合、これが参照される可能性があります。これにより、ノードの可用性と堅牢性が大幅に向上します。

良いニュースは、少し前に、StrongLoop にコア コードを提供している素晴らしくて才能のある人たちと話したということです。彼らは、プラットフォームに対する開発者の反応に耳を傾けることによって明確なアプローチをとっており、将来的に Node を使いやすくするためにこれらの問題を修正する適切な方法を見つけることを計画しています。複数の企業によるコア部分の同時開発を巡る争いがどう決着するかは分からないが、開発者主導の側が勝利することを期待したい。

これは個人攻撃を意味するものではありません。Node で働いている、あるいは Node の上で働いている本当に才能のある人々がたくさんいますが、私はもうそこに興味はありません。 Node コミュニティで素晴らしい時間を過ごし、本当に興味深い人々に会いました。

この話の教訓は、自分のサークルに限定されないでください!ということです。他の場所で利用可能なものを確認すると、プログラミングを再び楽しめるかもしれません。素晴らしいソリューションがたくさんあるので、それらを試すのに長く待ちすぎたのは間違いでした。