Ajax Girl

I remember talking with Ben and Brendan Eich about threading in JavaScript. It has come up at the Ajax Experience and as Brendan says:

So my default answer to questions such as the one I got at last May’s Ajax Experience, “When will you add threads to JavaScript?” is: “over your dead body!”

In Brendan’s latest piece he tells us yet again that threads suck and that JS3 will be ready for the multicore desktop workload.

There are better ways. Clueful hackers keep rediscovering Erlang.
Then there is STM.
One retro stylist I know points to an old
language-based solution, Hermes.

A requirement for JS3 (along with hygienic macros) is to do something along
these more implicit lines of concurrency support. In all the fast yet maintainable MT systems
I’ve built or worked on, the key idea (which Will Clinger
stated clearly to me over lunch last fall) is to
separate the mutable unshared data from the immutable shared data. Do that
well, with language and VM support, and threads become what they should be: not
an abstraction violator from hell, but a scaling device that can be composed
with existing abstractions.

So here’s a promise about threads, one that I will keep or else buy someone
a trip to New Zealand and Australia (or should I say, a trip here
for those over there):
JS3 will be ready for the multicore desktop workload.

Does this mean we won’t be hand-coding MT Gecko? I think Graydon said it best: “I’d rather eat glass.” Most high-level concurrent Mozilla programming will be in JS3 on the back of an evolved Tamarin.

Another popular concurrent paradigm that seems to be talked about a lot recently is COmega with its chords. I look forward to see if JS3 can pull of making things work well on multicore without putting the burden on the programmer.

Source: Ajaxian
Original Article: http://ajaxian.com/archives/js3-will-be-ready-for-the-multicore-desktop-workload