Khan Academy modernizuje svůj serverový software a přechází z monolitického řešení v Pythonu na mikroslužby implementované v Go.
Vývojáři uvádějí, že zvažovali použití Kotlinu (jazyk nad JVM), ale testy ukázaly, že řešení v Go používá mnohem méně paměti, takže stačí mnohem menší serverové instance. Volba proto padla na Go, nativně kompilovaný jazyk podobný „céčku“ od Googlu.
Tato zprávička byla zaslána čtenářem serveru Root.cz pomocí formuláře Přidat zprávičku. Děkujeme!
moc to nesleduju, mohl byste více rozvést to zaostávání Pythonu i jinde? popř. odkázat na nějaký článek, jestli se vám nějaký vybavuje, který by to srovnával a ukazoval v čem Python zaostává..
Jazyk Go je dost mladý (2009) na to, aby zatím potřeboval "revoluci" kvůli zásadní změně uznávaných paradigmat. Python vznikl v roce 1991. Unicode vzniklo 1993. Je logické, že původní verze Pythonu nepoužívaly Unicode jako výchozí reprezentaci řetězců. Ostatní změny se nabalily, když uzrál čas udělat tu změnu kvůli řetězcům. Samotná "revoluce" trvala deset roků a jeden měsíc. Bylo možné psát či upravit kód kompatibilní jak s Python 2, tak 3, i když nejpracnější bylo právě ohlídat kompatibilitu právě okolo řetězců. Popularitě Pythonu tahle revoluce nepochybně prospěla, což je také důležitá zpráva pro autory dalších jazyků.. Některé knihovny ovšem už nebyly příliš aktivně podporovány původními autory a tak modernizace proběhla spíš tvorbou forku jen pro Python 3, což komplikovalo kompatibilitu mnohem víc a odkládalo přechod závislých knihoven. (zdroj letopočtů - wikipedie)
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...
Generika má?
Tak to si určitě můžeš napsat vlastní typově bezpečnou frontu nebo mapu...
Můžeš mít jakoukoli mapu, pokud chceš černou...
...a opovaž se myslet si, že si můžeš napsat nějakou sám!
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?
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.
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]interface{} 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(idExistuje).map(idToid) 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.
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.
V článku se píše, že to byl hlad po výkonu. Přepisem codebase do Py3 by si pomohli o 10-15 %, podobně nákladným přepisem do Go získají násobně víc.
Vídám to poslední dobou často, zákazníci migrují na kompilované jazyky. Letos několik větších klientů s rozsáhlými Rails a Django aplikacemi začalo přepis na Rust (Rocket) a Go.
Častý je přechod z Rails na Crystal/Amber nebo souběžné použití. Měl jsem štěstí s Crystalem pracovat na jednom projektu. Skvělá věc, na rozdíl od Go cílí na pragmatické programátory stejně jako Rails. Podle mě je na Go vidět, že vzniklo v korporaci, kde produktivita práce programátorů nikoho moc netrápí. Ve webovém vývoji jsou jiné požadavky.
Tohle mi přijde skoro jako zlomyslná reakce zavilého konzervativce - (já to říkal!). Kromě tedy toho, že - jak píšou jiní - chtěli prostě získat při přepisu něco navíc, z jednoho nebo několika takovýchto odchodů bych nic nevyvozoval. Někomu Python 3 nebo přechod nesedí a odejde, jiný změnu uvítá a někdo to moc neřeší. Python 2 byl v mnoha ohledech nedořešený a Python 3 je objektivně lepší, evoluce by znamenalo pouze nabalování dalších možností, ale ne vyčištění jazyka.
Python z pohledu uživatelské báze roste, tak kde je ten neúspěch? To fakt chceme uživatele, kterým bude dobře jinde, držet násilím nebo nějakou obdobou Stickholmského syndromu? Podle mě třeba Python potřebuje ten vývoj urychlit - umožnit odstavení GILu, lepší práci s typy a lepší provázanost s dalšími jazyky (rád bych třeba viděl větší a hladší spolupráci s komponenty v Rustu).
Naopak já osobně Python 3 vítám, mnoho těch změn je skutečně potřebných. Jen ten přechod na Python 3 prostě není automatickej, což je u větších projektů problém (víme, jak to chce řešit autor Calibre). U mnoha jazyků se daří vývoj bez revolucí (čti - nekompatibilní změny), Python se rozhodl pro jiný způsob. To novým programátorům nevadí, ale udržovat stávající SW je dost opruz a třeba v korporacích to Python asi dost shazuje, i když by o něm třeba i uvažovali (zákon klesajících výnosů jim brání v přepisech).
Já mám s přechodem na Python 3 konkrétní zkušenosti. U nás jsme převedli co nejvíc konstruktů na notaci kompatibilní mezi Pythonem 2.7 a 3.x, kde to šlo, nasadili jsme mezivrstvu s názvem future a něco jsme si tam doplnili sami. Nebylo to hned, ale vzhledem k velikosti báze kódu, k minimu chyb atd. celý projekt považuju za slušný úspěch. Pořád nám všechno běhá na obou verzích, ale příští rok se snad odpoutáme od dvojky úplně.
Z prezentací lidí přímo z Googlu (https://www.youtube.com/watch?v=bmZNaUcwBt4&list=WL) vyplývá, že právě to měli na mysli. Práce programátorů je drahá, hodně drahá. A vzhledem k tomu, že se jim na pozici točí lidé průmerně po dvou letech a mají smíšené teamy, chtějí jazyk s jasnou syntaxí a sémantikou i pro juniory, ultra rychlým překladačem a pevně nastavenými pravidly formátování, jmenných konvencí atd.
Prostě opak C++, tam se asi dost spálili, co čtu mezi řádky těch prezentací :-) Někdy omezení Go trošku bolí (prostě si člověk nemůže tak moc dovolit, jako třeba právě v C++), ale zase je možný na produkční kód pustit i relativní nováčky a dost rychle je zaučit (ten kód vyžaduje mnohem mnohem menší znalost kontextu).
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).
Ono také u těch extrémně zatížených projektů zmiňovaný předpoklad neplatí. Většina úloh je primitivní - sčítáte čísla, řetězce, tam si nepomůžete chytřejším algoritmem. Ale těchto operací musíte vykonat stovky tisíc za vteřinu. Napsat takový kód efektivně ve vysokoúrovňovém jazyku vyžaduje buďto velmi specializovaného drahého programátora a nebo velké množství hw - a napsat sw, který dobře škáluje, také není nic jednoduchého.
Když Vám webová aplikace v pohodě běží v jednom virtuálním serveru, tak ji nemá cenu přepisovat. Pokud ale potřebujete serverů už i nižší desítky, tak to může být extra znát na ekonomickém výsledku. Jsou služby, které mají vyšší stovky serverů.
"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.
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.
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...
"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.
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.
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ý.
@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.
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
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 - a já s ním nemám žádný problém. Naopak u většího Pythoního projektu mám problém i ten projekt nastartovat, a o modifikaci kódu nemluvě.
Já jsem s Pythonem udělal docela negativní zkušenost - existuje docela hezký klient pgcli https://www.pgcli.com/. Nedokážu posoudit kvalitu jeho kódu. pgcli je zoufale pomalý při zobrazení jiného než malého výsledku - už při pár set řádcích se čeká - myslel jsem si, že nebude problém kód modifikovat tak, aby generoval jen tsv - což by mohlo být docela rychlé - finální zobrazení bych udělal já v pspg. Vzdal jsem to po deseti minutách. Vůbec tam není vidět, kam sáhnout.
"Go je klasický jazyk"
Tak to si ho pleteš s řečtinou a latinou.
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.
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
Tak ještě jednou... V tom jazyce si ani pořádně nenapíšeš mapu.
Konstruktivní kritika - vždyť to, co je na go blbě se omílá pořád dokola...
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.
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…
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
