GO #01 – Początki bywają trudne

Pora zacząć nową przygodę. Nie, nie porzucam Elixir, o nim będzie jeszcze nie raz na blogu. Ale dodaje sobie coś nowego. Coś świeżego coś innego, bo zwariuje :) Potrzebuje trochę odpoczynku od systematyczności i zrobić coś czego jeszcze nie robiłem. A że GO i Elixir były na mojej liście języków to zaczynam uczyć się podstaw GO.

Poza tematem

W elixir mój cel się nie zmienił: chcę napisać bittorrent i posty są trakcie tworzenia. Pewnie trochę minie zanim udam i się je skończyć. Pozostała jeszcze kwestia GenStage, Events i rejestru nazw. Pamiętam o tym i mam kilka rozpoczętych na ten temat postów. Ale potrzebuje więcej czasu na ich skończenie. To co do tej pory poświęciłem, nie wystarczyło a urywam, ile się da by skończyć :)

Koniec

Dlaczego GO?

Szczerze nie odpowiem wam na to pytanie teraz. Nie jestem wstanie. Nie jedno słyszałem o tym języku i chciałbym go spróbować. Widziałem też jego bezpośrednie zastosowanie u nas w zespole – deployment został napisany w oparciu o GO.

Podoba mi się też pomysł kompilacji do natywnej aplikacji na dany system. Chcę więc się tym pobawić i dowiedzieć się czy mi się to przyda czy też nie.

Pierwsze wrażenie po dniu spędzonym z GO?

Nie jest on tak przyjemny jak elixir, ale to też może być wina mojego setupu maca który dzisiaj trafia pod format. Tak czy siak na sam początek jest dużo więcej pracy narzuconej na programistę niż przy elixir.

W elixir po jednej komendzie mogliśmy już zacząć pisać i wszystko śmigało/działało. (wiem, że niektórym na macu go śmiga tak samo jak mi elixir, brew install go i go).

W GO tak nie jest. W GO musiałem ustawić $GOPATH (na tą chwilę: coś co jest wymagane przez go) ręcznie, domyślnie nie było ustawione. Tooling zaś do VS Code okazał się… sam nie wiem, jak to nazwać. Wymagał ode mnie nie tylko poznania VS Code trochę bardziej, ale także dowiedzenia się jak się obchodzi z GO zanim napisałem pierwszą linijkę kodu.

To mi się trochę nie podobało. W sensie, nie powinienem przez tooling musieć poznawać coś na temat GO które wykracza poza jakieś podstawy. A na przykład połowa paczek się wywalała. Cały czas byłem szczuty jakimiś alertami, że coś gdzieś nie śmiga tak jak powinno. A to mnie po prostu drażni i zniechęca.

Podoba mi się to, że w VS Code można debuggować GO, ale to może wina mojego macka, ale próba tego zrobienia kończyła się wyjątkami. To nie jest rant. Każde środowisko jest inne. Ale chodzi tylko oto, że by pisać kod w GO wymagane było ode mnie dużo więcej niż się spodziewałem.

Dużo więcej niż przy C#, JS, Elixir, HTML, Erlang itp.

Ale za to po przejściu problemów miałem gotowe rozwiązanie które śmigało pod VS Code (nie licząc debugging) wraz z podpowiedziami i dokumentacją. Pod tym względem super sprawa.

Okazało się, że także dokumentacja podczas instalacji jest nawet pomocna – nie jest super pomocna, ale jest pomocna.

Jak zacząć?

Najlepiej udać się na stronę golang.org i tam poczytać na temat tego jak instalować, co jest potrzebne a co nie. A następnie udać się do sekcji How to Write Code i wykonać kilka kroków przy pisaniu aplikacji.

To co ja zaobserwowałem, to po pierwsze, $GOPATH jest potrzebne, bo określna on nasz Workspace. Jednak to co właśnie mi się nie podoba to określenie jednego workspace. W sensie nie utworzymy aplikacji sobie wszędzie, gdzie chcemy. Ma ona być w wrokspace.

Więc z tego co widziałem to albo ludzie robią na $HOME albo mają jeden folder podzielony na kilka pod-folderów gdzie tworzą rozwiązania w GO.

Za pomocą komendy:

go env GOPATH

Możemy się dowiedzieć, gdzie znajduje się nasz $GOPATH. Jak pusto, to trzeba dodać, bo tooling nam nie zadziała.

Powinniśmy też dość szybko opanować metody z go – jak go build czy go test czy go run oraz:

• go get – ściąga paczki z sieci i potem instaluje wraz z zależnościami (chyba, że flaga mówi, iż ma tylko ściągnąć);
• go install – instaluje paczkę wraz z zależnościami.

Widać różnicę? Jedynie taka, że get coś ściąga a install nie. Ale istnieją dwie metody, bo chyba get nie ma opcji nie ściągania paczki. Zawsze musi ściągnąć by odpalić instalację.

Z toolingiem zaś sprawdziłem tylko i wyłącznie (bawiłem się) VS Code. Ale dla Atom i Sublime też jest wsparcie jak i dla vim i pewnie innych narzędzi.  Jednak tooling pod VS Code u mnie dalej nie dział w pełni (ale to wina pewnie mojego maca).

Tak naprawdę to tyle, jest trochę więcej do opisywania, ale to są już rzeczy na opisywanie i lekcję drugą. Teraz ja wracam do naprawiania systemu by móc pisać więcej na ten temat :)

Podsumowanie

GO wygląda na fajny język, dla którego z miejsca widzę zastosowanie. Czego w Elixir nie widziałem. Jednak GO wymaga dużo więcej od uczącego się na początku niż Elixir.

Ale z GO pewnie przejdę inną ścieżkę niż z Elixir i będę podążał dokumentacją – więc będę też opisywał go trochę z innej perspektywy. Będzie więc ciekawie.

Pic: © Moosealope – Flickr.com, CC by 2.0