abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 19:22 | Nová verze

Ondřej Filip, výkonný ředitel sdružení CZ.NIC, oznámil vydání verze 2.0.0 open source routovacího démona BIRD (Wikipedie). Přehled novinek v diskusním listu a v aktualizované dokumentaci.

Ladislav Hagara | Komentářů: 0
dnes 09:22 | Pozvánky

V Praze dnes probíhá Konference e-infrastruktury CESNET. Na programu je řada zajímavých přednášek. Sledovat je lze i online na stránce konference.

Ladislav Hagara | Komentářů: 1
9.12. 20:11 | Nová verze

Byl vydán Debian 9.3, tj. třetí opravná verze Debianu 9 s kódovým názvem Stretch a Debian 8.10, tj. desátá opravná verze Debianu 8 s kódovým názvem Jessie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 9 a Debianu 8 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 0
9.12. 00:44 | Nová verze

Po 6 měsících vývoje od vydání verze 0.13.0 byla vydána verze 0.14.0 správce balíčků GNU Guix a na něm postavené systémové distribuce GuixSD (Guix System Distribution). Na vývoji se podílelo 88 vývojářů. Přibylo 1 211 nových balíčků. Jejich aktuální počet je 6 668. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 3
8.12. 21:33 | Nová verze

Po půl roce vývoje od vydání verze 5.9 byla vydána nová stabilní verze 5.10 toolkitu Qt. Přehled novinek na wiki stránce. Současně byla vydána nová verze 4.5.0 integrovaného vývojového prostředí (IDE) Qt Creator nebo verze 1.10 nástroje pro překlad a sestavení programů ze zdrojových kódů Qbs.

Ladislav Hagara | Komentářů: 0
7.12. 11:11 | Komunita

Naprostá většina příjmů Mozilly pochází od výchozích webových vyhledávačů ve Firefoxu. Do konce listopadu 2014 měla Mozilla globální smlouvu se společností Google. Následně bylo místo jedné globální smlouvy uzavřeno několik smluv s konkrétními vyhledávači pro jednotlivé země. V USA byla podepsána pětiletá smlouva s vyhledávačem Yahoo. Dle příspěvku na blogu Mozilly podala společnost Yahoo na Mozillu žalobu ohledně porušení této

… více »
Ladislav Hagara | Komentářů: 0
7.12. 05:55 | Zajímavý článek

V Londýně probíhá konference věnovaná počítačové bezpečnosti Black Hat Europe 2017. Průběžně jsou zveřejňovány prezentace. Videozáznamy budou na YouTube zveřejněny o několik měsíců. Zveřejněna byla například prezentace (pdf) k přednášce "Jak se nabourat do vypnutého počítače, a nebo jak v Intel Management Engine spustit vlastní nepodepsaný kód". Dle oznámení na Twitteru, aktualizace vydaná společností Intel nevylučuje možnost útoku.

Ladislav Hagara | Komentářů: 5
7.12. 04:44 | Komunita

Virtualizační nástroj GNOME Boxy ve Fedoře 27 umožňuje jednoduše stáhnout a nainstalovat Red Hat Enterprise Linux, který je pro vývojáře zdarma. Vývojová verze GNOME Boxy již umožňuje jednoduše stáhnout a nainstalovat další linuxové distribuce. Ukázka na YouTube. Seznam distribucí a jejich verze, nastavení a cesty k ISO obrazům je udržován v knihovně a databázi libosinfo (GitLab).

Ladislav Hagara | Komentářů: 0
7.12. 03:33 | Nová verze

Google Chrome 63 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 63.0.3239.84 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře. Opraveno bylo 37 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 10
6.12. 22:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 147. brněnský sraz, který proběhne v pátek 15. prosince od 18:00 hodin v restauraci Severka na rohu Tučkové a Zahradníkové.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 951 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Google Go – co najdeme ve stavebnici

    1. 3. 2011 | Jan Mercl, Ondřej Surý | Programování | 6478×

    předchozím dílu seriálu byl představen stále ještě nový (2009) jazyk Go společnosti Google. Dnes se budeme stručně (opravdu) věnovat některým sémantickým konstrukcím jazyka Go.

    Obsah

    Hodnoty, ukazatele a referenční typy

    link

    Jazyk používá hodnoty a ukazatele velmi podobně jako jazyk C a naopak velmi odlišně než např. Java. Mírně rozvinutý příklad z tutoriálu:

    type T struct { a, b int }
    // klíčové slovo var uvádí seznam deklarací a jejich typ.
    // deklarace může být následována operátorem přiřazení '=' a inicializátorem
    var t *T = new(T) // new(T) je v prvním přiblížení shodné s calloc(1, sizeof(T))
    var u = new(T) // dtto, typ 'u' je v tomto případě zděděn z jeho inicializátoru
    
    // nebo více idiomaticky
    // ':=' je deklarace proměnné (se zděděním typu),
    // proto pouze současně s inicializátorem
    t := new(T) 
    u := t // 'u' nyní ukazuje na stejnou instanci T jako ukazatelová proměnná 't'
    v := *t // 'v' nyní obsahuje kopii obsahu na který odkazuje 't'
    w := &v // 'w' nyní ukazuje na 'v'
    i := (*t).a // deklarujeme a inicializujeme 'i' typu 'int'
                    // s explicitní dereferencí 't'
    
    // totéž idiomaticky
    i := t.a
    

    Uživatelské referenční typy (jako java.lang.Object a všichni jeho potomci) ve smyslu možnosti jejich přímé deklarace neexistují. Programátorem deklarované typy v Go jsou vždy buď hodnotou („v“ výše) nebo ukazatelem („t“, „u“ a „w“ výše). Operátor získání adresy (&) a dereference (*) je nutné v Go psát a je tedy vždy explicitně uvedeno, jakého typu (hodnota vs ukazatel) je výraz s jedním z těchto operátorů. Jako výjimka z tohoto pravidla vypadá poslední řádek kódu výše. V tomto specifickém případě jazyk dovoluje programátorovi nebýt explicitní (a ušetřit pár úhozů do klávesnice), ale jenom proto, že samotné 't.a' nemá vlastně žádný sémantický obsah. 't' je ukazatel, nikoli struktura a selektor '.' nemá co „selektovat“. Ve všech ostatních případech, kdy by takováto „pomoc“ kompilátoru/jazyka mohla vést k nejednoznačnému výkladu, se vždy a všude v Go vyžaduje explicitní zápis/použití adresních operátorů.

    Přesto referenční typy v Go vlastně existují, ale pouze v případě některých předdefinovaných, potenciálně generických objektů (mapa, řetězec, řez, kanál, …). Uživateli jazyka se tyto entity jeví jako hodnoty (tj. lze na ně například i normálně odkazovat ukazatelem), mají ale vždy referenční sémantiku. Pro příklad: pokud je m proměnná typu map[tkey]tvalue (golang.org/doc/go_spec.html#Map_types), pak po a = m jsou modifikace mapy ve stylu a[key] = value viditelné i přes hodnotu m, tj. m[key] nyní vrací value. Možná je/bude referenční sémantika ještě lépe vidět na tomto příkladu:

    var a = []int{1, 2, 3}
    b := a
    b[0] = 9
    println(a[0], a[1], a[2]) // vypíše '9 2 3'

    Ukazatel v Go smí být nil (hodnota nil se typicky používá jako sentinel). Nil je pro přiřazení a porovnání typově kompatibilní s ukazatelem na jakýkoli typ (a pro pohodlí programátora i s některými zabudovanými a/nebo „referenčními“ typy: mapa, řez, rozhraní, funkce, kanál).

    Aritmetika ukazatelů v Go neexistuje. Tento nástroj je v C mocným prostředkem pro některé oblasti systémového programování, současně ale potenciálně dosti nebezpečnou hračkou. Vůbec nejde jen o začínající nebo lajdácké programátory, záludné chyby v aritmetice ukazatelů v C se nevyhýbají žádnému programu napsanému lidskou bytostí. 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.

    Řetězce, pole a řezy (slices)

    link

    Předdefinovaný typ string je podložen polem bajtů. Jazyk i standardní knihovna podporuje řetězce kódované v UTF-8 a jejich převody na pole Unicode codepointů (zjednodušeně celé číslo v rozsahu 0 až 0x10FFFF, které může ale vždy nemusí být kódem nějakého znaku) a zpět. Řetězec je, podobně jako třeba v Javě, imutabilní (neměnný), ale ve všem ostatním se chová jako []byte, tj. řez bajtů. Je to ovšem samostatný typ, který není pro přiřazení kompatibilní s []byte.

    Řezy (slices) jsou značně podobné analogickým objektům např. v Pythonu. Jednou větou – řez je „pohled“ na nějaké pole s přidanou informací o začátku a délce řezu. Opět připomeňme referenční sémantiku řezů. Všechny různé řezy jednoho pole přistupují stále k tomu jednomu stejnému poli. Kde je tato vlastnost na překážku tam je nutné obsah řezu zkopírovat, třeba pomocí vestavěných funkcí append a copy.

    // Použití append:
    s0 := []int{0, 0}
    s1 := append(s0, 2)        // append a single element     s1 == []int{0, 0, 2}
    s2 := append(s1, 3, 5, 7)  // append multiple elements    s2 == []int{0, 0, 2, 3, 5, 7}
    s3 := append(s2, s0...)    // append a slice              s3 == []int{0, 0, 2, 3, 5, 7, 0, 0}
    
    // Použití copy:
    var a = [...]int{0, 1, 2, 3, 4, 5, 6, 7}
    var s = make([]int, 6)
    var b = make([]byte, 5)
    n1 := copy(s, a[0:])            // n1 == 6, s == []int{0, 1, 2, 3, 4, 5}
    n2 := copy(s, s[2:])            // n2 == 4, s == []int{2, 3, 4, 5, 4, 5}
    n3 := copy(b, "Hello, World!")  // n3 == 5, b == []byte("Hello")
    

    Typ array je staré dobré pole se statickým typem, který obsahuje jeho délku a typ položky pole. Dynamická pole v Go neexistují, jejich funkčnost je nahrazena pomocí řezů. Pole/řez je v Go vždy jednorozměrné/ý, ale pochopitelně položkou pole/řezu může být i jiné pole nebo řez. Tento mechanismus vytváření vícerozměrných polí Go sdílí například s Javou. Podstatným rozdílem je ovšem to, že v Javě typ pole neobsahuje jeho délku, pole v Javě jsou tedy víc podobná Go řezům.

    Složené/strukturované typy (structs)

    link

    Složené typy jsou velmi podobné jako v jazyce C a rozložení v paměti je úmyslně implementováno s ohledem na co největší kompatibilitu s C. Na rozdíl od C ale ve složených typech Go nenajdeme nic podobného jako „union“, tedy strukturu jejíž členové se mohou překrývat. Úplně stejně jako v případě aritmetiky ukazatelů je toto případ šikovné a mocné jazykové konstrukce, která je ale ve své standardní implementaci (entity různých typů sdílejí stejnou adresu v paměti) prakticky neslučitelná s žádným paměťově a typově bezpečným jazykem.

    Složené typy se velmi často používají v objektovém modelu Go (o pár kapitol níže), zde je jen nutno stručně podotknout, že strukturované typy lze zapouzdřit do dalších složených typů (jako v C), nejde přitom ale o mechanismus/sémantiku dědičnosti (jako v Javě).

    // Jednoduchý složený typ
    type T struct {
        name    string // jméno objektu
        value   int    // jeho hodnota
    }
    
    // Metoda T, její volání je např. s := instance_typu_T.String()
    func (t *T) String() string {
        return fmt.Sprintf("%s, %d", t.name, t.value)
    }
    
    // Schema základní kompozice typů
    type U struct {
        pair T
        next *U // další položka seznamu
    }
    
    // Schema kompozice s dědičností metod
    type V struct {
        T        // anonymní pole typu T, metody T jsou přístupné také z instance V
        next *V
    }
    
    func (v *V) Swap(t T) (result T) {
        v.T, result = t, v.T // na anonymní pole se odkazujeme jménem jeho typu
        return
    }
    

    Podrobněji ve specifikaci.

    Modulární programování a odkazy mezi moduly

    link

    Modul (v Go se nazývá package) se sestává z libovolného množství zdrojových souborů v rámci jednoho adresáře. Ve smyslu viditelnosti entit deklarovaných uvnitř modulu jsou hranice mezi soubory irelevantní, naopak externí entity jsou viditelné jen v rámci souboru, který je explicitně importuje, nikoli v celém modulu. Toto je příklad nenápadných pravidel, která mohou působit jako intuitivně nebo dokonce náhodně volená. Takový byl zhruba můj osobní dojem v době, kdy jsem se s nimi seznamoval. Jakmile ale Go projekt na kterém pracujete, začne mít desítky modulů a každý modul třeba i desítku zdrojových souborů, mohou vám snadno začít stejná pravidla připadat jako moc dobrá pomoc pro kodéra a najednou vidíte, že všechny ostatní možnosti by vedly k řadě potíží, jež se nás naštěstí díky autorům této části specifikace netýkají.

    Modul exportuje explicitně proměnné, typy, funkce/metody, konstanty.., které mají být viditelné zvenku poněkud neobvyklým, ale implementačně a v čitelnosti jednoduchým a účinným způsobem: všechny exportované entity mají identifikátory začínající velkým písmenem (Unicode kategorie Lu). V dobře psaném zdrojovém Go kódu jsou tedy zřetelně (bezkontextově) odlišitelné externí entity bez nutnosti konzultovat import klauzule a jimi odkazované moduly.

    Na straně uživatele modulu jsou všechny odkazy na externí entity standardně vždy s prefixem jmenného prostoru, např. name.Identifier, kde name je implicitně jméno package (import "fmt"; fmt.Printf("X")), ale lze použít alias (import alias "fmt"; alias.Printf("X")) nebo speciální alias, se kterým sice není prefix nadále potřeba, ale může docházet ke kolizím při vícero importovaných modulech (import . "fmt"; Printf("X")).

    Moduly mohou obsahovat libovolné množství inicializačních sekcí (func init()), takže inicializaci lze v rámci modulu jak centralizovat, tak inicializovat entitu v místě, kde je deklarovaná nebo spolu s jejími metodami apod. Co se víc hodí bude nejvíce záležet na konkrétním problému, který modul řeší, ale možnost volby je v tomto případě příjemná.

    Cyklické závislosti mezi moduly nejsou podporovány. K překrývání importovaných identifikátorů nedochází (s výjimkou importu s aliasem "."). Inicializační funkce modulů jsou při inicializaci aplikace volány v korektním pořadí dle jejich vzájemné závislosti.

    Správa paměti

    link

    Pro správu paměti používá Go garbage collector (GC). Explicitní uvolnění objektů z paměti není možné. K objektu lze registrovat funkci, která se později automaticky zavolá před jeho uvolněním pomocí GC. Problematika automatické správy paměti je samostatné téma na mnoho článků, ba i vědeckých prací, zde se jí proto nijak podrobně zabývat nebudeme.

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

    Paralelismus

    link

    Paralelismus je v Go integrální součást jazyka. Klíčovým slovem go se spustí paralelní vyhodnocení libovolného výrazu, kterým je samozřejmě i volání libovolné funkce nebo funkčního literálu (s případnou uzávěrou).

    Paralelismus je kooperativní (jde o koprogramy) s význačnou výhodou, že jednotlivé koprogramy v Go nejsou při provádění svázány pevně s vláknem, ve kterém byly vytvořeny. Pro tuto vlastnost se v Go koprogramy nazývají gorutiny.

    Gorutiny se liší od vláken dále významně i tím, že jsou velmi lehké. Jejich vytvoření a aktivace, rozhodování, zda je nutné gorutinu pozdržet, a přepínání kontextu probíhá v user landu (tj. v neprivilegovaném režimu procesoru, na x86 je to ring 3). Protože se předpokládá, že některé aplikace budou chtít někdy vytvářet enormní množství gorutin (řekněme silně zatížený databázový nebo webový server), jsou gorutiny implementovány se segmentovaným zásobníkem. Segment má například v implementaci pro x86_64 velikost 4 KB a zásobník se zvětšuje o další segment(y) až dle potřeby. Vytvořit například 100 000 gorutin může za příznivých okolností vyžadovat „jen“ 400 MB RAM, v případě stejného množství vláken nejspíše lze očekávat problémy nejen s požadavky na paměť.

    Například zde se uvádí, že pro typické desktop PC bude v POSIX vláknech (pthreads) implicitní velikost zásobníku přidělená vláknu mít velikost 2 MB. Pro výše uvedený počet gorutin bychom tedy (s)potřebovali 200GB paměti. Je možné při vytváření pthread vlákna chtít též jen podobnou velikost jako 4 KB v Go. Pokud ale některá vlákna budou potřebovat zásobník větší velikosti, tak dle konkrétní implementace pthreads nám systém může vyhovět jeho zvětšením. Protože ale zásobník pthread vlákna je obvykle paměťově souvislý (v Go nikoli), má OS s rozšiřováním velkého počtu zásobníků – i když bude chtít zvětšovat jen některé z nich, potíže při přidělování nových virtuálních adres. Pthread zásobník vlákna může (kvůli zachování platnosti dříve vytvořených ukazatelů na položky v zásobníku) růst jen směrem dolů, adresu jeho „horního konce“ už není možné dynamicky měnit. A připomeňme ještě, že standardní implementace pthreads přepíná mezi vlákny v privilegovaném režimu procesoru (kernel mode) a to je z hlediska času řádově náročnější než jinak podobné přepnutí, které používají gorutiny.

    Pro komunikaci mezi gorutinami se velmi doporučuje místo sdílených dat, které vyžadují explicitní synchronizaci (např. mutex), raději používat kanály. Kanály jsou staticky typované, s vyrovnávací frontou nebo bez (tj. asynchronní nebo synchronní).

    Zasílání a čtení zpráv z kanálů je samo o sobě z hlediska paralelismu bezpečné. Při dodržení konvence, při které gorutina odeslanou zprávou nijak dále nepoužívá, nejlépe tak, že se zbaví jakékoli reference na ni a naopak gorutina na straně příjmu modifikuje jen přijaté zprávy a lokální entity, pak pro korektní paralelní zpracování problému není nutné udělat nic dalšího a je to z hlediska programátora velmi pohodlné; snižuje se počet chyb, kterých se může dopustit. Pochopitelně ale toto samo o sobě nemůže zabránit například dead locku a/nebo jiným nekorektnostem návrhu/implementace.

    Pro shrnutí výše uvedených konceptů používá Go slogan v záhlaví (viz též golang.org a blog.golang.org). Vypůjčíme si ještě malou ukázku z Effective Go:

    c := make(chan int)  // Alokace nového kanálu.
    // Spusť třídění v nové gorutině a až bude dokončeno,
    // pošli o tom zprávu komunikačním kanálem.
    go func() {
        list.Sort()
        c <- 1  // Pošli zprávu/signál dokončení,
                // v tomto případě na zasílané hodnotě nezáleží.
    }()
    dělejPoNějakýČasNějakouJinouUžitečnouPráci()
    <-c   // Počkej na dokončení třídění, přijatou hodnotu z komunikačního kanálu
          // v tomto případě ignorujeme. Zajímá nás jen synchronizace gorutin,
          // tj. událost příjmu z kanálu => list je setříděn.
    

    Hezkou a myslím dost didaktickou ukázkou již o trochu složitějšího využití paralelismu gorutin, s důrazem na způsob uvažování nad návrhem konstrukce, je paralelní implementace Eratosthenova síta. Příklad je to skutečně jenom výukový, ve skutečnosti tato implementace začne rychle ztrácet dech i v porovnání s klasickým sekvenčním programem. „Profi“ implementace stále stejného zadání (generování všech prvočísel do daného limitu) v Go s využitím paralelismu gorutin je k vidění třeba tady a autor uvádí, že naměřil na svém 2,4GHz Core i5 stroji čas pro určení prvních 50 847 534 prvočísel menších než 1 000 000 000 v hodnotě kolem 0,7 sekundy.

    Distribuované zpracování

    link

    Součástí standardní knihovny, je také modul netchan. S jeho pomocí lze vytvářet složitější systémy pro distribuované zpracování tím, že netchan „protahuje“ koncept kanálu přes síťové připojení. Možnosti paralelismu v Go se tím dále rozšiřují a v tomto případě jsou důvody očekávat dobrou škálovatelnost současně s malými nároky na množství kódu, který takovou distribuovanou architekturu implementuje. Jde ve své podstatě o ekvivalent síťových socketů, ale s typovou podporou (přesněji řečeno pomocí interface{} a typově bezpečného castingu) uživatelsky definovaných entit.

    Shrnutí

    link

    V dnešním textu jsme poprvé pootevřeli krabici s novou hračkou a prohlédli si některé z větších stavebních prvků Dupla, ehm... Go. V příští části se pokusíme plynule přejít na přehled používání kostek LeGo (např. objektové programování, rozhraní, uzávěry, ...).

    Laboratoře CZ.NIC

    O autorech

    Jan Mercl a Ondřej Surý pracují v Laboratořích CZ.NIC, výzkumném a vývojovém centru správce české národní domény.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    1.3.2011 13:08 stewe
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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
    1.3.2011 13:33 vvv
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    + 1
    Bystroushaak avatar 1.3.2011 14:52 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    Navíc je to hnusná syntax jak prdel. Kdybych chtěl nějakou obludu, tak jdu dělat v delphi.
    1.3.2011 15:46 Sten
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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).
    1.3.2011 16:10 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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#
    Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
    1.3.2011 16:36 Sten
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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).
    5.3.2011 12:30 littleli
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.
    1.3.2011 17:47 pht | skóre: 48 | blog: pht
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.
    In Ada the typical infinite loop would normally be terminated by detonation.
    1.3.2011 18:35 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.
    3.3.2011 09:34 imploder | skóre: 11
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.
    3.3.2011 10:27 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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).
    q66 avatar 1.3.2011 19:05 q66 | skóre: 32 | blog: Q's CZ devblog
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.
    q66 avatar 1.3.2011 19:08 q66 | skóre: 32 | blog: Q's CZ devblog
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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ě.
    1.3.2011 19:36 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    Bystroushaak avatar 1.3.2011 21:24 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    :). 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 :).
    q66 avatar 1.3.2011 22:08 q66 | skóre: 32 | blog: Q's CZ devblog
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    no, ono C++ stojí z větší části za h*vno (hlavně STL), D je daleko líp designovaný (D2)
    Bystroushaak avatar 1.3.2011 22:20 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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..
    q66 avatar 1.3.2011 22:58 q66 | skóre: 32 | blog: Q's CZ devblog
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    IMO objektivní pravdivé informace o C++ jsou hezky shrnuty zde: http://yosefk.com/c++fqa/
    Bystroushaak avatar 1.3.2011 23:11 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    Jo, to je vcelku výstižné.
    2.3.2011 13:44 __dark__
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    Aneb velmi objektivní a neutrální informace od C++ hatera.
    2.3.2011 19:07 Sten
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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é).
    q66 avatar 2.3.2011 19:27 q66 | skóre: 32 | blog: Q's CZ devblog
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici

    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) avatar 2.3.2011 20:04 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.
    q66 avatar 2.3.2011 20:26 q66 | skóre: 32 | blog: Q's CZ devblog
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici

    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) avatar 2.3.2011 22:04 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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...
    q66 avatar 2.3.2011 22:09 q66 | skóre: 32 | blog: Q's CZ devblog
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici

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

    q66 avatar 2.3.2011 22:16 q66 | skóre: 32 | blog: Q's CZ devblog
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    ok, sorry, špatně jsem pochopil kontext - v podstatě jsem zopakoval, co jsi řekl. :-D
    2.3.2011 20:45 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    Luboš Doležel (Doli) avatar 2.3.2011 21:52 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    Co je na něm přesně mizerného?
    q66 avatar 2.3.2011 22:13 q66 | skóre: 32 | blog: Q's CZ devblog
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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ě.
    2.3.2011 23:44 Seki | Michalovce/Brno
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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).
    q66 avatar 3.3.2011 00:45 q66 | skóre: 32 | blog: Q's CZ devblog
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici

    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")

    2.3.2011 23:30 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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í.
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    Luboš Doležel (Doli) avatar 2.3.2011 23:39 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.
    4.3.2011 13:02 imploder | skóre: 11
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.
    4.3.2011 14:27 __dark__
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    template<typename T>
    class Something {
      static void func(void)
      {
        T::tady bude asi problém;-)
      }
    };
    
    4.3.2011 17:07 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    4.3.2011 23:14 imploder | skóre: 11
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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ší.
    5.3.2011 00:28 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    5.3.2011 01:17 imploder | skóre: 11
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.
    4.3.2011 13:09 imploder | skóre: 11
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.
    4.3.2011 12:17 Sten
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.
    3.3.2011 06:04 JS
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.)
    4.3.2011 12:31 vlastagf | skóre: 11
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    D jsem videl jen zrychliku, ale kdyz jsem se tak rozhlizel, v cem by se mi libilo delat, D bylo na prvnim miste.
    6.3.2011 15:34 optik
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.
    q66 avatar 6.3.2011 16:58 q66 | skóre: 32 | blog: Q's CZ devblog
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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)
    2.3.2011 07:15 kos
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.
    5.3.2011 12:33 littleli
    Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
    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.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.