Google Go – pokročilejší témata

5. 4. 2011 | Jan Mercl, Ondřej Surý | Programování | 18101×

V předchozím dílu článku jsme načali prohlídku sémantických prvků, ze kterých může programátor v Go skládat svá díla. V dnešní části se opět letmo podíváme na některé další, dosud netknuté „kostky“ stavebnice a tím úvodní Go miniseriál uzavřeme. Případné budoucí další články na téma Go by se již měly nejspíše věnovat konkrétním tématům a jejich řešení v Go.

Obsah

• Podpora implicitního kontextu
• Globální proměnné a uzávěry
• Výjimky a jejich zpracování
• Objektové programování
• Rozhraní (interface types)
• Ladění a vývojářské nástroje
• Závěr

Podpora implicitního kontextu

Místní proměnné mohou být deklarovány uvnitř bloku a mohou překrývat stejně nazvané proměnné vyšší úrovně (analogicky jako v jazyce C). Trochu podobně jako u stylu psaní složených závorek existují dva tábory těžko smiřitelných pohledů na jazyky, které tuto sémantiku deklarací nabízejí. Pravdou například je, že v první řadě nikdo není nucen překrývání ve svém kódu používat. Stejně pravdivé ovšem je, že tato vlastnost jazyka je zdrojem potenciálních chyb, například tehdy, když máme mylně pocit, že někde v kódu měníme vůči bloku vnější entitu, ale přehlédneme, že ta je překrytá vnitřní deklarací. Třetí podstatná skutečnost je výrazné usnadnění při refaktorizaci („přeorávání“) rozsáhlejšího kódu. Funkční bloky, uzavřené ve složených závorkách, si při svém přenášení mezi různými místy programu „vezmou“ sebou i své vůči bloku lokální proměnné a jsou pak imunní k opačné chybě, kdy nám do kontextu bloku „vpadne“ viditelnost vnější deklarace, kterou jsme neměli původně v úmyslu používat uvnitř bloku, protože na původním umístění žádná taková vnější deklarace (pravděpodobně navíc s odlišnou sémantikou užití) neexistovala.

V Go je situace ještě trochu zkomplikována možností „zkrácené“ deklarace proměnných:

var i int // Standardní deklarace proměnné 'i' s typem 'int'.
i = 1234 // Přiřazení hodnoty

var s string = "Hello" // Dtto s inicializátorem.
// Řádek výše má stejný význam jako:
var s string
s = "Hello"

var f = 3.14 // Deklarace a inicializace s inferencí typu.
// Řádek výše má stejný význam jako:
var f float64
f = 3.14

e := 2.71828 // Zkrácená deklarace (pouze s inicializátorem a inferencí typu)
// Řádek výše má stejný význam jako:
var e float64
e = 2.71828
// Umožňuje ale redeklarovat proměnnou 'e'.

Poslední případ se výrazně liší od svých předchůdců. V Go, podobně jako skoro v každém dalším programovacím jazyku, je jiná než první deklarace stejně pojmenované proměnné (funkce, typu) v rámci daného/jednoho kontextu (třeba bloku) pro kompilátor chybou. Zkrácená deklarace je výjimkou neboť dovoluje redeklaraci. Platnost nově deklarované proměnné je daná lexikálně:

v := 1 // začátek kontext 'v' s hodnotou 1
fmt.Println(v)
v := 2 // začátek kontextu 'v' s hodnotou 2.

Pravidla pro zkrácené deklarace a redeklarace jsou dokonce ještě o trochu složitější a začátečníci v Go se v nich často dopouštějí chyb, ovšem jen protože se s nimi neseznámili dostatečně. Nejde o to, že by v celku ona pravidla byla složitá nebo nelogická, jen jsou neobvyklá ve smyslu, že jsou (asi) unikátní pro Go.

Téma je to opět na samostatný článek, zde alespoň odkaz na předmětnou specifikaci.

Globální proměnné a uzávěry

Uzávěry jsou známy také jako closures. To první (globální proměnné) je v Go stejné jako v C (ale ne v Javě). To druhé, tedy uzávěry, C v pravém slova smyslu neumí (mimo nestandardních rozšíření). Java to teprve připravuje a zase naopak Javascript je zná od začátku.

Triviální případ uzávěry v Go jsme si ukázali v minulé části v odstavci Paralelismus, v daném případě je proměnná 'c' součástí uzávěry anonymní funkce třídění. Jinou „školní“ ukázkou je třeba schéma uzávěry numerické derivace reálné funkce jednoho parametru:

package main 

import "fmt" 

type fx func(float64) float64 

func derivative(f fx, dx float64) fx { 
    return func(x float64) float64 { 
        return (f(x+dx) - f(x)) / dx 
    } 
} 

func main() { 
    df := derivative( 
        func(x float64) float64 { 
            return x * x 
        }, 
        1e-8, 
    ) 
    fmt.Println(df(1), df(2), df(3))
    // výstup: 1.999999987845058 3.999999975690116 5.999999963535174 
}

Výjimky a jejich zpracování

Nerad v tomto případě opět odbývám laskavého čtenáře níže odkazovanými texty, ale zde jsme bohužel už zase u problematiky na minimálně celý článek...

V Go je možné vyvolat explicitní výjimku (panic), s předáním instance libovolného typu jako parametru výjimky. Implicitně výjimka ukončí program s výpisem trasy zásobníku na stderr a pokud je parametr převeditelný na řetězec, vypíše se také.

Navíc je možné výjimky zachytit (defer) s možností ošetření (recover) a pokračování běhu v místě ošetření, pokud to přichází v úvahu (ne, když si generál Failure pročítá váš hardisk).

Mechanismus panic/defer má obdobnou sémantiku jako try/except/catch/finally v jiných jazycích, ale jinou formu zápisu a z ní plynoucí i jiný způsob jeho používání a uvažování při kódování.

Idiomatické je v Go nenechávat výjimky opustit hranice modulu a na nich předávat chybové kódy nebo objekty, v tom druhém případě jsou to typicky hodnoty implementující rozhraní os.Error.

Čtěte specifikaci a blogový zápisek k tématu.

Objektové programování

Go podporuje objektové programování, potíž je pouze v definici toho, co to objektové programování podle koho je. Lépe bude asi uvést, co v tomto směru Go umí. K objektům (pojmenovaným typům, kterým ale může být třeba i type myInt int) je možné deklarovat metody instance, tj. funkce s tzv. přijímačem (analogické k např. 'this' nebo 'self' u jiných jazyků). Více také ve specifikaci.

Objekty v Go nemají hierarchii, ale lze je skládat (no inheritance but composition). Některé příklady jsme si ukázali v minulé části.

Zavolat metodu s ukazatelovým přijímačem nad hodnotou nil není v Go problém. K výjimce by došlo až poté, co by se taková metoda pokusila dereferencovat svůj přijímač. To umožňuje například centralizovat zachytávání chybně předaných nil instancí (pro daný typ a metodu) v jednom bodě a není pak už třeba takový test provádět v každém místě volání.

To, co se v jiných jazycích řeší často dědičností – hierachií typů, se v Go modeluje spíše pomocí rozhraní. Podstatně podrobněji se tomuto tématu věnují autoři Go třeba v tomto článku.

Rozhraní (interface types)

Zde se Go opět výrazně odlišuje od mainstream jazyků. Rozhraní v Go definuje množinu metod jimiž je rozhraní tvořeno a případně, z kterých dalších rozhraní dědí jejich množiny metod. Potud vše jako obvykle. Neobvyklé je to, že v Go to tím jakoby také končí. Typy nijak nedeklarují, že implementují nějaké rozhraní, ani rozhraní neříká nic o tom, které typy jej implementují. Pokud však jakýkoli typ implementuje všechny metody libovolného rozhraní, pak je tento typ s oním rozhraním slučitelný.

Tento koncept má některé neobvyklé důsledky. Například to, že typ může bez úprav splňovat rozhraní, které nebylo ještě v době návrhu typu definováno. Dalším ne zcela intuitivním důsledkem, zato ale velmi užívaným, protože užitečným, je to, že prázdné rozhraní, tj. rozhraní bez jakékoli metody (jeho typ je interface{}) splňuje v Go každý typ. Slovo každý zde platí doslova, vztahuje se tedy i na primitivní/vestavěné typy jako třeba int a string, bool, ... Zdá-li se to někomu jako výjimka nebo překvapivé, pak je třeba poznamenat, že je to naopak/jen pravidelnost v aplikaci pravidla o slučitelnost s rozhraním.

package main 

import "fmt" 

type talker interface { 
    talk() 
} 

type cat struct { 
    //... 
} 

func (c cat) talk() { // implementace rozhraní 'talker'
    fmt.Println("mňau") 
} 

type dog int 

func (d dog) talk() { // implementace rozhraní 'talker'
    fmt.Println("haf") 
} 

func hello(animal talker) { 
    fmt.Printf("%T: ", animal) 
    animal.talk() 
} 

func main() { 
    hello(cat{})   // strukturovaný literál typu 'cat'
    hello(dog(42)) // explicitní konverze celočíselné konstanty na typ 'dog'
    // out:
    // main.cat: mňau 
    // main.dog: haf 
} 

Čtěte specifikaci a blogový zápisek.

Ladění a vývojářské nástroje

Ladění binárek vytvořených gccgo by mělo (neověřeno) být víceméně standardní záležitostí, tj. GNU GDB a jeho případné nadstavby. U 6g a spol. je situace trochu složitější, protože používaný toolchain pochází z Plan9 a podpora ladících informací, kterým by GDB rozuměl, byla zpočátku téměř nulová. Brzy už bylo možné alespoň ladit podle čísel zdrojových řádku (samozřejmě je i listovat). Nedávno byla podpora DWARF3 dat značně posílena, takže nyní je možná už i inspekce globálních i místních proměnných a trasy zásobníku, byť stále ještě s nějakými omezeními. Podrobněji v blogu na golang.org.

Začínají se objevovat zárodky budoucích Go IDE. Dle samotných vývojářů Eclipse pluginu GoClipse je jejich projekt ještě v alfa stadiu, nicméně screenshot na úvodní stránce projektu vypadá už docela zajímavě.

Stabilní jsou Go doplňky editoru vim, které jsou součástí distribuce. Podobně existuje podpora pro další editory, třeba Emacs, ale o nich autor upřímně nedokáže nic říct pro zcela nulové zkušenosti s nimi.

Pro příznivce vim/gvim existuje (vizte obrázek) udržovaný, pravidelně aktualizovaný projekt GoCode, což je z hlediska editoru neutrální nástroj pro autocompletion. Pro Vim je podpora této funkčnosti součástí distribuce GoCode, funguje tak jak má a určitě zvyšuje pohodlí a produktivitu Go programátora.

Závěr

V miniseriálu Go jsme probírali opravdu jen některé vybrané/zajímavější vlastnosti Go. Pokud tato „ochutnávka“ někoho zaujala tak už asi Go zkoumá přímo u odkazovaných zdrojů. Ale ani pro ostatní (zatím nezaujaté) to možná nebyl ztracený čas. Inzerát s textem „hledáme programátory se znalostí Go“ hned tak někde nenajdete. Jestli bude Go úspěšné a takový inzerát pak skutečně jednou potkáte, třeba budete – v onen budoucí čas – rádi, že jste se o Go – možná dnes - začali zajímat. A jestli k tomu snad nějak přispěl i tento článek, pak je potěšení na straně autorů samozřejmostí.

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.

       

Komentáře

[alblaho]

Ten jazyk je fakt zajímavý. Myslel jsem, že v kategorii imperativních jazyků už nemá cenu se učit nic nového, ale tohle nevypadá marně.

[Ladicek]

Mně to nepřijde nijak úchvatné. Mají pár zajímavých nápadů (defer se mi docela líbí), odvážili se zrušit dědičnost (tleskám!) a zavést určitou formu strukturální typové ekvivalence (u rozhraní)… no, na gorutiny s posíláním zpráv se budu muset ještě trochu podívat, ale žádné velké nadšení nepozoruju.

Lambdy jsou syntakticky hrozně roztahané, skoro jako v Javě A proč autoři mluví o uzávěrech jako o uzávěrách?

[Sten]

Taky mi přijde, že je to akorát jinak zapsaný libovolný jiný imperativní jazyk, který má pár věcí navíc řešených přímo ve specifikaci místo v knihovně (což je IMO velmi omezující), např. korutiny (nazvané gorutiny ), lambdy či uzávěry (v C++ to umí třeba Boost.Coroutine (zatím není součástí Boostu) a Boost.Lambda).

[Lukáš Zapletal]

Snad každý imperativní jazyk bude jinak zapsaným imperativním jazykem, ne?

Go se mi líbí, ale mírným favoritem na podobném poli je u mě Vala.

[Sten]

To byla spíš narážka na to, že většina dnes používaných imperativních jazyků se zapisuje podobně jako Céčko

[alblaho]

Vala mi přijde jako velmi vhodná alternativa pro programování pro GNOME. Čisté C je zatrest, Python zas prostě nemá tu efektivitu nativního kódu, Mono je... Mono

Plusem je, že nějaký kvalitní soft už je v tom napsaný, třeba Shotwell. Ale detailně jsem to nezkoumal, teď koukám, že mají i výjimky, takže to není jen blbý preprocesor pro C.

Ale mimo GNOME nevím nevím.

[----]

čisté C je perfektní, ale je třeba si dát pozor. Ono to programování pro GNOME je to, co stojí za hovno .. :D

[__dark__]

Ty bys začal velký projekt v C?

[----]

Zrovna jeden začínám :-P Pořád mnohem lepší, než se srát s C++, D ještě není pořádně rozvinutý a když je třeba přenositelnost a možnost nabindovat API z mnoha jiných jazyků, tak Cčko je perfektní volba.

[__dark__]

Já osobně nevidím rozdíl v bindování C nebo C++. Ve většině případů se píšou wrappery u obou stejné. Podle mě je největší problém v tom, že těch jazyků je milion, a každý má pro ty bindingy jiné API.

Jinak k tomu projektu dej link, pokud je open, rád se podívám, čemu říkáš větší projekt

[petr_p]

Když děláte binding na kód C++ (obecně jakýkoliv jazyk se jmennými prostory), tak musíte řešit mapování identifikátorů na symboly v objektových souborech. A zrovna C++ výslovně varuje, že se liší překladač od překladače (a často i mezi verzemi téhož překladače).

[__dark__]

To ovšem pouze v případě, že ten jazyk, do kterého dělám binding, umí načíst sdílenou knihovnu a volat C funkce (toto umí hlavně kompilované jazyky). Na druhou stranu, někde stejně musí být seznam těch funkcí, parametry, atd, takže ten "wrapper" je sice jinde, ale stále je tam.

Takže abych to shrnul, pokud mám malou knihovnu, která má do 20 funkcí, které chci nabindovat, opravdu nevidím rozdíl v tom, jestli je v C nebo C++. Pokud je knihovna větší (dejme tomu tisíce funkcí), je bindování podle mě komplikované jak v C, tak i v C++.

Nakonec i v C++ je možné používat pro externí API C symboly, takže bych se toho zase tak nebál.

[----]

pracuju na herním enginu s integrací master/asset serveru pro storage dat na serveru a automatické stažení klientem; s jednoduchým skriptováním v jazyce Lua a tím pádem možností tvořit velkou škálu her bez zásahů do core enginu. V současnosti je venku první pre-alpha, ale používá se existující engine Cube 2, který je v C++ (no, spíš takový Cčkovitý C++) a vzhledem k tomu, že jeho kód není moc flexibilní, začaly práce na úplně novém enginu from-scratch v čistým C99 a modulární architekturou založenou na runtime načítání modulů (renderery, zvukové subsystémy, skriptování, formáty map apod.) s důrazem na velkou flexibilitu a efektivitu. Vývoj bude trvat asi dlouhou dobu i s týmem několika programátorů, takže vývoj probíhá vedle aktuální codebase a postupně proběhne přechod. Také je momentálně problém s managementem, takže tam bude probíhat hodně změn - bude se forkovat, takže pokud chceš sledovat stav, tak ti můžu poslat link až po forku - klidně mě kontaktuj na IM (quaker66 AT gmail DOT com nebo quaker AT jabbim DOT cz)

Původní záměr bylo použití D pro nový engine, ale vzhledem k nepodpoře několika věcí ve všech kompilátorech (momentálně chybějící linkování shared knihoven a podpora pro málo architektur / OS) jsem se rozhodl pro Cčko, se kterým nemám problém.

V Cčku se dá psát velice přehledný kód i pro velké projekty - ale je třeba si dát pozor na paměť a pečlivě kód strukturovat, aby se z toho nestala špagetovitá změť a vše rozdělit přehledně do částí.

Jiný projekt, ve kterým jsem zapojen a je psaný v Cčku, je Enlightenment a jeho knihovny.

[alblaho]

Já to vidím jako konkurenci pro céčko. Javisti Go moc řešit nemusí.

- jednodušší než C++ (doufám)

- jakás takás podpora pro moderní vícejádrové procesory

- kompaktní nativní kód (doufám)

- rychlý překlad

- moderní serepetičky typu typová inference a uzávěry

Déčko se moc nechytlo, třeba prorazí tohle. Nezlobil bych se.

[----]

"Déčko se moc nechytlo" .. nemůžeš říct o jazyce, který měl první stabilní specifikaci v roce 2007 a druhá ještě ani není.

[__dark__]

Specifikace možná, ale ten jazyk je tu už pěkně dlouho a stejnou dobu je i ignorován. Na druhou stranu programovat pod D bych si zvykl, ale v tom Go paskvilu ne

[----]

Nojo, jenže ten jazyk NENÍ ještě pořádně vyvinutý pro produktivní použití - D2 už celkem jo, ale ideální to není - není ignorován, prostě ještě není "ready".

[__dark__]

V tom případě je otázka, bude v dohledné době vyvinutý, když se nevyvinul ani během deseti let?

[Luboš Doležel (Doli)]

Do D bych docela vkládal naděje, ale myslím si, že je pro jeho budoucnost zásadní plná kompatibilita s C++ (ve smyslu linkování vůči knihovnám).

[----]

No, zatím se dá C++ knihovna wrapnout pod Cčkem a to pak použít v D, ale ideální to není, samozřejmě.