JavaをGo言語に変換する必要がありますか?

#Java を Go 言語に変換する必要がありますか?

Go 言語に切り替える必要があるかどうかは状況に応じて判断してください。Go 言語に興味があり、条件が許せば Go 言語に切り替えることをお勧めします。静的に強く型付けされたコンパイル言語であり、構文が Java よりも単純で、パフォーマンスが Java よりも優れており、コンパイル速度が速いだけではありません。

Go

#同時実行性の観点から見ると、ゴルーチンとチャネル メカニズムは、言語レベルで軽量でスムーズな同時実行メカニズムを提供し、パフォーマンスの観点からは、さまざまな機能を提供します。パフォーマンスは Java より劣ります (パフォーマンスは誤った命題です) が、メモリ リソースの消費という点では、Java や他の動的言語よりも明らかな利点があり、構文の点では、Python の動的言語機能の一部を備えています。オブジェクトの初期化、構築、シーケンスの観点から、最適化などの点で非常に簡潔な表現方法を提供しており、特にデータ処理、構成、プロトコル マッピングでは、これらの処理コードがコードの 10% ～ 50% を占める場合があります。 C、C、Java と比較すると、この点は不器用ですが、これが動的言語が非常に魅力的な理由の鍵です。

これは、Go 言語の最初のバージョンがリリースされたときに大きな注目を集めた主な理由でもあり、特に動的言語では、動的言語にはない同時実行性とパフォーマンス上の利点が得られます、とパイク氏は述べています。 Go 言語を設計する目的は、C/C の別のオプションの役割として機能することです (これは代替ではなく、その設計目標は代替することではないことに注意してください) Go 言語の父でありチーフ ソフトウェア エンジニアであるパイク氏Google の同氏は、2012 年の「Road to Simplicity」スピーチでこのことについて言及しました。Goal は不満に満ちており、ここに引用します: 「C プログラマーが Go を代替手段として考えることを期待していましたが、代わりに、ほとんどの Go プログラマーは Python などの言語から来ています「C から来ているものはほとんどありません。」C の価値の本質は、この言語がより広範な抽象化、優雅さ、柔軟性を提供し、これらの表現機能がハードウェア コストゼロであるということです。C 言語の設計目標はハードウェア コストゼロです。 Go の考え方の方向性は明らかにゼロコストではなく、少なくとも CPU コストがゼロではありません。Go の提案はプログラマの作業負荷を最小限に抑えることです。

1 つはゼロコストのハードウェアの究極の追求であり、もう 1 つはプログラマーの作業負荷を最小限に抑えることです。最も価値のある部分は誰も置き換えることはできません。Go は両方の目標を同時に達成することはできません。動的な構文を選択します。そして、gc は開発効率を選択し、開発効率のためにハードウェア効率を犠牲にする運命にあるため、別の方向に進みます。これは、Java が得意とするアプリケーションの方向であり、特に現在のネットワークと HTTP アプリケーションでは、優れた標準ライブラリとエコシステムのサポートが必要です。標準ライブラリに関しては、Go は tcp/http/xml/json/暗号化と復号化などを処理するためのより軽量で優れたコード ライブラリを提供し、ネットワークのコア プロトコルである http の高い同時実行性をサポートしています。 Java を活用するための足がかりが提供されています。

しかし、私たちはその現在の欠点に直面しなければなりません。重要な言語機能と厳密さの点で成熟にはほど遠く、まだ多くの欠点や一時的な解決策があり、それは生態系の成熟度にも影響を及ぼします。これらの問題は新しいバージョンでも解決する必要があります。 Go 言語の最初のバージョンは、2012 年 3 月 28 日に正式にリリースされました。現在まで、バージョン 1.7 がリリースされています。ほぼ 1 年で 2 つのメジャー バージョンがリリースされ、その間にいくつかのベータ版と RC バージョンがリリースされました。これは基本的に次のことを示していますGo 言語はまだ完成していません。準備をしてください。

概要

Go は、動的言語のパフォーマンス要件の点で、Python および Ruby の理想的な候補であることが証明されています。アプリケーション開発、特に HTTP 関連のアプリケーションの点では、現在、Go は最高水準にあります。 Java の前の挑戦者である Java は、リソースの制御がそれほど強力ではない場所で C/C 以外の別の役割も提供します。

生産性の点では、その言語機能とエコシステムはまだ成熟しておらず、バージョンはまだ急速に更新されており、動的言語や Java と比較して利点はありません。現段階では、これらの言語は特定のシナリオで制限されます。オプションの役割。長期的には、Google の全面的なサポートにより、新しい機能とライブラリ アプリケーション機能が追加され続けるでしょう。これは盛んなプログラミング言語です。ただし、現段階では、プログラムの規模と複雑さを考慮する必要があります。言語と生態系はまだ十分に開発されていないため、健全なサポートを提供するには、その未熟さと急速なバージョンの反復によって引き起こされるリスクも認識する必要があります。

Java

Java の成功は、10 年前には主に Unix システムをベースとしていた SUN、IBM、Oracle などの大企業の強力なサポートにより、エンタープライズ アプリケーションと WEB の分野で確固たる足場を築くことができました。上半期は x86 Linux による革命に依存してシェアを維持しましたが、下半期は Android の成功により再びトップに躍り出ました。よろめいて立ち止まる。過去 20 年間、Java は最も強力なエコシステムを蓄積してきました。それは包括的であると言えます。Java が長い間空母の巨大な本体であったことは疑いの余地なく、その地位と成功を証明するのに十分です。 。ただし、その言語、ライブラリ、フレームワーク、エコシステムの複雑さは、同時実行性、言語の同期メカニズム、標準ライブラリの通知と同時実行など、技術者にとって大きな障害を生み出します。また、HTTP は Apache tomcat コンテナを通じて取得することもできます。 JVM テクノロジーに基づいた Java は、同時実行性の点で Scala などの他の言語との相互運用性が優れています。Actor または Scala で書かれた Akka を選択できます。もちろん、業界では nginx を選択するマッシュアップ シナリオが多数あります。 etc. 多すぎる...

これは Java の世界です。多すぎることはありませんし、車輪を再発明する必要もありません。これが Java の成功の鍵です。歴史上、Java は選択肢が多すぎて奥が深いのですが、後で知ったのですが、Java の学習コストは C よりも高く、プログラマーへの要求も C よりも高いことが分かりました。 7 年前、あるいは 10 年前の Java テクノロジをまだ使用している場合、技術者はフレームワークと設計を非常に慎重に整理する必要があります。そうでないと、さまざまな再利用の結果、非常に肥大化したプログラムが積み重なり、実行時のリソースの消費に恐怖を感じることがあります。 . これが、Java に基づいて開発されたプラットフォームが多すぎるという広範な批判の鍵です. 再利用は諸刃の剣です. 画一的なものではなく、調整する必要があります. 開発者が必要とする規模は間違いなく最大ですただし、言語と標準ライブラリが最良かつ最も直接的なオプションを提供しない限り、要求は厳しくなります。

推奨チュートリアル: 「Go チュートリアル」「Java チュートリアル」

以上がJavaをGo言語に変換する必要がありますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。