Statický typing v TS je fajn, sám ho obľubujem, avšak funguje len v compile-time, naopak runtime typescriptovým typom nerozumie nedá sa s typescriptovými typmi pracovať za behu napr pomocou reflexie
V TypeScript-e som takéto reflexie nikdy nepotreboval. Veci tam do seba pekne zapadajú už v compile time vďaka vlastnostiam ako discriminated unions alebo type predicates. Môj názor je presne opačný - ak potrebujem reflexie, aby som v runtime zistil typ objektu, tak je to nedostatok daného jazyka (prípadne nevhodný návrh kódu). TypeScript je pre mňa dôkaz, že sa to dá urobiť bez reflexií, jednoducho, čitateľne a v compile time.
C++ má ďaleko pokročilejší typový systém.
V C++ nie som až taký zbehlý, ale toto tvrdenie sa mi nepozdáva
Áno, moderné C++ už má veci ako std::variant a std::optional, ale aj tak potrebujem často používať napr. static_cast a aj tak nakoniec nevyjadrím všetko to, čo by som vyjadril v TypeScript-e. Navyše, kým takýto kód v TypeScript-e je jednoduchý a čitateľný aj pre juniora, porovnateľný kód v C++ vyzerá ako dizertačná práca z matematiky a vyžaduje roky praxe. A to ani nehovorím o kryptických build erroroch, ktoré template-y produkujú.
Jestliže celou administraci bude obsluhovat jedno vlákno, bude se to vzájemně blokovat a nebo budu každou blbost explicitně pouštět ve vlastním workeru a v tom případě mi to celé přestává dávat smysl, ne?
Práve v tom je krása event loop-u, že sa to blokovať nebude. Z pohľadu programátora (aplikačného kódu) dokáže jedno vlákno obsluhovať množstvo "paralelných" requestov. Je to vďaka async/await syntaxi. Jasné, že na pozadí sa blokujúce operácie (čítanie/zápis na disk...) udejú v samostatných vlákach, aby sa využil potenciál viacerých jadier. Aplikácia to však nevidí a programátor môže existenciu vlákien úplne abstrahovať. Jedinou výnikou je, ak máte dlhú časť kódu bez await a skutočne začnete blokovať vlákno. Vtedy tam stačí niekde dať await a je to vyriešené. Za mňa výborný trade-off.