Comment by jerf | Hacker News Reader

Comment by jerf | Hacker News Reader

The biggest problem with "Javascript on the server" right now is that Javascript has no concurrency story whatsoever. You could easily hack in shared-state threading, but there would be no faster way to turn me off of Javascript forever than to do that. You could hack in message-passing, but it won't be clean and you're still going to have terrible fun trying to not pass mutable references, which, again, if you leave that in I will run screaming. STM isn't exactly going to be easy to stick in either.

(I say I will "run screaming" not merely because I don't want to deal with it, but because I don't want to deal with yet more libraries based on shared-state concurrency. No. I've left that behind and I'm not going back, and certainly not in a space where I've got an abundance of languages to choose from.)

Without a solution to that problem, I see this as a terribly, terribly wrong move, and a terrible time for JS to try to be picking up the server. Servers are in the multicore age and have been for a couple years now.

(And if your answer is "well, we'll just keep all the tasks simple and we won't need multiple threads", I would remind you that you're running on the server, which often needs to do, you know, actual work. A language that can't do that may have a small niche, but it's going to be an uphill battle against entrenched competitors.)

One solution that will almost certainly get implemented is WebWorkers. From that you get string-only message passing (though it'd obviously be easy to do json-encoding of data in messages) between js processes.

That, combined with event based non-blocking apis for managing multiple tasks neatly covers more or less everything you can do in many other mainstream languages like Python and Ruby (excluding some magic in native code extensions).

That makes some sense. I would agree that it should be optimized to specify that JSON-able objects should be passable in such a way that it is if they are being fully serialized out to strings then deserialized again, giving the implementation the ability to do some optimization (which may or may not be a good idea but you'd have to try it to find out, best not to write yourself into a corner), but actually doing that in a library would be easy enough.

Given the way that JS performance has been moving, that would indeed be able to take on quite a workload, if you can run a decent number of "webworkers" at a time.

What use cases are you envisioning where threading will be essential? Or aiming in the opposite direction, what use cases are people envisioning for server-side Javascript at all?

I presume its anticipated niche is as a CGI-type replacement --- relatively light-weight 'programs' executed per request. If that's the case, is there much need for multithreading?

"What use cases are you envisioning where threading will be essential?"

In 2009, my default presumption is that an emerging platform that probably won't even be viable until 2010 ought to have a concurrency story better than what we already had. If it doesn't have that, why wouldn't I use an existing language?

If it were entering a vacuum, sure, great, no problem, but it's not.

I guess this goes back to my old standard for examining the usefulness of a language: "What problem does it solve?" There ought to be a single sentence that says what problem the language solves. Python: "It's too hard to program; we need to make it easier." Perl: "Too many separate UNIX tools, we should merge them together." Haskell: "Our academic theory is great and all, but we need to come out of our ivory towers and prove it works.

Javascript on the server: "..."? "I really want to be able to use the same language on the server as the client" is a I think what it's going for, and as far as that goes it's ok, but my objection is that it isn't a very good server language. And note my objections really are about the language, not merely a lack of libraries, which is completely solvable. You can't just graft on concurrency anymore, at least not as far as I'm concerned; my standards have risen.

While I agree with you that the lack of concurrency is problematic in the long run I think that JavaScript on the server will be at least as useful for many web applications as PHP, Python, Ruby, Perl - all of which have modest or non-existant concurrency stories.

I'm curious as to why you think JavaScript can't hold it's own weight against said-languages for the server-side?

as a commenter below me pointed out, there is node.js which got some attention recently.

there was a rather long concurrency discussion on commonjs http://groups.google.com/group/commonjs/browse_thread/thread...

there was no consensus and the topic was delayed for later discussion - but it seemed the promises idea got most attention (my pov) http://wiki.commonjs.org/wiki/Promises

I agree, although OS processes, job queues, and libevent/libev can help in many cases. Erlang is also an option for when you need massive concurrency.

http://nodejs.org

I don't think node.js handles anything related to concurrency... what if you wanted to write a multithreaded raytracer in javascript?

Arguably you can use webworkers (available on V8 and JSC, and thus Narwhal on those platforms) for concurrency problems. Webworkers enforce no shared state though, they use a message passing mechanism. Not the greatest solution.

Concurrency is important, but I think most server tasks don't require it. JavaScript doesn't need to be the 100% language to "win" it just needs to be the 80% language.

HTML5-style Workers are coming to nodejs.

Here's a javascript raytracer: http://www.slimeland.com/raytrace/

Wouldn't be hard to implement the rendering part as WebWorkers.

Reply on news.ycombinator.com