Portál AbcLinuxu, 17. říjen 2017 13:55

Google Go – 2. narozeniny

15. 12. 2011 | Jan Mercl
Články - Google Go – 2. narozeniny  

V listopadu uplynuly dva roky od oficiálního vydání tehdy nového programovacího jazyka Go. Místo ohlednutí se za těmito dvěma roky se dnes věnujme výhledům do blízké budoucnosti Go.

Obsah

Začátkem října Russ Cox, člen vývojového týmu Go, poslal do mailové konference golang-nuts krátký příspěvek, který v onom vláknu vyvolal stovky reakcí. Stručná zpráva, která to všechno vyvolala, pouze odkazovala na článek na oficiálním blogu Go. Níže jej přinášíme v české verzi včetně vybraných částí souvisejícího technického dokumentu, ve kterém jsou shrnuty detaily celého záměru.

Náhled Go verze 1

link

Chceme být schopni uživatelům Go nabízet stabilní základnu. Lidé by měli mít možnost psát v Go programy, od kterých lze očekávat, že je bude možné překládat a provozovat beze změn v časovém horizontu mnoha let. Podobnou možnost by měli i mít lidé píšící knihy o Go, mělo by stačit říct o které verzi Go text pojednává a i o mnoho později by takové číslo verze ještě pořád mělo dávat smysl. Ani jedno z toho Go dnes nesplňuje.

Počátkem příštího roku připravujeme vydání Go, které se bude jmenovat „Go verze 1“, zkráceně Go 1, které bude prvním vydáním Go, stabilním ve smyslu předchozího odstavce. Zdrojové kódy přeložitelné v Go 1 půjdou, až na několik málo výjimek, překládat po celou dobu života této verze, tak jak budou postupně vycházet Go 1.1, 1.2 atd. Chceme udržovat Go 1 opravami chyb a bezpečnostními záplatami i poté, co již vzniknou další verze Go. Navíc jej produkční prostředí, jako je třeba Google App Engine (GAE), budou podporovat po rozšířenou dobu.

Go bude ve verzi 1 stabilní jazyk se stabilními knihovnami. Kromě kritických oprav budou změny v knihovnách a modulech verzí 1.1, 1.2 atd. smět pouze přidávat funkčnost, ale neznemožní překlad existujících programů Go verze 1.

Cílem je, aby Go 1 bylo stabilní verzí dnešního Go, nikoli jeho úplným předěláním. Zejména výslovně odmítáme jakékoli snahy pomocí nějakých „komisí“ navrhovat nové vlastnosti jazyka.

Nicméně, existují různé změny jazyka Go a modulů, které už nějaký čas zamýšlíme udělat, jen jsme se k nim ještě nedostali, především proto, že jsou značné a zpětně nekompatibilní. Jestliže má mít Go 1 před sebou dlouhou životnost, pak je důležité, abychom tyto změny naplánovali, oznámili a otestovali coby součást příprav na Go 1, místo toho, abychom je odkládali až do jeho vydání a způsobili tak rozdělování vývojářů na původní a nové verzi, což by bylo proti smyslu našich snah.

Zveřejňujeme dnes naše předběžné záměry s Go 1, abychom měli zpětnou vazbu komunity. Pište prosím do tohoto vlákna na golang-nuts, jestliže se chcete k návrhu vyjádřit.

(Pozn. překl.: Následující text je výběr z technického dokumentu, v původním blog postu pouze odkazovaném – a to z dobrého důvodu. S různou intenzitou se tato technická část stále upravuje, v současné době spíše už jen doplňováním informací o tom, ve kterém týdenním vydání Go byla ta která část návrhu již implementována)

Go verze 1

link

Jazyk

link

append (od weekly.2011-10-18)

link

append nedovoluje přidat k řezu typu []byte řetězec (typ string).

V Go 1 půjde napsat append(b, s...), kde b je []byte a s je string.

close (od weekly.2011-10-18)

link

Účelem close je ze strany odesilatele informovat příjemce o tom, že už nemá očekávat další zprávy (data posílaná kanálem).

V Go 1 už nebude nadále možné použít close na kanál typu „pouze pro příjem“.

Kompozitní literály (od weekly.2011-12-06)

link

Kompozitní literál ve tvaru T{...}, který inicializuje hodnotu typu T, je dnes možné psát v některých případech s vynecháním specifikace typu T. Pro inicializaci hodnoty typu *T (ukazatel na T) ve formě &T{...} takovéto vynechání možné není.

type Entry struct {
        Name  string
        Value float64
}

// Současný stav, nezkrácený tvar prvků řezu typu Entry.
var dict4 = []Entry{
        Entry{"pi", 3.14},
        Entry{"e", 2.72},
}

// Současný stav, zkrácený tvar prvků řezu typu Entry.
var dict5 = []Entry{
        {"pi", 3.14},
        {"e", 2.72},
}

V Go 1 bude možné zkrátit zápis kompozitního literálu tvaru &T{...}, který inicializuje hodnotu typu *T zápisem s vynecháním &T.

// Současný stav, nezkrácený tvar prvků řezu typu *Entry.
var dict6 = []*Entry{
        &Entry{"pi", 3.14},
        &Entry{"e", 2.72},
}

// V současné době chyba.
// V Go 1 povolený zkrácený tvar prvků řezu typu *Entry.
var dict7 = []*Entry{
        {"pi", 3.14},
        {"e", 2.72},
}

Tato změna nebude ošetřena gofix modulem („skoroautomatický“ nástroj usnadňující úpravy zdrojového kódy při přechodu mezi vydáními Go, pozn. překl.), protože stávající forma zůstane v platnosti.

Typ error (od weekly.2011-11-02)

link

Go 1 zavádí nový zabudovaný typ error, jehož definice je

type error interface {
        Error() string
}

Podrobněji v debatě o typu os.Error v níže uvedené části „Moduly“.

Gorutiny během provádění init funkcí (od weekly.2011-10-25)

link

Stávající jazyk definuje, že příkaz go, provedený ve funkci init, vytvoří gorutinu, která ale nebude spuštěna dříve, než se dokončí inicializace celého programu.

Bude rozhodnuto později: Je možné, že Go 1 nebude mít toto omezení. Připravujeme experiment, ve kterém toto omezení zcela zrušíme. Pokud vzniknou nějaké hrozivější potíže, tak změnu vezmeme zpět.

int/rune (od weekly.2011-10-26)

link

Specifikace jazyka dává volnost implementacím vybrat si pro typ int buď 32-bitové nebo 64-bitové hodnoty. Stávající implementace používá 32-bitový int dokonce i na 64-bitových platformách. (Go má od začátku také celočíselné typy s pevně danou velikostí, pozn. překl.). Na 64-bitových platformách by bylo výhodné mít int s velikostí 64 bitů. (Závažné důsledky to má například pro indexy velkých řezů). Na druhé straně by ovšem taková změna znamenala, že při zpracování Unicode znaků se bude plýtvat místem, protože nyní se pro to používá typ int, tedy každý codepoint by neužitečně používal dalších 32 bitů paměti.

Tento problém napravuje nově zavedený typ rune, který je určený pro Unicode data velikosti codepoint.

V Go 1 bude typ rune definován jako alias typu int32, analogicky ke stávajícímu aliasu byte, tedy jiného názvu pro uint8. Standardní knihovna bude používat pro Unicode codepoint hodnoty všude typ rune. Používání podloženého typu int32 tak dovolí bezbolestně přejít k 64bitovému typu int na příslušných platformách kdykoli v budoucnu.

Ve zdrojových kódech, kde se pro uložení rune používá int nebo []int, bude potřeba změnit typy na rune nebo []rune, jinak bude kompilátor taková místa vykazovat jako chyby.

Tuto změnu neprovází žádná podpora pomocí gofix.

Vyjmutí položky z mapy (od weekly.2011-10-18)

link

Syntaxe přiřazení m[x] = ignored, false je zvláštním případem, jediné přiřazení s počty 1 = 2 položek, a vyžaduje předání ignorované hodnoty, která se vyhodnotí, ale nepoužije; dále je nutné předat bool hodnotu, která je takřka pokaždé false.

Tato syntaxe se v Go 1 ruší a místo ní se zavádí nová zabudovaná funkce delete: delete(m, x) vyjme z mapy m položku asociovanou s klíčem x. Pokus o vyjmutí nepřítomné položky je prázdná operace. Funkce nevrací žádnou hodnotu.

Gofix přepisuje m[x] = ignored, false na delete(m, x) všude tam, kde lze odvodit, že ignorovanou hodnotu lze bezpečně z programu odebrat a kde false má význam předdefinované bool konstanty. Všechna ostatní místa, kde se používá tato původní konstrukce, gofix oznámí, aby je mohl programátor podrobněji prozkoumat a rozhodnout o případných úpravách.

Iterace map (od weekly.2011-10-18)

link

Jazyk nikde nepředepisuje pořadí procházených položek při iteraci obsahu mapy. V praxi je pořadí na různých HW platformách odlišné.

Go 1 definuje, že pořadí iterace se smí měnit dokonce i mezi danou a následující iterací. Implementace map tak mohou např. optimalizovat mapy i v případě, že program mapu iteruje příkazem range. (Některé programy chybně spoléhaly na to, že pořadí iterace bude stabilní pro nijak mezitím nezměněné mapy, pozn. překl.).

Vícenásobná přiřazení (od weekly.2011-10-18)

link

Původní specifikace vícenásobného přiřazení zaručovala pouze to, že všechny RHS výrazy jsou vyhodnoceny předtím, než bude přiřazeno do kteréhokoli LHS operandu. „Výrazy na pravé straně se vyhodnotí předtím než se přiřadí do kteréhokoli operandu na levé straně, avšak jinak není pořadí vyhodnocování předepsáno...“ To ovšem neříká vůbec nic o pořadí přiřazování.

Go 1 kompletně předepisuje vícenásobné přiřazení. Všechny výrazy na pravé straně a všechny druhotné výrazy na straně levé (např. indexy) se vyhodnotí předtím, než dojde k přiřazení kterékoli levé straně. Přiřazení levým stranám pak probíhá v pořadí zleva doprava.

Tedy:

m := []int{1, 2, 3}
i := 0
i, m[i] = 1, 2     // nastaví i = 1, m[0] = 2
i = 0
m[i], i = 2, 1     // nastaví m[0] = 2, i = 1
m[0], m[0] = 1, 2  // nastaví m[0] = 1, pak m[0] = 2
                   // (takže na úplném konci je m[0] == 2 )

Příkaz return a překrytí návratovách hodnot pomocí := (od weekly.2011-10-18)

link

Běžně se objevuje chyba, kdy provádíme return (bez argumentů) poté, co bylo přiřazeno do proměnné se stejným názvem, jaký má pojmenovaná návratová hodnota, jenže tato přiřazovaná proměnná není onou návratovou hodnotou. (Snadno např. v rámci blokové viditelnosti, kde lze znovu deklarovat existující jména, pozn. překl.). V této situaci říkáme, že návratová hodnota byla překryta jinou proměnnou.

Kompilátor Go 1 odmítne příkaz return bez argumentů, pokud kterákoli z návratových hodnot byla překryta. Toto pravidlo nebude součástí definice jazyka, podobně jako v ní není pravidlo o funkci s chybějícím příkazem return. Vynecháním tohoto pravidla z definice jazyka, za současného jeho vyžadování kompilátorem, nám pomůže při vyhodnocování všech důsledků tohoto rozhodnutí.

Ekvivalence hodnot

link

Stávající jazyk nedefinuje operaci ekvivalence pro typy strukturované (struct), ani pro jakékoli pole. Na druhé straně shodnost pro funkční typy a mapy definována je. S funkčními typy to není až tak jednoduché, jak by se mohlo zdát. (Obvyklá a snadná implementace kde postačí prosté porovnání dvou ukazatelů svazuje v některých případech kompilátoru ruce, pozn. překl.) U map je to ještě horší, protože se porovnávají reference na mapy, nikoli obsah kontejneru. Dále je ve specifikaci řečeno, že jako klíč mapy lze použít pouze typy, které mají definovanou operaci shodnosti.

Go 1 definuje shodnost strukturovaných typů a polí strukturovaných typů které mají definovanou shodnost pro všechny členy struktury (porovnání probíhá postupně pro každý prvek). Naopak ze specifikace mizí možnost porovnávat funkce a mapy, s výjimkou shody s nil.

V Go 1 i nadále nebude možné porovnávat řezy. (V obecném případě nelze snadno zajistit „hluboké“ porovnání).

Kopírování hodnot s neveřejnými členy (od weekly.2011-11-18)

link

Současné Go nedovoluje modulu vytvořit kopii strukturované hodnoty, pokud tato obsahuje neveřejné položky a je definována v jiném modulu. Jenomže i přesto existuje výjimka, nutná pro metody (s přijímačem nikoli ukazatelového typu, pozn. překl.), navíc implementace nikdy neuplatňovala toto pravidlo v případě zabudovaných funkcí copy a append.

V Go 1 bude možné vytvářet kopie strukturovaných hodnot s neveřejnými položkami z jiných modulů. Moduly tak mohou mít trochu jiná API než doposud, mohou vrátit „neprůhlednou“ hodnotu bez toho, že by jí musel být ukazatel nebo rozhraní. Příkladem API, která této výhody využívají, je time.Time nebo reflect.Value.

Nic se tím nemění pro existující kód, poběží i nadále. Ovšem pokud je nějaký modul silně závislý na tom, že jiné moduly nemohou vytvářet kopie jím definovaných typů, (hodnot takových typů) s neveřejnými položkami – pak se může vyplatit zamyslet se nad tím, zda-li by nešlo třeba nahradit některá pole struktury neveřejným ukazatelem na nějakou hodnotu místo hodnoty samotné; popřípadě, zda by nebylo spíše na místsě použít rozhraní. Jako příklad přístupu k věci s neveřejnými ukazateli může posloužit třeba os.File.

Moduly

link

Pro úplný a dlouhý seznam změn v modulech odkazuji laskavého čtenáře na původní text, zde jen o jedné změně důležité pro tento článek.

os – os.Error se nahrazuje zabudovaným typem error (od weekly.2011-11-02)

link

Umístění os.Error do modulu os má převážně historický důvod. os byl jedním z nejdříve implementovaných modulů vůbec, který potřeboval chybový typ. Tehdy se nám takový typ jevil jako zásadní právě pro interakci s operačním systémem. Od té doby se však ukázalo, že Error je obecnějším prvkem. Například se zjistilo, že by bylo výhodné používat Error v modulu, který je modulem os importován, jako je třeba syscall. Navíc volba modulu os pro definici typu Error způsobila mnoho umělých závislostí na modulu os, které by jinak nemusely vůbec existovat.

Go 1 má zabudovaný typ error, ekvivalentní definici type error interface { Error() string } a zcela oddělený modul errors (v analogii k modulům bytes, strings), kde se nacházejí pomocné funkce. os.NewError je nahrazen errors.New. V souvislosti s touto změnou se os.EOF „stěhuje“ do io.EOF, os.Errno do syscall.Errno a přímé práci s chybovými hodnotami operačního systému byste se měli raději úplně vyhnout. (Takové hodnoty ani nikdy nebyly cross platform, pozn. překl.)

Gofix umí automaticky upravit většinu výskytů os.Error, které jsou touto změnou dotčeny.

Nástroje

link

Go 1 bude k dispozici ve zdrojové i binární formě přinejmenším pro tyto platformy:

FreeBSD 7+: amd64, 386
Linux 2.6+: amd64, 386, arm
OS X (Snow Leopard + Lion): amd64, 386
Windows (2000 + later): amd64, 386

Pro kompilaci zdrojových kódů Go nebudou programátoři potřebovat kompilátor Cčka, ani si nebudou muset stahovat Xcode v případě OSX. (Ti kteří se budou chtít podílet na vývoji jazyka samotného však budou tyto nástroje potřebovat i nadále.)

Součástí vydání Go 1 bude nový nástroj „go“, který nahradí jak původní goinstall, tak nutnost použití make.

Dvě sady kompliátoru a jeho podpůrných nástrojů – gc a gccgo – budou z hlediska specifikací Go 1 rovnocenné. Pro gccgo to znamená dokončit plnou implementaci gorutin (nyní implemetovány jako samostatná vlákna OS, pozn. překl.) a totéž pokud se týká podpory cgo modulů.

Shrnutí

link

(Od překladatele). Go již nějakou dobu podporováno v GAE. Jak společnost Google, tak i členové jeho vývojového týmu to s rozvojem Go myslí viditelně vážně. Považuji již probíhající proces, směřující k vydání Go 1, za ukázku velmi dobrého řízení FOSS projektu, pochopitelně je to vše podmíněno podporou velké společnosti, což se ne každému podobnému projektu podaří. Go dostalo do vínku starostlivé pečovatele a přejme mu k jeho druhým narozeninám – co jiného než hodně štěstí.

Český text vydán v souladu s původní licencí textu (Creative Commons Attribution 3.0 License).

Laboratoře CZ.NIC

O autorovi překladu

Jan Mercl, autor překladu, pracuje v Laboratořích CZ.NIC jako programátor pro výzkum a vývoj.

Seriál Google Go (dílů: 8)

První díl: Google Go – 1. narozeniny, poslední díl: Google Go – 2. narozeniny.
Předchozí díl: Google Go – pravidla reflexe

Další články z této rubriky

LLVM a Clang – více než dobrá náhrada za GCC
Ze 4 s na 0,9 s – programovací jazyk Vala v praxi
Reverzujeme ovladače pro USB HID zařízení
Linux: systémové volání splice()
Programování v jazyce Vala - základní prvky jazyka

Diskuse k tomuto článku

15.12.2011 08:04 polymorf | skóre: 14 | blog: tar_zxpf
Rozbalit Rozbalit vše Re: Google Go – 2. narozeniny
Odpovědět | Sbalit | Link | Blokovat | Admin
Naozaj podporuje GO taketo uvodzovky? “pi”
15.12.2011 09:34 avzgag
Rozbalit Rozbalit vše Re: Google Go – 2. narozeniny
a nejsou takovehle uvozovky jen zalezitost toho fontu co je pouzit v clanku pro kod?!
15.12.2011 09:39 polymorf | skóre: 14 | blog: tar_zxpf
Rozbalit Rozbalit vše Re: Google Go – 2. narozeniny
Nie. Ked si to skopirujes do ineho textoveho editora tak ten kod nie je validny. Bodka.
15.12.2011 10:25 jnml
Rozbalit Rozbalit vše Re: Google Go – 2. narozeniny
Naozaj podporuje GO taketo uvodzovky? “pi”
Samozřejmě tam mají být klasické ASCII uvozovky (0x22), jako v "pi". Bohužel jsem přehlédnul, že Open Opice mi při vložení zdrojového kódu uvozovky takhle “yntelygentně” zmastí.

Prosím za prominutí, doufám, že příště budu pozornější.
Luboš Doležel (Doli) avatar 15.12.2011 12:56 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
Rozbalit Rozbalit vše Re: Google Go – 2. narozeniny
Opravil jsem to. Automatické opravy v OO.org jsou neskutečné zlo, častěji něco zkazí než skutečně opraví :-(
15.12.2011 16:21 Opravář
Rozbalit Rozbalit vše Re: Google Go – 2. narozeniny
A nebude to spíše tím, že co opraví dobře, toho si nevšimneš? Řekl bych, že je to stejné jako "pravda" o kouření: "Můj děda kouřil do devadesáti a nic mu nebylo!"
Luboš Doležel (Doli) avatar 15.12.2011 16:59 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
Rozbalit Rozbalit vše Re: Google Go – 2. narozeniny
Kdeže. Zakázal jsem si všechny automatické opravy a výsledek je nejlepší, co kdy byl. Nejvíc k zlosti jsou velká písmena, co vám to cpe po zkrácených slovech.
15.12.2011 22:20 Petr Ježek | skóre: 10
Rozbalit Rozbalit vše Re: Google Go – 2. narozeniny
Netušil jsem, jak moc se Libre Office liší od OpenOffice :-)
Archlinux for your comps, faster running guaranted!
16.12.2011 00:54 w4rr10r
Rozbalit Rozbalit vše Re: Google Go – 2. narozeniny
Huh? Automatické opravy mi cpe obojí. Zcela náhodně.
Bilbo avatar 18.12.2011 13:40 Bilbo | skóre: 29
Rozbalit Rozbalit vše Re: Google Go – 2. narozeniny
Odpovědět | Sbalit | Link | Blokovat | Admin
Používá se vlastně Go vůbec někde? Zatím jsem tedy neviděl nic co by v tom bylo napsané ...
Big brother is not watching you anymore. Big Brother is telling you how to live...
18.12.2011 13:55 jnml
Rozbalit Rozbalit vše Re: Google Go – 2. narozeniny
Používá se vlastně Go vůbec někde? Zatím jsem tedy neviděl nic co by v tom bylo napsané ...
Jeden z mnoha příkladů: 1200 Go projektů jenom na Github. OK, je mi jasné, že nějaký podíl z nich jsou siroty, ale i tak...

Nebo... Líbil se třeba jeden z posledních Google Doodle? Já jen, že je to GAE applikace v Go ;-)

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.