Má Python budoucnost?

[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.

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...

Stále nevidím náznak toho, že by to nebyl jen CRUD. Mezi akcí uživatele a akcí na databázi či dalších službách je jen sada transformačních funkcí.

[Reklama]

[gl]

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).

Hlavní výhoda Node.js je v tom, že v javascriptu jsou všechny knihovny od začátku neblokující a nemusíte se nijak omezovat v tom, co použijete. Třeba v Pythonu při použití něčeho jako Twisted/Tornado/asyncio musíte používat jen knihovny kompatibilní s daným event loopem. Předpokládám, že v tom Spring Reactoru to bude podobné. Akka používá vlákna. Jak jsem psal výše, s takovým přístupem zkušenosti nemám. Asi to bude v něčem lepší a v něčem jiném horší.

[noef]

Akka používá vlákna. Jak jsem psal výše, s takovým přístupem zkušenosti nemám. Asi to bude v něčem lepší a v něčem jiném horší.

Pouziva, ale pokud se nepletu, tak v jednom vlakne bezne bezi mnoho actoru - pouziva take neblokujici pristup. Narozdil od NodeJS ale actori nesdili jeden globalni mega-stav, kazdy ma svuj malicky, a zpravy jsou serializovatelne, takze je velmi jednoduche pridat vice vlaken nebo servru.

[gl]

Akka používá vlákna. Jak jsem psal výše, s takovým přístupem zkušenosti nemám. Asi to bude v něčem lepší a v něčem jiném horší.

Pouziva, ale pokud se nepletu, tak v jednom vlakne bezne bezi mnoho actoru - pouziva take neblokujici pristup. Narozdil od NodeJS ale actori nesdili jeden globalni mega-stav, kazdy ma svuj malicky, a zpravy jsou serializovatelne, takze je velmi jednoduche pridat vice vlaken nebo servru.

Myslel jsem, že Akka používá zelená vlákna o kterých mluvil Mirek Prýmek. Ale není to tak. Máte pravdu, pokud jsem to správně pochopil, blokující kód se v Akka musí obalit Future, aby nezablokoval hlavní vlákno.

[noef]

Akka používá vlákna. Jak jsem psal výše, s takovým přístupem zkušenosti nemám. Asi to bude v něčem lepší a v něčem jiném horší.

Pouziva, ale pokud se nepletu, tak v jednom vlakne bezne bezi mnoho actoru - pouziva take neblokujici pristup. Narozdil od NodeJS ale actori nesdili jeden globalni mega-stav, kazdy ma svuj malicky, a zpravy jsou serializovatelne, takze je velmi jednoduche pridat vice vlaken nebo servru.

Myslel jsem, že Akka používá zelená vlákna o kterých mluvil Mirek Prýmek. Ale není to tak. Máte pravdu, pokud jsem to správně pochopil, blokující kód se v Akka musí obalit Future, aby nezablokoval hlavní vlákno.

Ja myslim, ze hlavni vlakno neblokuje, ale sada aktoru sdili jedno vlakno - muze tedy blokovat jine aktory. Future, co jsem alespon cetl, se moc nedoporucuje a lepsi je pouzivat docasne actory (pripadne v jinem thread poolu blokujici aktory).

Nejvetsi rozdil oproti ostatnim pristupu jeto rozdeleni dat mezi aktory - zadny (nebo minimalni) globalni stav.

[Reklama]

[Mirek Prýmek]

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

Já tam teda vidím Javu na druhém a 5.-8. místě, přičemž se jí tam vetřel jenom Ur (asi málo kdo používá) a C++. První výskyt Pythonu vidím až někde na místě, do kterého se mi nechce počítat. Cca čtyřicátém?

Ty tam vidíš něco jinýho?

[ByCzech]

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

Já tam teda vidím Javu na druhém a 5.-8. místě, přičemž se jí tam vetřel jenom Ur (asi málo kdo používá) a C++. První výskyt Pythonu vidím až někde na místě, do kterého se mi nechce počítat. Cca čtyřicátém?

Ty tam vidíš něco jinýho?

Já vidím v původním příspěvku, že je řeč o Spring (na Javě) vs Flash (na Pythonu). Ty tam vidíš něco jiného?

[Mirek Prýmek]

Ja myslim, ze hlavni vlakno neblokuje, ale sada aktoru sdili jedno vlakno - muze tedy blokovat jine aktory. Future, co jsem alespon cetl, se moc nedoporucuje a lepsi je pouzivat docasne actory (pripadne v jinem thread poolu blokujici aktory).

Nejvetsi rozdil oproti ostatnim pristupu jeto rozdeleni dat mezi aktory - zadny (nebo minimalni) globalni stav.

Řekl bych, že v téhle oblasti se ty pojmy dost melou a těžko se dá říct něco, co by bylo úplně zjevná ověřitelná pravda

Ideální stav je samozřejmě takový, jaký má Erlang, jak jinak - každý actor může mít bez problému vlastní (zelené) vlákno a zároveň jich nemůže mít víc. I tak se ale nedá vyhnout tomu, že actor, který čeká na nějakou externí událost (EDIT: nemusí být ani externí, stačí nekonečný výpočet nebo cyklus vzájemných čekání), může blokovat další actory. Čistě proto, že čekají na zprávu od něj. Pokud čekají synchronně (blokovaně) a bez timeoutu, je z toho deadlock. Pokud s timeoutem, je potřeba nějak ošetřit chybový stav. Pokud čekají asynchronně, je to relativně ok, ale vyžaduje to neúměrné množství logiky kolem zjišťování, na co všechno vlastně ještě čekám, jak dlouho na to mám čekat, co mám udělat, až se to stane atd., takže tohle se uvnitř actoru prakticky vůbec nepoužívá, pokud ta funkcionalita není ze své podstaty asynchronní (není svázaná s žádným stavem, proto si k ní nemusím nic pamatovat, jenom ji odpálím a až přijde odpověď, tak na ni reaguju pořád stejně).

Takže shrnuto podtrženo, ani v (reálně dosažitelném) ideálním stavu nemůžu mít žádné silné garance o tom, že nedojde ke stavu, který si moc nepřeju (deadlock nebo chyba). Čili pokud actory poháním nějakým poolem threadů, může to (imho) fungovat docela dobře, pokud je to dobře navržené a dobře dimenzované.

Typicky i v té první "ideální" situaci chci mít věci, které můžou blokovat, uzavřené do samostatného actoru, takže pokud je tohle řešení doporučované[1] v Akka, není to žádná velká ostuda

[1] http://doc.akka.io/docs/akka/snapshot/general/actor-systems.html#Blocking_Needs_Careful_Management

[Mirek Prýmek]

Já vidím v původním příspěvku, že je řeč o Spring (na Javě) vs Flash (na Pythonu). Ty tam vidíš něco jiného?

Kromě toho tam vidím neplatné zobecnění "co platí pro Spring, platí pro Javu". Proto jsem ho korigoval.

[ByCzech]

Já vidím v původním příspěvku, že je řeč o Spring (na Javě) vs Flash (na Pythonu). Ty tam vidíš něco jiného?

Kromě toho tam vidím neplatné zobecnění "co platí pro Spring, platí pro Javu". Proto jsem ho korigoval.

Aha, já to tam nevidím :-)

[Mirek Prýmek]

Aha, já to tam nevidím :-)

To se stává, že člověk sem tam něco nevidí.

[ByCzech]

Aha, já to tam nevidím :-)

To se stává, že člověk sem tam něco nevidí.

V téhle diskuzi je to spíš naopak. Že tady často vidí něco co není ;-)

[gl]

Nevíte proč v tom benchmarku zkončil Luminus tak bídně? Zejména v latenci.

[gl]

*skončil

[.]

Aha, já to tam nevidím :-)

To se stává, že člověk sem tam něco nevidí.

Je komické, že nerozpoznáš parodii na benchmarky...