[Videó] Backend: Python vs. JavaScript

HUP

Ha valaki neki áll web alkalmazást fejleszteni, akkor gyorsan felmerül a kérdés, hogy milyen nyelven készüljön a backend. A Python mind backend nyelv egy elég gyakori választás, de sokakban felmerül a kérdés, hogy miért is? A prezentációban azt járjuk körbe, hogy a nagyvilágban ki mit gondol erről, valamint milyen érvek szólnak mellette és ellene.

(Dr. Guta Gábor (Axonmatics) előadása a HWSW free! meetup-sorozat 2021. november 29-i modern webfejlesztés című állomásán hangzott el.)

( SzBlackY | 2022. 01. 24., h – 09:51 )

A Python mind backend nyelv egy elég gyakori választás, de sokakban felmerül a kérdés, hogy miért is?

A magyar mind beszélt nyelv egy elég gyakori választás errefelé, de sokakban felmerül a kérdés, minek?

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

A kriminális tükörfordítást (legalábbis remélem, hogy az...) leszámítva egy gondolatolvasó. Bennem is felmerült a kérdés, hogy miért is.

Miért választ valaki szerver oldalra:

  • egyszálú (global interpreter lock-os)
  • interpretált, lassú
  • gyenge memóriamenedzsmenttel rendelkező (pl java GC-hez képest fapados, buta, rosszul profilozható)
  • borzasztó típuskezelési anomáliákkal terhelt (főleg a js, de python ducktyping is meg tudja keseríteni az életet)

programnyelvet?

Régóta vágyok én, az androidok mezonkincsére már!

backendet csakis assemblyben szabad irni!

amugy python WSGI kikeruli ezeket a problemakat, mert a php-fpm-hez hasonloan tobb peldanyt is futtat(hat) es "terheleseloszt" kozottuk, ha kell, restartolja oket.

a memoria py-nal nem szokott gond lenni (nem ugy mint javanal).

interpretalt, de leforditja (JIT) es mivel 1 wsgi processz rengeteg kerest is kiszolgal, csak inditaskor/betolteskor kell 1x interpretalni, ez nem akkora problema a gyakorlatban.

Persze workaround-ok vannak, csak mindennek megvan a maga hatulutoje is. Eleve ott kezdodik, hogy az egesz architekturadat az alapoktol kezdve WSGI kore kell tervezned. Persze megvannak a design patternek ra (kulon api service, kulon dispatcher, kulon worker service, mindezeket rabbitmq-val osszedrotozni, majd keruloutak beepitese a get-ek gyors kiszolgalasara, majd az igy fellepo konkurenciaproblemakra tovabbi hack-ek beepitese stb). Alapbol egy workaroundra fejlesztesz.

WSGI is addig jo, amig max 10-20 szimultan kerest kell kiszolgalnod. 100+ kornyeken meg csak pislogunk mint macska a padon, hogy miert kell 128GB ram...

Memoria a py-nal nem szokott gond lenni - ha folyton ujrainditgatod a kiszolgalo processzeket. Tud mar esetleg valamelyik python runtime vissza is adni felszabaditott memoriat az oprendszernek?

JIT - a standard cpython ilyet nem tud. Van 1-2 alternativ python runtime (pyston, pypy), ami mondjuk 2x gyorsabb a cpython-nal. Amivel ki vagy segitve...  Raadasul 3-4 eve mikor ezzel foglalkoztam, sajnos nem minden python lib mukodott siman alternativ futtattokkal, ugyhogy nem igazan volt a cpython-nak valodi alternativaja.

Régóta vágyok én, az androidok mezonkincsére már!

Ha egy startup mondjuk a Python/Django párost választja a kezdeti gyors fejlesztéshez, akkor pont nem a microservice architektúrát fogja követni, amit felvázoltál, hanem monolitikusat egy VPS-en, ami sokáig elég lehet. Ha már kezdik kinőni, akkor jöhet a microservice, és/vagy valami cloud megoldás, ami megoldja a vertikális skálázódást. De a startupok többsége nem fogja megélni azt a pontot, hogy "jaj melyik message-brokert használjuk" kérdéskör legyen a legnagyobb gondjuk.

Másrészt meg egy szint fölött ugyanazok a skálázódási problémák elő fognak jönni nyelvtől függetlenül (legfeljebb picit később).

Nekem mind a kettõben a duck typing tetszik. Egyrészt egy hosszabb életciklusú kódnál többet olvasol mint írsz, és az olyan dolgok mint a goto definition/implementation, find all references eléggé megkönnyítik az életed, ahogy az is, hogy tudod hogy a függvény egy adott paramétere milyen típusú anélkül, hogy ehhez bele kellene másznod a függvény kódjába, vagy megnézni hogy kik hívják. Aztán az sem hülyeség, hogy megvan az a nyugodt érzésed, hogy az adott függvény egy paramétere mindig szám lesz, és soha nem valami szöveg vagy épp dátum. És nem, runtime sem fog hülyeség belekerülni mint Pl. TypeScriptnél. Az sem hülyeség, ha van rendes OOP Pl. láthatósági szabályokkal.

Miért választ valaki szerver oldalra:

 

Mort gyors benne programozni, es olcsobb gepet venni, mint embert.

 

Hallod en mar mikrokontrolleren is inkabb pythont valasztok. Es olyan problemak jonnek elo mint 3 naponta elfogyo memoria es ettol lefagyo cucc.

De meg igy is gyorsabb kidebuggolni, mint c-ben megirni.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Egy bizonyos projektméretig igen, gyorsabb a pythonban fejlesztés. A gond akkor van, amikor egyrészt a projekt túlnövi magát, másrészt olyan huncutságok kerülnek elő, hogy HA meg stabilitás, meg teljesítmény (értsd: performance statement-et kell adni az ügyfélnek).

Amikor szívsz olyanokkal, hogy a mariadb driver nem képes lekezelni egy galera node failover-t. A rabbitmq driver totál misztikus hibajelenségeket produkál, ha HA-s rabbitmq clusterrel találkozik (sok-sok év után asszem tavaly javították végre, már nem dolgoztam azon a projekten, volt kollégám még utólag felhívott, hogy "végre megvan"). Mikor kiderül, hogy az eventlet behúzása lecseréli az egész socket kezelést, és domain név feloldásra a normál libnss helyett egy greendns nevű natív python implementációt rak, ami egyrészt leszarja az összes konfigurációt (pl nsswitch.conf), másrészt nem találtam benne olyan részletet, ami ne lett volna így vagy úgy hibás. IPv6-ot ne is említsem...

Sorolhatnám még a hajmeresztő hibákat, amiket ki kellett debuggolnom...

Nagy része ráadásul nem magának a nyelvnek a közvetlen hibája, hanem azoknak a libraryknek, amiket azért húzol be (vagy csak tranzitív függőségként behúzódik), hogy a GIL ellenére legalább kvázi-normálisnak látszó preemptív threadkezelés legyen.

Régóta vágyok én, az androidok mezonkincsére már!

En nem latok itt alapjaiban rossz elgondolast. Vannak bugok, teljesitmenyproblemak, amik mind javithatok nagyfelhasznalos ipari kornyezetben.

Namost ha joska-pista otthon ezt hasznalja, mert ez tetszik neki. Akkor a cegek is ebbe az iranyba fognak lassacskan elmozdulni.

Aztan amikor jonnek az igenyek, valamelyik ceg beleteszi a penzt es kidebuggoljak es megirjak rendesen.

 

Egyebkent mi lenne az alternativa? Java?:) Go?

Embert is kell talalni aki ezeket nyunyurgeti. Ha android nem lenne, sztem a java mar kihalt volna.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"Akkor a cegek is ebbe az iranyba fognak lassacskan elmozdulni." - Ez lényegében már a múlt. Kb az Openstack volt, ami miatt sokan elhitték, hogy igazi giga enterprise projektekre alkalmas lehet a python. Indult már kb 10 éve. Csomó nagy cég urgott rá, RedHat, telko vendorok és operátorok, számtalan startup, úgy 2015-18 környékén ezen pörgött mindenki, aztán elkezdett elmúlni az érdeklődés. Még a vége fele is olyan problémák kísértették a projektet, hogy python 2.x-ről hogy lehetne végre teljesen átállni 3.x-re. 2016-ban még új subprojektek indultak python 2.6-tal, mert ez volt az upstream amihez igazodni kellett (!).

A python legnagyobb rákfenéje a GIL. Workaroundolni kell, és ha workaroundolsz annak mellékhatásai vannak.

A Java nem annyira vicc, mint gondolod. Cégek rengeteg helyen használják, bár tény hogy új projektet nem szexy Java-ban kezdeni. A JVM bloat-ságáért kapsz is cserébe sokmindent, debugolás, profilozás, megfigyelhetőség terén. A JVM-ben van kb a legjobb GC (sajnos kell is). A Java-nak egy igazi baja van, hogy elkezdtek utólag kvázi-funkcionális programnyelvet csinálni belőle. Funkcionálisnak látszó elemek vannak, fejleszteni tök jó vele, de alatta teljesen imperatív, brute-force végrehajtás van, ami iszonyatos mennyiségű temporary kollekciót hoz létre és dob is el azonnal. Ez az ami miatt a GC folyton szét van tekerve, és általában borzasztóan erőforráspazarlóak lettek a java-s szoftverek. De nálunk régivágású Java service-ek simán visznek többszáz request/sec-et, 2-4 core terheléssel és 8GB rammal. Ugyanez python-ban (volt szerencsénk, újraírattak velünk 1-2 dolgot python-ba), ennek a közelébe nem tudtak menni, a wsgi-ben 100-as process pool-okkal sem. A memória ilyenkor már 64GB-ba sem akart beleférni, és a rabbit is szűk keresztmetszet lett.

Go - igazából van pár problémája, de talán javíthatóak, nem elvi szintű bajok. A GC-je fos, ezen nincs mit szépíteni (don't ask how I know...), de nem látom elvi akadályát, hogy kicseréljék jobbra. Nekem személy szerint nem tetszik, hogy nincs dinamikus library linkelés ezért minden binárisba monolitikusan belefordít minden libet. De úgy tűnik a mai docker-centrikus világban megtalálta a zsák a foltját, és kényelmes, hogy csak 1db binárist kell bedobni az image-be és mindenféle függőség nélkül. A tapasztalatom az, hogy a go-ban írt szerver-oldali programok többségükben egyszerűen működnek. Kevés a baj velük.

Régóta vágyok én, az androidok mezonkincsére már!

> hogy csak 1db binárist kell bedobni az image-be és mindenféle függőség nélkül.

 

En most csereltem le a gyari firmware-t a robotporszivoban (eleve ugy valasztottam a modelt), az opensource firmware node.js-ben van irva.

Egy darab arm binarisbol all:

https://github.com/Hypfer/Valetudo/releases/tag/2022.01.0

 

 

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"Riporter: És mondja Sir Arthur sok porblémával járt ez a munka?
Sir Arthur: Nos azt hiszem nyugodtan elmondhatom, hogy ez a munka egyáltalán
   nem járt porblémával. Szívemre tehetem a kezem, vagy bárki más
   szívére és megesküdhetek, hogy soha, soha semmiféle porbléma nem volt.
   Szó sem volt porblémáról. Azt hiszem maga arra kíváncsi, hogy járt-e
   problémával ez a munka.
R: Igen. Elnézést. Nyelvbotlás volt, szóval sok problémával járt ez a munka?
A: Rengeteggel." /Peter Cook-Dudley Moore: A hollók/

"Az élet tele van kérdésekkel. Az idióták tele vannak válaszokkal."

"Its easier to fool a man than it is to convince they have been fooled"

( Oregon | 2022. 01. 24., h – 12:57 )

Szerkesztve: 2022. 01. 24., h – 12:57

@arpi_esp

Assembly. Ehh,. Felesleges absztrakció! :)

( STP | 2022. 01. 24., h – 15:30 )

A php már smafu?!

Ha már viccelődünk...