| Concurrency is not much of an issue, you write concurrent JS apps like you write them in other languages. There are three types of applications, and two are easy in JavaScript. The first is something that is well within the capabilities of one modern CPU core. This class of applications includes every program that's currently running on your machine. Servers that only do IO (message queues? memcache? SMTP?) can also be included, in many cases. This is easy to handle because there is no concurrency. For IO, you use an event loop, of course. The second class of application is something like Facebook. One machine will never be enough to handle it, so you design for it to be as distributed as possible. Each app is "shared nothing" and passes messages to communicate with other components. Obviously, JavaScript will do fine here. Each tiny component runs on one CPU core, and then you run a million copies of the app on 250,000 4-core servers. Easy. Need to double capacity? Just buy more servers. Wonderful. The third case is the Enterprise Application. This is something like your company's HR portal or your online bank. It's an application that's the swiss-army-knife of applications. It slices, dices, and reads email too. Just compiling it is a week-long process involving 10 engineers and 4 consultants. For maximum SPEEEEED, everything happens in its own threads, which share 100% of everything with the other threads. (How could you read email and RSS feeds and check your paycheck if there weren't threads!?) This type of app can only ever run on a single machine; if it's too slow, IBM and Oracle would be happy to help you out with a marginally-faster box for a few million more dollars. Since everything is shared, once you hit the most expensive hardware, that's the best you can ever do. If you wonder why it takes 120 seconds to load your bank account balance... this kind of app is why. And no, you can't write one of these in JavaScript. Shared-state threads are not implemented. What a loss... |