Vlákno názorů ke zprávičce Začalo hlasování o přidání generických typů do jazyka Go od anonym - A co algebraické datové typy?

A co algebraické datové typy?

Jsem poměrně zmlsán Rusten, takže používat pro mě Go je docela těžké :)

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.