こんにちは、 Ebitengine 作者です。

はい、おそらく Go を選ぶと思います。理由はいくつかありますが、「Go のツールチェーンが大変良くできている」「Go の言語仕様がそこそこ良くできている」「Go のコミュニティがそこそこ大きい」などの点等が挙げられます。

Go のツールチェーンが大変良くできている

まずコンパイルが高速です。デスクトップ向けやブラウザ向けのコンパイルは基本的に秒で終わります。ゲーム (エンジン) 開発において高速なイテレーションは大切ですので、コンパイル速度は非常に重要です。モバイル向けのコンパイルは、 C/C++ コンパイラが必要であることにより多少時間がかかってしまいますが、それでも 1 分もかからず終わります。

また、様々なプラットフォームに展開するためのクロスコンパイルも容易です。ブラウザ向けにここまで非常に簡単にコンパイルできる環境は他になかなかないと思います。 Windows 向けのコンパイルも Go コンパイラのみで可能です。残念ながら macOS や Linux 向けは Ebitengine が C ライブラリに依存しているためクロスコンパイルは難しいのですが、それでも環境整備は容易な方です。

依存関係の解決も Minimum Version Selection により決定的に決まります。他の人の環境で、違うバージョンの依存ライブラリを使ってしまう、ということがありません。これは他の言語にはない利点だと思います。

フォーマッタツールである gofmt も良い点の一つです。 gofmt の結果が大変良いフォーマットかどうかはさておき、「皆が共通のフォーマットを使っている」という点が最高ですね。フォーマットは、自分の些細なこだわりよりも、皆が同じものを使っているという点が重要だと考えています。 gofmt が登場するまではこの価値に思いつきもしませんでした。こういったツールが Go 1 当初から導入されていて、文化的にも浸透しているということは、非常に大きな価値があります。

Go の言語仕様がそこそこ良くできている

Go の言語仕様は、ベストとは言わないまでも、自分にとってはそこそこよく出来ていると思います。よく Go はシンプルだと言われますが、それには概ね同意します。シンプルではないのではないかと思う点も正直ありますが、詳しくは割愛します。言語がシンプルで学習しやすいという点は重要で、他の人に使ってもらいやすいということにつながるからです。いくら自分が良いと思った言語でゲームエンジンを作ったとしても、言語自体が難解だったら他の人に使ってもらうのは難しかったでしょう。自分の場合は Daigo (Odencat 株式会社社長) に Ebitengine を理解して使ってもらう必要があったのですが、彼はあっさり Go をマスターしてくれました。彼は、エンジニアの経歴はあれど、本職はディレクターです。

また Go が後方互換性を重視しており、過去のプログラムが何もせずとも動くため、ソフトウェア資産が溜まりやすいというメリットがあります。過去のゲームプログラムのメンテに困ったことは殆どありません。ただ、 Ebitengine の場合、低レイヤーで重箱の隅をつつくようなことをしているため、 Go のバージョンアップで動かなくなることは稀にあります (例: Go 1.22 にバージョンを上げたら、メモリアロケーションの実装が微妙に変わったせいか、 32bit Windows + DirectX 12 で動かなくなってしまった。がんばって直した)。

Go は、書きやすさよりも読みやすさを重視している言語であると思います。実際ソースコードを読むのは非常に平易です。概ね字面通りに振る舞うため意外性が少ないです。また、同程度の抽象度がフラットに並ぶコードになりやすいです。

Go のコミュニティがそこそこ大きい

Go は 21 世紀に出た後発の言語としては、ユーザー数がそこそこ大きくなりました。また、おかげさまで Ebitengine Discord サーバーの参加人数が 1600 人を超えました。 2D ゲームライブラリとしてはそこそこの人数に使われているという手応えを感じています。 Go ゲーム開発者が他言語に比べると大きいかと言うと全くそんなことはありませんが、それは今後とも増えていくといいですね。