Vlákno názorů k článku
Khan Academy přechází z Pythonu na Go od atarist - Důležité je, že je k tomu rozhodnutí vlastně...

To jsem předpokládal že je mezi nelepícími vývojáři všeobecně známé. Škálovatelné síťové aplikace (servery, služby, proxy). Záběr je za ty roky širší, ale toto byl prvotní cíl.

Bohužel nedostatek zkušeností vede juniory ke zcestné kritice, síla Go není v jazyce (syntaxi), ale v runtimu. Konkurencí (částečnou) se pomalu stává Rust a byl by jí Swift, kdyby se Apple více věnoval jiným OS.

https://www.twitter.com/TheWizardTower/status/1207954288816746497

Jinak kritika se většinou netýká syntaxe, protože třeba nedomyšlený typový systém není otázka syntaxe...

Ten tweet má říkat co?

Ten typový systém by měl mít co navíc, aby se líbil lepičům? Generika už má a HKT je pro ně moc složité. Nebo jen vadí chybějící dědičnost? Nechci se rozhodně hádat, ale upřímně by mě zajímal (odkaz na) článek s konstruktivní kritikou (od někoho věrohodného pochopitelně).

Generika má?

Tak to si určitě můžeš napsat vlastní typově bezpečnou frontu nebo mapu...

Ano, má. Dokonce má i mapu, nemusím ji psát :)

Můžeš mít jakoukoli mapu, pokud chceš černou...

...a opovaž se myslet si, že si můžeš napsat nějakou sám!

Psal jsem, že runtime má generické typy. Že je syntax omezenější je právě problém syntaxe, když už. Typový systém možná zaostává za Haskellem, ale ne Javou apod.

Aha, takže super vlastnosti tam jsou, jen se nedají použít.

"Typový systém možná zaostává za Haskellem, ale ne Javou apod."

Ciwe jako vážně? U jazyka, kde si ani bezpečně neimplementuješ datové struktury?

Smrtelně. Koukni na kód runtimu, typový systém tam je se vším všudy (generické argumenty apod.), žádné tupé type erasure jako třeba v té Javě.

https://golang.org/doc/faq#generics

Jasně říkají, že to nezvládli nadesignovat.

A kde je spor? Jasně jsem opakovaně psal, že syntax je omezená. Jestli někomu nějaká fíčura chybí, tak tady rozhodně vřeští na nesprávném hrobě.

U nás konkrétně se projekty píšou vždy ve vhodném jazyce. Kde je nutný maximální výkon a mírnixdírnix (meta)šablony, použije se C++. Go je na síťové komponenty a API, tam exceluje. Sorry jako, ale kdyby někdo chtěl v Go psát něco jako simulaci urychlovače částic (nebo cokoliv se sofistikovaným modelem a vysokými nároky na výpočetní výkon), tak ať se vrátí na VŠ a dostuduje. To je jako “asembler nemá generika, béééé!”

Tohle chození kolem horké kaše, že tvůrci go nezvládli to, co se jinde umí už desetiletí...

Ale ano, v kusů máš pravdu. A lze to i zobecnit: kdyby někdo chtěl v Go psát něco, tak ať se vrátí na VŠ a dostuduje.

Moc nechápu ten hejt. V Go vznikají kvanta kódu a většinou si autoři výsledek pochvalují. Zní to jako od studenta, co právě pochopil generika a teď je agresivně prosazuje a haní vše, co jimi není prolezlé. Není jiné cesty než počkat 10-20 let, až přijdou zkušenosti. Nebo jiný jazyk...

Ne, ta kritika je od programátorů co musí v golang psát věci, na které není určené. Protože hype a síla Google (mimochodem vzpomeňte na Angular 1..), v golang se totiž píše spousta věcí, které nejsou API ani síťové služby.

Pro vysokoúrovňovou logiku se ten jazyk totiž extrémně nehodí. Dobře to třeba ilustruje názor, že výjimky nikdo nepotřebuje. Je ovšem zajímavé, že if error return error je celkem běžný vzor. A další perlička, z error návratového typu v hlavičce funkce nelze zjistit, jaké chyby může funkce vrátit.

Obojí jsou přiznané nedostatky a existují návrhy na jejich řešení. Oba se mi i celkem líbí.

https://go.googlesource.com/proposal/+/master/design/go2draft.md

Dalším problémem je práce s dynamickými strukturovanými daty. Zkuste si napsat tak jednoduchou věc jako načíst json data, když neznáte přesnou strukturu (kompatibilita s různými verzemi), změnit jednu známou položku, serializovat a poslat dále. Zjistíte, že se kód hemží typem map[string]in­terface{} a operací přetypování .(typ). I ta "blbá" typovaná Java umožňuje takovou operaci provést syntakticky mnohem příjemněji (s využitím výjimek pro chyby).

Golang je velmi čitelný, pokud Vás zajímají nízkoúrovňové instrukce. Jenže já třeba u zpracování dat dávám přednost sémantickým operacím jako filter(idExis­tuje).map(idTo­id) před for cykly a podmínami obalenými haldou komentářů. Funkce to umožní emulovat i v golang, za cenu porušení DRY principu.

Co vím z prezentací Pika, tak právě schválně nechtěli tupě reimplementovat něco, co jinde umí už desetiletí (se všemi negativními důsledky).

Jinak kde konkrétně je problém? Nemožnost mít generickou funkci?

Problém nikde není, to jen někteří mají fetiš v hejtování některých zajímavých a úspěšných jazyků. Dříve to odnášelo Objective-C. Aneb zhejtujeme Drahoše a vychválíme Zemana, stejná omezená “logika.” Ale co, zas došlo na slova klasika: “Begun the language war has.”

Objective-C nikdo nekritizoval, neb nikoho nikdy moc nezajímalo (kromě prostředí Apple, protože jinde se neuchytilo). Tahat do té absurdní analogie Zemana s Drahošem, to by se hodilo spíš na Silvestra. V jiné dny by se snad hodila trocha té argumentace.

Ten styl argumentace mi silne pripomina zdejsiho Idrise/Zboje.

23. 12. 2019, 15:07 editováno autorem komentáře

Typový systém Go za Javou opravdu nezaostává – bavíme-li se o Javě 1.4.

Generické typy pro vyjmenované případy nejsou primárně omezenou syntaxí (i když ano, do syntaxe se to taky může promítnout), ale omezením typového systému. Je celkem jedno, jestli kompilátor umí s generickými typy interně plně pracovat a „jen“ k nim chybí syntaxe, nebo jestli jazyk má syntaxi pro generické typy omezenou typovým systémem. Výsledek je stejný.

BTW, generika omezená na speciální typy mají i C a Java 1.0. Akorát fungují jen pro pole. Navíc je nelze použít pro metody/funkce jako putIfAbsent – aspoň ne bez přetypování za běhu.

Nejen mezi řádky, celkem napřímo to uvádějí.

Zaprvé, srovnáváte s C++, to není vysokoúrovňový jazyk. Zadruhé, jak píšete, cílí na nováčky a příležitostné uživatele píšící kritickou infrastrukturu, což je specifický use case. Vysokoúrovňové jazyky a frameworky jako Rails naopak nabízí dlouhodobým uživatelům možnost postupného zlepšování produktivity a eliminaci psaní opakujícího se kódu (DRY).

"Ale těchto operací musíte vykonat stovky tisíc za vteřinu."

v klasických webových aplikacích takové operace provádí databázový server, webová aplikace pracuje jen s množstvím dat potřebných pro jednu stránku (případně jednu odpověď API). Rails stačilo na prehistorickém HW před patnácti lety, není důvod, aby nestačilo dnes. AFAIK stále na tom běží třeba github.

Vam to staci, takze z toho plyne ze to staci vsem? Evidentne Googlu ne a Khan Academy taky ne (o tom je blogpost, o kterem diskutujeme).

OT: mam pocit, ze se bavime o dost uzkem use case - nejake providovani dat a castecne i logiky pro SPA (nebo je logika na webu, nevim jak je to ve vasich aplikacich). Ale Go se pouziva i jinde, tam kde obecne tecou mnohem vetsi data. Joy4 nebo NSQ napriklad.

"mam pocit, ze se bavime o dost uzkem use case"

IMO častější use case než Google nebo i ten Khan Academy ( ještě uvidíme jak s tím přepisem dopadnou).

Taky mě to zajímá, ale pokud si ten monolit dobře rozsekají, tak to asi budou moci dělat po částech, no uvidíme.

Jinak pokud máte logiku v Rails (+ nějaký framework na frontendu), tak to IMHO není špatné řešení. Ale například ve chvíli, kdy budete potřebovat naškálovat databázi (a to jako že hodně naškálovat), tak pro tuto vrstvu aplikace bych doporučil sáhnout například po https://vitess.io/ psaném v Go, než to "mastit" (omlouvám se za ten termín) v Pythonu nebo Ruby.

A asi tady je nejzajímavější ekosystém Go, na který se ten jazyk dobře hodí - různé siťové tooly, proxy, load balancery, message brokery, streaming servery a klasické REST API mikroslužby.

Hezký konkrétní příklad. Sice fandím Rustu a Go nemám rád, ale některé věci v Go sám používám (třeba Gitea).

Z těch komentářů tady čiší zoufalý nedostatek zkušeností. Někdo si splácá stránku v Pythonu nebo PHP a vydává to za důkaz jejich nadřazenosti nad Go. Lpění na nepodstatných vlastnostech jako generika, když jde o aplikaci, která má být škálovatelná a robustní, taky jasně křičí “nic nevím o skutečných projektech, mé zkušenosti jsou mizivé, ale koukejte vsichni, vím o existenci generických typů!” Nezbývá než doufat, že i taková nemehla časem získají zkušenosti a prozřou. Ostatně web je plný blogových zápisků o migraci z Pythonu/PHP/Javy... na Go a zatím to všem řádově pomohlo. Stejně bylo kdysi ve stupidní módě bez elementárních znalostí kritizovat Objective-C a za nějaký ten čas se objeví zase něco.

"Někdo si splácá stránku v Pythonu nebo PHP a vydává to za důkaz jejich nadřazenosti nad Go."

Tak asi budou i takoví kritici. No a?

"Lpění na nepodstatných vlastnostech jako generika, když jde o aplikaci, která má být škálovatelná a robustní,"

To je blábol.

Parametrizované typy jsou nepodstatná vlastnost?
Jsou jazyky, kterým se to vyčítat nedá, ale když se jazyk pokouší o statickou typovou disciplínu, tak to problém je.

Se škálovatelností to souvisí volně, ale jedna dobrá vlastnost dobrý jazyk nedělá.

""Nezbývá než doufat, že i taková nemehla časem získají zkušenosti a prozřou."

Go je jazyk explicitně mířený na nemehla...

Co tě pudí k tomu generovat na Vánoce víc žvástů než obvykle? Go cílí na juniory v Googlu, i to největší “nemehlo”, které Google přijme, převyšuje 99% matroše, co píše kód.

"Go cílí na juniory v Googlu, i to největší “nemehlo”, které Google přijme, převyšuje 99% matroše, co píše kód."

No očividně máš o nich vyšší mínění než tvůrci go.

Zajdi si na pohovor do Googlu. Až vyletíš v prvním kole (pokud tedy projdeš telefonickým pohovorem o algoritmizaci), dojde ti, že někdo, kdo je pro Pika nemehlo, je pro tebe nedostižný guru.

Hele šmudlo, po letech v praxi i na místech, jako byl Sun... Ti nevím ;-)

Každopádně fakt nemám zájem jít dělat pohovor někam, kam ani nechci ani nemohu.

A neměj strach, svou várku binárních stromů a podobných legrací už jsem viděl z obou stran dost.

Kyselé hrozny :)

Co bych si měl dokazovat taháním rodiny někam, kam nechci? Další cool jméno do CV? Egoboost z toho, že budu kolečko v megakorporaci?

Já bych spíš napsal, že je explicitně mířený na nováčky v týmu, ať již se tím myslí skutečný junior nebo i seniorní člověk, který je v týmu nový a musí se vše naučit. Pro tyto lidi je důležité snižovat "cognitive load" (omlouvám se - neznám přesný český termín) a pokud bude alespoň jazyk jednoznačný, s malými nároky na kontext, s dodržovanými pravidly zápisu, jmenných konvencí atd., tak je to jen dobře; ten prvotní šok a zaučování se zmenší (stejně se ten člověk bude muset naučit milion dalších věcí, protože v IT zatím není velká standardizace).

Dále, podle Googlu se jim točí lidi v teamu průměrně každé dva roky (u nás celkově netuším, ale v jednom týmu to je i rychlejší :-), což vlastně znamená, že středně velký tým přijímá nového člověka každý měsíc. V takové situaci asi nemá smysl investovat 2-3 měsíce jen zaučováním nového jazyka (a to se mi píše těžko, protože mám rád například Clojure, tj. jazyk v mnoha ohledech na opačném konci spektra, než je Go), protože se ztratí 2-3 měsíce nového člověka a řekněme měsíc člověka z týmu, který dělá peera.

Vidím to na týmu ve kterém pracuje - v Go jsme schopni úprav i v rozsáhlých cizích projektech (které patří jinému týmu, ale někdy do něj zasahujeme), aniž bychom přesně znali všechnu štábní kulturu, která mnohdy není nikde popsaná, ale je to uvnitř týmu dodržováno. V Go je to předepsáno zvenku, ať již samotným jazykem, nebo prostě dodržovanými idiomy ("happy path", jmenné konvence, konvence docstringů, komunikace přes kanály a ne sdílenou pamětí atd.). Naproti tomu je mnoho projektů v C++, kde se rozhodli používat jen určitý výsek jazyka; bohužel v každém projektu jiný.

Používáte Go? Podle Nekoly jste nemehlo a měl byste se (cituji) “vrátit na VŠ dostudovat.”

Takovéhle fauly snad nemáš zapotřebí.

@Josef Nevím, jestli to bylo na mou odpověď (chybí tady stromový náhled od určitého levelu), ale fakt popisuji situaci, jakou jsem viděl v několika týmech.

Pavle, to bylo na Calculona a jeho "Podle Nekoly jste nemehlo". Kdybych to po sobě četl, taky bych nepochopil, na koho reaguju, příště budu explicitnější.

V pohodě, já jsem se jen v té diskuzi trošku ztratil :-) Jsem spíše zvyklý na Reddití styl řazení a odsazování komentářů.

@Pavel Tišnovský
V pohodě, já jsem se jen v té diskuzi trošku ztratil :-) Jsem spíše zvyklý na Reddití styl řazení a odsazování komentářů.

Po onom slavném "respoňzívním imprůvmentu" je diskuse na root-u od úrovně 3 (no, možná 4, ale to je fakt fuk) nepřehledná a nikdo nikdy už nezjistí, kdo na koho jak reagoval.

A evidentně se s tím už nebude nic dělat...

@pavel

Co popisuješ zní rozumně, pokud hledáš náhradu za špatné HR ;-(

23. 12. 2019, 14:46 editováno autorem komentáře

Tak pravda, HR je téma na dlouhou diskusi :)

Databáze by neměla řešit prezentaci dat - zde se bavíme o finální integraci dat do šablon, práce s parametry. Pokud máte prostředí, kde nejde dost dobře použít aplikační cache, tak nízkoúrovňovým jazykem nic moc nezrychlíte. Pokud ale dokážete mít gro dat v redisu, memcache - tak pak bottleneck je generování html

Je potřeba brát v úvahu kontext - asi nic, co by cílilo na zdejšího uživatele by nemělo utavit aplikaci psanou v RoR nebo PHP.

"Go je klasický jazyk"

Tak to si ho pleteš s řečtinou a latinou.

IMO je Pavel S. prostě klasický céčkař a "mírný pokrok v mezích zákona" zvolený těmi starými unixáři mu přijde akorát.

V Pythonu můžeš napsat program 1000 způsoby. Souhlasím, že pgcli je napsán dost nepřehledně - nedávno jsem přemýšlel, že ho naučím vypisovat sloupce v tabulce abecedně (divím se, že to neumí sám od sebe a pokud mi něco neuniklo, stejně tak to neumí ani psql) a přišlo mi jednodušší udělat si vlastní udělátko.

řadit sloupce abecedně je dost atypický požadavek u relačních databází, takže se nedivím, že to pgcli a i psql nemá.

pspg umí vyhledávat sloupce - písmeno c - hledá substr v názvu sloupce, a na první sloupec, který obsahuje podřetězec umístí vertikální kurzor.

Mě vždycky víc zajímá, jak se sloupec jmenuje - už třeba když si člověk nemůže vzpomenout na přesný název - (abecední pořadí), než kdy byl přidán do tabulky. Za tip děkuju, ale s tou atypičností bych si jistý nebyl. Přijde mi, že to je ergonomický nedostatek.

V ideálním případě, jako že takový není, by nemělo záležet na pořadí sloupců, stejně tak jak nezáleží na pořadí řádků (v relačním modelu). V praxi do toho přichází třeba požadavek na zarovnávání, případně u širších tabulek s NULL sloupci pomalejší dohledání hodnoty v sloupci (tj u nějakého 70 sloupce, a všimnete si toho u agregací nebo fullscan filtrů nad milióny řádků). Také se snáz přidávají sloupce dozadu než doprostřed, atd.

Běžný úzus je do prvních sloupců dávat primární klíče, pak případně cizí klíče, a pak přidávat podle významu. Dovedu si představit, že může mít smysl abecední řazení - když není nic lepšího, ale fakt jsem to moc neviděl, a jste první, od koho takový požadavek slyším.

Implementačně by to asi nebylo nic extra těžkého - jen by se při generování matice hodnot, která se bude tisknout jelo pomocí mapy místo lineárně. Jinak v psql jsou dva nástroje které by Vám mohli pomoct.

\x
SELECT ... ;

pro široké tabulky je zobrazení v řádcích dost přehlednější

nebo

SELECT ..
\gdesc

Vypíše strukturu výstupní matice - sloupce, typy

24. 12. 2019, 09:33 editováno autorem komentáře

Nevím, jestli klasický, ale má vše potřebné pro efektivní práci a běh.

Tak ještě jednou... V tom jazyce si ani pořádně nenapíšeš mapu.

Nemusíš už rozpoutávat flamewar, teď už jsi v kategorii troll.
Konstruktivní kritika by byla lepší, když už nemůžeš mlčet.

Konstruktivní kritika - vždyť to, co je na go blbě se omílá pořád dokola...

Ondro, ale stejně tak to můžeš napsat v podobném duchu o Javě, nebo o Rustu "v tom jazyce ani pořádně nenapíšeš obousměrně vázaný seznam s hodnotami nebo obecný graf". Ono je to vždycky něco za něco.

No zrovna Java za nedomyšlenosti v začátcích později dost zaplatila.

A u Rustu to skutečně je něco za něco. Ne protože to tvůrci jazyka neuměli.

Nevím, čemu říkáš pořádně, ale napíšeš dnes už poměrně snadno: https://www.reddit.com/r/rust/comments/7zsy72/writing_a_doubly_linked_list_in_rust_is_easy/

A recepty nebo idiomy pro konkrétní problémy se řeší intenzivně, kód nebude jako z učebnice od Wirtha, ale nevím, proč by to mělo vadit.

Píšu o obousměrně vázaném seznamu https://en.wikipedia.org/wiki/Doubly_linked_list, ne o nečem založeném na vektoru :-) Viz hned první komentář (za obhajobou původně až triviálně jednoduché datové struktury). To není nic proti Rustu (rád bych ho někde reálně použil), jen ukázka, že většinou je to něco za něco. Go má ultra rychlý překladač, daní za to je, že (zatím???) neřeší věci jako šablony nebo generika. A to jak z hlediska syntaxe (LL parser), tak i sémantiky.

Oni ta generika časem přidají, jen je to teď nepálí (jejich slova). Holt mají jiné priority.

Jenže oni mají priority už pěknou řádku let… V roce 2007 začal návrh jazyka, v roce 2009 byl public announcement, v roce 2012 verze 1.0. Dnes je konec roku 2019, tedy přes 7½ roku poté, a stále to není priorita – ani jsem nenašel zmínku, že by se na tom začalo dělat. Než proběhne návrh změny jazyka, dosáhne se dohody na podobě a implementuje se to do překladače, uplyne spousta času.

Pro mě jazyk bez generik je asi jako kdyby mi někdo řekl, že mám jíst oběd z talíře lžící, že vidličku a nůž nepotřebuju. Pravda, jde to, ale není to ono.

Go jednoho dne možná generika mít bude. Asi to nebude brzy a za tu dobu asi jeho konkurenti taky udělají nějaký posun…

Nějaké prototypy už jsou, dokonce dost odlišné co do konceptu. Ale prostě v jejich use casech generika nepotřebují, tak radši vylepšují GC apod.

Tak ne, nakonec to není neschopností tvůrců:

https://www.twitter.com/antumbral/status/1201214511341957120
https://www.twitter.com/tef_ebooks/status/1201164897754734592

Začalo se na tom dělat, stejně jako na použitelném error handlingu: https://go.googlesource.com/proposal/+/master/design/go2draft.md

To vypadá hodně slušně, zejména ty kontrakty.

No OK, nebudeme slovíčkařit, je nám oběma jasné, o co jde. Hezké svátky, ať už s Go nebo s Rustem, případně i s Pythonem. V nejhorším i v reálu mimo svět počítačů. ;-)