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

17 KOMENTARZE

    • wygląda na bardzo ciekawy, na pewno miło się zaskoczyłem chociażby tym, że jest kompilowany do natywnego formatu!

  1. Świetny temat. Czekam na kolejne posty. Go jest też na mojej liście. We dwójkę zawsze raźniej ;) I generalnie dzięki za świetną robotę na tym blogu!

  2. “GO wygląda na fajny język, dla którego z miejsca widzę zastosowanie. Czego w Elixir nie widziałem. ”
    Możesz rozwinąć? Trochę dziwi uwaga o elixirze – opracowali go chłopcy-railsowcy którym doskwierały niedostatki tandemu ruby-rails, więc raczej wiadomo, że chodzi o aplikacje webowe, real-time app i wszystkie zalety erlanga, w tym wieloletnie sprawdzenie w boju na platformach telekomunikacyjnych

    • Elixir jest sprwadzony w boju. zgadza się. I jest super do pewnych zastosowań.

      Teraz, poza framework Phoenix który trochę teraz ciągnie ludzi ale na końcu jak gadałem z rubystą to jest to samo – w sensie, to tylko framework, apkę i tak piszesz w react, angualr itp. czy jesteś wstanie wskazać zastosowanie elixira? tak z miejsca. Do czego byś go użył.

      W GO, znajomy napisał skrypt deployujący całą aplikację, łączący się z linuxem, wykonujący poleceni yarn i webpack, kopiujący pliki, czyszczący po sobie, i nic nie musiałem instalować więcej. Nic. wziąłem git pull i dep stg i koniec :)

      Jak przy elixir musiałbym się zastanowić nad wykorzystywaniem i dalej się zastanawiam, tak tutaj z miejsca miałem przykład który działał.

      • Nie, no owszem, w tej chwili zastosowanie ze względu na specyfikę widzę tylko w aplikacjach sieciowych, erlang po to został opracowany, trudno tutaj mówić o uniwersalnym języku do wszystkiego, wydaje się że na pewno nie do zastosowań które wymieniłeś w przypadku GO. Ja akurat zajmuję się tylko i wyłącznie tym.
        Sam miałem taki dylemat, zająć się GO czy elixirem, ekosystem jest bogatszy w GO, na chwilę obecną pewnie ma szersze możliwości zastosowania. Sądzę, że dużo zależy od tego czym kto się zajmuje, ja jestem ukierunkowany na aplikacje typowo sieciowe, sierota po Railsach/Rubym, składnia elixira bardziej mi pasowała, przykład serwisu Bachelor Report zrobił na mnie wrażenie. Java mi nigdy nie podchodziła ze względu na przykre doświadczenia jako użytkownika takich aplikacji, do pozostałych zadań mam pythona i basha. Środowiskiem MS się nie zajmuję. Elixir to jeszcze młode rozwiązanie, nie stoi za tym duża firma typu Google wiec i hype pewnie na niego nie ma za dużego.
        Ale twoje uwagi skłoniły mnie by powtórnie przyjrzeć się GO. Sam za bardzo nie angażuję się jeszcze w Elixira/Phoenixa, czekam aż trochę ustabilizuje się rozwój.

        • Nie no jasne, elixir ma swoje zastosowanie. i fajnie ze brak za tym duzej firmy ale tez szkoda. bo to moze byc tylko zajawka na krotki okres. Do tego prog wejscia… bardzo niski. fajnie ale za razem nie fajnie. Ciezko znalezc dobre przyklady – ladnego poprawnego kodu. Kazdy robi to na swoj sposob i sie da. fajnie ze sie da, ale tez… no wlasnie :) cos za cos

          A go… go to dodatek :) elixirem dalej bede sie bawil :)

    • 1.8.3 ale jak mówię, to może być wina mojego setupu: boxen, homebrew, zsh itp.

      Ogólnie nie miałem $GOPATH ustawionego :(

  3. Polecam liteIDE a pisanie że GOPATH to bolączka języka programowania to trzeba zignorować wstęp manuala.
    Na linuksie wystarczy dopisać dwie linijki do pliku {zsh,bash}rc

    export GOPATH=$HOME/go
    PATH=$PATH:$GOPATH/bin

    I tyle pracy. Polecam przejrzeć kod np. gitlab-ci

Comments are closed.