Vlákno názorů k článku
Dění okolo generických typů v Go
od Wavelet - Čekají se nějaký výrazný změny v idiomatickým psaní...
-
Dělals někdy na něčem rozsáhlejším v go? Já bych přežil ten divný jazyk a ty zvyklosti kolem něho, ale když se pak na ten kód člověk podívá, tak všechno tak nějak splývá - jediná konvence je začít malým písmenem pro interní věci, a velkým pro export. Už toto je naprostá syntaktická noční můra - žádné visuální oddělení konstant, struktur, atd..., všechno to splyne dohromady a člověk potřebuje dobrý editor, aby v tom nějaký smysl našel. A exportnout něco, co bylo třeba interní znamená změnit název toho symbolu, a upravovat všechny místa, kde byl použitý.
Já nevím jak ostatní, ale větší projekt bych sám od sebe v go nikdy nezačal a ty na kterých jsem dělal už bych nikdy nechtěl zpět :)
A úplně nejlepší jsou hardcore gophers co čumí na černobílý editor, protože tak to dělá i sám tvůrce a tak to je přece nejlepší :-D
-
Dělal jsem na velkých projektech v Javě, C++ a Go, a pokud někde byly větší problémy, nesouvisely s jazykem. Zrovna Go si mnozí na velké projekty pochvalují, já to vidím spíš neutrálně, Go nebo Java, z pohledu řízení projektu prašť jako uhoď. Pain je spíše C++ nebo Rust, ne kvůli syntaxi — tu se naučí i opice — ale prostě stylu jazyka (zvlášť C++ je občas bordel). Pokud si někdo stěžuje u větších projektů na jazyk (Javu, Go, to je fuk), buď ten jazyk pořádně neumí, nebo by neměl vést/řídit projekty. Ale to je off topic, téma jsou typové parametry a typové množiny. Marně přemýšlím, který jiný jazyk je v této formě má.
-
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?
-
Pavel TišnovskýZlatý podporovatelJo 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.
-
Pavel TišnovskýZlatý podporovatel
"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.
-
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.
