Russ is pretty much describing Go as it existed in its developer's minds in 2007. He even explains nearly all of Go's (future) interesting features - with nearly identical syntax - before he even gets to an example.
A small usability note - I looked at the page, seeing no way to do anything with it, I reloaded it ("So little text, so much votes on HN - there must be something there!"), and then - still not knowing what it is - accidentally clicked on the page, which moved me to the next slide... There is no hint there that it's a presentation and you can move forward by clicking on it.
Right, it's never been either/or, they can be used to together. Several years ago I implemented libevent support at mysql using a pool of threads, allowing an order of magnitude more client processing. And for many years prior Microsoft had APIs and examples supporting similar operations on Windows.
In my view, the biggest drawback of the evented approach is that logically sychronous code involving IO becomes very low level spaghetti code. E.g:<p><pre><code> log(write(process(read(source))))
</code></pre>
becomes:<p><pre><code> read(source, function(input) {
write(process(input), function(success) {
log(success)
})
})</code></pre>
The important question is: how can humans correctly write concurrent code?<p>We think of "threads" as one of the options. The thing is that we've mostly been using threads with locks (e.g. Java), and slide #3 points out where we have gone wrong:<p><pre><code> Drawbacks of threads
...
Drawbacks of events
...
Actually drawbacks of locks and top-level select loops!
</code></pre>
In fact, it is "locks" that humans have trouble with.<p>Note the title of the presentation - <i>Threads without Locks</i> - suggesting another option. (as others have noted, this presentation describes Go, and I personally believe this is why Go will do well)<p><i>edit: wording, formatting</i>
I'm not really sure, but it seems like an Erlang execution model (except for single-assigment, to which everything can be, and frequently is, automatically boiled down anyway)
This is exactly where I want to go with RingoJS: Many threads with private mutable scope, global read-only scope, worker/actor based thread interop, one event loop per thread.<p>Currently we still have shared mutable state that sometimes requires locking (unless you resort to a functional style of programming): <a href="http://hns.github.com/2011/05/12/threads.html" rel="nofollow">http://hns.github.com/2011/05/12/threads.html</a>
Threads tend to be event driven anyway. If one used, say ObjecTime back in the Olden Days, one could actually configure which FSMs had their own O/S thread and which were shared on a single thread.<p>This being said, event-driven as a <i>design</i> choice has much to recommend it.
YES. THANK YOU. I was just ranting about this elsewhere. People go "threads are evil" with vague rationales about getting locks right and such, and insist we all use separate heavyweight processes. It's ridiculous.<p>Selection of sane data structures and communication channels can get you virtually all of the safety and ease of separate processes WITH the performance benefits of a shared memory space.<p>It reminds me of people that criticize C++ for allowing memory leaks. There as here, simply selecting the right primitives and development strategy in advance make the problem simply disappear.