There is one bit of all the current buzzwords that seems to be overlooked, like when people talk about Ruby being so productive for Web 2.0 style projects. It was part of my objection for the introduction of JAX-WS and a Web Server into Java SE 6 as well. Its the rise of async coding models.
Callbacks in JAX-WS are a great example of this, but so are lots of the dynamic elements being done in Web 2.0 and the eventing models of EDA. They require people to code in a non-linear model and require an environment that can handle threads sensibly and efficiently. Async isn't just a matter of "waiting for a request" because then you are blocking, its a matter of actually being able to trigger off a related piece of code when you get the request and then tie it back to what was originally happening and may still be happening.
Async is hard and yet all I've read so far on the web is lots of people going on about how great this new Async model is, without a mention of thread safety around. The rise of Async (and of technologies like BPEL that have Async baked into them) also makes an interesting question around the quality of developers and platforms required.
Ruby et al are all out for this world for professionals until they are thread safe, if you can't even get to that level then how on earth are you going to build ontop of it? So yup you can build something really quickly, then lob in a nice bit of async and you "sometimes" get random behaviour... nice Groovy on Rails could be a migration path for those folks of course as you get the benefits of a thread safe platform. Saying "it was okay when I tested it" isn't enough.
Remember Meyfroidt's Law, and start planning now for how you are going to make async easy for the masses.