O autorovi překladu
Jan Mercl, autor překladu, pracuje v Laboratořích CZ.NIC jako programátor pro výzkum a vývoj.
Portál AbcLinuxu, 26. května 2024 12:26
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.
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.
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)
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.
Úč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á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.
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“.
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.
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.
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.
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.).
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 )
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í.
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í).
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.
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.
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.
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ů.
(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).
Jan Mercl, autor překladu, pracuje v Laboratořích CZ.NIC jako programátor pro výzkum a vývoj.
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ší.
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...
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.