Dnia Fri, 26 Apr 2013 12:08:01 -0500 po głębokim namyśle A.L. rzekł:

> On Fri, 26 Apr 2013 17:07:00 +0000 (UTC), Edek
> <e...@g...com> wrote:

>> Miałem na myśli tyle,
>>że w takiej architekturze wyjątki są podobnie niepotrzebne co COM i
>>takie "generyki" jakie ma Java.
>
> Jakies argumenty?

Po naprawdę ciężkie argumenty musiałbym zejść do piwnicy, więc
zaryzykuję tylko teoretyczne [1]. Mogę też nie pamiętać niuansów Go,
nawet nie znam wersji 1.0.

Pierwszy problem w procesach mających kilka wejsć i kilka wyjść,
lub nawet po jednym, jest taki: kto ma złapać wyjątek? Downstream,
upstream, rodzic? Jednocześnie mówimy o Failure więc powiem o jakie
Failure mi się (nie) rozchodzi.

Wyjątki mogą być spowodowane wadą algorytmiczną. Powiedzmy, że
w systemie płac Złośliwy Zenek zakodował:

if (name == Żółty.Stefan and boss == doopa.noerweskiego.renifera)
then die;

Wtedy _zawsze_ proces dawania podwyżki dla Stefana Architekta
nie przejdzie [2].

Ale takie problemy na bok, Poisonous Messages są znane,
tak jak i Tagged Logging, gdzie "zarażane" są wszystkie wyjścia
i procesy mające od czynienia ze sktukiem jednej wiadomości.

Większość modeli teoretycznych jakie ja znam operuje
na kilku prymitywach zakładając, że z wielu procesów zawsze
jakiś padnie w przypadkowy sposób, powiedzmy promieniowanie
jonizujące uszkodzi ALU procesora. Prymitywy to najczęściej
atomiczne rejestry, Procesy realizujące algorytm, message passing,
i Wyrocznia, możliwie słaba. Jeżeli znane N procesów ma liczbę
mogą one ustalić największą liczbę[3], jeżeli Wyrocznia
w dowolnym momencie informuje każdy proces, który z procesów
jest Leaderem. Ale to samo jest też możliwe dla Wyroczni
informującej czy procesy jeszcze nie padnięte a) to wszystkie
b) czy ich liczba jest parzysta (jeżeli czegoś nie pokręciłem).
Ta druga jest ściśle słabsza, bo z informacji dawanej przez
pierwszą da się wyprowadzić drugą, a na odwrót już nie. To cała
dość fajna dziedzina algorytmiki, science of its own. Dość
dobrze znana, na pewno znana doskonale od strony praktycznej
przez Google i na pewno mają odpowiednią infrastrukturę.

Nie znam odpowiednich prac mających za postawę wyjątki, ale
jak przekazać wyjątek przez message passing tak,
żeby uniknąć samego problemu w message passing lub procesie
w momencie wysyłania wyjątku? Tu mógłbym skończyć.

Drugi punkt widzenia jest taki, że trzeba napisać oprogramowanie
za pomocą pracy Szarych Edziów, którzy mogą nie zrozumieć niuansów
zabezpieczeń przed dowolnym Failure, lub Sowich Adamów,
ekspertów od ...analizy kryształów, którzy nie chcą być tym
obarczani. Podejrzewam, że mając Go można ukryć większość
tych włochatych problemów przed Szarymi Edziami, o ile
Żółty Stefan Architekt sam nie jest Dooponte tak jak
jego szef.

Go może wszystkie te powyższe mechanizmy mieć ukryte
w implementacji. Z punktu widzenia Szarego Edzia i Sowiego
Adama wystarczy wysłać int-a przez channel, żeby dotarł i
obsłużyć wynik WynikBrakMuzgu. To jedna linijka w przeciwieństwie
do CORBY czy COMa. Za to w implementacji poszczególne
algorytmy są Procesami zgodnie z teorią i mają określany stan
w każdym punkcie dostępu do channela, więc można je restartować
i odtworzyć bez widocznego skutku dla realizowanego
algorytmu. Infrastrukturę robi się raz, Edzie mają znać Go i
tylko pójść przed rozpoczęciem pracy postemple ppoż i bhp, a
nie mieć wtłaczaną tygodniami do głowy teorię systemów
rozproszonych i potem jeszcze zgodnie z nią pisać kod.

Pewnei coś pokręciłem, mam nadzieję że jutro ędzie
nadal wyglądało w miarę...

Jest jeszcze punkt widzenia taki, że modna Java ma modne
wyjątki więc Go jest niemodne, ale ja zawsze wolę jak
coś działa i jest spokój, mam nadzieję że na p.c.p to
podejście przejdzie :). A, i Google nigdy nie faworyzowało
wyjątków.

[1] Uprzedzałem, jakby ktoś coś do mnie miał mieć
[2] Bez manualnej ingerencji Doopy Renifera, inni głosu nie mają
[3] Z żyjących procesów, i procesy nie odżywają

--
Edek