> This is all nice in theory but if this were indeed true then Nodejs scripts should be blazing fast compared to Python and even Java considering that most prog

> This is all nice in theory but if this were indeed true then Nodejs scripts should be blazing fast compared to Python and even Java considering that most programs we write are I/O heavy and 99% of time, they're just waiting for an input from a File/URI/User? * Node is blazingly fast. * I don't think it's true that most programs are just waiting for input, and if they were, then the language you choose would matter less because you can't fix a slow user. > blazing fast compared to Python and even Java My day job is Java. I typically find that JS/TS test suites run a lot faster than Java test suites. And by that I mean wall-clock time taken to spin up, do 100-300 test cases, and shut down. > Node would have been the numero one and only language being used today? Node is a runtime, its language JS/TS is numero uno being used today. But (surprise, surprise) it turns out there are other criteria to judge languages/runtimes on. It's not just one checkbox that reads "non-blocking IO". > You can also replicate the same thing that Node.js is doing in your Java or Python too by applying multi-threading (i.e. one thread just "waits" for the I/O in the background while the other keeps doing its job). 1) If you could just 'replicate the same thing', you'd see that it's not a farce. 2) You're grossly underestimating the work required to retrofit single-threaded/event-driven onto an existing JVM/library/user-code: You can't naively schedule some method foo() onto either an IO or non-IO thread, because some part will be IO, and some part will be non-IO (fractally - because some parts of its IO work will be non-IO also, all the way down). 3) Other languages are aware of this "farce" and are trying to do it also: * My favourite language Haskell also has a runtime which does non-blocking IO. * Java started introducing non-blocking IO libs for this reason a long time ago. [1] * Some Java frameworks offer assistance to users trying to program in this way [2] * More recently, Java is trying to also embrace this "farce" wholeheartedly into the language, with Project Loom [3]. It's now mature enough that it's either been released in the latest Java, or is about to be. > I feel it's better to just implement multi-threading in your own code (as needed)... How do you feel about garbage collection or synchronised blocks? Is it better to implement those yourself rather than relying on the runtime? If not, what's the difference? JVM GC is too confusing for me to understand, but I don't want to go back to malloc(). > ...instead of using something convoluted and confusing like Node.js. You showed the blocking python code `open('xyz.txt', 'rb').read()`. Show the Node code as well, and then we judge if it's more convoluted or confusing. For all that criticism, you missed the what's actually wrong with that model, which is that you can't do true simultaneous computations (and make use of those cores in your CPU). At least you used to not be able to. Web workers came along, offering true parallelism, but I don't live enough in the JS/TS world to know if people are actually using them. [1] https://www.baeldung.com/java-io-vs-nio https://www.baeldung.com/java-io-vs-nio [2] https://reactivex.io/RxJava/3.x/javadoc/io/reactivex/rxjava3/schedulers/Schedulers.html#io-- https://reactivex.io/RxJava/3.x/javadoc/io/reactivex/rxjava3... [3] https://stackoverflow.com/questions/70174468/project-loom-what-happens-when-virtual-thread-makes-a-blocking-system-call https://stackoverflow.com/questions/70174468/project-loom-wh...