Má Python budoucnost?

[gl]

Všem milovníkům benchmarků doporučuji prostudovat následující stránky:
https://www.techempower.com/benchmarks/

Jen aby se vám z toho ale nezamotala hlava. Ten tolikrát vychvalovaný Spring v o několik řádů rychlejší Javě je v něm totiž například pomalejší než flask s Pythonem. A to se bavíme o reálných problémech webového backendu, žádné syntetické přičítání jedničky. Jsou tam i zdrojové kódy, tak můžete začít hledat, kde soudruzi udělali chybu a přidat vlastní verzi, která tomu Pythonu natře zadek..

Tak se ukažte, jestli máte svaly i někde jinde než pod jazykem.

P.S.: Tahle diskuse mi připomíná souboje děcek v mateřské školce. Slovní spojení jako brutálně rychlá java, o několik řádů rychlejší, atd jsou zpravidla v praxi naprosto nesmyslné. Pokud si pro svůj problém náhodou nevyberete opravdu nevhodný nástroj, jsou rozdíly mezi jednotlivými jazyky zpravidla do jednoho řádu, často ještě mnohem menší a v nemálo případech o nich rozhoduje především kvalita knihoven. Tiše se tak pomíjí skutečnost, že nevhodné zpracování problému programátorem (které je v praxi naprosto běžné) klidně  způsobí 100 násobné zpomalení výsledného programu, takže zvolený jazyk/framework je téměř irelevatní.

Souhlas. Ve webových aplikacích je bottleneck většinou databáze. Backendový jazyk je jen lepidlo, které v jednom requestu nikdy nezpracovává víc dat než se zobrazí na stránku. Rychlost jazyka většinou nemá cenu řešit. Naopak, u skriptovacích jazyků je příjemná nízká paměťová náročnost a rychlý start. O rychlost běhu tolik nejde.

[Reklama]

[noef]

A srovnavate srovnatelne? Neznam ani jedno, ale opravdu umi Flask to stejne, co Spring?

Ale to jsem psal vyse, pokud mate stejne neschopne programatory pouzivajici stejne defaultni prostredi a doprasi to stejne, tak v Jave to vetsinou pobezi rychlej (asi kvuli JITu), nez v Pythonu. Take pokud prasite, tak v Jave jste alespon svazani typy, v Pythonu (stejne jako v JavaScriptu), pokud si vzpominam spravne, nic takoveho neni a mate o dalsi problem navic (typy), co musite pro kazdy kus kodu testovat.

Souhlasim, ze na male veci je to opravdu skvele, protoze se v tom rychle vyviji (Python, Ruby, JavaScript). Dokud mate v hlave cely mentalni model aplikace, tak je to zuzo. Ale jak tu nekdo jiny psal (Javaman?), tak na ty opravdu velke veci je to IMO nevhodne, protoze musite cim dal vic resit absenci formalnich kontraktu, ktere ve staticky typovanych jazycich kontroluje automaticky prekladac a proste kdyz to API porusite, tak se to neprelozi a pres to vlak nejede. V Pythonu/Ruby/JS se to vesele spusti a pokud nepisete opravdu dusledne unit testy, tak na tyto zaludnosti budete narazet cim dal casteji, jak se projekt refaktoruje, jak se meni pozadavky (ano, realnemu projektu se meni pozadavky neustale), jak se opravuji chyby a zanasejici se tak dalsi chyby, atd. Pokud nevenujete cas tem unit a dalsim testum, tak za chvili z toho mate minove pole, kde se kazdy z tymu boji cokoliv refaktorovat, aby nerozbil desitky souvisejicich veci, nove feature se placaji do stavajiciho kodu tak, aby se co nejmene upravoval stavajici a vznika z toho neudrzovatelny propletenec.

PS: K tomu PHP, to take nemusim. Jazyk "vyvijeny" clovekem, ktery nezna zaklady CS. Nekonzistentni pojmenovani a chovani funkci v std lib, vecne zbugovany parser (to mozna uz konecne zvladli v 7 opravit, nevim, moc optimisticky nejsem), nastaveni rozeste na nekolika mistech, nelogicky podmineny vyraz a mnoho dalsich vychytavek. A nez nekdo napise, ze se v tom bezne vyviji, tak to asi nemuze byt tak spatne - ano, ale musite dodrzovat seznam zakazanych vlastnosti jazyka, ktery je oproti jinym jazykum dost objemny. Kdyby se enterprise veci programovaly v BrainFucku, tak taky nebudu trvrdit, ze asi nemuze byt tak spatny, kdyz se v tom delaji mega veci.

[gl]

A srovnavate srovnatelne? Neznam ani jedno, ale opravdu umi Flask to stejne, co Spring?

Neumí a je to dobře.

Ale to jsem psal vyse, pokud mate stejne neschopne programatory pouzivajici stejne defaultni prostredi a doprasi to stejne, tak v Jave to vetsinou pobezi rychlej (asi kvuli JITu), nez v Pythonu.

Jak jsem psal výše, webové aplikace toho většinou moc nedělají. Maximálně na něco čekají. V tom případě pomůže použít neblokující framework. Například Paypal přešel od Javy k NodeJS https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/. Použití rychlejšího jazyka většinou nepomůže. Ten benchmark dává smysl jen pokud používáte nějaké opravdu rychlé uložiště jako Redis.

[noef]

Souhlas. Ve webových aplikacích je bottleneck většinou databáze. Backendový jazyk je jen lepidlo, které v jednom requestu nikdy nezpracovává víc dat než se zobrazí na stránku. Rychlost jazyka většinou nemá cenu řešit. Naopak, u skriptovacích jazyků je příjemná nízká paměťová náročnost a rychlý start. O rychlost běhu tolik nejde.

Aha, vy stale mluvite pouze o CRUD? Na to ale snad neni ani potreba specialni BE a staci nejake hotove reseni typu "Backend as a Service". Treba projekt, na kterem nyni pracuji, ma webovy rypak a rozhodne to neni jen a pouze CRUD - podle nejakeho algoritmu se ruzne updatuji tabulky a synchronizuje se to s dalsi sluzbou podle toho, jake uzivatel udela zmeny.

Pametova nenarocnost po startu IMO neni zadna vyhoda v pripade enterprise veci, kde za cenu dne prace vyvojare muzu poridit dalsi pakl pameti do servru. A i kdyby JVM potrebovalo 1GB pro start, coz realne nepotrebuje, tak to v prepoctu ta pamet vyjde na par stovek, to se asi bavime o nejakych pidi projekticich, kdyz se resi kazdy megabajt pameti zabirany VM, ktery se navic nezvetsuje s pametovymi pozadavky aplikace... Rychly start to stejne (v benchmarksgame to merili a bylo to tusim spise par stovek milisekund) - co je par (i kdyby desitek) sekund proti uptimu servru a aplikace? Pokud je navic start kriticky, tak se proste prihodi SSD nebo se udela nejaka magie s hotswapovanim trid. Jedina situace, kde to je opravdu vyhoda, jsou shell skripty*, ale tady se bavime o backendu webove aplikace a od te se neocekava, ze se bude spoustet vicekrat nez (strelim od pasu, realne asi jeste mene casto) jednou za tyden.

*: I to ale lze resit, existuje napr. NailGun, ktery udrzuje "zhave" JVM a spoustenou aplikaci mu jen prideli, takze start aplikace je instantni (po skonceni behu aplikace se JVM recykluje).

Nevim, ja osobne, pokud bych vybiral jazyk pro projekt, ktery bude mit odhadovanych par tisic LOC, zivotnost delsi nez par mesicu a potencionalne ho budou vyuzivat treba tisice lidi, tak radeji zvolim Javu (nebo neco nad JVM, v horsim pripade .NET + C#), nez to pak zpetne cele prepisovat z Pythonu a v podstate to tak implementovat nadvakrat.

[Kit]

Take pokud prasite, tak v Jave jste alespon svazani typy,...

..., protoze musite cim dal vic resit absenci formalnich kontraktu, ktere ve staticky typovanych jazycich kontroluje automaticky prekladac...

... jak se projekt refaktoruje, jak se meni pozadavky...

PS: K tomu PHP,... A nez nekdo napise, ze se v tom bezne vyviji, tak to asi nemuze byt tak spatne - ano, ale musite dodrzovat seznam zakazanych vlastnosti jazyka, ktery je oproti jinym jazykum dost objemny.

V PHP je také možné (nikoli nutné) vytvářet formální kontrakty a typové vazby.

Těch zakázaných vlastností jazyka PHP není mnoho. Žádné z běžně uváděných jsem nikdy neměl potřebu použít. Stačí programovat normálně. Jazyky C/C++ jsou jako minová pole mnohem záludnější.

Je zvláštní, jak mnoho lidí vkládá pojmy refaktorování a redesign do jedné věty, i když jsou to odlišné záležitosti, které se řeší samostatně.

[Reklama]

[Kit]

Aha, vy stale mluvite pouze o CRUD? Na to ale snad neni ani potreba specialni BE a staci nejake hotove reseni typu "Backend as a Service". Treba projekt, na kterem nyni pracuji, ma webovy rypak a rozhodne to neni jen a pouze CRUD - podle nejakeho algoritmu se ruzne updatuji tabulky a synchronizuje se to s dalsi sluzbou podle toho, jake uzivatel udela zmeny.

Podle popisu je ten projekt stále jen CRUD.

[gl]

Aha, vy stale mluvite pouze o CRUD? Na to ale snad neni ani potreba specialni BE a staci nejake hotove reseni typu "Backend as a Service". Treba projekt, na kterem nyni pracuji, ma webovy rypak a rozhodne to neni jen a pouze CRUD - podle nejakeho algoritmu se ruzne updatuji tabulky a synchronizuje se to s dalsi sluzbou podle toho, jake uzivatel udela zmeny.

Existuje nějaký Backend as a Service, který zpřístupňuje plnohodnotné SQL? Podle mne to z hlediska bezpečnosti není možné.

[gl]

Pametova nenarocnost po startu IMO neni zadna vyhoda v pripade enterprise veci, kde za cenu dne prace vyvojare muzu poridit dalsi pakl pameti do servru. A i kdyby JVM potrebovalo 1GB pro start, coz realne nepotrebuje, tak to v prepoctu ta pamet vyjde na par stovek, to se asi bavime o nejakych pidi projekticich, kdyz se resi kazdy megabajt pameti zabirany VM, ktery se navic nezvetsuje s pametovymi pozadavky aplikace... Rychly start to stejne (v benchmarksgame to merili a bylo to tusim spise par stovek milisekund) - co je par (i kdyby desitek) sekund proti uptimu servru a aplikace? Pokud je navic start kriticky, tak se proste prihodi SSD nebo se udela nejaka magie s hotswapovanim trid. Jedina situace, kde to je opravdu vyhoda, jsou shell skripty*, ale tady se bavime o backendu webove aplikace a od te se neocekava, ze se bude spoustet vicekrat nez (strelim od pasu, realne asi jeste mene casto) jednou za tyden.

*: I to ale lze resit, existuje napr. NailGun, ktery udrzuje "zhave" JVM a spoustenou aplikaci mu jen prideli, takze start aplikace je instantni (po skonceni behu aplikace se JVM recykluje).

Rozhodně je příjemnější když tyhle problémy řešit nemusíte.

[perceptron]

1. prgate rest v pythone / ruby / php.
2. tesite sa lebo zerete malo ram
3. pride 50k userov
4. server hori
5. skalujete = prepisujete do jvm / .net

[Kit]

1. prgate rest v pythone / ruby / php.
2. tesite sa lebo zerete malo ram
3. pride 50k userov
4. server hori
5. skalujete = prepisujete do jvm / .net

Pokud mi aplikace přitáhne 50k uživatelů, tak mě nebude škálování vůbec trápit, prostě ho udělám. Samozřejmě ho nebudu dělat vertikálně přepisem do JVM/.NET, ale horizontálně přidáním dalšího nodu.

[.]

1. prgate rest v pythone / ruby / php.
2. tesite sa lebo zerete malo ram
3. pride 50k userov
4. server hori
5. skalujete = prepisujete do jvm / .net

Nevim, ja osobne, pokud bych vybiral jazyk pro projekt, ktery bude mit odhadovanych par tisic LOC, zivotnost delsi nez par mesicu a potencionalne ho budou vyuzivat treba tisice lidi, tak radeji zvolim Javu (nebo neco nad JVM, v horsim pripade .NET + C#), nez to pak zpetne cele prepisovat z Pythonu a v podstate to tak implementovat nadvakrat.

No vidíte, a přitom existují obří firmy s tisíci vývojáři, kteří opouštějí .NET/Javu a přechází třeba na node.js nebo Go.
Tady je zrovna aktuální článek:
https://blog.risingstack.com/node-js-examples-how-enterprises-use-node-in-2016/

To není nic proti .NET/Jave, jen chci ukázat, že existují firmy které se (určitě po zvážení všech hledisek) rozhodnou opustit .NET nebo Javu a vydat se směrem k nové platformě. A pokud tady v diskusi od některých zaznělo, že cokoliv skriptovacího je tak akorát na 200 řádkový skript, tak tyto firmy ukazují, že ony si to nemyslí. Taky se tady někteří chvástali 300kLOC programy. Nic proti, i takové jsou potřeba, jen si nemyslím, že počet řádků kódu je měřítkem čehokoliv. Možná jen managor má dobrý pocit, že za ty vyplacené peníze má něco, co může vykázat. Ale nabízí se otázka: nežije architekt této aplikace někde v roce 1995? Kdo bude tuto aplikaci udržovat, jak se bude reagovat na měnící se podmínky. Dnes se aplikace píší jinak, vytváří se malé týmy a každý pracuje nad samostatným problémem.

Osobně si myslím, že statické typování má velký význam, ale na druhou stranu si nemyslím, že je to spása na všechny problémy. Pokud tady někteří propagují, že se statickým typováním nemusí psát unit testy, tak to je naprosté nepochopení funkce unit testů.

[perceptron]

No vidíte, a přitom existují obří firmy s tisíci vývojáři, kteří opouštějí .NET/Javu a přechází třeba na node.js nebo Go.

to je pravda

node.js tiez neriesi ramku :-)

[Ondrej]

1. prgate rest v pythone / ruby / php.
2. tesite sa lebo zerete malo ram
3. pride 50k userov
4. server hori
5. skalujete = prepisujete do jvm / .net

Tak prvně nebudu blbec a nebudu mít web od kterého něco čekám jen na jednom stroji, ale budu ho mít nejlépe navržen tak, aby mohl běžet v clusteru, kde na větší zátěž zareaguju tak, že přidám další node. Nebo se mě to nebude chtít řešit a šáhnu po nějakém hotovém řešení, nebo na to celé budu kašlat nechám to na jednom stroji a budu si pak nadávat že sem osel. Zvolenej jazyk mě tenhle problém možná oddálí, že chudák jeden server utáhne víc lidí, ale rozhodně nevyřeší.

[noef]

Například Paypal přešel od Javy k NodeJS https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/. Použití rychlejšího jazyka většinou nepomůže. Ten benchmark dává smysl jen pokud používáte nějaké opravdu rychlé uložiště jako Redis.

Zrovna nedavno jsem nekde cetl, ze NodeJS je neuveritelny hype a ze v JVM svete vsechny veci, co umi, davno existuji (nemam zkusenosti, ale neni treba Spring Reactor v podstate ten stejny princip?).

IMO takova Scala + Akka je mnohem lepsi pristup - out-of-box se to da skalovat jak do vice vlaken (podobne jako cluster s NodeJS, akorat bez nutnosti zpetne resit IPC, protoze aktori z principu pouzivaji zpravy) tak na vice stroju (to uz netusim, jestli v NodeJS nejak lehce jde).

Pametova nenarocnost po startu IMO neni zadna vyhoda v pripade enterprise veci, kde za cenu dne prace vyvojare muzu poridit dalsi pakl pameti do servru. A i kdyby JVM potrebovalo 1GB pro start, coz realne nepotrebuje, tak to v prepoctu ta pamet vyjde na par stovek, to se asi bavime o nejakych pidi projekticich, kdyz se resi kazdy megabajt pameti zabirany VM, ktery se navic nezvetsuje s pametovymi pozadavky aplikace... Rychly start to stejne (v benchmarksgame to merili a bylo to tusim spise par stovek milisekund) - co je par (i kdyby desitek) sekund proti uptimu servru a aplikace? Pokud je navic start kriticky, tak se proste prihodi SSD nebo se udela nejaka magie s hotswapovanim trid. Jedina situace, kde to je opravdu vyhoda, jsou shell skripty*, ale tady se bavime o backendu webove aplikace a od te se neocekava, ze se bude spoustet vicekrat nez (strelim od pasu, realne asi jeste mene casto) jednou za tyden.

*: I to ale lze resit, existuje napr. NailGun, ktery udrzuje "zhave" JVM a spoustenou aplikaci mu jen prideli, takze start aplikace je instantni (po skonceni behu aplikace se JVM recykluje).

Rozhodně je příjemnější když tyhle problémy řešit nemusíte.

Toz zmeril jsem to a hello world vychazi takto:
OpenJDK 1.8 - 17MB
Python 2.7.5 - 4MB

VPS se snad bezne ani po par mega pameti stelovat neda, takze tu nevidim zadne problemy k reseni - proste placnu minimalnich 1GB a ono to svete div se staci i pro Javu.

Aha, vy stale mluvite pouze o CRUD? Na to ale snad neni ani potreba specialni BE a staci nejake hotove reseni typu "Backend as a Service". Treba projekt, na kterem nyni pracuji, ma webovy rypak a rozhodne to neni jen a pouze CRUD - podle nejakeho algoritmu se ruzne updatuji tabulky a synchronizuje se to s dalsi sluzbou podle toho, jake uzivatel udela zmeny.

Podle popisu je ten projekt stále jen CRUD.

Hmm, takze desitky minut pocitani pomoci nejakeho proprietarniho algoritmu je podle vas CRUD jak vysity? Tak to asi vlastne nemame jine ulohy nez CRUD, kdyz kazdy ukol musi data cist a plivat => CRUD, ze? Ne, databaze to opravdu nepocita...

No vidíte, a přitom existují obří firmy s tisíci vývojáři, kteří opouštějí .NET/Javu a přechází třeba na node.js nebo Go.
Tady je zrovna aktuální článek:
https://blog.risingstack.com/node-js-examples-how-enterprises-use-node-in-2016/

A taky existuji firmy jako Twitter, kteri presli z duvodu vykonu k JVM. Ja nerikam, ze to nejde delat v NodeJS, jen ze si myslim, ze je to spatny nastroj, pro vyvoj "ve velkem".

Osobně si myslím, že statické typování má velký význam, ale na druhou stranu si nemyslím, že je to spása na všechny problémy. Pokud tady někteří propagují, že se statickým typováním nemusí psát unit testy, tak to je naprosté nepochopení funkce unit testů.

Jestli to "nekteri" je na mne, tak ja nepsal, ze staticke typovani plne nahrazuje unit testy. Ja psal, ze bez statickeho typovani musite psat testu mnohem vice, testu, ktere by se psat manualne nemuseli, kdyby se pouzil staticky jazyk.

[Kit]

Taky se tady někteří chvástali 300kLOC programy. Nic proti, i takové jsou potřeba, jen si nemyslím, že počet řádků kódu je měřítkem čehokoliv.

Většinu takových aplikací, které se mi dostanou pod ruku, zkracuji na cca třetinu pouhým refaktorováním. To by člověk nevěřil, kolik zbytečností a duplicit se v nich obvykle nachází.

Osobně si myslím, že statické typování má velký význam, ale na druhou stranu si nemyslím, že je to spása na všechny problémy. Pokud tady někteří propagují, že se statickým typováním nemusí psát unit testy, tak to je naprosté nepochopení funkce unit testů.

Statické typování má velký význam, pokud se neomezuje na číselné a řetězcové typy, což bývá bohužel velmi časté.

Hezky je to vidět na Haskellu. Pokud někdo napíše typovou deklaraci

Kód: [Vybrat]

funkce :: Int -> Int -> Int -> Inttak to neříká prakticky nic o tom, co ta funkce dělá a co je jejími parametry. Autor místo toho, aby nahradil "Int" tím správným typem, to popíše do zbytečných komentářů.