Názory k článku
Začalo hlasování o přidání generických typů do jazyka Go

Osobně se domnívám, že Go by se nemělo snažit takto konkurovat sofistikovanějším jazykům. Go je svým způsobem nový BASIC. Za svůj úspěch vděčí tomu, že se ho každý naučí snadno a prakticky hned, a že zároveň už ze své podstaty poskytuje ochranu před tendencí psát kód "chytře". Je to jednoduchý nástroj na řešení jednoduchých problémů, a mělo by takové zůstat.

Generické typy na takto primitivní úrovni jsou jednoduché k pochopení a při typové inferenci (kterou autoři explicitně zmiňují) člověku píšícímu kód ani nepřijdou na oči (“sofistikovanou” práci za něj odvede autor knihovny). Generika ostatně nejsou o “chytrosti”, ale (typové) bezpečnosti. Kdyby tam chtěli nacpat třeba závislostní typy, to už by byla jiná, ty skoro nikdo nechápe (proto je taky skoro žádný jazyk nemá, i když Go vlastně jeden má :)), ale základní typové parametry nejsou ani vyšší dívčí a skoro všichni je dávno znají v různých obměnách z C++, Javy, dotnetích jazyků...

Možná se pletu, ale domnívám se, že Go nemá plnou Hindley-Millnerovu typovou inferenci jako např. Rust, OCaml a Haskell. Je to spíš jenom něco jako deklarace "auto" v C++. Hlavní problém ale vidím v tom, že i základní typové parametry nejsou tak jednoduchá věc, jak se zdá na první pohled. Člověk nemusí sahat rovnou po závislostních typech, co třeba obyčejné type bounds, které, jak jsem viděl na vlastní oči, nejsou pro spoustu začátečníků vůbec intuitivní?

A potom, jak to konkrétně bude implementované? Jestli formou monomorfizace, jako v Rustu nebo C++, tak je to celkem hluboký zásah do jazyka, když daná funkce může ve skutečnosti představovat několik různých subrutin. Opět to je něco, to hodně lidí tak docela nechápe, a kromě toho se to celkem blbě kombinuje s rozhraními, jaké má Go, a de facto kachním typováním. Navíc to znamená, že každá knihovna, která exportuje takové API, se musí překompilovávat pro každou případnou instanciaci a to pak snadno vede k dependency hellu. V Rustu se tenhle problém tolik neklade, tam to má cargo ošéfované téměř dokonale, ale i tam může občas vzniknou opruz, když má nějaká závislost závislosti sama závislost na nějakou třetí knihovnu v C, jejíž hlavičky atd je pak nutné doinstalovávat. Ale pokud si pamatuju, v Go je správa závislostí trochu problematičtější.

Naopak jestli to bude pouhá elize typů jako v Javě (dejme tomu, že překladač všechny typové parametry nahradí interface {}) tak to bude mít negativní dopad na runtime výkon, kde Go už beztak ztrácí proti C/C++ nebo Rustu.

Určitě nebude mít Hindley-Millner, ale něco jednosměrného ála C++. Ono když HM selže, tak na ty rovnice začátečník čumí jak péro z gauče a netuší která bije. A to jde úplně proti základním principům Go.

To je na Go moc akademické a prakticky zbytečné, zvlášť teď, když zavedou lepší ABI.

Akademický je akorát tak název. Jinak je to velice praktická věc. Hodí se tam, kde má smysl uvažovat o Visitor design patternu.

Ta myslenka, ze uzivatele daneho jazyka mohou kolektivne rozhodovat o tom co bude soucasti standardu a co ne, se mi strasne libi. Prijde mi to opravdu jako super vec, protoze se na jeho vyvoji clovek muze podilet a je mu ten jazyk mnohem blyzsi a bude se mu urcite i lepe pouzivat. Urcite vic jak kdyz o tom rozhoduje nejake konsorcium, vzdalen cloveku jak galaxie v Andromede....

Na druhou stranu se bojim, zda tu neni trochu nebezpeci, ze to nekdy casem nesklouzne k neotesanemu hybridu typu "ze vsecho neco a poradne nic"... Trochu C, trochu Java, trochu Python, trochu Lua (samozrejme prehanim, ale myslim ze to ilustruje myslenku).

Otázka je, jestli ten systém bude jako švýcarská referenda nebo spíš něco à la brexit. Budoucnost ukáže.

Spíš se obávám, jestli to nepovede k tomu, že vždycky někdo bude chtít jenom ještě jednu featuru, bez které se neobejde, a postupně tak vznikne nové C++.

Doopravdy je nemá dodnes.

Jo, a to už byla poměrně populární. Živě si pamatuju tuny typecastů v kódu. Pak s velkou slávou přišla verze s generickými typy a všichni z toho byli na větvi :)

Jo na to doplatilo hodně jazyků. Bohužel i mé oblíbené D. Tam se sice poslední dobou snaží jít (chtěly by jít) opačnou cestou, ale jak se jedno nastoupí na tento vlak tak už je pozdě a nejde vystoupit.

D přímo nepoužívám, sleduji ho spíš jen zpovzdálí, ale připadá mi, že tam je jiný problém. Před časem se na dlang fórech někdo zmínil, že Rust má svoji každoroční uživatelskou anketu State of Rust, a že D by možná mělo mít něco podobného. Jenže to zamítli, protože to údajně nemá smysl, protože před lety takovou anketu udělali a nic prý z toho nevzešlo. Což v praxi znamenalo, že s žádným z problémů, které tehdy trápily uživatele, se nic neudělalo, místo toho se Walter a Andrej pustili do vývoje jakéhosi polovičatého borrow checkeru à la Rust, který doopravdy nefunguje. Tak je to v D se vším, každou chvíli se snaží honit nějakého nového zajíce a přitom nástroje a tooling jsou nedotažené, podpora cílových platforem vázne, dokumentace je mírně řečeno slabá, integrace do IDE veškerá žádná, knihovny a ekosystém jsou hrozný bordel, schizma GC/noGC je... bez komentáře, komunita je sektářská, apod. Škoda, D mohlo být silným konkurentem pro Swift i pro Go, a potenciálně výborným jazykem pro Android (lepším, než Kotlin a samozřejmě než Java).

Ano přesně jak píšeš, anketu udělali. Sám jsem se jí účastnil. A vyšla skvěle přesně jak jsem volil já. Bohužel jak píšeš nemá to smysl aspoň ne dokud o tom rozhodují lidé, kteří žijí v cela jiném světě.

Jako snahu jim nemůžu upřít, dokonce založili fond. A peníze z toho fondu šli na projekt co měl zlepšit podporu v IDE. Smutné bylo že šly někam kde jít asi neměly. Protože šly na plugin pro jeden editor, a ten plugin už v té době nebyl zázrak a existoval (osobní názor: lepší plugin pro ten samý editor, který aspoň nějak fungoval). Což vedlo přesně k opačnému jevu. Ten dotovaný stále stojí za prd. A autor toho lepšího se na to kvůli tomu vykašlal.

Takže jsem poslal několik tisíc zbytečně. Ono pravdou je že sám nevím kdo to tomu jazyku poštval víc. Jestli Walter Bright a nebo Andrei Alexandrescu. Oba dva jsou kapacity, ale jeden je extrémně tvrdohlavý a je velmi těžké ho o něčem přesvědčit a druhý je Andrei (můj idol), který zbaběle pláchnul.

Tak zrovna u Go věřím, že k tomu snad nedojde. Když vezmu v potaz jak dlouho se bránili generickým typům (což je podle mne poměrně lákavá fíčura). U jazyka D to trvalo cca. rok, než byl autor jazyka přetlačen.

K tomuhle je odsouzen každý jazyk, co se ujme. Je to jen otázka času.

Tak na rychlo jsem si to prošel, a nemyslím si že se to liší od spousty jiných programovacích jazyků. Uživatelé nemohou kolektivně nic rozhodnout. Jen to mohou komentovat. Ale jestli proces chápu správně tak je zde vždy nějaká skupina potažmo arbitr kdo o tom rozhodne.

Ano, zprávička je dost zavádějící. Uživatelé o ničem nehlasují.

Zatím - klepu na dřevo - je Go příjemně konzervativní a současně i otevřené názorům mimo Google, takže zatím dobrý :-) Samozřejmě uvidíme, co a jak bude v Go 2 (pokud tedy vznikne, když "goto is considered harmful"), ale prakticky jistě by to neměla být taková změna jako například Python 2 -> Python 3.

Jazyk, který potřebuje goto, má podle mě v návrhu něco podivného. Je nějaká ukázka kódu v Go, kde se vysloveně hodí a nedá rozumně nahradit?

To byla narážka na Go 2, které se čte goto - někde to zmínil Rob Pike jako vtip, proč to s Go 2 tak dlouho trvá.

Jinak k tomu goto - sám jsem ho v produkčním kódu nepoužil nikde (a to máme několik mega Go zdrojáků). Ve standardní knihovně Go je použito - pokud správně hledám - jen na jediném místě a to je implementace LZ-77 dekomprimace okopírované z C++ :-) Ostatní použití goto je v testech (testech chování samotného goto).

Máte pravdu - vždycky jde nahradit, ale ne (IMHO) vždy šikovným idiomatickým kódem.

Aha, to mi nedocvaklo.

Trochu off-topic: v Ritchieho céčku šlo mít návěstí v proměnných, které měly typ int*. Například “int* x = label; goto x;”. Z Ansi C to ale vyhodili. GCC pak přišlo s operátorem &&, ale návěstí jsou typu void* a v goto se používá hvězdička (goto *x). To jen taková historická perlička (viz C Reference Manual, odstavec 14.4).

Třeba asembler?

Používá se poměrně běžně u vyskočení z násobného cyklu.

Na to ale stačí break label (pokud je). Každopádně dík.

Celkem rozumně tohle řeší Rust se svými pojmenovanými smyčkami:


'a: for ..... {
while ... {
loop {
...
break 'a; // vyskočí ze všech tří vnořených smyček
}
}
}

V zásadě to není nic jiného, než goto, ale omezené jenom na tenhle jediný scénář.

Swift má in-betweeny goto, je to ještě “podivné” nebo už to je přijatelné i pro puristy?

Pokud to mělo být na mě, tak nevím, co přesně to znamená, Swift neznám.

Trochu off topic: Když jsem to googlil, narazil jsem na různé příklady s příkazem switch. Tenhle příkaz nesnáším od té doby, kdy jsem začal s C, šílené minové pole zabudované přímo do základů jazyka - zlatý pattern matching a (samozřejmě) sum types...

Pro ty komu vadi goto je k dispozici INTERCAL a jeho PLEASE COME FROM.

PLEASE je zásadní featura kterou by měli ostatní jazyky převzít. Jak má jinak překladač poznat, jestli je programátor nevychovaný nebo podlézavý?

Jenže v návaznosti na ten slavný článek byl napsán článek “Goto considered harmful considered harmful”, takže tak jednoznačné zlo to není ;)

Publikován byl, pravdu neměl.

jj v tom článku používá něco čemu by se dalo říkat "lokální goto", tedy například omezené tak, jak je to v Go. Naproti tomu v klasických BASICech se dalo skákat kamkoli (ono taky nebývaly bloky omezující scope, takže to šlo bez problémů - třeba přeskočit jedno DIM a nahradit to úplně něčím jiným, nebo přeskočit FNxx, což je pěkná prasárnička)

BASIC si pamatuju akorát ze ZX Spectra, kde se skákalo na číslo řádku :)