Hello world v různých programovacích jazycích

Drew DeVault v příspěvku Hello world na svém blogu porovnává programy Hello world napsané v různých programovacích jazycích. Vedle velikosti se zaměřuje na počet systémových volání. Reakce ohledně programovacího jazyka Go.

6.1.2020 23:33 | Ladislav Hagara | Zajímavý článek

Komentáře

[xvasek]

No ty kráso, svět je v řiti a ten borec pro go to ještě obhajuje. In this day and age a 5MB binary hardly seems like a big deal. Disk space is ubiquitious, even on small hardware. Nedávno jsem dělal program, který na obrazovce vykreslí okýnko (v GUI), do něj vypíše text předaný na příkazové řádce, načte term ze sériového portu a uloží do souboru. Stripnutá binárka gcc / mingw pro WinGUI měla myslím 70kB a to jsem přemýšlel, co to asi tak může v těch 69kB dělat. (Původní multiplatformní program v Perl/TK měl jiné své nevýhody. )

[Heron]

Hello World test vůbec nic neřeší a netřeba z něj dělat jakékoliv závěry. Tohle se desítky let opakuje pro pobavení publika - délka kódu pro "pouhý jeden print" apod. ale neříká to vůbec nic o tom, jak se v tom kterém jazyku bude dát vyrobit běžná appka.

Go je staticky kompilovaný jazyk (což má své nevýhody i výhody), takže výsledek je zkrátka velký. Ano, člověka překvapí, když si udělá jen kostru a naimportuje si potřebné knihovny a už to má 11MB a nic to nedělá. Ale ono těch 11MB to bude mít i na konci u kompletní appky. Gitea má 38MB a je to kompletní hotové prostředí pro selfhosting git repositářů. Nic víc potřeba není (snad jen konfig) + git + ssh. Srovnejme si to s velikostí třeba gitlabu.

[Michal]

A proc to vsechny ty veci go binarky dava, kdyz se nic z toho nepouzije? Se nechtelo autorum optimalizovat?

[...]

Vysrali se na to

[Petr]

Pošli jim deset tisíc dolarů s poznámkou, ať se tím zabývaj, a oni tomu chvíli pověnujou...

[m.]

No ani me by se teda nechtelo optimalizovat kompilator na situaci, kdy vysledkem ma byt program, ktery nic nedela.

[xkucf03]

Hello World test vůbec nic neřeší a netřeba z něj dělat jakékoliv závěry.

+1

Na druhou stranu, staticky linkované binárky nemám moc rád a nevím, proč by běžné malé programy/binárky měly mít jednotky nebo dokonce desítky mega. Statické linkování má svoje využití, ale nerad bych, aby z toho byl obecný trend a každá aplikace si tahala svoje závislosti zabalené do jednoho velkého blobu.

Něco jiného je ten „magický“ kód, který se přibalí i k dynamicky linkované binárce, aby udělal nějaké inicializace, a nad kterým se autor článku tak podivuje/pohoršuje (mluví o tom jako o „crap“ a „shit“). Tohle většinou nějaké opodstatnění a rozumný důvod má, akorát ho autor nevidí, když píše jen Hello world.

[Heron]

Na druhou stranu, staticky linkované binárky nemám moc rád

Já taky ne a toto je jedna z věcí, která se mi na golangu příčí. Na druhou stranu se to pokusili obejít velmi snadnou a rychlou kompilací, kdy přímo součástí kompilačních toolsů je nástroj na automatické potahání všech závislostí. Takže update binárky v případě bezpečnostního update knihovny je velmi snadný.

Na druhou stranu chápu, proč se k tomu golang uchýlil.

proč by běžné malé programy/binárky měly mít jednotky nebo dokonce desítky mega.

Otázkou je, co to je "běžný malý program". Gitea určitě není běžný malý program. Už jsme na to narazili v diskusi o Clicku, prostě pomocí dvou řádků přidáš programu kompletní CLI + JSON. To nejsou malé komponenty. V Go si naimportuješ balíček http a třeba json nebo xml nebo něco a máš kompletní http server a nepotřebuješ k tomu webserver pro fcgi nebo wscgi iface, ta výsledná 11MB binárka už je kompletní služba, která krom kernelu nic dalšího nepotřebuje. Takže to, co se na první pohled může zdát veliké je ve výsledku vlastně mnohem menší, než stávající řešení.

A dívám se na to i jako admin (a to teda zejména), vůbec se mi nelíbí stávájící pojetí kontejnerů jako "schovka na bordel", kdy někteří vývojáři používají typicky docker jako kontejner, kam si schovají všechny svoje závislosti a knihovny a potom nutí docker jako jediné správné řešení na spouštění jejich appek. Trochu se zapomnělo na to, že OS poskytuje oddělení procesů, uživatelů apod a že služba vůbec nemusí běžet jako kontejner, ale může to být klidně lokální proces. A golang se do tohodle docela dobře trefuje. Jedna binárka, stačí spustit jako kterýkoliv jiný proces s potřebnými omezeními a oprávněními a je z toho služba. Kontejner netřeba.

[Boban]

Jo to je taky věc. Tohle to automatické potahání závislostí bez jakéhokoliv ověřování z URL na kterých může být zítra cokoliv. Fajn tyhle moderní bezpečnostní vychytávky.

[Heron]

+1

Ale to už je na rozhodnutí každého soudruha. Na straně jedné to zjednodušuje tvorbu vlastních balíčků (tj v importech bude jen vlastní doména a standardní knihovna), na druhé straně to může škodit. Já nejsem přítelem stahování komponent "z náhodných míst na netu".

[Petr]

Pokud těm lidem nevěříš, tak nepoužívej jejich knihovny... Buďto jim věříš, nebo jim nevěříš. Nic mezi tím neexistuje. Leda že by sis přečetl celé zdrojáky té knihovny...

[m.]

Ze nekomu veris dnes neznamena, ze bude mit tvou duveru i zitra. A mezi temi dvema dny se muze stat lecos.

[xkucf03]

Network connectivity must not be required during build – the build must be possible completely offline. All dependencies must be downloadable and documented including secure hashes or preferably cryptographic signatures.

[Heron]

Což pro balíčky go platí. Klidně si je všechny postahuj ručně dopředu a potom offline můžeš sestavit ten finální program.

[trekker.dk]

Pak je ale otázka, jak moc ten překládací systém proti tomuhle bude člověku házet klacky pod nohy, ať už úmyslně nebo jenom nedotažeností oproti automatickému stažení z internetu. A druhá - kolik lidí to skutečně bude dělat - tj. ověřovat, že opravdu stáhli to, co chtěli, ať už automaticky nebo ne (což je ale samozřejmě univerzální problém všech těchhle systémů, jak věci udělat co nejjednodušší pro vývojáře, přestože to může být na úkor něčeho jiného)

[Heron]

Pak je ale otázka, jak moc ten překládací systém proti tomuhle bude člověku házet klacky pod nohy, ať už úmyslně nebo jenom nedotažeností oproti automatickému stažení z internetu.

Tak jistě. V golangu není rozdíl mezi tím, když si stáhneš ten balíček samostatně (s cílem na něm třeba pracovat nebo si jej zkomplikovat jako samostatných program) a tím, když jej použiješ v importech jako součást tvého projektu. Stáhne se totéž. Stejně jako v pythonu je mnoho modulů současně i samostatný program a lze jej použít jako knihovnu ve vlastním programu.

A druhá - kolik lidí to skutečně bude dělat - tj. ověřovat, že opravdu stáhli to, co chtěli, ať už automaticky nebo ne

Tak tohle nezáleží na konkrétním jazyku ani nástroji. Každý jazyk má nějak bohatou standardní knihovnu a ke každému jazyku si můžeš dotáhnout cizí kód.

což je ale samozřejmě univerzální problém všech těchhle systémů, jak věci udělat co nejjednodušší pro vývojáře, přestože to může být na úkor něčeho jiného

Ano, a to mě jako admina sejří na různých distribučních platformách, snad každý jazyk má nějakou (CPAN, PyPi, PECL, úplně do extrému to dotáhl NPM, kde může každý cokoliv a navíc to může i smazat, takže při dalším update ta site přestane pro jistotu fungovat) a je těžké přesvědčit vývojáře, že by měl dávat přednost standardní knihovně, potom balíčkům ve standardním repositáři distribuce a až potom eventuálně sáhnout do balíčkovače té které platformy. Bohužel v různých tutorial videích "jak za 10minut udělat vlastní youtube" se to náhodným stahováním z githubu jen hemží a někteří lidé jsou přesvědčení, že toto je jediná správná cesta.

[trekker.dk]

Z druhého dílu původního článku:

And hidden therein is my actual point: complexity. There has long been a trend in computing of endlessly piling on the abstractions, with no regard for the consequences. The web is an ever growing mess of complexity, with larger and larger blobs of inscrutable JavaScript being shoved down pipes with no regard for the pipe’s size or the bridge toll charged by the end-user’s telecom. Electron apps are so far removed from hardware that their jarring non-native UIs can take seconds to respond and eat up the better part of your RAM to merely show a text editor or chat application.

[j]

To se pletes, zavery se z toho prave delat daji pomerne obsahly, protoze naprosto vpohode najdes zcela funkcni binarku ... 1/10 velikosti.

A pak muzes zacit premyslet, proc.

Ze mozna i nasobne slozitejsi aplikace nebude i nic vetsi znamena totiz proste to, ze tvurci kompilatoru nekde neco hodne posrali, protoze prave kompilator (pripadne linker) ma zaridit to, ze se pouzije a do binarky vlozi jen to co je treba. Uz jen proto, ze jakykoli zbytecny kod navic nasobne (v tomhle pripade radove) zvysuje riziko, ze aplikace bude obsahovat bezpecnostni chybu, o ktery navic autor nemuze mit ani paru, protoze ho ani ve snu nenapadne, ze by tam neco takoveho bylo.

Smutny, kdyz si clovek uvedomi, ze se do par kB vpohode vejde cely system. Jiste, bez spousty veci ktery se dnes povazujou za bezny, ale vejde.

Pricemz ten problem se multiplikuje, takze ve finale nam aplikace zabiraj TB na discich, GB v pameti ... a pritom neumej nic vic, nez ta kB appka pred 30 lety. Co hur casto i naopak, tam kde by vyuziti ram smysl davalo prozmenu soudruzi vyvojari vubec neuvazujou nad tim, ze ledackdo v PC muze mit i vic nez (dnes) 4/8GB ram (gamesa zurive chroupajici na disku/ssd, zabirajici 2GB a ani tuk navic, pricemz by si vpohode mohla vzit 60GB ...).

[xkucf03]

prave kompilator (pripadne linker) ma zaridit to, ze se pouzije a do binarky vlozi jen to co je treba.

V zásadě bych souhlasil, ale jde o to, že když 99 % programů psaných v daném jazyce potřebuje funkcionalitu/vlastnosti X, Y a Z, tak nemá moc smysl optimalizovat pro to 1 % Hello world příkladů, které tyto funkcionality či vlastnosti nepotřebují.

Ono udělat kompilátor/linker tak, aby byl natolik flexibilní, že dokáže vygenerovat optimální binárky pro všechno od Hello world příkladů po rozsáhlé aplikace, je dost obtížné.

Většina jazyků má nějak definovanou svoji cílovou skupinu a typické využití a pro ně se snaží optimalizovat. Nikdo neoptimalizuje pro Hello world příklady.

[j]

1 nebo 99%? Ja se klidne vsadim ze 99% je realite mnohem bliz => 99% vsech binarek obsahuje kod, ktery se "nikdy" nemuze spustit. Proc ty uvozovky? Protoze prave tenhle kod muze nekdo vyuzit pro utok na tu binarku, protoze vi, ze tam je.

Ale abysme nebyli jen u tvurcu kompilatoru, tvuci aplikaci nejsou prasata o nic mensi ... viz (napr) vsemozny makefiles, ktery testujou (klidne kvuli tomu helo world) pritomnost a verze stovek knihoven.

BTW: Vubec neni rec o optimalnich binarkach, to je uplne neco jinyho, nez vkladat zcela nepotrebny kod. Optimalne umim prohodit trebas obsah dvou registru aniz bych potreboval treti. Tohle ale kompilator typicky delat nebude.

[deda.jabko]

Optimalne umim prohodit trebas obsah dvou registru aniz bych potreboval treti. Tohle ale kompilator typicky delat nebude.

Jsi frajer, ale tohle kompilator delat nebude, protoze to ma opravdu k optimalnimu kodu (na dnesnich procesorech) daleko.

Prohozeni obsahu dvou registru bez tretiho vyzaduje tri provazane operace ALU, coz neni uplne levna zalezitost, pricemz by ALU mezi tim mohla jit pouzit na vypocty, ke kterym je urcena.

Na druhou stranu, vyuziti tretiho registru v podstate znamena, ze se v ramci registr renaming uvnitr procesoru jen zmeni mapovani logickych registru na fyzicke, tj. nic se nikam nepresouva.

[m.]

+1

[Michal]

Take to nebude delat z toho duvodu, ze to omezuje rozsah prohazovanych operandu. Pokud soucvet pretece, tak se to cele posere. Tak jako tak to ponici flagy a celkove je to blby napad

[Radovan]

To by mě zajímalo, co na tomhle může přetéct:

a^=b^=a^=b;

Jestli to poničí flagy opravdu netuším.

[Jendа]

Pokud soucvet pretece, tak se to cele posere.

Ty jo, tak se součtem jsem to snad ještě neviděl. Normálně se na to používá XOR. Ale jinak fakt se to se součtem rozbije i když máš aritmetiku s bezpečnými overflows? (a to nejspíš máš, protože to vyžaduje C)

[Heron]

zavery se z toho prave delat daji pomerne obsahly

Nedají. Hello world je tak primitivní příklad, že ve skutečnosti nehovoří nic o ničem. A dá se to říct i opačně, pokud někdo chce programovat cosi na úrovni hello world a použije k tomu třeba Javu a potom nadává, že k "jednomu řádku" musí mít i 200MB JRE, tak je to jen jeho chyba a jeho špatný výběr technologie. K Hello World navíc ani nepotřebuje počítač a může to generovat TTL logika nebo rovnou zadrátovaný signál v monitoru.

Ze mozna i nasobne slozitejsi aplikace nebude i nic vetsi znamena totiz proste to, ze tvurci kompilatoru nekde neco hodne posrali, protoze prave kompilator (pripadne linker) ma zaridit to, ze se pouzije a do binarky vlozi jen to co je treba.

Co má nebo nemá za úkol kompilátor toho kterého projektu je věcí jeho tvůrců.

o ktery navic autor nemuze mit ani paru, protoze ho ani ve snu nenapadne, ze by tam neco takoveho bylo.

To je ovšem jeho chyba, že si neprostuduje specifikaci jazyka, který si vybral. Navíc když je to tak známá věc objevující se ve všech debatách (a každého začátečníka trkne).

Smutny, kdyz si clovek uvedomi, ze se do par kB vpohode vejde cely system.

Chápu tě, ale stěžuješ si na nesprávném místě. Inspirativní přednáška.

Jinak pokud ti opravdu leží na srdci velikost go binárek (o čemž teda pochybuju) tak se to dá stripnout, vypnout debug apod.

aplikace zabiraj TB

Fakt jo? Jsem si nevšiml. Moje distribuce na disku se pořád vejde do 2GB stejně jako před 15 lety. (A z toho je 350MB locale, což teda vůbec nevím, proč tady je.) Jediné, co zabírá víc jsou data a tam to dává smysl a je to vlastně chtěné (ne to, že zabírají místo na disku, ale to, s jakým rozlišením jsme schopni je pořizovat a zobrazovat).

Co hur casto i naopak, tam kde by vyuziti ram smysl davalo prozmenu soudruzi vyvojari vubec neuvazujou nad tim, ze ledackdo v PC muze mit i vic nez (dnes) 4/8GB ram (gamesa zurive chroupajici na disku/ssd, zabirajici 2GB a ani tuk navic, pricemz by si vpohode mohla vzit 60GB

Ano. Memory management některých programů je ... fascinující.

[xvasek]

Hello world je tak primitivní příklad, že ve skutečnosti nehovoří nic o ničem.

Kdyby to bylo jenom o "Hello world", tak by to bylo v pohodě, bohužel stejný princip je ve světě zažraný úplně všude, a to horizontálně i vertikálně. I takové Raspberry PI je hardware s poměrně brutálním výkonem, jenomže pro "moderní" aplikace je to zcela na prd, protože je to zadušené hromadou balastu. Na druhou stranu na každé úrovni od "Hello world" až po browser určitě existuje nějaká přednáška, článek nebo aspoň mailová diskuse, kde se vysvětluje, že ten "bulky" přístup je vlastně pro danou věc nejvíc nejoptimálnější a jakékoli zlepšení není možné, protože by to bylo vlastně už jenom horší.

[Heron]

To trochu záleží na tom, co si pod těmi slovy jako bulk představíme a co všechno do nich budeme zahrnovat. A jaký výsledek chceme. Proto jsem odkazoval na Joe Armstronga, spoluautora Erlangu, který jinou svou přednášku začíná schválně naivní otázkou: "vyhodil jsem pryč jednojádro, koupil jsem si osmijádro, tak proč všechno najednou není 8x rychlejší?" Ano, všichni víme proč, alespoň v "klasickém" IT světě a s Erlangem nás neotravuj. Chceme se ještě chvíli tvářit, že neexistuje

Mezitím je na trhu 64core / 128thrd CPU.

Takže posuzovat jazyk z hlediska velikosti binárky je totálně mimo mísu, když současně s tím poskytuje velmi snadno použitelný multithreading, pomocí gorutin a kanálů lze mít tisíce interních procesů, stejně jako ten erlang někdy v roce 86. Erlangu se to nějak nepodařilo, Go (a Rust), zdá se má našlápnuto lépe. Takže třeba za pár let opravdu bude platit, koupil jsem si 512jádro a všechno je opravdu rychlejší.

Ale pochopitelně je to svobodný svět, pokud se toto někomu nelíbí, tak může všechny ostatní převálcovat tím, že hry budou mít 600B.

Jinak já mám RPI like destičku taky a nezdá se mi, že by byla zcela na prd. Provozuju na tom co chci k plné spokojenosti. Ale konverze RAWů to není, nejsem padlej na hlavu.

[Jirka]

Jestli myslíš konverze foto rawů, tak jasný, ale pokud máš k dispozici nekomprimovanej raw přímo z čipu, tak se s ním daj dělat docela psí kusy ještě před vyvoláním.
Rpi s nima lítá jak raketa, přijde z kamery v callbacku frame, ještě před příchodem dalšího ho stihnu přičíst k obsahu pole int[velikost rawu], udělat nějaký countery, pak třeba po pěti minutách takový expozice z výsledku bleskově uplácat finální raw, kdy nejsvětlejší pixel bude mít hodnotu 0xFFFF a nejtmavší 0x0000, nebo lépe nejsvětlejší 0xFFFFFFFF, nejtmavší 0x0... v 32bitech, pak to celý odmocnit a nacpat do 16bitovýho rawu. Výsledek naprosto bez šumu i s malinkým senzorem, kór když uděláš stejnej počet černých snímků, který prozměnu odečteš.
To samý i HDR, uděláš expozici pod hranicí přepalu, naplníš array do poloviny (0b0111...), pak nastavíš dvojnásobnej čas/gain, přičteš do array čtvrtinu výsledku, pak čtyřnásobnej čas nebo gain, přičteš osminu... A všechno dřív, než vyslovíš "pumpička".

[xkucf03]

Tohle by stálo za článek nebo zápisek do blogu :-)

[Jirka]

Možná bude, stavím na tom digitální fotoaparát ala 19.století (pěkně ve dřevě), jak bude hotovo, určitě se podělím.

[Heron]

Jo, tohle je přesně účel těchto destiček. Udělat z toho flexibilní předzpracování nějakých dat ze senzorů, snadno se změní alg. apod. Nikoliv se z toho pokoušet udělat univerzální komp a potom si stěžovat na výkon. Článek o stavbě foťáku bych si také rád přečetl. Třeba z toho bude jednou něco jako Chronos od Tesla500 (když už jsme u těch doporučení sledovaných YT kanálů )

[Jirka]

Když jsme u toho, nemá někdo tip na dobrou knihu arm assembler? Jestli je pravda, co jsem někde četl, že rozdíl v rychlosti C a asm je cca 5x, tak by stálo za to ho zkusit.

[gcc]

Tak v podstatě ti stačí to C zkompilovat ručně a aplikovat na to stejné optimalizace jako kompilátor a dostaneš se maximálně na stejnou rychlost, ne-li horší.

[Jendа]

To musel být nějaký extrémní případ, kdy to kompilátor totálně nedal.

Já bych ti doporučil řešit aby kompilátor přišel na autovektorizaci, a pokud to fakt nejde, tak intrinsics. Ale pro ARM o žádné hezké příručce nevím. Pro Intel je tohle a to je boží.

[deda.jabko]

Pro Intel je tohle a to je boží.

Jestli je toto bozi, tak nevim, co je pak Agner Fog. ;-]

[Jendа]

To nevypadá jako seznam a popis intrinsics, která mohu použít…

[sybik1]

"hardly seems like a big deal. Disk space is ubiquitious, even on small hardware."

Vzpominam si na jednoho kolegu, ktery byl nespokojen, ze se mu nedari zkompilovat program na analyzu zdravotnickeho signalu do dostatecne male velikosti, aby se vesla na zarizeni, ktere by mel pacient sebou.

[Petr]

Přemýšlel jsem dlouho, ale tuhle část se mi nepodařilo rozparsovat

pro go to

to je anglicky nebo česky?

[xvasek]

"pro to go" Přehozená slova. Afekt. :)

[Radovan]

Tebe to snad překvapuje? Tohle doufám znáš: http://programujte.com/clanek/2006030305-rozhovor-s-bjarne-stroustrupem/

Holt kdysi k tomu měli programátoři jiný přístup: http://www.folklore.org/StoryView.py?story=Puzzle.txt

...

Since the number puzzle was written in Pascal, it had to link with the Pascal run-time, which dragged in lots of extra code that wasn't used. This made the Puzzle over 6K bytes long, even though most of it was just the run-time.

...

It only took a few hours on Saturday to recode it in assembly language, and get it down to the required 600 bytes, since it no longer had to link with the bulky Pascal code.

...

[xkucf03]

Ten rozhovor je fiktivní, ale je povedený :-)

[Radovan]

Jo, je fiktivní, a Bjarne se prý dost vztekal když ho četl

[Blaazen]

Pěkný. Já to "Hello world" včera zkoušel ve FreePascalu a dostal jsem 30kB binárku a 12 syscallů (6 unique). Oni to lidi používaj i na embedded, tak se musí šetřit.

[skunkOS]

https://rosettacode.org/wiki/Hello_world/Text

[xkucf03]

Pozor, ten článek je dost mizerný, viz komentáře na lobste.rs.

[Andrej]

Pre zaujimavost - Hello World! vo vizualne zaujimavom ezoterickom programovacom jazyku Piet: https://www.dangermouse.net/esoteric/piet/samples.html

[_]

V pietu jsem před pár lety jako seminárku implementoval louskač vigenerovy šifry... dost maso.

[Petr]

Mít vlastní programovací jazyk je dneska známka punku. A pak se jen hledaj kritéria, podle kterejch je zrovna ten můj jazyk nejlepší..