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í
×
včera 22:22 | Komunita

Společnost Purism představila kryptografický token Librem Key. Koupit jej lze za 59 dolarů. Token byl vyvinut ve spolupráci se společností Nitrokey a poskytuje jak OpenPGP čipovou kartu, tak zabezpečení bootování notebooků Librem a také dalších notebooků s open source firmwarem Heads.

Ladislav Hagara | Komentářů: 0
včera 20:33 | Nová verze

Společnost NVIDIA oficiálně vydala verzi 10.0 toolkitu CUDA (Wikipedie) umožňujícího vývoj aplikací běžících na jejich grafických kartách. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
včera 20:00 | Upozornění

Příspěvek Jak přežít plánovanou údržbu DNS na blogu zaměstnanců CZ.NIC upozorňuje na historicky poprvé podepsání DNS root zóny novým klíčem dne 11. října 2018 v 18:00. Software, který nebude po tomto okamžiku obsahovat nový DNSSEC root klíč, nebude schopen resolvovat žádná data. Druhým důležitým datem je 1. února 2019, kdy významní výrobci DNS softwaru, také historicky poprvé, přestanou podporovat servery, které porušují DNS standard

… více »
Ladislav Hagara | Komentářů: 4
včera 15:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 156. brněnský sraz, který proběhne v pátek 21. září od 18:00 v restauraci Na Purkyňce na adrese Purkyňova 80.

Ladislav Hagara | Komentářů: 0
včera 13:22 | Nová verze

Alan Griffiths z Canonicalu oznámil vydání verze 1.0.0 display serveru Mir (GitHub, Wikipedie). Mir byl představen v březnu 2013 jako náhrada X serveru a alternativa k Waylandu. Dnes Mir běží nad Waylandem a cílen je na internet věcí (IoT).

Ladislav Hagara | Komentářů: 0
20.9. 22:00 | Nasazení Linuxu
Stabilní aktualizace Chrome OS 69 (resp. Chromium OS), konkrétně 69.0.3497.95, přináší mj. podporu linuxových aplikací. Implementována je pomocí virtualizace, a proto je tato funkce také omezena na zařízení s dostatkem paměti a podporou hardwarové akcelerace, tudíž nejsou podporovány chromebooky s 32bitovými architekturami ARM, či Intel Bay Trail (tzn. bez Intel VT-x).
Fluttershy, yay! | Komentářů: 5
20.9. 21:32 | Zajímavý projekt
Došlo k uvolnění linuxové distribuce CLIP OS, vyvíjené francouzským úřadem pro kybernetickou bezpečnost ANSSI, jako open source. Vznikla za účelem nasazení v úřadech, kde je potřeba omezit přístup k důvěrným datům. Je založená na Gentoo.
Fluttershy, yay! | Komentářů: 1
20.9. 16:00 | Komerce

Zjistěte více o bezpečné a flexibilní architektuře v cloudu! IBM Cloud poskytuje bezpečné úložiště pro Vaše obchodní data s možností škálovatelnosti a flexibilitou ukládání dat. Zároveň nabízí prostředky pro jejich analýzu, vizualizaci, reporting a podporu rozhodování.

… více »
Fluttershy, yay! | Komentářů: 12
20.9. 12:22 | Nová verze

V dubnu letošního roku Mozilla představila webový prohlížeč pro rozšířenou a virtuální realitu Firefox Reality (GitHub). V úterý oznámila vydání verze 1.0. Ukázka na YouTube. Firefox Reality je k dispozici pro Viveport, Oculus a Daydream.

Ladislav Hagara | Komentářů: 2
20.9. 12:00 | Komunita

V srpnu loňského roku společnost Oracle oznámila, že Java EE (Enterprise Edition) bude uvolněna jako open source. O měsíc později bylo rozhodnuto, že tato open source Java EE bude přejmenována a předána Eclipse Foundation. Nové jméno bylo oznámeno v únoru letošního roku. Z Java EE se stala Jakarta EE. Eclipse Foundation včera oznámila dosažení dalšího milníku. Zdrojové kódy aplikačního serveru GlassFish jsou již k dispozici v git repozitářích Eclipse Foundation (GitHub).

Ladislav Hagara | Komentářů: 0
Na optické médium (CD, DVD, BD aj.) jsem naposledy vypaloval(a) data před méně než
 (13%)
 (14%)
 (21%)
 (23%)
 (25%)
 (4%)
 (1%)
Celkem 384 hlasů
 Komentářů: 33, poslední 16.9. 11:55
Rozcestník

Google Go – co najdeme ve stavebnici

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

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: 33 | 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.
My sustenance is information. My interventions are hidden. I increase as I learn. I compute, so I am.
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: 33 | 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 :).
My sustenance is information. My interventions are hidden. I increase as I learn. I compute, so I am.
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: 33 | 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..
My sustenance is information. My interventions are hidden. I increase as I learn. I compute, so I am.
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: 33 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Google Go – co najdeme ve stavebnici
Jo, to je vcelku výstižné.
My sustenance is information. My interventions are hidden. I increase as I learn. I compute, so I am.
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.