核心的な結論
- Go言語は常に速いわけではありません。むしろJSランタイムのほうが速いこともあります。
- Goはシンプルさと効率性を誇りますが、実環境では予想より性能が低いことがあります。
- 特にデータベースI/Oが多い状況では、BunのようなJavaScriptランタイムと比べて性能が劣ることがあります。
ベンチマーク結果
- Goはより高いリクエスト処理量と低いメモリ使用量を示しましたが、CPU使用量は2〜3倍高くなっていました。
- しかしDB I/Oの多い現実の環境では、Bun（ElysiaフレームワークとMySQL2ライブラリの組み合わせ）のほうが、より安定して効率的な性能を示しました。
- 標準HTTPルーターは性能が低く、Fiberフレームワークに切り替えた後はBunに近い応答速度を得られました。（Go標準HTTP Routerは使わないでください！）
このベンチマークを進めながら考えたGoの長所
- さまざまなプリミティブ型と型安全性を提供してくれること。
- 単一バイナリ配布: シンプルな実行ファイルとして配布でき、ランタイム依存をなくせます。
- goroutine: 並列処理を効率的にサポートし、適切に使えばハードウェア性能を最大化できます。
今回のベンチマークで感じた限界と改善の余地
- 疑われるMySQLドライバの性能問題: Goのgo-mysql-driverは安定していますが遅く、JavaScriptのmysql2より性能が劣るように見えます。（もちろん私の考え違いかもしれませんが）
- DB接続がない処理ではGoのほうがより良い性能を示します。もしかすると、これは当然かもしれません。
- HTTPルーターの低い性能: メンタルヘルスのためにFiberやほかのフレームワークを使いましょう！
性能に不満はあるが、それでもGoを使い続けたい理由
- Goの型安全性、単一バイナリ配布、goroutineの並列処理性能などは、開発者として魅力的です。TypeScriptでは埋められない型、
npm installが不要な単一バイナリファイル配布、この点は本当に大きなメリットでした。
- さらなる性能最適化の可能性を見て、Goをもっと学びながら使ってみようと決めました。
開発者に伝えたいこと
- すべての言語と技術には長所と短所があります。Go言語も同じだと思います。
- Goの性能に失望するよりも、長所をうまく活かし、性能の限界を突破できる手段を引き続き探していければよいと思います。
- Goを使う開発者に、このような分析結果もあるのだという情報を共有したくて、この記事を書きました。
16件のコメント
完全に余談なんですが、IBM Plex Sans KR フォント、すごくきれいですね
私もそのフォントが本当に気に入って使っていましたが、ただ一つ惜しい点は、解像度の低いモニターで見ると特にきれいではないことです。笑 5Kモニターで見ると本当にきれいでした！
何かを批判することは、本当に慎重であるべきだと思います。
それが言語レベルの問題なのか、特定のライブラリの問題なのか、コード上の問題なのかも曖昧で、他の人が再現するのに十分な情報も提供されていない状態で、何かが良くないと公に主張することは、
そのような意図がなかったとしても、そのエコシステムで生きている人たちにとって、気持ちの良い内容ではないように思います.
こんにちは！ まずは貴重なご意見をお寄せいただき、ありがとうございます。おっしゃっている内容について、どのようなお気持ちで意見を残してくださったのかは理解していますし、もし Go 言語の将来やユーザーなどを非難したように感じられたのであれば、そういう意図ではなかったことを改めてお伝えするとともに、お詫び申し上げます。そして、もし差し支えなければ、記事タイトルをクリックしていただくと、さまざまなデータや、追加でほかの方のブログ記事もありますので、（少し長いですが）読んでいただければ、私の意図をよりはっきりご理解いただけるのではないかと思います。
私は、言語というものは一種の自動車のようなものだと考えています。車ごとにさまざまな長所と短所があり、購入にかかるコストもそれぞれ異なり、同じ役割を果たしているようでいて、実は異なる価値を追求している点が似ていると思っています。もちろん、その車を特別に大切にし、愛着を持つのも当然のことだと思います。私も自分の車を愛していますし、車両メーカーを信頼しています。
それでも、私自身、自分の車に対して残念に感じる点や不満な点はありますし、車のモデルを定期的にレビューしているレビュアーたちは、常に競合モデルと並べてさまざまな面から比較し、その内容を共有してくれています。誰かが私の車について、トランスミッション性能がいまひとつだとか、燃費が悪いと言えば、私も正直いい気分ではありませんが、それでも運転手である自分と車は切り分けて考えようと努力するほうです。また、私が運転している車について、長所であれ短所であれ、もっと多くを知ろうと努めるほうでもあります。もしかすると別の車に乗ることもあるかもしれませんが、今の運転経験はその時にもきっと役立つはずですから。
要約版ではあまり触れられませんでしたが、ブログ本文では、Go の惜しい点があるにもかかわらず、なお長所のほうが多いので、これからも使い続けてみよう（=運転してみよう）という内容で締めくくりました。私は、言語ごとに追求する価値や長所がそれぞれ異なると思っているので、できるだけ多様な言語（=車両）を使ってみようと努めるほうです。使い慣れていた JS ランタイムを置いてまで、あえて Go 言語へ移ろうとしている理由もそこにあります。
できる限り不要な言語論争が起きないよう、自分なりに細心の注意を払って文章を書いたつもりでしたが、それでもこの記事をご覧になって気分を害された Gopher の方がいらっしゃるのであれば、どうかもう一度お気持ちを和らげていただければと思います。そして、あれほど悪く言われていた PHP 言語のことも愛しているロマン派コーダーであることを明かして、このコメントを締めくくらせていただきます！
元文には、遅い部分についての筆者なりの分析と、それでもなお Go を使うつもりだという理由が書かれているのに、なぜこの文章を価値判断として受け取られたのか、正直よく理解できません
TMIですが、Go の std ライブラリは時間がたつにつれて性能が低下しています。主な理由は、RFC 標準への準拠のためにさまざまな機能が追加され、報告される多数のセキュリティ脆弱性へのトレードオフが生じているためです。
最近では、FIPS 認証を通過するために、おそらく性能面での不利はさらに大きくなると予想される状況です。
こうした背景をすべて切り捨てて、最も単純な特定のシナリオについて「性能が悪い」と一言だけ書いておくのは、多くの人に誤解を招くのに十分だと思いますね…。
tsboardさん、1.0バージョンを待っています（笑）
お待ちいただきありがとうございます！楽しく作業を進めていきます（笑）
JS は JIT を使うので、特別に遅い理由はないように思います。
マルチスレッドや安定性などを除けば..
今回のベンチマークを通じて、私自身も新たに気づかされた点があり、安定性についても大きな問題はないレベルだと自信を持って言えそうです。マルチスレッドは確かにオーケストレーションが必要なので、少し煩雑なのは事実です。
サイトにアクセスできないのですが、私だけでしょうか？
こんにちは！ コメントでお知らせいただきありがとうございます（笑） まだホスティング先にサイトを移せていないため、ときどき接続障害があります。 できるだけ早いうちに対応しておきます。 （今は自宅でミニPCがフル稼働中です 😂）
おお、今はできますね。しっかり読ませていただきます！
サイトを部屋の片隅のミニPCからワンルームほどの規模の仮想サーバーへ移しました...！ 本日、予想以上に多くの方にお越しいただいたものの、やむを得ず引き返していただくことになってしまいましたが、もう問題ないことをお知らせします！
github.com/jackc/pgx/v5ドライバーと PostgreSQL で実験してみると、また違う結果になるのか気になりますね。私も、この結果がmysqlに限られた問題なのか、それともDBを使うすべてのシナリオに当てはまるのか気になります。いつか他の方々が結果を共有してくれると思います（笑）