> Oh yes, part of the real-world where concurrency (via threads) is the core of the system, not some niche sub-technology like 'slow templating PHP engine'. Yo

> Oh yes, part of the real-world where concurrency (via threads) is the core of the system, not some niche sub-technology like 'slow templating PHP engine'. Your claim was "you can't go far without threads in real world programming" which is now "real world programming where concurrency is the core of the system". Does it need to be said that you won't go far without concurrency in a system which needs concurrency? Isn't that a tautology? And I wasn't referring to PHP. I was referring to Jinja2. Jinja2 is neither slow nor simple, but that's tangential. What if it's slow? Adding threads will do shit as far as rendering templates is concerned. > Now we are not talking about events vs threads, I don't care about events vs threads. I care about throughput(parallelism - make 5 dns requests in shortest span of time) or co-ordinating processes(spell checker thread while I type). Processes, threads, events are all implementation details. > I still can't understand why someone should be stopping from starting a thread in any point of code, front-end or back-end. So you are twitter. I post a tweet. I have 1500 followers. Your cute little java process spawns 1500 threads to update the timeline for my 1500 followers, and I am waiting at my browser watching the loading git. How about 15000 followers? 150000? A controllers job is to return ASAP. Spawn threads all you want. Nobody is stopping you. I was talking about why you don't want that. > If your language of choice is bad at threads (and threads are hard to implement, hard to use, hard to debug, we know that) then you are lucky you can use something else to hack your way out. For the second time, I don't care about threads. Processes, threads, events, agents, transactions with STM - whatever it is doesn't matter as long as I can get the job done. > But to push it as a normal standard way of doing things... what for? I am not pushing it as normal standard of doing things. For the tasks I generally write, threads won't cut it(Java or no java). Take 1000 threads on a 4 core machine - we will have (memory per thread) * 1000 ram usage, 1000 threads contending for execution on 4 cores. Threads work fine for small values of n, and even for small values for n, threads itself come with a lot of baggage and extra care has to be taken to ensure correctness. > It also has 'event' frameworks for those who really need it for some very specific use-cases like networking (netty, grizzly,something from apache, etc ). You are responding to claims I didn't make. I didn't say Java is bad at concurrency or Java doesn't have evented frameworks.