Hlavní navigace

Názor k článku Go: minimalistický a překvapivě výkonný programovací jazyk od Michal Mühlpachr - Přijde mi, že mindset programátorů je více ovlivněn...

Článek je starý, nové názory již nelze přidávat.

  • 20. 11. 2018 15:05

    Michal Mühlpachr

    Přijde mi, že mindset programátorů je více ovlivněn fenomény o kterých mluví "Uncle" Bob Martin v přednášce "The Future of Programming" https://www.youtube.com/watch?v=ecIWPzGEbFc (pozor, je to spíše historie, ale podle mě vysvětluje srozumitelně stávající stav) než jazykem, který používají.

    Dříve jsem si myslel, že téměř nejdůležitější je dělat věci správě (např. programovat správě). Proto jsem nechápal, jak někdo může nepovažovat za nejrozumnější funkcionální programování a ANSI Common Lisp a stále "plýtváme" zdroji s procedurálním programováním (tam kde Alan Turing začal). Proč jsme se nebyli schopni reálně úrovní posunout ?
    Nyní se přikláním k názoru, že mnohem důležitější než dělat věci správě, je dělat je srozumitelně a použitelně pro "hodně" lidí. To mě vede k přesvědčení, že minimalismus a "user space" samostatnost Go je jedou ze správných cest.

    Ad "systémová knihovna" - co to vlastně je ? :-) Kernel (Linux) je také knihovna. Hranice mezi user space knihovnami a kernelem není ostrá (nezřídka dělají obdobné věci a umístění funkcionality kernel vs user space je dáno spíše historicky, mnohá funkcionalita se také překrývá - např. API logování). Budeme "kárat" user space knihovny a kernel za duplicity ?

    Domnívám se, že běhové prostředí aplikace by měl mít aplikační programátor více pod kontrolou, čemuž "brání" stávající pojetí distribucí, kde běhové prostředí aplikace značně ovlivňuje package maintainer. No a proč nutit uživatele řešit závislosti knihoven, když nemá pro svou aplikaci balíček distribuce ? Nebo proč nutit dělat aplikačního programátora binárky (balíčky) pro řadu distribucí, když stačí binárka per architektura/plat­forma ?

    Proč nám vlastně vadí spouštět binárky (důvěřovat autorovi aplikace), když důvěřujeme jeho kódu a kódu knihoven co aplikace používá ?

    Je lepší mít hromadu verzí dynamických knihoven (a evidovat v distribuci závislosti) nebo je lepší aby každá aplikace měla běhové prostředí svoje, to co otestoval a připravil autor aplikace ? Mě přijdou lepší binární "aplikační kontejnery" (staticky linkované binárky), než noční můra závislostí, hromada mrtvého kódu (to co je v dynamicky linkovaných knihovnách) s nezbytností se o něj starat a patchovat všechny verze. Či bizáry typu Virtualenv pro Python. Nedejbože když je třeba stejná verze dynamické knihovny přeložená s jinými parametry - to už je teprve schiza :-(

    Go samozřejmě umí využít "systémové" úložiště certifikátů, viz např. https://medium.com/@pierreprinetti/the-go-1-11-dockerfile-a3218319d191 Na úrovni clusterů je pak jistě lepší používat rozumnější správu konfigurace než distribuce na jednotlivých serverech - tedy něco jako etcd, Consul atp - k tomu budeš "systémové knihovny" přemlouvat těžko, ale v Go je to otázka cibulové struktury API (bez vlastní implementace knihoven by to bylo velmi obtížné).
    Kontejnerově distribuované aplikace s minimalizací povrchu pro útoky je myslím také rozumná strategie.

    Proto si dovolím nesouhlasit s přirovnáním k Javě a prohlásit čím více se Go rozšíří (obecněji strategie přístupu méně je více, osvobození od dynamických závislostí), tím lépe.

    Když moje oblíbená distribuce nemá balíček pro aplikační program, je fajn když binárka "just works" a to i na několika platformách, dva malé příklady:
    https://github.com/peco/peco
    https://github.com/asciimoo/wuzz

    Řada aplikací z https://github.com/avelino/awesome-go by tu asi nebyla nebo ne v tak skvělé formě.
    Já např. mohu doporučit (všechny najde na GitHubu):
    https://grafana.com/
    https://www.influxdata.com/time-series-platform/
    https://traefik.io/
    https://prometheus.io/
    https://emitter.io/

    BTW sdílím tvoji bolest s běhovým prostředím Java.

    K minimalizaci nepoužívaného kódu běhového prostředí (zejména pro menší devices) směřují další iniciativy i na úrovni kernelu, např. https://next.redhat.com/2018/11/14/ukl-a-unikernel-based-on-linux/

    Michal Mühlpachr