There was a post linked here a couple of days ago where JWZ was bemoaning the lack of #!/usr/bin/javascript - and it's still not possible to use JS as a general purpose language a la Perl, Python, Ruby, etc.

I know it has all sorts of negative stereotypes, but the combination of JavaScript and PHP is the new Visual Basic - something that will let someone who isn't an expert quickly make a useful GUI application. And it won't go anywhere VB didn't go.

Yeah but #!/usr/bin/node does work. I've used some node.js command line scripts, and it works decently well. Some people praise Node.js for general purpose command line scripts. Personally, I find Ruby easier to use for command line utilities and scripts.

It's more than that - if you could assume #!/usr/bin/javascript (Or c:\windows\system32\javascript.exe) on any machine that had Netscape installed, then you'd have a viable ecosystem. The reason Perl became popular was not because it was the "best" language for CGI scripts but because you could assume that the sysadmin had already installed it for his own use. Node.js (which admittedly I've never used) would appear to be available only on a tiny minority of machines you would encounter "in the wild".

> Node.js (which admittedly I've never used) would appear to be available only on a tiny minority of machines you would encounter "in the wild".

Given that it really only hit the public consciousness last November or so, that's more or less expected. What makes people so bullish is that the number of JS developers isn't going to decrease any time soon.

It is, however, a pretty awful shell scripting environment and I don't know who would prefer it to Ruby. I say this despite writing a build system for it this weekend to drop dependencies on Ruby and Java. Coffeescript improves things but it's still pretty raw.

JavaScript is definately a candidate, but I don't think it's going to be node.js. Doing all IO asynchronously strikes me as very premature optimization. I prefer the way Go or Erlang deal with these scaling issues.

Funny you should consider async i/o to be premature optimization. To me it looks like the only reasonable way to build a non-trivial system.

Threads on the other hand, are the often the wrong optimisation -- processes are the right one.

The distinction of threads v processes is not something that necessarily influences the logic of our code. If I want to say a() b() c() I can do that with a thread or a process and it doesn't matter what a, b or c actually do. However, with the "IO must be asyc" stipulation, I have to know whether any of those functions is an IO call, because if it is, I have to write it in a completely different way, even if the logic I need is synchronous. I don't like that kind of interference with my logic.

Well, with very high probability, your logic is broken in the face of errors / malicious users then.

Node's async structure is just taking the async model of the web one step further, into processing the same request asynchronously if you need to wait for something else.

You might be master of doing this logic right, but I've audited tens (perhaps hundreds) of systems, and all the synchronous ones got it wrong.

(Disclaimer: I've never worked with Node. But I've been writing async servers in C and Python since 1999).

Node.js has synchronous, blocking IO options along with all the async ones. Just append Sync to the end wherever it makes sense.

I'd like to add that I already count Javascript as a "big language" as I wrote:

As we all know C, C++, C# and Java are these big mainstream languages of today with “recent” additions Python, Ruby, Javascript and, especially in the Apple world, Objective-C.

I totally agree with you that Javascript is going to get much bigger but to me it is already big so it doesn't even need to contend against the other languages in my blog post ;).

I think the problem with F# is going to be competition from Clojure (which also runs on the .NET platform).

I don't think that there will be that many competition, the ML folks that really want to try something new will go to F#, the Lisp folks will go to Clojure. Still there aren't that many reasons to abandon Common Lisp for Clojure(specially with Oracle controlling the JVM), or ML for F#(for Haskell maybe, but Haskell has its problems too).

The only existing reason is that the two of them run on modern, enterprise accepted platforms. If you're hacking your personal projects in Lisp, you have no reason to switch. If you want to sling some Lisp/ML at work, well Clojure of F# are likely to be your only options.

In that setting, I think F# has an advantage currently, since it's an officially supported/blessed language on Visual Studio and .NET.

You could say Clojure is a Java library. It's a single JAR file.

To ship it, yes, but there's the compiler, too. With F#, if your organization uses the latest Visual Studio, you're good; but if your shop uses a typical Java IDE setup, anyone who wants to build your project has to do extra work beyond the standard environment (e.g. installing Clojure's Eclipse or NetBeans plugins, with extra fun if you depend on Clojure libs that use Leiningen).