🚀 go-pugleaf

On Apr 29, 2:32 pm, Edek <edek.pienkow...@gmail.com> wrote:
> Dnia Mon, 29 Apr 2013 04:29:20 -0700 po głębokim namyśle Andrzej Jarzabek
> rzekł:
>
> > No ale wyjątki (takie jak w Javie czy C++) nie służą do powiadamniania
> > procesów. Jeśli trzeba powiadomić procesy, to kod, który to robi możesz
> > mieć w catch.
>
> Tylko że to jest strasznie niewygodne.

Tak samo niewygodne, jak zwracanie z funkcji pary (wynik, błąd).

> Działa ok w c++ dla prostych
> rzeczy, typu odczytaj dokument z bazki, przetwórz, zapisz, ale mając
> nie jeden wątek tylko masę i bilioteki w setkach tysięcy linii kodu
> nawet RAII robi się kłopotliwe gdy dołączona jest reakcja
> zewnętrznych systemów.

W ramach tego, że w C++ nie masz wbudowanych mechanizmów takich jak
channel i goroutine, nie jest to bardziej kłopotliwe niż rozwiązanie
bez wyjątków.

A że zamiast goroutines używasz bibliotek dających ci patterny takie
jak futures, to jest to zdecydowanie mniej kłopotliwe, bo owe
biblioteki zapewniają ci propagację wyjątków przez granicę wątku.

> Dopiero małe goroutines z mniejszym stosem są światełkiem
> w tunelu. Zamiast olbrzymiego stosu przez który leci wyjątek ma
> się niewielkie procedury połączone kanałami. Widzę, że niedługo
> powiemy, że BASIC też działał.

Nic ci to nie zmienia, nadal musisz ten błąd obsłużyć. W Erlangu
różnicę masz faktycznie o tyle, że piszesz programy w ten sposób, że
każdy błąd powoduje ubicie "procesu", który możesz potem albo
automatycznie restartować, albo czekać na interwencję operatora, który
może dojść do tego co się stało i naprawić błąd - włącznie z
poprawieniem błędnego kodu i uruchomieniem go bez zatrzymywania
systemu.

> > recover i jak dla mnie są to po prostu wyjątki, tylko troszeczkę inaczej
> > zrobione. Z tego co przeczytałem jest to ficzer dodany do języka w
> > późniejszym etapie i sądzę, że narzekanie, że nie ma wyjątków raczej
> > pochodzi z czasu, kiedy nie było.
>
> Hmm. Ja żyję tu i teraz, ale może źle robię ;)

I narzekasz, że Go nie ma wyjątków?

> > Jeśli chodzi o to, co panic/recover wnoszą do rozproszonej architektury,
> > to przykro mi, ale nie widzę różnicy. W dodatku z wykorzytsaniem w
> > kontekście współieżności nie wydają się wnosić zbyt wiele w stosunku do
> > wyjątków, bo z tego co wyczytałem to wyjście z goroutine w stanie
> > spanikowanym wywala cały program.
>
> Tu nie ma żadenj różnicy, wyjątki też trzeba łapać. Mi nie jest przykro
> że rozmówca się nie zgadza, wręcz przeciwnie.

Mi jest przykro, że nie widzę różnicy, a nie, że się nie zgadzasz.
Bałem się po prostu, że oślepłem, więc z ulgą przyjmuję do wiadomości,
że różnicy nie ma.

> > Interesującą różnicą między tradycyjnymi wyjątkami a panic/recover jest
> > "dynamiczny" charakter tych drugich. Jak rozumiem defer/recover można
> > rejestrować np. warunkowo w klauzuli if. Czy to dobrze czy źle,
> > nie mam szczególnie zdania: widzę potencjalne problemy z czytelnością,
> > łatwością wnioskowania p programie, wykrywaniem błędów i refaktoryzacją,
> > w dodatku "tradycyjne" podejście oparte o zakresy wydaje mi się
> > elegantsze. Być może natomiast panic/defer/recover mają jakieś ciekawe
> > idiomatyczne sposoby stosowania, które może nawet jeszcze nie są
> > odkryte. Po prostu nie wiem.
>
> Może najpierw "doczytam i wiem" a potem sugerowanie problemów? Podobny
> cleanup stosuje się w C, tylko bez automatycznego zwijania stosu. Z tymi
> znienawidzonymi goto.

No więc otóż również uważam, że C jest kiepskim językiem, w którym
brak sensownych rozwiązań jest przyczyną dużej ilości problemów.

> > Niepokojące natomiast są argumenty ze strony projektantów języka typu
> > "tak, wiemy, że (cośtam w) panic/recover jest kijowe. Specjalnie
> > zrobiliśmy kijowe, żebyście nie używali panic."
>
> No tak, bo panic to wszyscy lubią. Ech... . Go ma taką filozofię:
> pozwlamy pisać ryzykowny kod, ale oferujemy bezpieczne metody
> pisania.

Nie ma nic szczególnie bezpiecznego w tym, co oni proponują zamiast.
Odpowiednikiem rzucenia wyjątku i nie złapania go jest coś takiego:

foo, err := getFoo(bla)
bar, err := makeBar(foo)

Tak, oczywiście, taki mechanizm i taka konwencja są krokiem do przodu
w stosunku do tego, co jest w C, ale nad wyjątkami nie widzę żadnej
przewagi.

> > Ach, ale akurat to, czy wyjątki są dobre, czy niedobre to jest oddzielny
> > temat od tego, czy sprzątanie zasobów przez finally jest dobre czy
> > niedobre. Są języki, które mają inne rozwiązania rtego problemu, i nawet
> > w samej Javie da się stworzyć (i tworzy się)
> > odpowiednie wrappery.
>
> Ja podałęm konkretny przykład i nic nie mówiłem o tym, czy finally
> jest "dobre" czy "niedobre". Mając RAII używa się RAII, mając finally
> używa się finally, mając goto w C używa się goto. Mówimy o braku
> wyjątków w Go i z czym to się je w porównaniu do innych języków.

Ale twój argument dotyczył tego, że defer jest lepsze od sprzątania
zasobów niż finally. Może i jest, ale to nie jest argument za tym, że
bez wyjątków lepiej, bo przecież istnieje wiele mechanizmów językowych
do sprzątania zasobów lepszych niż finally.

W Groovy na ten przykład, który ma dokładnie takie same wyjątki jak
Java, problem zamykania pliku można załatwić w ten sposób:

myFile.withWriter { writer ->
    zapisuj_do_pliku_używając writer
}

> > Takie rozwiązanie, jak daje ci go, czyli złapać wyjątek w wątku, który
> > go rzucił i przekazać jako wynic coroutine to z grubsza tak samo możesz
> > zrobić w C++ przy pomocy future, try/catch, i pair.
>
> Ano nie. To znaczy da się, ale praktyka zupełnie inaczej wygląda.

Praktyka jest taka, że się używa wyjątków, bo tak lepiej.

> W BASICu też się da pisać.

Ale nie da się uzyskać praktycznie tego samego rezultatu.

> > [...]
> > No więc dokładnie w taką stronę, w jaką mu exception handler każe
> > polecieć. Dokładnie tak jak z panic w Go.
>
> Ano nie. Chociażby kod podzielnoy jest na goroutines, a nie na
> jeden monolityczny wątek ze stoma ramkami stosu.

Ale dlaczego monolitycznego? Wątki masz takie, jakie sobie napiszesz.
Dokładnie tak samo, jak rozumiem, jak goroutines - będzie ich tyle i
takie duże, jak sobie programista podzieli program. Mylę się?

> To inna architektura,
> trzeba przekazać informację o błędzie przez channele a nie tylko w górę
> stosu.

I czym to się różni od programu wielowątkowego w C++?

> Panic nie jest "dokładnie tak samo", tylko właśnie "zupełnie
> inaczej", choć ma wspólne cechy, bo służy do tego samego celu.

Jest dokładnie tak samo, z dokładnością do duperel. Tak samo jak
wyjątek przerywa wykonanie bieżącej funkcji i zwija stos tak długo, aż
nie trafi na handlera. Różnica jest taka, że handlery można sobie
dynamicznie rejestrować, co z pewnością może być przyczyną wielu
radosnych błędów, ale czy ma jakieś praktyczne zastosowania?

> > Po przyjrzeniu się wygląda trochę tak, jakby w Go interfejsy dawały
> > generyczność - przynajmniej taką jak w Javie, a może nawet trochę
> > mocniejszą. Nie mam racji?
>
> Oj, j.w., doczytajmy może najpierw. Bo ja już nie wiem, czy brakuje
> generyków czy są generyki, zdecydujmy się na zajęcie jakiejś
> pozycji w argumentacji, pogubiłem się ;)

Moja pozycja jest taka: w językach statycznie typowanych generyki w
takiej czy innej formie są przydatne. Również, a może nawet przede
wszystkim przy pisaniu złożonych systemów serwerowych, również w
przypadku, kiedy są one współbieżne czy rozproszone.

W temacie czy Go ma generyki, wyjątki i tak dalej nie mam żadnego
szczególnego stanowiska - tak czy inaczej raczej używać nie będę. Na
podstawie tego, co widzę pobieżnie się przyglądając, Go ma wyjątki i
generyki. Jeśli chcesz mi wyłumaczyć, dlaczego panic/recover nie są
wyjątkami w takim sensie, jak exceptions z Javy czy C++, albo dlaczego
interfejsy nie są typami generycznymi w takim sensie, jak w Javowych
generics, to chętnie przeczytam i ewentualnie podyskutuję. Nie chce ci
się - też dobrze, możemy w takim razie chyba zakończyć dyskusję na
tym, że nasza rozbieżność zdań co do przydatności generyków i wyjątków
bierze się stąd, że inaczej rozumiemy te pojęcia.