the enterprise isnt ready. but they will be. (Score 1)

I'd split this into two questions. _will_ node.js be very successful in the enterprise, and _should_ it be.

the first is pretty easy - no. Fundamentally if you do a project in java, and it screws up, no one is going to come looking for your head - but if you do it in javascript - it doesn't matter how many gains you get - at the first tiny little problem you are going to be attacked. People are scared of new things, particularly in big business - and all those people who've spent 20 years becoming god's gift to C++ have a very strong interest in watching you fail.

however, should it? I also think this is easy.. "yes". The why is a very complicated answer.

Years ago we spent a long time "getting it working". The tools, libraries, frameworks, services and particularly knowledge (i.e. google) out there mean that any idiot can get something major working very quickly - in most cases you can just type in exactly what you want and find source code for it.

We also spent a lot of time optimising. But now computers are _fast_. and they have lots of memory. And optimisers and jits and vms are really fast. And libraries are so high level that all of your critical sections are usually in someone else's existing highly optimised code anyway. People like to talk a lot about speed - but usually conflate latency and throughput the amount of latency sensitive tasks is _very_ few and far between once you mention hft you starting having to think. And for throughput your grid or gpu able to do thousands or millions of things at once sorta makes you start laughing at the supposed 1.6x improvement you'll get for C++ over java. Then it becomes a _cost_ issue - and that has some interesting trade-offs.

When you really look at it 99..999% of code is not latency sensitive. For that that is, obviously, C is the best option. Then, as your code complexity increases, C becomes messy, and java starts looking like a good way of managing that complexity. Imagine a graph of complexity vs performance requirements - your requirement is a point on the graph and the suitability of the language is a line. Java is ok at performance, but great at complexity. C++ is _much_ better at performance, but worse at complexity - and C is just much better at complexity. As great a language as C++ is, there's just no point on the graph where it makes sense to use it. Especially as your choice doesn't have to be mutually exclusive - it's quite possible to write the 1% of code that gets executed 99% of the time in C, or hell even ASM - and use a pretty language for the rest (mind you I _hate_ java with a passion - it can never hope to equal the elegance of a C# or Miranda)

Of course, large enterprises still spend a lot of time writing code. That's because of many things - mostly because every single person is writing the same thing - and because they are all doing it in the context of "legacy" apps which have good historical reasons for what now appears to be rampant insanity.

and you start seeing the real cost of software - which is not "making it work" - but really "putting it together" - "reusing" - "sharing" - "discovering", not duplicating. And this is where C++ has really hurt the industry. It's _much_ easier to rewrite a library than to get it compiling with another one. Sorry What version of RogueWave was that?

This is something java is really good at - if you can live with the fact that every word has been used a thousand times - java libraries tends to just compose fairly well. Besos showed another way - which is to have services everywhere. That's great in theory.

But it's really hard to write a large new thing that way. It's hard to trace - to debug. and especially release. And nowadays - it's all about releasing - people talk about CI, CD - gatekeepers and the like - but websites now have to be up 24x7. Trading systems give you an hour window a day maybe - but that's going away. Software quality _expectations_ have gone up. It's no longer acceptable for your program to _crash_ (omg - it's been years) bad enough for a bit of it to error.

And we want resiliency in machines as well - it's _not_ ok for your system to go down just because one of the machine's hard drives crashes. It's not ok to be relying on just one NY - London cable - etc.

And suddenly, the problems in the "traditional" languages start becoming apparent. This whole program is linked together - as one _executeable_ you're insane - I can't just swap out one function while it's running? But I can swap out one web page in a web farm without bringing it down. Easily. It's normal. I can change the code in my CMS without even thinking I'm programming - and even have a workflow for it to go through various stages of "liveness" while the previous version just keeps on happily ticking.

I suddenly need this to run _over there_ right now. umm we need to copy the code.. install it. Is that the right os? what do you mean _and the data it was using_? Give me a month and I'll write a serialisation function for you, and then we can have that capability for this particular thing.

As we move on to a new era of software, where there are no longer "programs" - just a system that does stuff - it becomes obvious the advantages of something like javascript. It runs well anywhere. You shuffle it around as source code - but it's really like an IL - people have spent unbelievable resources trying to optimise it, and still do. It's inherently serialisable - at the code level, the data level, and even the state level. You really can just have your code attached to your data and throw it into a grid.

And - and this is vital it runs in your browser. Locally. So we can build a design that seamlessly scales across a grid of thousands of machines, but we can test it, trace it, and debug it - the server, the client, the interaction - the whole stack... on our box. Without changing anything. (beyond a configuration setting telling it where to run).

Beyond that - it really _is_ getting faster - V8 is good, but people keep pushing the envelope. That speed improvement works on _all_ code out there. More interestingly, people have already started looking at javascript and gpus. Gpu's are interesting because you inherently have another language anyway - you have your host language which is just uploading a shader program. So the most highly optimised C program on earth will have _exactly_ the same performance as the javascript version if you are offloading all the heavy lifting to a GPU.

And as a programmer. (and to some extent ignoring lisp) - it's the first viable language with any semblance of speed to include an "eval". C++ people have been metaprogramming for a long time, it's its single best justification for existence, and scala and boo are interesting - but really? compared to the metaprogramming/AO/weaving and other capabilities of a language that has reflection and eval, the are all jokes. (interestingly objective C actually can come to THIS party. not many others :))

Also - cost was mentioned earlier, as a speed trade-off. People ignore the fact that software is _really_ expensive. This is much to do with the sort of things mentioned earlier - people writing the same things over and over again or wrestling with connecting to or extending something that wasn't designed to be connected or extended.. but there are other elements. Look at how fanatical smalltalk people get - it's because they are programming into a live environment. Bret Victor in his amazing videos have shown the modern potential of this - computers are fast enough now not just to compile as we type, but to run, analyse and even simulate things like time.. I'm committed to the concept of TDD - but he's envisioned a future way past that - a live world that you type into and the computer assists you coding. And because you are writing into an existing world - you only have to code the function you need. You don't need to make yet another main - yet another parameter parser - reference that library yet again etc. I don't think anyone who hasn't tried it can understand just how much more productive it's possible to be - a programmer doing this sort of thing compared to some bearded old guy writing c++ into vi is not going to be 2 or 3 times faster, they are going to be 50-100 times faster

Finally, people really are writing the same thing all the time. The simplest client server app in a modern enterprise has three different representations of most objects - the C# or javascript representation on the client - the coded representation in the message, and the java representation at the back end. So even in the simplest possible program - we've written three different versions of the code. _AND_ code to put them together. Given that the web is the obvious end state for essentially all UI - that means you are going to have a javascript representation. Therefore javascript is the _ONLY_ possible language choice if you want to write the handling code only once.. And as javascript == JSON - you also have your message format.

So - you have a language which

• is performant _enough_
• is if not the, at least one of the, most written in, supported languages on the planet
• means you can write the code only once
• supports arbitrary topology of execution
• supports hot-swapping at runtime with little risk
• supports trivially persisting code with data for true repeatability/auditability and simulation capability
• runs on essentially every device on the planet _without modification_
• and has unlimited power for the developer (reflection/metaprogramming/eval) etc
• has an extant library to do well. anything
• is getting faster every day without you doing anything new

  ie - the correct technical decision for your new project _IS_ node.js. It's just not a very wise political one. But the people who dismiss it out of hand? well throw your favourite insult in here, and you get the right idea.