I think quite a bit of it is to do with lazy programmers.
With asynchronous programming, it's fairly constant. You have to think about things as you go, and once you get the hang of it, there are little surprises.
With synchronous programming you have the illusion that it is easier - fork() ! magic!. So you can get a lot done quickly. But then you have the realization that as things get more complex, you'll have to deal with locking,concurrency,scaling issues, etc. But by that time it may be too late to change architecture.
It's probably best though for programmers to work on a big synchronous system, realize just how much code you're writing to cope with the fact you asked the OS to execute your code in random order, and then hopefully realize that telling the OS to execute your code in an explicit order is probably a better idea.
>> If we look at Django or Ruby on Rails, arguably the two most promising new web application frameworks to emerge in the past few years
I'd also disagree with that. They're probably the most hyped up, but that's something entirely different. Once again, likely lazy programmers who want a framework for this, a framework for that. How about just make your own framework.
I'm still not sure I follow. Where does the "ton of code" come in? The boilerplate code around spawning new threads? The painfulness of that task varies widely amongst OS-level threading primitives, user-level thread libraries, and other programming models that let you do tasks with dependences like Cilk http://supertech.csail.mit.edu/cilk/ or TBB http://www.threadingbuildingblocks.org/ .
Personally, if I have a DAG of tasks to do, I prefer to encode that DAG in the structure of my code by breaking independent chains into separate tasks/threads/whatever and feeding that to some piece of software to do the scheduling for me, rather than roll my own scheduling in a potentially bug-prone and unscalable way. For the example shown, either is perfectly fine, but if you have hundreds of outstanding jobs with a more complex dependence structure, I'd rather not deal with scheduling myself.
without giving the game away of course, could you possibly explain the kind of features yours has that others are lacking? I'm working on 2 different web frameworks currently, 1 a long standing one and another "start from scratch" project. I'd love to include the meat of the real needed features the current popular frameworks are missing.
With asynchronous programming, it's fairly constant. You have to think about things as you go, and once you get the hang of it, there are little surprises.
With synchronous programming you have the illusion that it is easier - fork() ! magic!. So you can get a lot done quickly. But then you have the realization that as things get more complex, you'll have to deal with locking,concurrency,scaling issues, etc. But by that time it may be too late to change architecture.
It's probably best though for programmers to work on a big synchronous system, realize just how much code you're writing to cope with the fact you asked the OS to execute your code in random order, and then hopefully realize that telling the OS to execute your code in an explicit order is probably a better idea.
>> If we look at Django or Ruby on Rails, arguably the two most promising new web application frameworks to emerge in the past few years
I'd also disagree with that. They're probably the most hyped up, but that's something entirely different. Once again, likely lazy programmers who want a framework for this, a framework for that. How about just make your own framework.