Kiedy po raz pierwszy dowiedziałem się o Go, własnym języku programowania Google, byłem zaintrygowany. Zaprojektowany i wydany w 2007 roku, Go, a.k.a. Golang, był jednym z wielu nowych języków – Rust, D, Nim, Scala, Clojure – generujących szum na początku i w połowie 2010 roku: W tamtym czasie programiści wydawali się być chętni do odejścia od gadatliwego bagażu starszych języków backendowych (Java, C++), a także od nieefektywności obliczeniowej i braku bezpieczeństwa typów języków dynamicznych używanych w sieci (PHP, Ruby, Python). Chcieli bezpieczeństwa typu, co oznaczało, że chcieli statycznego typowania. I chcieli prędkości.
Łatwo było znaleźć historie o startupach, takich jak IronMQ, które przeszły od dziesiątek serwerów używanych do hostowania Railsów do kilku, które mogły być hostowane w języku takim jak Go. I jako ktoś, kto w tamtym czasie był przesiąknięty PHP5 i wszystkimi jego problemami, zaliczałem się do grona zainteresowanych.
Kiedy po raz pierwszy zetknąłem się z Go, w mojej starej pracy jako CTO w ActiveCampaign, spróbowałem napisać w nim trochę kodu. I nie spodobało mi się to. Sprawiał mi problemy za każdym razem, gdy zostawiałem nieużywaną zmienną lub importowałem nieużywany pakiet. Go było szczególnie restrykcyjne w kwestii typowania – znałem koercję typów w PHP, ale byłem też przyzwyczajony do C i C++, które pozwalały mieszać liczby całkowite podpisane i niepodpisane, a także mieszać rozmiary liczb całkowitych (16-bitowe, 32-bitowe, 64-bitowe).
Go nie miało generycznych. W rzeczywistości jeden z jego głównych projektantów języka (Rob Pike) był dość stanowczy w kwestii tego, czego brakowało temu językowi. Jak to ujął Pike, była to dobra rzecz i dobra dla użytkownika. Język został zaprojektowany dla „przeciętnych” inżynierów, którzy pracowali w Google, jeśli można ich tak nazwać. W pewnym sensie to, co czytałeś o Go w tamtym czasie, wydawało się być poniżające. I do dziś nie jest trudno znaleźć ludzi, którzy nadal podzielają tę krytykę.
Co więc zmieniło moje zdanie?
Go jest prosty. Pod tym względem wyróżnia się na tle innych języków. Prostota jest cnotą, a każda złożoność, którą wprowadza się do języka jest starannie przemyślana.
Przez długi czas – zbyt długi, jeśli zapytać niektórych -Go nie posiadało żadnego prawdziwego zarządzania pakietami. Dopiero w 2018 roku – po kilku rundach zaangażowania społeczności i nieoficjalnym eksperymentalnym menedżerze pakietów o nazwie „dep”- do języka dodano jakiekolwiek oficjalne wsparcie dla ich rozwiązania („moduły”).
Ale w ramach tej prostoty można znaleźć wiele wartości. Możesz z łatwością napisać w Rubim kilka jednolinijkowców, które robią fajne rzeczy, ale w tych jednolinijkowcach kryje się wiele magii: trudno jest niefrasobliwemu programiście zawsze zrozumieć proces, który dzieje się za kulisami. Może potrzeba pięciu linijek kodu, aby napisać to samo w Go, ale wiesz, co te pięć linijek robi.
Go odbiera również jedną z klasycznych koncepcji OOP: dziedziczenie. Nie możesz napisać klasy bazowej w Go i mieć innej klasy dziedziczącej po niej. W rzeczywistości, nie masz „klas” w ogóle.
Na początku, to czuje się jak ogromny przymus, aby mieć jedno z podstawowych narzędzi ponownego użycia kodu i enkapsulacji zabrane od ciebie. I to jest naturalne, że twoją pierwszą skłonnością jest uczucie niechęci.
Ale w dzisiejszych czasach często nie używasz dziedziczenia, nawet jeśli mógłbyś. Używasz interfejsów, skupiasz się na zachowaniu i abstrakcji – i to możesz łatwo zrobić w Go. W zasadzie, to wszystko, co można zrobić w Go. Po pewnym czasie, brak dziedziczenia wydaje się dobry, ponieważ unikasz warstwy długu technicznego, nie musząc wracać do niebezpiecznego gniazda relacji, które zbudowałeś używając dziedziczenia. Może Pike był jednak na coś gotowy.
Dzisiaj, Go wyrzeźbiło sobie określone miejsce w ekosferze języka. Nie próbuje zastąpić C++, jak kiedyś sądzono (i sugerowano). Choć 10 lat temu można było pomyśleć, że do pewnego projektu potrzebna jest Java, dziś lepiej sięgnąć po Go.
Języki do naukiLiderzy inżynierii dyskutują o Ruby on Rails, C#, Pythonie i JavaScripcie