Na wczorajszej prezentacji Marcin Biegała przedstawił nam język GoLang. Język stworzony na bazie eksperymentów panów Roberta Griesemera, Roba Pikea i Kena Thompsona. Używany przez ważnych w branży czyli Google (oni wydali ten język), ale również Docer, Dropbox, BBC, Uber czy ThoughtWorks. W Polsce język mniej znany, aczkolwiek kilka firm go używa między innymi PlusGPS.

Go jako taki (czego dowiedziałem się na prezentacji) to właściwie cały ekosystem zawierający język sam w sobie, kompilator i zestaw narzędzi. Język jest dość ścisły i łatwy w odczytaniu. Między innymi dlatego właściwie jest już zamknięty na modyfikacje. Sama “gramatyka” zaprzestała się rozwijać. W tej chwili trwają pracę nad rozwijaniem narzędzi i kompilatora. GoLang wymusza trzymanie projektów w odpowiednich katalogach na dysku. Dość kontrowersyjne posunięcie i to nie jest jedyna kontrowersja związana z tym ekosystemem, wiec trzeba się przyzwyczaić. Na pewno ma to swoje plusy.

Większość narzędzi przeznaczona do Go służy do wymuszania pewnego stylu programowania, który sprawia, że jest czytelnie. Jest gofmt, który formatuje kod czy golint, który sprawdza styl pisania. Jest godoc który tworzy dokumentację z odpowiednich komentarzy w naszym kodzie. Jest gotest który uruchamia testy automatyczne (tego niestety zabrakło na prezentacji, a jest bardzo ciekawe). Jest goget do pobierania pakietów (taka namiastka nugeta, za to pobierająca pakiety prosto z gita czy githuba). To o czym nie wspomniano również na prezentacji to narzędzia do refactoringu czyli gorename, czy gogenerate służący do generowania kodu.

Kompilatorów jest kilka, ale dwa główne, o których się mówi to udostępniany przez google wraz z pakietem GoLang kompilator gc oraz tworzony przez GNU gccgo. Różnice w nich są takie, że gcc nie nadąża za standardem, ale ma swoje sztuczki i kruczki wyniesione z doświadczeń w tworzeniu gcc, a gc jest wolniejsze, na razie gorzej dopracowane, ale zgodne z najnowszym standardem języka.

W GoLang ścisłość, styl i sposób pisania jest wymuszany przez kompilator i narzędzia. Program nie skompiluje się jeśli importujemy biblioteki, których nie używamy. Program nie skompiluje się, jeśli stworzymy zmienną i jej nie użyjemy. Jednym słowem StyleCop + FXCop + treat warnings as errors. Ma to oczywiście swoje plusy i minusy. Czasami jednak zaimportowanie czegoś, czego nie używamy bezpośrednio w kodzie może się przydać. Stworzono zatem zapis, że jeżeli import zaczyna się od “_” to kompilator zaimportuje bibliotekę i nic nie powie.

Jest to bardzo ciekawy język z którym warto się zapoznać zwłaszcza ze względu na jego podejście do wielowątkowości. Jeśli nie byliście na prezentacji, to żałujcie, bo było to świetnie wytłumaczone i pokazane na dość skomplikowanym przykładzie. Sam poszedłem na tą prezentację z bardzo podstawową wiedzą na temat GoLang. Napisałem w nim 1 produkcyjny kod, który porównuje 2 spore pliki xml (ok 50 MB/szt). Co ciekawe dzięki rutynom zyskałem takie przyspieszenie, że program porówna oba pliki i stworzy 3 plik HTML, który w ładny sposób pokazuje różnice, szybciej… Niż jeden z plików XML otwiera się w Atomie.

 

Co do samej prezentacji, ponieważ autor prosił o feedback. Była bardzo fajna! Na pewno ciekawie i dowcipnie przygotowana. Powiedział chyba o wszystkim na co trafiłem jako początkujący “gopherzysta” (oprócz testów). Z minusów należy podać, że nie była pokazana w solidnej kolejności. Podczas prezentacji padało dużo pytań, a co to, a co tamto, co trochę psuło “flow”, ale uważam, że spowodowane było to właśnie kolejnością. Marcin podał za, podał przeciw, podał, że się uczy. Naprawdę fajnie przygotował przykłady. Jakość prezentacji udowadnia to, że jak niektórzy zaczęli się zbierać, okazało się że jest 20. Zupełnie nie czułem upływającego czasu. 1,5 godziny jak z bicza strzelił. Uważam, że po dopracowaniu i dodaniu testów (jak cokolwiek można pisać bez nich?!) spokojnie nadaje się na szkolenie z podstaw języka.

 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *