Google 独自のプログラミング言語である Go について初めて知ったとき、私は興味をそそられました。 2007 年に設計、リリースされた Go、別名 Golang は、2010 年代初期から中期にかけて、Rust、D、Nim、Scala、Clojure などの新しい言語の群れから話題を呼んでいました。 当時、プログラマたちは、古いバックエンド言語（Java、C++）の冗長性や、Webで使われる動的言語（PHP、Ruby、Python）の計算効率の悪さや型の安全性の低さから脱却したいと考えていたようである。 型安全性、つまり静的型付けが必要だったのだ。 IronMQ のような新興企業が、Rails をホストするために何十台ものサーバーを使用していたのが、Go のような言語でホストできる数台になったという話は、簡単に見つかりました。 当時、PHP5 とその問題点にどっぷり浸かっていた私は、興味を持つ人の群衆の一人に数えられていました。
ActiveCampaign で CTO として以前働いていたとき、初めて Go に出会い、いくつかのコードを書いてみました。 そして、私はそれが好きではありませんでした。 変数を未使用のままにしておいたり、未使用のパッケージをインポートしたりすると、必ず問題が発生したのです。 PHP の型強制には慣れていましたが、C や C++ では、符号付き整数と符号なし整数を混在させたり、整数のサイズ (16ビット、32ビット、64ビット) を混在させたりすることができました。 実際、言語設計の責任者の一人（Rob Pike）は、この言語に欠けているものについて、かなり強硬に主張しました。 Pikeが言うように、これは良いことであり、あなたにとって良いことだったのです。 この言語は、Googleで働く「平均的な」エンジニアのために設計されたのです。 ある意味、当時読んだGoについての文章は、貶しているように感じられました。 そして今日まで、その批判を共有し続ける人々を見つけるのは難しいことではありません。
So what changed my mind? その点では、他の言語とは一線を画しています。 シンプルであることは美徳であり、言語に複雑さを持ち込む場合は、慎重に検討されます。
Go は長い間 (ある人に言わせれば長すぎるくらい)、本当のパッケージ管理を欠いていました。 コミュニティの関与と「dep」と呼ばれる非公式な実験的パッケージマネージャーの数ラウンドの後、そのソリューション（「モジュール」）の公式サポートが言語に追加されたのは、2018年になってからでした。 Rubyでは、クールな処理を行うワンライナーを簡単に書くことができますが、そのワンライナーには多くのマジックが隠されています。 Go で同じことを書くには 5 行のコードが必要かもしれませんが、その 5 行が何をしているかはわかります。
Go はまた、OOP の古典的概念の 1 つである継承を排除しています。 Go ではベース クラスを記述して、別のクラスがそれを継承することはできません。 実際、「クラス」はまったくありません。
最初は、コードの再利用とカプセル化の基本ツールの 1 つを奪われたことが、とてつもない制約のように感じられたものです。 そして、最初に憤りを感じるのは当然です。
しかし、最近では、たとえできたとしても、継承を使用しないことがよくあります。 インターフェイスを使い、振る舞いや抽象化に焦点を当てますが、これはGoで簡単に行えます。 実際、Goでできるのはこれだけです。 しばらくすると、継承を使わないことが快感になってきます。継承を使って構築した危険な関係の巣を再訪する必要がないため、技術的負債の層を避けることができるからです。 1932>
今日、Go は言語生態圏の中で定義されたスロットを切り開きました。 Go は、かつて考えられていたように (そして示唆されていたように)、C++ を置き換えようとしているのではありません。 10 年前、あるプロジェクトに Java が必要だと思ったかもしれませんが、最近では、Go に手を伸ばしたほうがいいかもしれません。
Languages to LearnEngineering Leaders Discuss Ruby on Rails, C#, Python and JavaScript