3 ms·

''Am curious. Where in basic web development does concurrency help? As far as servers go, evented servers(thin, mongrel) will perform as good as, if not better,

• irahul 14y ago
  > I don't know what is 'basic web development', The type of web development where your controller renders a page. BTW I was quoting OP, where he mentioned he uses Java for basic web development. > I mean if you are a front-end developer/designer and mess with CSS/JS/HTML all day (without format CS education), you are probably wondering why concurrency even exists, but in real-world programming you can't go far without it. I said evented servers out-perform threaded servers. Threaded servers will eat more RAM and have higher cost of context switching. As far as application code goes, your controller isn't supposed to spawn threads(at least mine doesn't). The heavy-lifting should be done by the background services, and you can very well do concurrency in Ruby/Python(EventMachine, gevent). Generally, threaded code doesn't cut it where number of threads are large. And I am pointing this out for the second time. You ignored it all and went on a tangential regarding how I am a frontend developer/designer without formal cs education, and am wondering why concurrency even exists. > but in real-world programming you can't go far without it. Yay. No true scottsman. All programming is real world programming, and you can go far without concurrency. Are templating engines real-world programming per your certification institute?
  • democracy 14y ago
    ""Yay. No true scottsman. All programming is real world programming, and you can go far without concurrency. Are templating engines real-world programming per your certification institute?"" 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'. Now we are not talking about events vs threads, I still can't understand why someone should be stopping from starting a thread in any point of code, front-end or back-end. ""As far as concurrency at language level goes, very rarely have I needed to spawn a thread(I go for gevent) in the controller. Controller's job is to dispatch ASAP - everything else goes in the queue where you use EventMachine or gevent or whatever if you need concurrent processing."" 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. But to push it as a normal standard way of doing things... what for? Java is great at concurrency. 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 ). For the majority of us? Threads do just fine...
    • irahul 14y ago
      > 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.