osobiście zdecydowanie jestem już poza etapem juniora , teraz zbliżam się do etapu senior, oczywiście żaden ze mnie guru
wciąż się uczę i choc swobodnie przenoszę na kod nie tylko swoje pomysły, to wciąż wiele nauki przede mną. Niemniej jest to już
taki etap w którym mogę sobie pozwolić na pewne przemyślenia czyli jak zaczyna się każda gołowa przygoda ...
Na początku jest cisza ............ wstawiłbym tu jakiś "silence box" w środku ciemnego lasu ......................
Mam oto nowy projekt, w nim pusty plik main.go i serce pełne entuzjazmu.
Ładuję przykładowy program > słynne Hello World << patrząc na magiczne napisy ....
Otwieram terminal, wpisuję magiczne go run . Czuję się jak czarodziej....
I nagle otwiera się portal nowych możliwości i magii i właśnie odkryłem magiczną formułę - fmt.Println().
Potem przychodzi czas na napisanie czegokolwiek .....
Etap 1: Odkrywca
„Wow! Goroutines! To jak wątek, tylko szybszy!”
[syntax=c]for i := 0; i < 10; i++ {
go fmt.Println("Witaj z goroutine", i)
}[/syntax]
Komentarz: Hura działa!
A potem.... nie działa.
A potem działa.... z kolejnością 9, 2, 5, 0, 7, 1… i nie wiem, dlaczego.
To Go uczy mnie pierwszej lekcji: „deterministyczność jest dla słabych.”
Etap 2: Optymista
„Nie potrzebuję sync.WaitGroup, ja czuję, kiedy goroutine się skończy.”
[syntax=c]go doSomething()
fmt.Println("Gotowe!")[/syntax]
Komentarz: fiuuu i w sumie gotowe… tylko doSomething() jeszcze trwa... trwa... trwa ....
to właśnie pierwszy kontakt z asynchronią.
i pierwsze zwątpienie w człowieczeństwo.
Etap 3: Panikujący
„Nie wiem, czemu się zawiesiło, ale spróbuję to naprawić… close(ch)?”
[syntax=c]for v := range ch {
fmt.Println(v)
}
close(ch)[/syntax]
Komentarz: panic: close of closed channel ...... Co jest przecież dobrze napisałem ...
I tak poznaje drugą brutalną zasadę Go:
Kanały są jak związki — zamyka tylko ten, kto wysyła.
Etap 4: Debugger z modlitwą
„Nie wiem, co się dzieje, więc dodałem fmt.Println("tu").”
[syntax=c]fmt.Println("1")
go doStuff()
fmt.Println("2")
fmt.Println("3")[/syntax]
Komentarz: i nagle logi zaczynają żyć własnym życiem. Jakby coś opętało mój program ....
Widzisz „1”, potem „3”, potem panikę.
Moje fmt.Println stają się dla mnie religią.
To nic że logi przypominają hieroglify, ale przynajmniej coś się dzieje.
Etap 5: Eksperymentator
„Słyszałem, że można użyć contextu. To pewnie coś fajnego.”
[syntax=c]ctx, cancel := context.WithCancel(context.Background())
go func() {
doSomething(ctx)
}()
defer cancel()[/syntax]
Komentarz: Wygląda profesjonalnie.
Nie mam absolutnie pojęcia, co to robi .....
Ale.... wygląda profesjonalnie.
Etap 6: Tester przez przypadek
„Nie planowałem testów, ale go test i tak się odpaliło.”
[syntax=c]func TestMagic(t *testing.T) {
if 2+2 != 5 {
t.Fatal("czemu?")
}
}[/syntax]
Komentarz: Pierwszy czerwony test.
Pierwsze t.Fatal().
Pierwsze przeczucie, że życie to pasmo niekończących się refaktorów.
Etap 7: Pokora
„Nie wiem, czemu to działa. Ale działa.”
[syntax=c]if err != nil {
panic(err)
}[/syntax]
Komentarz: to zdecydowanie najczęściej kopiowany fragment kodu w karierze każdego juniora.
Wiem już, że Go nie wybacza, ale nagradza za prostotę.
Zaczynam rozumieć: „im mniej magii, tym mniej bólu.”
Podsumoiwanie etapu ....
W pewnym momencie, docieram wreszcie do etapu gdy Go przestaje mnie zaskakiwać —
bo zaczyna mnie wychowywać. Z można powiedzieć uporem maniaka uczy cierpliwości, dyscypliny i tego, że:
- nil to nie wróg, tylko niezrozumiany przyjaciel,
- goroutine leak to po prostu sposób, w jaki runtime mówi „zrób przerwę”,
- a go vet to takie twoje lepsze ja, lub surowsze sumienie.
- i jeśli coś działa — nie pytaj dlaczego, tylko zrób commit.
Dociera do mnie, że każdy senior kiedyś był juniorem.
Tylko... niektórzy lepiej ukrywają swoje pierwsze panic().
I wiem już, że powoli, powoli staję się seniorem,
Bo moje TODO brzmi już nie jak plan,
ale jak pożegnanie.
Tymczasem znów minęło kilka miesięcy i kilkadziesiąt kodów i projektów za mną. zaliczam kolejny etap ....
tu wydaje mi się, że moje przemyślenia mogą być już znacznie głębsze bardziej pewne siebie .... ale .... to tylko złudzenie,
to etap przejściowy pomiędzy naiwnym entuzjazmem, a cynicznym spokojem.
To moment, gdy wiem już, że Go nie wybacza… ale, nadal próbuję z nim dyskutować. A co .... przecież jestem mądrzejszy ... prawda ?
„jeszcze walczę, ale już wiem, z czym”
Mam już dawno za sobą pierwszego panika, kilka race condition i jeden tajemniczy deadlock, który.... „zniknął sam” --> magia ? , a może ingerencja obcych ?
Znam context, sync, interface{} i wierzę szczerze, że umiem je kontrolować. Tymczasem to w brew temu co się wydaje, to najniebezpieczniejszy etap kariery w Go...
na etapie MID --- wszystko się nam tylko wydaje .....
Etap 1: Mam misję ...
„Napisałem własny framework, bo standardowa biblioteka jest zbyt prosta.”
[syntax=c]func HandleRequest(req *Request) Response {
mw := []Middleware{Log, Auth, RateLimit, Recover}
return Chain(mw...)(req)
}[/syntax]
Wygląda świetnie.
Działa… dopóki .... nie działa.
Zaczynam wierzyć, że prostota jest przereklamowana, że to taki chwyt marketingowy .....
Do czasu..... aż nil pointer przypomina mi brutalnie, skąd przyszedł.
Etap 2: Władca Goroutines
„Używam errgroup — jestem profesjonalistą.”
[syntax=c]g, ctx := errgroup.WithContext(context.Background())
for _, job := range jobs {
job := job
g.Go(func() error {
return job.Run(ctx)
})
}
if err := g.Wait(); err != nil {
log.Println("błąd grupy:", err)
}[/syntax]
Mam pełną kontrolę nad współbieżnością. To cudowne uczucie ... jestem bogiem ...
Do momentu, gdy ktoś dorzucił go func() w środku job.Run()…
i nagle moja cudowna grupa robi się bardziej anarchiczna niż zorganizowana.
Koszmar z przed miesięcy powraca ....
Etap 3: Ekspert od błędów
„Używam errors.Join, bo tak jest nowocześnie.”
[syntax=c]err := errors.Join(dbErr, cacheErr, apiErr)
if err != nil {
log.Println("kombinowany błąd:", err)
}[/syntax]
Teraz mam jeden błąd, błąd który zawiera trzy błędy, które zawierają jeden główny błąd — brak sensu.
Ale... przynajmniej jest idiomatyczne...
Etap 4: Refaktorysta
„Nie podoba mi się context.Context – napiszę własny.”
[syntax=c]type MyContext struct {
Done chan struct{}
Data map[string]any
}[/syntax]
Nie podobał mi się globalny context, więc stworzyłem potwora - taki lokalny problem globalny .
Mogę sobie pogratulować – od teraz jestem oficjalnie Go-midem. Mogę sobie przyznać order z ziemniaka...
Etap 5: Tester z misją
„Pokrycie testami 90%! Tylko.... nikt nie wie, co testują.”
[syntax=c]func TestSomething(t *testing.T) {
got := DoIt()
want := DoIt()
if got != want {
t.Errorf("expected %v, got %v", want, got)
}
}[/syntax]
Nie, nie to nie jest żaden test, to dialog między dwiema kopiami tej samej funkcji.
Ale w raporcie CI wygląda pięknie.
Etap 6: Filozof runtime’u
„Nie wiem, kto odpala te goroutines, ale najwyraźniej są szczęśliwe.”
[syntax=c]for {
go doBackgroundTask()
time.Sleep(time.Second)
}[/syntax]
Mam goroutines, które żyją dłużej niż niektóre projekty, mówi się , że przetrwają ludzkość ....
Wiem, że to źle, ale… przecież runtime się nie skarży.
Etap 7: Pragmatyczny zen
„To nie bug, to emergentne zachowanie systemu.”
[syntax=c]select {
case <-ctx.Done():
return
default:
// żyj chwilą
}[/syntax]
Nie szukam już doskonałości, jestem nią ....
Teraz poszukuję równowagi.
Bo już wiem, że Go to nie język programowania – to styl życia.
Podsumowanie tego etapu
Mid to stan przejściowy między „chcę wszystko przepisać”, a „niczego nie dotykam, bo działa.”
To moment, w którym zaczynam wreszcie rozumieć, że idiomatyczne Go to nie reguły — to proces dojrzewania.
Ale znów mija kilka miesięcy i klika projektów i programów mniej więcej znajduję się tu teraz.
Czyli w miejscu z którego wyraźnie widać jak z czasem zmienia się moje if err != nil
Etap 1: Idealista
„Każdy błąd musi mieć sens.”
[syntax=c]if err != nil {
return fmt.Errorf("nie udało się wczytać pliku: %w", err)
}[/syntax]
Czysto, pięknie, zgodnie z konwencją.
Właściwie to jestem dumą dla każdej codereview.
Etap 2: Pragmatyk
„Nie ma co przesadzać.”
[syntax=c]if err != nil {
return err
}[/syntax]
Minimalizm absolutny...
Mniej słów, więcej spokoju.
Wreszcie pojawia się zen.
Etap 3: Realista
„Nie wiem, czemu znowu nie działa, ale lognę.”
[syntax=c]if err != nil {
log.Println("coś poszło nie tak:", err)
}[/syntax]
Nie naprawiam – obserwuję.
To już nie jest zwykły błąd, to informacja zwrotna od wszechświata.
Etap 4: Filozof
„Nie ma błędów, są tylko ścieżki alternatywne.”
[syntax=c]_ = doSomething()[/syntax]
Cisza....
Żadnych logów, żadnych błędów.....
Osiągnąłem nirwanę !!!
Etap 5: Senior
„if err != nil { this is fine }”
[syntax=c]if err != nil {
// TODO: naprawić kiedyś (fajnie to wygląda w kodzie nie? Gufim?)
}[/syntax]
Znam wszystkie bugi, ale żyję z nimi w harmonii.,,
Wiem, że stabilność projektu to stan umysłu....
Epilog Epilogu
Go nauczył mnie:
-- popełniać błędy idiomatycznie,
-- potrafię napisać od ręki taki race condition, którego nawet go vet się nie spodziewa,
-- zdaję sobie sprawę , że context to nie tylko „kontekst” — to stan emocjonalny programisty.
-- perfekcja jest przereklamowana,
-- umiem pisać funkcje bez argumentów, które .... i tak zwracają błędy.
-- umiem perfekcyjnie użyć sync.WaitGroup, żeby poczekać... poczekać na coś, co już się zawiesiło.
-- umiem zrobić slice, taki specjalny slice, który dzieli pamięć z trzech innych slice’ów, a każdy z nich zmienia coś innego.
-- dokumentacja to też kod,
-- a panic() ? to tylko manifest pasji.
-- i przede wszystkim: wiem, że := to broń masowego shadowingu.
Pozostaje mi jeszcze jeden etap. Etap w którym zapewne odkryję wejście do Narni , albo Matrixa , ale na pewno się podzielę z wami
moimi przemyśleniami ... w tej chwili na pewno możecie zapamiętać te kilka zasad , choć bardziej nazwałbym to:
Objawione prawdy Go !!!!
---> panic() nie rozwiązuje problemów, ale przynajmniej robi je głośnymi.
---> context.WithTimeout zawsze wygasa wtedy, gdy właśnie zaczyna działać.
---> go fmt nie naprawi Twojego życia, ale sprawi, że będzie wyglądało schludnie.
---> defer jest jak obietnica — złożona przez kogoś, kto już dawno odszedł z projektu.
---> interface{} to taki wieeeeeeeeellllllki worek — wszystko się zmieści, ale potem nikt nie wie, co tam jest i po co.
---> errgroup to świetny sposób na współdzieloną katastrofę.
---> „idiomatyczne Go” znaczy: „napisz tak, żeby nie dało się tego poprawić bez flame waru na GitHubie.”
Na koniec zostaje nam nil..., a nil... nil zawsze czeka.
Na ciąg dalszy przyjdzie jeszcze poczekać… droga przede mną długa. Ale myślę, że to dobry moment na morał – nie tylko z tej opowieści,
ale z całego materiału w >>> cookbooku <<<. Coś, do czego warto wracać.
Nowy język kusi i ekscytuje, ale droga do mistrzostwa w Go bywa męcząca. Relacja z nim jest trudna, choć jego prostota bije po oczach niczym LED-y w starym gracie.
Go nie jest sexy – ale jak każda zdrowa relacja, daje stabilność.
W Go nie chodzi o klasę, tylko o package main.
Nie chodzi w nim o dziedziczenie, tylko o kompozycję cierpliwości i logów.
A jeśli kiedyś Twoje go build przejdzie za pierwszym razem… --- sprawdź, czy na pewno jesteś w dobrym katalogu.
Go to język dla tych, którzy chcą zbudować coś, co przetrwa. I w tym – w prostocie i cierpliwości – kryje się jego piękno.
Zapamiętaj, młody padawanie Go:
Kiedy patrzysz w goroutine,
goroutine patrzy w Ciebie.
Przyszłość widzi Twą – a jasna ona nie jest…
Nie wszystkie one znikną. Niektóre z nich są niemal nieśmiertelne.
Zostaną na długo po Tobie .....
, a nil ?? .... wciąż czeka ......
Więcej .... znajdziecie >>> tutaj <<<przyjaciele ... zapraszamStatystyki: Napisane przez SunRiver — 8 lis 2025, o 18:45
]]>