Google Go – co najdeme ve stavebnici (diskuse)

[stewe]

zaujimave, ale stale sa neviem zbavit pocitu, ze to je od Googlu ... oplati sa to vobec ucit? (ano blba otazka), ale kolko ludi v tom kodi? jednotky percent ... podla mna to bude vzdy jazyk v stadiu beta, ako vlastne vacsina produktov od googlu ... neviem si na to predstavit nejaku realnu app s komercnym vyuzitim. boze, strasne sa mylim co? :D

[vvv]

+ 1

[Bystroushaak]

Navíc je to hnusná syntax jak prdel. Kdybych chtěl nějakou obludu, tak jdu dělat v delphi.

[Sten]

Však ono to vypadá jak Delphi, až na chybějící „begin“ a „end“

Nevím, co si o tom myslet, až na korutiny mi to přijde úplně nesmyslné. A i korutiny jdou řešit lépe a v existujících jazycích (OpenMP, Boost Thread, ThreadWeaver, Scheduler/Linux Activations).

[deda.jabko]

A i korutiny jdou řešit lépe a v existujících jazycích (OpenMP, Boost Thread, ThreadWeaver, Scheduler/Linux Activations)

imho gorutiny maji byt neco jineho nez vlakna a v kombinaci s kanaly to muze byt docela mocne. i kdyz osobne by se mi libilo spis, kdyby zpravy zaslane kanalem definitivne neslo precist, jak to ma udelane treba sing#

[Sten]

Však taky nepíšu o vláknech, ale o korutinách (korutiny jsou implementované automaticky pomocí vláken, fiberů/context switchů a cykly, všechny uvedené frameworky je umí). MPI (ty takzvané kanály) jsou samozřejmě buď součástí těch frameworků nebo jsou pro ony jazyky také dostupné (třeba Boost MPI).

[littleli]

A to je právě ten problém... implementace pomocí vláken vyžaduje v podstatě nadužívání konceptu zámků, mutexů a jiných synchronizací. koroutina v Go je lehčí a runtime sám rozhodne, zda je vhodné ji svázat s konkrétním vláknem. Viz dokumentace.

[pht]

Go je typově a paměťově bezpečný jazyk a to se s aritmetikou ukazatelů nedá snadno, tedy spíše v podstatě asi vůbec nijak, skloubit dohromady.

Přijatelný kompromis je systém vlastních alokátorů, jak ho např. má C++ nebo Ada.

[Radek Miček]

Go je typově a paměťově bezpečný jazyk a to se s aritmetikou ukazatelů nedá snadno, tedy spíše v podstatě asi vůbec nijak, skloubit dohromady.

Jazyky se silnějším typovým systémem by s tím neměly mít problém. Viz třeba ATS.

[imploder]

Přímý a efektivní přístup k paměti jako v C a přitom bezpečný - to zní až moc dobře na to, aby to byla pravda . Na to se podívám.

[Radek Miček]

V článku Safe Programming with Pointers through Stateful Views se tím zabývají. Osobně bych, ale takové programy psát ani číst nechtěl.

Praktičtějším řešením je sixgill (příklad použití: Overflow Checking in Firefox).

[----]

no nevím, Go se mi moc nelíbí. Osobně poslední dobou dělám hlavně s jazyky D, C, částečně C++ (bez STL), k tomu Python a Lua.

[----]

Jinak hezký článek, ale české pojmenování programovacích termínů je otřesnost - jako "ukazatel", "šablona", "spojový seznam", "silný typový systém" (ne vše v článku) ... ughhhhhhhh ... IMO lepší pojmenovávat věci tak jak jsou, v angličtině.

[Ladicek]

Většina českých názvů v článku je úplně normální, ale slice myslím žádný zažitý překlad nemá a řez se prostě nehodí. Řez bajtů je hnůj. Nemám nic skvělého, ale úsek by byl myslím o trošičku lepší.

Jo a imutabilní, to je taky slušnej hybrid.

[Bystroushaak]

:). Nad Luou uvažuju, python je můj primární jazyk, C je povinná lingua franca, D se učím a C++ jsem uměl :P. Je potěšující vidět někoho kdo dělá v čechách do D :).

[----]

no, ono C++ stojí z větší části za h*vno (hlavně STL), D je daleko líp designovaný (D2)

[Bystroushaak]

Jo, to je. Osobně mě dost dlouho C++ štvalo, přijde mi to jako jazyk který se úmyslně snaží házet programátorovi klacky pod nohy a maximálně mu znepříjemňovat práci. Možná je to tím že jsem prvně poznal javu..

[----]

IMO objektivní pravdivé informace o C++ jsou hezky shrnuty zde: http://yosefk.com/c++fqa/

[Bystroushaak]

Jo, to je vcelku výstižné.

[__dark__]

Aneb velmi objektivní a neutrální informace od C++ hatera.

[Sten]

Jsou to spíš informace „Když to blbě navrhnete, může se stát tohle“. C++ je dobrý jazyk, ale vyžaduje praxi, protože půlka jeho vlastností je určena pro méně než jedno procento dobře navrženého kódu (např. pointerová aritmetika nebo private členové).

[----]

Třeba tohle? http://yosefk.com/c++fqa/defective.html#defect-7

a to vznikne jednoduchým std::map<std::string, std::string> STL je hodně blbě navržená knihovna a kdykoliv musím s C++ dělat, tak se jí obloukem vyhýbám a využívám raději přímo Clib. (cstdlib, cstdio, c*)

[Luboš Doležel (Doli)]

To s map není špatný návrh, to je naopak hodně propracovaný návrh. Oni si s takhle složitými šablonami nedávali tu práci protože by museli, ale protože v tom viděli smysl...

A pak ten příklad s vectorem const char* komentovaný jako it doesn't make any sense, because your function guarantees that it won't change anything, tím se slušně diskvalifikoval, protože jeho příklad je prostě pitomost. Dal ukázku nekorektní práce se šablonami a svaluje vinu na jazyk.

[----]

nikoliv - třeba místo komplexních templates mohli naprogramovat opravdový dynamický arrays s měnitelnou délkou a tak mohly být dělaný i stringy - např. jako to dělá jazyk D. Btw, Dčkový string jako array je v benchmarku asi 3x rychlejší než std::string, daleko lépe navržený a mnohem elegantnější co se týče úprav, vyhledávání apod. (např: slicing: string a = "hello world"; string b = a[6 .. $]; /* b je "world" */)

co se týče std::map, D má asociativní arrays: int[string] x = [ "foo":5, "bar":10 ]; x["y"] = 143; který jsou opět efektivnější než std::map a mnohem lépe se s nimi pracuje.

[Luboš Doležel (Doli)]

Co se výkonu týče, to je asi věcí konkrétní implementace.

Ale asociativní pole D nejde srovnávat s std::map, protože to první je hash mapa, kdežto to druhé je tříděný asociativní kontejner - to jsou poněkud odlišné datové struktury. Toto pole v D bych proto spíš srovnával s netříděným unordered_map.

Jinak to není nic proti D, to je jen pro pořádek...

[----]

Špatně, std::map není hashtable, ale binary search tree; hashtable v C++ je std::unordered_map, který je ale až součástí TR1.
Co se týče asociativní array v D, tak je to ve skutečnosti opravdu hashtable.

[----]

ok, sorry, špatně jsem pochopil kontext - v podstatě jsem zopakoval, co jsi řekl.

[Ladicek]

To s map není špatný návrh, to je naopak hodně propracovaný návrh.

No, to se přece nevylučuje. A jestli je skutečný typ té StringToStringMapy opravdu takový, jak se v odkazovaném dokumentu píše (což nemám nejmenší chuť zjišťovat), pak je to skvělý příklad toho, jak mizerný může být takový propracovaný návrh.

[Luboš Doležel (Doli)]

Co je na něm přesně mizerného?

[----]

No, C++ spec má kolem 650 stran v PDF; více než kterýkoliv jiný jazyk, a většina z toho je standardní knihovna, která je dost neintuitivní s komplexní implementací; vše by se to dalo udělat daleko jednoduššeji, jenže už zpět jít nejde, protože na aktuální knihovně závisí obrovské množství programů; takže se na to prostě jen nabaluje další a další kód; sice C++0x pár věcí opravilo, ale pořád je toho dost. Ale celé STL je (ne)kvalitou nic oproti např. Boost, což je kapitola sama o sobě.

[Seki]

Neda mi nereagovat na Vas prispevok, ktory je...no nepodlozeny ziadnym faktom alebo relevantnym tvrdenim. Celkom by ma zaujimalo ako by ste chceli "lepsie" implementovat model, na ktorom je STL zalozena( kontajnery + iteratory + algoritmy + funktory ). Ako by sa podla Vas dala jednoduchsie zaistit napr. vlastnost kedy je vlastne algoritmus genericky a nezavisly na type kontajneru nad ktorym pracuje, jedine co vyzaduje je spravny druh iteratoru, to vsetko bez ceny obrovskych objektov a volani virtualnych metod. V C++ tieto problemy STL a Boost riesia extenzivnym vyuzitim sablon a sablonoveho metaprogramovania. Bohuzial dokazem pochopit frustraciu a rozcarovanie ludi prechadzajucich z Javy a C#, kde je standardna kniznica o niecom inom(f*cking huge i can do everything standard library), ked nedokazu ani len z pola odstranit elementy, ktore tam nechcu(erase_remove idiom).

[----]

Nemám nic proti templates ani metaprogrammingu, ale STL a Boost mi přijdou dost "overengineered" a rozvrstvené; asi je to tím, že pracuju hlavně s Cčkem, kde nic takového neexistuje - ale jako správně udělanou mid/high-level standardní knihovnu si představuju něco jako Phobos2 z jazyka D https://github.com/D-Programming-Language/phobos/tree/master/std - umí toho dost (včetně algorithm knihovny pro různý filtrování polí a takové věci) a přitom je srozumitelně a jednodušše naprogramovaná; Co se týče kontejnerů jako vector, map atd, nic takového není třeba, protože jsou podporovány dynamic arrays / hashtables na kterých je možno provádět bez problému slicing, vyhledávání apod a pro filtrování (např. odstraňování elementů, nebo nalezení největšího čísla v array apod) je možné využít algorithm knihovnu (např. template "reduce")

[Ladicek]

Ehm… srozumitelnost? Myslím, že ten odkaz by mohl sloužit jako skvělá definice výrazu overengineering.

Jen ze zvědavosti: Jak vypadá typ takové proměnné v debuggeru? Hádám, že IDE dělají nějaké zjednodušující předpoklady, ale lehké to tedy určitě nemají.

[Luboš Doležel (Doli)]

Jestli je to jen ta srozumitelnost, tak to je to ještě dobré.

Když jsem před mnoha lety s C++ začínal, považoval jsem STL za ukázku, jak se to má dělat, ale nedovedl jsem zároveň si nikdy představit, že bych něco podobného tvořil.

[imploder]

Proč by mělo mít v principu IDE problém se šablonami? Jsou to statické informace, přeloží se na jeden určitý kód. Dynamické jazyky, s těmi je problém, protože tam je toho příliš mnoho známo až při provádění programu a to IDE dělat nemůže.

[__dark__]

template<typename T>
class Something {
  static void func(void)
  {
    T::tady bude asi problém
  }
};

[Ladicek]

Nechápu. Kde píšu, že IDE má v principu problém se šablonami? Mne zajímalo, jak vypadá v debuggeru typ proměnné vygenerovaný z takové monstrózní šablony.

Jo, to co píše dark je pravda – typ parametrů šablon je uvnitř jejich těla neznámý (pokud to dobře chápu, tak je to varianta strukturní typové ekvivalence), ale o to mi nešlo.

[imploder]

Jo, to je samozřejmě pravda - IDE nemůže vědět, pro jaké typy tu šablonu chci používat. Je to v podstatě statické strukturální typování - něco podobného jako duck typing v Pythonu, akorát se provádí při překladu, takže je to lepší.

[Ladicek]

No, vzhledem k tomu, co za psí kusy musí překladač při instancování šablon vyvádět, bych se zdráhal tvrdit, že to je lepší, ale jinak si rozumíme. A mluvíme o něčem úplně jiném, než mne zajímalo.

[imploder]

Vypisuje se to nepřehledně, protože to má v C++ takovou nepřehlednou syntaxi. Zřejmě se nepočítá s tím, že by se šablony až tak zanořovaly do sebe.

[imploder]

Jo, to je blbá poznámka s tím constem. Pokud si je jistý, že z jeho funkce to vypadne ve stejné podobě jako to do ní vlezlo, ale nemůže použít const, protože ta funkce s tím něco dělá a pak to dá do pořádku, mohl by to myslím přetypovat na const. Ale obecně tohle je hodně neobvyklý případ, většinou když funkce zaručuje, že ji proměnná opustí nezměněná, tak je to proto, že se do ní opravdu nezapisovalo a tak by to mohla být normálně konstanta.

[Sten]

STL je šablonová knihovna. To znamená, že když potřebujete jakoukoliv část upravit, nemusíte to celé přepisovat, stačí nahradit patřičnou část (třeba alokace, změna řazení, změna traits, ...), aniž byste musel obětovat rychlost třeba kvůli dynamic dispatch. Když se podíváte na Boost, zjistíte, že vypadá a funguje úplně stejně — a rozhodně to není tím, že by jeho autoři byli masochisti. Ale ona spousta takzvaných C++ programátorů vlastně programuje C with Classes a šablony (což jsou základní stavební prvek C++) vůbec neumí.

To máte spíš blbý kompilátor. Mě kompilátor „std::map<std::string, std::string>“ také tak hlásí, protože respektuje typedefy.

[JS]

C++ je dobrý jazyk, ale vyžaduje praxi, protože půlka jeho vlastností je určena pro méně než jedno procento dobře navrženého kódu (např. pointerová aritmetika nebo private členové).

Nebylo by pak lepsi rozdelit jej na 2 dobre spolupracujici jazyky, a tu pulku umistit do toho nizkourovnoveho?

Ale ja to chapu. Podle me C++ melo sve misto v historii jako urcity meziclanek - jazyk na psani komplikovanych aplikaci v dobe, kdy kompilatory byly jeste v plenkach. Mista, kde se opravdu hodi nasadit C++ - slozity program, ktery musi byt zaroven rozumne rychly - dost ubyvaji, namatkou jeste treba herni enginy.

(Na druhou stranu, Common Lisp tyto problemy resil taky. I kdyz ta nizka uroven mohla byt v nem trochu lepsi.)

[vlastagf]

D jsem videl jen zrychliku, ale kdyz jsem se tak rozhlizel, v cem by se mi libilo delat, D bylo na prvnim miste.

[optik]

D mi dost připadá jako staticky typovaný Perl, je tam strašně moc možností jak něco udělat, můžete a nemusíte používat GC, můžete psát skoro funkcionálně, nebo procedurálně atd. to už radši to Go nebo Javu. Až bude mít D podporu pro 64 bit na Win i Linuxu, tak se o tom dá začít uvažovat.

[----]

ale on má - unstable v DMD 2.052 (ještě není venku, win, mac, linux, bsd) a stable v GDC (na win s mingw, na linuxu/bsd/.. s klasickým gcc)

[kos]

GC v Go přináší stejné výhody, ale i pochopitelně i shodné nevýhody jako v cca každém jiném GC jazyku. Pocit, že na uvolňování paměti lze z hlediska programátora zapomenout, je oprávněný jen z velmi malé části.

Ze statistik o tvorbě programů vyplývá něco jiného. GC se zavádí právě kvůli problémům programátorů s uvolňováním paměti.

Nedobře napsaný kód v libovolném GC jazyce generuje pro GC zbytečně mnoho práce (třeba alokace v cyklu, kterou ale přitom lze vytknout před něj). Za to se platí zpomalením/zpomalováním/přerušováním běhu aplikace a zvýšenými nároky na zdroje systému. Dva funkčně shodné programy v GC jazyce se mohou lišit až příliš snadno na škále od perfektně vyhovující aplikace až po program, který pro soustavný trashing není použitelný vůbec k ničemu, tedy pokud nepočítáme účinnou „výrobu“ frustrace jeho nešťastného uživatele.

Tohle není věc specifická pro jazyky s GC. Tuhle chybu může udělat i vývojář v jazyku bez GC.

[littleli]

Ano, navíc paradoxně alokace v cyklu není to největší zlo. Největší zlo bude až když dojde k stop-the-world a program se kvůli předešlým excesivním alokacím zbytečně zastaví, aby mohlo dojít k úklidu.