Looking forward JavaScript could be adopted as the programming language of large enterprises; looking forward JavaScript could become the backbone of integration layer, and the solution for building microservices in enterprise level. 

It might be ok at the I/O layer but not for computation. That's the realm of functional languages. 

+Dean Budd I mostly agree with that.  The work that Google's been doing with V8 with JIT and other bits and pieces can make JS faster than you think.  It's biggest problem is that it's not multi threaded so for a computationally expensive use case you'd have to fork child processes.  Depends if you think that's worth it or not.

+Dean Budd​ Deano, it's the time to rethink JavaScript, non-blocked I/O, non-JVM, and really really fast ... skipped 10,000 words explain more to you here.

Medical research has shown evidence that long-terms functional programming leads to the damage of body and low birth weight of infants ...

:-)

Yeah, I agree it's good at i/o, but not at computation, like big data map reduce, etc. What I see is a future of non-blocking i/o at the top and functional (multi-core) at the bottom. I don't see one single language being appropriate for every part of a complex system. 

The JVM argument is dead anyway. Docker has seen to that and therefore I think languages like Haskell, LISP, Elixir/Erlang are going to be more common in the future.

The guys here have been doing some Elixir coding. It looks pretty amazing. Erlang has a very solid distributed programming model. The guys who wrote RabbitMQ, re-wrote it in Erlang. I doubt very much they considered Javascript. RabbitMQ is blindingly fast.

elixir-lang.org

I've decided Elixir will be the next language I try to learn. I've got a pretty good handle on Clojure/LISP now.
I always suggest to learn something that takes you out of your comfort zone. Something that changes the way you think about programming and rewires some of those old neurons. It's time to leave Java.* in the past I think ;)

LOL! I just read your long-term functional programming research results!!! HAHAHA

Just for a bit of a brain teaser +Dean Budd with a big data map-reduce where's all the data living?  Have you buffered it all into RAM to have individual threads process it?  Are you forking out the $$$ for a box or two with lots of RAM?  Are you reading in chunks of data off disk, processing it and potentially dumping it to a store for reuse?  Are you having distributed map-reduce to speed up the computation?  All but the first option involves a lot of IO and threads blocking.  Would a Node based application really be much slower than a traditional JVM app (you love your Clojure :p)

I personally wouldn't use Node for CPU intensive tasks, but as our problem domain gets bigger the amount of IO we do increases so we need to take a holistic approach which is damn hard, because there's so many shiny toys out there.

RAM

You should have went to this talk. It was pretty eye-opening ;)

http://yownights.yowconference.com.au/dave-thomas-huge-memory-collection-oriented-programming-less-code-more-speed/

Next time you go invite me.  I'll buy the beer ;)

(handshake) Actually I took this thing off topic. The stuff I'm talking about isn't really 'enterprise' software. Maybe Javascript-Everywhere might take off in that space. But I kind of doubt it to be honest.