Názory k článku
Dění okolo generických typů v Go

A typové množiny jsou nějaký jejich nový koncept? Přináší to co?

Je to něco jako algebraické typy, jen flexibilnější a hlavně jednodušší než původní kontrakty u typů. Nejspíš si chtěli ušetřit práci, proto naroubovali typové množiny na rozhraní. Runtime (implementace pod kapotou) se podobá typovému systému Rustu, syntax je dost odlišná. Rust je o krok napřed, jelikož má přidružené typy a GADT (potažmo HKT), ale to nemá většina rozšířených jazyků.

Hezký příklad je typová množina typů, jež mají ukazatelovou metodu Init(). Instance vytvořená pomocí new(T), kde T je typový parametr, je typu “ukazatel na T” a Init() nejde přímo zavolat, je nutné použít omezený (bounded) polymorfismus. Ovšem nejde použít něco jako [T Initialisable], když je Init() ukazatelová metoda, proto se použije typová množina (zde jednoprvková), která dodá omezení na typ *T, kde už jde Init() zavolat. Tady to je koukám typová množina vyššího řádu (množinový operátor), neboť má typový parametr :) Sakra, začíná to znít jako Haskell :/ Tohle bude hezký námět na článek od p. Tišnovského ;)

Mě zajímá ergonomie a jak to tedy ovlivní psaní kódu. Scala 3 třeba měnila koncept typů a zdá se mi, že k lepšímu. Pod kapotou mají lepší teorii a navrch se to zjednodušilo. Já sem právě zvědavý, jak se s tím popere osazenstvo, které ke Go přišlo jako k jednoduchému jazyku. Což není špatně. Zdálo se mi, že ta alternativa proti složitosti jiných jazyků je u Go záměrná. Kdo chce, může s klidem sáhnout po Scala 3, Idris, Mercury atd., pokud si chce hrát s něčím pokročilějším ve světě typů, nebo ne?

Jo no, chystám se na to :-)

Jinak k těm velkým aplikacím - otázka je, co je to velká aplikace, ale obecně v Go vznikají větší projekty (NATS nebo NSQ například, ale i OpenShift a spol.). Nějaké obří informační systémy by se stejně měly nakouskovat na mikroslužby a tady je Go velmi dobrým prostředkem.

Samozřejmě generické typy můžou chybět. To jsme viděli například v článku o Gonum (https://www.root.cz/clanky/gophernotes-kombinace-interaktivniho-prostredi-jupyteru-s-jazykem-go/#k02) kde to evidentně hodně drhne.

Zase ty mikroslužby :)

Ono asi není sporu, že typové parametry občas chybí, mít místo nich všude interface{} je dost na houby. Ještě víc na houby je reflexe. A úplně nejhorší je generování kódu :)

"Zase ty mikroslužby :)"

ale jo já vím, je to buzzword a možná se někde tlačí na sílu, nebo se to porovnává s monolitem, který se vyvíjel X let.

Osobně si myslím, že mám na mikroslužby zdravý kritický názor - kromě všech nevýhod se ale při dobrém návrhu spousta věcí zjednoduší, jsou flexibilnější týmy, fíčurky jdou škálovat (jak vývoj, tak i nasazení).

PS: my udělali v návrhu architektury jednu chybu, v podstatě (když to hodně zjednoduším) máme jednu DB jak pro "skutečná" data, tak i pro uložení feedbacku od zákazníků. A toto spojení se nám vymstilo, protože ke třem frontnedům teď přidáváme čtvrtý, dosti odlišný v požadovaném chování. Kdybychom si dali tu práci a měli 2x DB + 2 různé služby pro přístup k nim, bylo by vše o dost jednodušší. No, u další fíčurky už nebudeme na začátku líní, doufám :-)

Já si z toho tady dělám legraci, protože to je buzzword, ale my je taky na jednom větším projektu používáme. A ano, taky má několik modulů jednu databázi, ale to proto, že prototyp byl monolit a teď se postupně rozsekává, takže v tom je teď solidní zmatek.

Člověk si s mikroslužbami ani moc kódu nenapíše, většinu generuje Protobuf a ORM, ale z hlediska nasazení a hlavně řízení týmu to výhoda určitě je, takové praktické rozděl a panuj.

“A typové množiny jsou nějaký jejich nový koncept? Přináší to co?”

Po nedávných zkušenostech s novým překladačem se zdá, že to je něco jako Union{…} v Julii, ovšem Julia nemá typově vázané funkce, proto je v Go implementace poněkud složitější.

Go má knihovny pro všechno, na co si člověk vzpomene, včetně dost obskurních věcí. Hlavně je dobré, že to nejdůležitější je přímo součástí buď standardní knihovny, nebo aspoň v x/..., takže napsání serveru, nějaké mikroslužby apod. nevyžaduje žádné "cizí" knihovny. Jediné, co tomu chybí, je něco pro GUI, ale to je záměr. Na to jsou jiné jazyky a nástroje, např. Flutter, haha :)

Go ma knihovny, ale nema kvalitni knihovny. Nebo alespon nemelo.
Pred par lety se u nas resilo vetsi XML, ktere obsahovalo dva separatni elementy (rekneme jmeno a prijmeni) a nejake data v atributu (vek) a chteli jsme vybrat jmeno mezera prijmeni mezera vek rekneme u vsech muzu. XML bylo komplikovane, ruzne vnorene nechtelo se mi to popisovat prez Go struktury. Reknete si XPath? Jasne, v Jave to slo jako nic, hotovo za 10 minut. Go melo tehda tri implementace XPath a zadna nevedela dost na tohle.

Ocaml si rozhodně zaslouží pozornost (a články). A Dependent ML pro rozšíření obzorů :)

OCaml! Promiňte mám OCD :). Ale k věci, hrozně rád bych někdy viděl články o: OCaml a Erlang/Elixir (něco tu bylo, ale chtělo by to víc). jeden čas mi přišlo, že třeba ReasonML prorazí, pak to ale přejmenovali na ReScript (https://rescript-lang.org/) a většinu času věnují změně syntaxe, aby byla podobná JS. Naprostá ztráta času. Na pozadí to stejně používalo https://www.bloomberg.com/company/press/open-source-at-bloomberg-introducing-bucklescript/ ...

Sorry, to nebylo napsané špatně naschvál. Popravdě mě překvapuje, že se o ML větvi jazyků člověk prakticky nic nedozví ani na většině našich VŠ. Tam je to buď čistě funkcionální přístup (dejme tomu, že ok) nebo Algolská větev, většinou tažená do class-based OO (takže Java :-).

Jo, rozbily se např. optimalizace (restrict), protože byl bug v LLVM, pak si mysleli, že to opravili, tak je v Rustu povolili, aby je následně zase zakázali. Takovéto detaily, které se navíc obtížně sledují, nejsou úplná vzácnost.

Časem si to snad sedne, jako u Swiftu, tam taky trvalo dlouho, než jej stabilizovali.

Takže problémy spíš teoretické a okrajové. Super.

Mají v tom prostě bordel, ale to je cena za použití LLVM.

Jedna regrese v kompileru nám teď prakticky znemožnila sestavit rozsáhlejší projekt používající Axum framework :)

Rust je super, ale občas trochu divočina a zvolit ho jako primární jazyk pro komponenty ve firmě vede kromě nesporných výhod i k nutnosti přispívat do upstream knihoven víc než jinde, a mít v teamu někoho kdo se vyzná v kódu rustc je celkem dobrý nápad.

No OK, dal jsem Ti palec nahoru za konkrétní případ, ale v reálu se stalo co? Nezkompilovalo se vám to na 1.56, vrátili jste se k 1.55, někdo udělal issue pro rustc, Axum to mezitím obešel změnou v routingu, v další verzi předpokládám, že ta regrese zmizí. Všechno funguje jak má.

Ten problém v rustc existoval od začátku existence Axum (a projevoval se v menší mířé i v jiných knihovnách s komplexními typy)

Celou dobu se na to používaly workaroundy, ale 1.56 to rozbil úplně.

Jasně, není to zas až takový problém, ale ve chvíli kdy to nastane, je docela otrava řešit to, hledat jestli je chyba v kódu… V o něco dospělejších jazycích bych tolik nezvažovala výhodu mít v teamu vývojáře co se umí vrtat v kompileru :)

A nijak tím nehaním Rust, jen je prostě potřeba počítat s občasným výskytem trochu otravnějších regresí než jinde. I tak si za svou volbou jazyka na celý backend stojíme :)

Přesně o tom jsem psal. A poslední dvě věty klidně podepíšu :)

Tak nějak, Rust má sice nějakou tu výhodu, ale stabilita a spolehlivost k nim zatím nepatří. (Taky má dost otřesnou syntax, zlaté ObjC :) Ono to je trochu okolnostmi, za jakých vznikal. Ale C++ je ještě horší guláš, člověk si moc nevybere. Rust aspoň nutí vývojáře přemýšlet nad pamětí, typy etc.

Otřesná syntax Rustu pod článkem o Go? To už je Apríl dvakrát za rok?

Go má jednoduchou a pragmatickou syntax. Z Rustu bolí oči (což ovšem nijak nesnižuje výhody a sofistikovanost jeho překladače). Lepší hnusná syntax a zajímavá implementace pod kapotou než naopak (looking at you, Java). Druhá věc je, že Rust nemá runtime (a jeho autoři se tím dokonce chlubí), jejich přístup “it’s a feature” není úplně přesvědčivý. Ovšem Rust se živelně vyvíjí, co není, může záhy být.

Jenže proč má Go jednoduchou syntax? Protože ten jazyk nic moc neřeší, je to o malý kousek vylepšené C (a v něčem IMO horší, viz ta někým zde zmiňovaná velká písmena pro public jména, to je fakt bizár). Proč má Rust složitou syntax? Protože toho ve skutečnosti řeší hodně. Já nevím, jestli by se dala vymyslet hezčí, ale mám za to, že se někdo fakt hodně snažil (a to je u Rustu myslím pravidlo) to navrhnout nejlíp, jak to vůbec jde.

Ale za mě toho flame waru bylo fakt dost. Rust a Go nejsou přímí konkurenti a že je každý z těch jazyků jiný, beru jako fakt.

30. 10. 2021, 11:13 editováno autorem komentáře

Go nic neřeší syntaxí, ale runtimem, ten je dost komplexní (a sofistikovaný). Syntax Rustu není složitá, jen hnusná. Rust je celkově jednoduchý a jediná zajímavá věc, se kterou přišel, je borrow checker (a ten je natolik výrazný, že zastiňuje vše ostatní). Rust je super všude, kde není potřeba (nebo by překážel) tracing GC, ale má pár zádrhelů, o kterých je nutné při jeho používání vědět (taky pár vyhod, o kterých se na rozdíl od bezpečné správy paměti nemluví). BTW až bude gRPC v Rustu aspoň stejně rychle jako v Go, dejte mi vědět :)

Vedle zmiňuješ makra a že se mají jazyky navzájem inspirovat. No tak se vývojáři Rustu inspirovali všude možně, akorát si z jazyka udělali další Swift, Scalu nebo D nebo nějaký další jazyk, který má "všechno". Já jsem spokojený a Ty ne, to se stane. Navrhuju udělat téma ve fóru a Rust tam můžeš vesele hejtovat, jsem zvědav.

Swift je podstatně komplexnější než Rust.

gRPC? Třeba tady: https://www.reddit.com/r/grpc/comments/hv7h6i/grpc_bench_a_clear_objective_grpc_benchmark/

Tady další: https://www.nexthink.com/blog/comparing-grpc-performance/

30. 10. 2021, 13:55 editováno autorem komentáře

Až na to, že ta implementace se dá měnit. Syntax je většinou už navždy. Dá se s tím nějak hýbat, ale pak skončíš jako C++ (který mám vlastně docela rád :).

30. 10. 2021, 18:49 editováno autorem komentáře

Syntax se taky mění, Fortran si tím prošel nebo třeba ObjC. C++ je aspoň konzistentní, i když některé zápisy se šablonami jsou občas lahůdka :)

Tak ano, ale nový Fortran (90+) to je skoro nový jazyk. BTW: Programuju ve Fortranu .)

31. 10. 2021, 00:35 editováno autorem komentáře

To já taky, jako správný fyzik. Fortran forever! Jenže dnes už to je fuk, stejně dobře se dá psát v C++ nebo i tom Rustu.

Já nevím, ale Fortran (moderní) je mnohem čitelnější, má spoustu featur přímo zabudovaných a kompilátory vyladěné. Spousta lidí v tom dělá, právě proto, že stejně napsané výkonné C++ vyžaduje spoustu hnusných věcí v kódu (direktivy) a ruční práci. Komunita v poslední době hodně maká: https://lfortran.org/; https://github.com/fortran-lang/fpm; https://en.wikipedia.org/wiki/Coarray_Fortran

Já měl na mysli výkon, čitelnost je jiná věc, tam C++ asi skutečně nevede… Pro fyziky existují ještě čitelnější jazyky než Fortran, zápis vzorečků v HALu je nepřekonatelný. Bohužel jak tak vidím kolem sebe, dnes studentům fyziky cpou akorát Python.

:) No asi lepší než MATLAB, ten do studentů rvou ještě víc. Ale zase z těch komerčních věcí mě mile překvapila Mathematica. Jinak jsem nedávno "sjížděl" APL, a člověk si říká kolik zajímavých jazyků se drží sice v šedé zóně, ale stále se používají. Na práci s poli ideální: https://problems.tryapl.org/ Na první pohled bordel, ale po chvíli cviku do dává smysl. Problém C++ je podle mě, jiného druhu. Tam se dají z historických důvodů psát věci různě a pořád se to nabaluje (decltype, enable_if, concepts...). Je težký držet jeden styl i napříč jedním projektem.

HAL jsem neznal, dík.

31. 10. 2021, 10:38 editováno autorem komentáře

Mně jednou Ruda Kryl říkal, že APL navrhli Američané schválně šíleně, aby ho podstrčili Sovětům (kteří Západu kradli technologie a vše možné kopírovali, vlastní výzkum byl zabrzděný ideologickým postojem, že kybernetika je buržoazní pavěda) za účelem způsobení chaosu ve vesmírném programu. Ale Iverson byl Kanaďan, tak nevím. Sověti se pak údajně pomstili vytvořením ještě šílenějšího jazyka, ale už si nevzpomenu na jméno.

A kterou verzi Fortranu? Ptám se proto, že znám jednoho fyzika, který stále používá Fortran 77. Má v tom spoustu kódu a je v oboru asi hodně dobrý.

To je asi o osobních preferencích, syntax Rustu mi přijde jako jedna z velkých výhod :D A stabilita a spolehlivost - porád platí že pokud se to zkompiluje, tak to prostě funguje.
To že to občas hapruje při kompilaci nám sice třeba v případě Axum ukradlo nějaký čas vývoje, ale zase nemusíme řešit spoustu jiných problémů, které Rust prostě nemá.

Tak jistě, každý jazyk má výhody a problémy. U Rustu jsou třeba skvělá makra, to by se mi opravdu líbilo i v jiných jazycích. Vůbec by bylo nejlepší, kdyby se jednotlivé jazyky vzájemně inspirovaly (více než teď) a “kradly” si zajímavé věci.