Dnia Sun, 28 Apr 2013 21:23:43 -0500 po głębokim namyśle A.L. rzekł:

> On Sun, 28 Apr 2013 23:02:31 +0000 (UTC), Edek
> <e...@g...com> wrote:
>>Potem, w Go switch + przekazanie błędu kanałem pozwala w kilku linijkach
>>propagować błędy pomiędzy Procesami, co w przypadku wyjątków _zawsze i
>>wszędzie_ jest kłopotliwe, nawet w C++11.
>
> Moze oddac glos tym ktory maja na ten temat zdanie
>
> http://joneisen.me/post/38188396218

Nie wiem kto to jest, ale to wstępny artykuł do tematu. Autor
coś mówi o tym, że Go "uses shared data model", co nie jest prawdą.
Twórcy Go mówią o tym że "pozwala na dzielenie pamięci", ale
lepiej jest nie dzielić, a jak już dzielić to "by communicating"
jak w przykładzie sharemem - ownership jest w tylko jednym miejscu
dla tych przekazywanych przez pointer, pamięć faktycznie dzielona
też ma ownership w jednej procedurze przez closure. Czyli
efektywnie nie dzieli pamięci, choć jest taka możliwość i pakiet
sync.

A to sporo zmienia w całej argumentacji. Co do Erlanga autor
robi dość jasne zastrzeżenie, że właśnie doczytał. Ja sam
Erlanga nie znam.

--
Edek

do góry

Dnia Mon, 29 Apr 2013 09:29:39 -0500 po głębokim namyśle A.L. rzekł:

> Przy okazji wypada przypomniec entuzjastom GO ze "goroutines" nie sa
> woatkami. Sa KORUTUNAMI (coroutine) a to jest zwierze inne niz watek
> (threaad). Ten model wspolbieznosci byl wprowadzony po raz pierwszy w
> jezyku Simula-67 a potem uzyty przez Wirtha w jezyku Modula-2.
> Programuje sie to-to ineczej niz watki, bo coroutines (w odroznieniu od
> watkow) nie sa kontrolowane pzrez scheduler systemu operacyjnego.

I właśnie dlatego między innymi jestem entuzjastą Go. Poza tym
nic nie przeszkadza w tym, żeby procedury były mapowane na wątki,
implementacja gccgo ma do tego zmienną środowiskową. Nie jest to
1:1, to kwestia abstrakcji. Tak jak wątek OS jest dostarczaną
abstrakcją i nie jest rdzeniem procesora, tak goroutines są
abstrakcją dostarczaną przez implementację Go wraz z channels.

> Dla mnie to krok do tylu, jakby co...

Mówienie, że pliki są w systemie plików a nie na dysku, to dopiero
krok wstecz...

PS. Proszę się o KF, będę miał spokój ;)

--
Edek

do góry

On Mon, 29 Apr 2013 15:06:06 +0000 (UTC), Edek
<e...@g...com> wrote:

>
>Mówienie, że pliki są w systemie plików a nie na dysku, to dopiero
>krok wstecz...
>
Nonsens. Programujac z korutynami, programista zam muzi sie zabawic w
scheduler. Jest to zajecie dosyc upierdliwe i dajace okazje do roznych
ciekawych bledow, miedzy innymi z "zakleszczeniem" sie programu.

Osobiscie, po latach programowania w Simuli i Moduli z ulga przyjalem
smierc korutyn (w Simuli programuje do dzis bo nei wymyslono lepszego
jezyka do symulacji; polacem kompilator CIM). No, ale widac od czasu
do czasu zarowke odkrywa sie na nowo. Krzyczac glosno EUREKA!

A jak idzie o pryncypia: Kolega zna wyzszosc GO nad innymi jezykami
moca teoretycznej wszechwiedzy. Proponuje popprogramowac, ale nie tak
hobbystycznie, ale produkcyjnie, z rok albo dwa. I wtedy wyrazac
opinie na temat przydatnosci jezyka.

A.L.

do góry

On Apr 29, 2:32 pm, Edek <e...@g...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.

do góry

On 2013-04-29, Edek <e...@g...com> wrote:
> Dnia Mon, 29 Apr 2013 10:27:59 -0500 po głębokim namyśle A.L. rzekł:
[...]
>> A jak idzie o pryncypia: Kolega zna wyzszosc GO nad innymi jezykami moca
>> teoretycznej wszechwiedzy. Proponuje popprogramowac, ale nie tak
>> hobbystycznie, ale produkcyjnie, z rok albo dwa. I wtedy wyrazac opinie
>> na temat przydatnosci jezyka.
>
> Hobbystycznie to ja na zmianę jem czekoladę i robię sobie dobrze ;/
>
> Produkcyjnie z Go nie miałem do czynienia. Pan rozumiem miał, czy
> mógłby Pan opisać doświadczenia?

Zapewne miał, ale nie może podać szczegółów ze względu na podpisane
NDAs.

Z dokładnością do tego, że przyznał się na samym początku wątku do braku
wcześniejszej znajomości Go.

--
Secunia non olet.
Stanislaw Klekot

do góry

Dnia Mon, 29 Apr 2013 10:27:59 -0500 po głębokim namyśle A.L. rzekł:

> On Mon, 29 Apr 2013 15:06:06 +0000 (UTC), Edek
> <e...@g...com> wrote:
>
>
>>Mówienie, że pliki są w systemie plików a nie na dysku, to dopiero krok
>>wstecz...
>>
> Nonsens. Programujac z korutynami, programista zam muzi sie zabawic w
> scheduler. Jest to zajecie dosyc upierdliwe i dajace okazje do roznych
> ciekawych bledow, miedzy innymi z "zakleszczeniem" sie programu.

Odpierałem zarzut, że "wątki nie słuzą do wykorzystania rdzieni".
A nie, wróć, że goroutines nie nadają się do wielowątkowości. Na tyle
mnie to wyczerapło, że do meritum wrócę później.

W Go zdaje się zakleszczenie wymaga niebuforowanych kanałów;
zakleszczenie komunikacyjne nie jeset domeną języka, ale i tu
Go ma plus, bo wyjątki do współpracy maszyn stanów się średnio
nadają; javove ThreadDeath czy pthread.cancel to już rzeźnicka
subtelność.

> Osobiscie, po latach programowania w Simuli i Moduli z ulga przyjalem
> smierc korutyn (w Simuli programuje do dzis bo nei wymyslono lepszego
> jezyka do symulacji; polacem kompilator CIM). No, ale widac od czasu do
> czasu zarowke odkrywa sie na nowo. Krzyczac glosno EUREKA!

Nitk tak nie mówi. Autorzy Go mówią wyraźnie, co dopiero przeczytałem:
żadnych ambicji zmiany teorii, ambicja zmiany praktyki. Ja już chyba też
to mówiłem, ale wtedy to były opary czegośtam.

Ale to prawda, zrobili ogólnie prawie to samo co już było, tylko
w innej kombinacji i twierdzą, że warto było stworzyć język. I nawet się
z nimi zgadzam, ale poczekamy, zobaczymy.

> A jak idzie o pryncypia: Kolega zna wyzszosc GO nad innymi jezykami moca
> teoretycznej wszechwiedzy. Proponuje popprogramowac, ale nie tak
> hobbystycznie, ale produkcyjnie, z rok albo dwa. I wtedy wyrazac opinie
> na temat przydatnosci jezyka.

Hobbystycznie to ja na zmianę jem czekoladę i robię sobie dobrze ;/

Produkcyjnie z Go nie miałem do czynienia. Pan rozumiem miał, czy
mógłby Pan opisać doświadczenia?

--
Edek

do góry

On Apr 29, 3:29 pm, A.L. <a...@a...com> wrote:
[...]
> Teraz czekamy na generic

Według mnie interfejsy to właśnie dają (na co najmniej javowym
poziomie)

> i dziedziczenie wprowadzone "kuchennym wejsciem"

Nazywa się "embedding".

> Przy okazji wypada przypomniec entuzjastom GO ze "goroutines" nie sa
> woatkami. Sa KORUTUNAMI (coroutine) a to jest zwierze inne niz watek
> (threaad). Ten model wspolbieznosci byl wprowadzony po raz pierwszy w
> jezyku Simula-67 a potem uzyty przez Wirtha w jezyku Modula-2.
> Programuje sie to-to ineczej niz watki, bo coroutines (w odroznieniu
> od watkow) nie sa kontrolowane pzrez scheduler systemu operacyjnego.

Wydaje mi się, że goroutines to nie są ani wątki, ani coroutines,
tylko coś pomiędzy. Znaczy runtime decyduje ile fizycznie wątków
odpalić i jak na nich rozmieścić goroutines, mogą się wykonywać
równolegle, ale mogą tez sekwencyjnie jak coroutines i wtedy
przełączanie ma miejsce na operacjach kanałowych. Ale może się mylę?

do góry

Dnia Mon, 29 Apr 2013 08:32:16 -0700 po głębokim namyśle Andrzej Jarzabek
rzekł:

> On Apr 29, 2:32 pm, Edek <e...@g...com> wrote:
>> Dnia Mon, 29 Apr 2013 04:29:20 -0700 po głębokim namyśle Andrzej
>> Jarzabek rzekł:

>> 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.

Ano jest: w sytuacji błędu z sąsiedniego systemu nie wystarczy tylko
rzucić wyjątek i wyczyścić stan. Para 'wynik, błąd' jest lepsza.
Ogólnie lepsze moimn zdaniem jest podejście takie, że logger,
monitoring, komunikacja, i cała reszta infrastruktury są dokładnie
takimi samymi modułami jak treść - powiedzmy propagowanie dokumentu
do działów. Na desktopie nie ma znaczenia czy logowanie jest "doklejone",
w rozproszonych już jest inaczej.

[... objawienie istnienia futures i przekazywania wyjątków ...]

[... 'nic to nie zmienia' bez pokrycia i jak to jest w Erlangu... ]

[snip...]

> 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.

No więc ja uważam, że w Javie programują dwie grupy ludzi: dzieci
Javy lubiące ten język i osoby umiejące używać Javy.

> 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.

Tak, zastrzegałem: tylko mały przykład, fragment całości. Lista jest
dużo dłuższa.

> 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
> }

W Javie, C++, C (!), Pythonie też. Różnica polega na ujęciu tego
w języku, w rdzeniu języka. W Go w rdzeniu języka są goroutines.
Nie ma sensu mówić o jednej cesze (?) języka bez uwzględnienia
pozostałych.

[... oczywista oczywistość ...]

> 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ę?

Trochę inny jest narzut składni nad treścią, inne debugowanie,
inne automatyczne detekcje, itd. itp.

>> 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++?

Z A.L. właśnie sobie to wyjaśnialiśmy. Trochę tak jak pomiędzy
systemem plików a dyskiem 2TB.

> 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.

Generyki Javy owszem, są przydatne, ale nie mam zamiaru o nich mówić,
bo nie warto. O programowaniu generycznym już mogę.

> 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.

No bo o 'generykach Javy' mogę powiedzieć tyle, że są
- niespójne z systemem typów. Matematycy robią listy floatów,
mapy int na boolean, itd., generując kod.
- nie pozwalają pisać kodu zależnego od T
- w zasadzie to syntaktyczny cukier na zbędne classcasty wynikające
z braków w systemie typów Javy, nic więcej

O tym czy są przydatne już mówiliśmy.

--
Edek

do góry

Dnia Mon, 29 Apr 2013 10:27:59 -0500 po głębokim namyśle A.L. rzekł:

> A jak idzie o pryncypia: Kolega zna wyzszosc GO nad innymi jezykami moca
> teoretycznej wszechwiedzy. Proponuje popprogramowac, ale nie tak
> hobbystycznie, ale produkcyjnie, z rok albo dwa. I wtedy wyrazac opinie
> na temat przydatnosci jezyka.

Czasami temperament ponosi...

Nie mam takiego doświadczenia jak Pan. Nie znam Erlanga ani nawet Ady.
Co nie przeszkadza mi znać dobrych kilku nowszych języków, mniej
popularnych i pewnie gorszych, ale jak łatwo zauważyć te same motywy
przewijają się w coraz to nowej formie.

Za to przynajmniej staram się nie rzucać słów na wiatr i czytać co
się do mnie pisze. Doświadczenie zawodowe mam spore i nie byle
jakie.

Ostatecznie: jasne, to tylko moje opinie w usenecie. I EOT,
bo nic sensowanego nie usłyszałem tylko jakieś teksty, że
'goroutines to nie wątki'.

PS. Heh, KF nie, ale mój czytnik pozwala oflagować autorów+-. Fajne!

--
Edek

do góry

W dniu poniedziałek, 29 kwietnia 2013 16:29:39 UTC+2 użytkownik A. L. napisał:

> 1. Faceci uznali ze "nowatorsko" bedzie bez wyjatkow
> 2. Faceci stwierdzili ze bez wyjatkow sie nie da
> 3. Faceci stwierdzil ize po 1. wprowadzeie wyjatkow byloby utrata
> twarzy
> 4. Wiec wprowadzili "panic" ktory oficjalnie wyjatkiem nie jest a de
> facto jest

Nie znam Go, ale czyta ten wątek i dochodzę do wniosku, że zrobią
"inny, ale taki sam" C++. Po co oni w ogóle zaczęli robić ten
język? Jest masa języków i jeszcze większa masa problemów z dobrymi
narzędziami/bibliotekami do istniejących języków. Dlaczego
ludzie z Googla naprawdę nie załatali dziury w językach programowania?
Można przecież z pożytkiem dla wszystkich rozwinąć dobry wysokopoziomowy
język gdzieś po środku drogi łączącej C++ i Javę, można rozwijać choćby
taki język D.

Pozdrawiam

do góry