Vlákno názorů k článku
Nejlepší programovací jazyky aneb co se učit v roce 2018 od Michal Smrž - Kéž by se nějak (nevím jak) vyřešil GIL,...

"nevím jak" je odpověď :) V tomto ohledu se mi mnohem víc líbí to jak je navržený JS - single-thread by design a pokud chceš víc tak si spustíš víc VM a komunikaci zajistíš buď pomocí messaging nebo pomocí sdílených bufferů.

Takže přesně stejně, jako se to dělá v Pythonu? Kde navíc (nezávisle na multiprocess architektuře aplikace) můžu používat i skutečná vlákna například aby mi IO neblokovalo proces?

Vlákna jsou pro high concurrency aplikace nepoužitelná, protože žerou moc paměti.

súhlasím. a nejde len o pamäť, prepína sa celý kontext a trvá to veľa času.

A objekty nejsou dost objektovy.

Ne nutně - záleží na architektuře jazyka. Kupříkladu Erlang má svoje vlastní vlákna (kterým se nesmyslně říká procesy), která jsou přiřazena vláknům (skutečným) pomocí vlastního scheduleru, který zajišťuje, že počet skutečných vláken nepřesáhne počet jader CPU - tudíž odpadají nároky na vytváření nových vláken a přepínání mezi nimi.

Velikost zásobníku vlákna je možné nastavit a minimum je tuším 4096 bytů (1 page), to je určitě míň než si vezme nový proces.

Tím komentářem jsem myslel hlavně to, že GIL se Python už asi nikdy nezbaví, ale mínusáři to nedali, protože jsem si dovolil zmínit ten ošklivý JS :) Threading v Pythonu je vtip, který má tolik omezení, že je lepší async nebo rovnou ten multiprocess.

Non-blocking io má třeba node.js přes libuv od samého začátku, takže moc nerozumím tomu příkladu s io. Co se týče vláken tak V8 už umožňuje spustit více VM v jednom procesu, takže když člověk pořeší komunikaci tak má multithreaded aplikaci aniž by musel přejít na multiprocess (v případě, že multiprocess není potřeba).

Singlethread by design je výhoda, protože není potřeba řešit věci, které rozumně v takovém jazyku řešit asi ani nejdou. Kompromis typu SharedArrayBuffer a WebWorkers v JS mi přijde jako mnohem rozumnější řešení než multithreading zabitý díky GIL.

Ale GIL to zabije jen pro výpočetní vlákna. Nezapomínejte, že je tu například i svět GUI, kde Pythoní vlákna vůbec nejsou problém. Stejné api jako threading má pak taky třeba multiprocess, jen spouští separátní procesy. Pro IO už to pak řeší novinky v oblasti async no.

Nevím, mně to moc netrápí - Python je inherentně pomalý, takže nemá cenu používat ho pro aplikace, kde je potřeba výkon (a tedy by se hodilo více threadů), a blokující operace (I/O, síť) i výpočetně náročné věci co si napíšeš v C (nebo použiješ nějakou knihovnu typu numpy) a voláš je přes Swig/(C)FFI GIL uvolňují a více threadů umí.