[zhong-j-yu]

Yes, if you have light-weight threads, there's no question that threaded programming is better than async programming. But we are talking about heavy Java thread, and whether its cost is so high that we need to avoid threaded programming. I think the answer is no, generally.

Also, the discussion is in the context of imperative programming.

[lmm]

But there's no reason Java threads have to be heavy. Flip the question around: suppose you had a good syntax for nonblocking logic, and a library ecosystem where everything was async by default. In such a context (and we're getting there), why would you ever want to use traditional 4k threads? The only answers I can think of are for heavy number crunching and just maybe I/O on very fast dedicated devices.

So I think that's the future we're looking at: most code async, with the likes of LAPACK and some ultra-low-latency I/O libraries (hedge funds and the like) being the only users of traditional heavy threads.

[gamegoblin]

Funnily, Java's original threads (back in 1997) were green threads, but they got dropped in favor of native threads.

[dragonwriter]

IIRC, Java's original threads were N:1 green threads, while the lightweight threads in Haskell discussed above are M:N green threads. N:1 is easier to implement, and fine for single core systems, but doesn't give you real parallelism. M:N, like 1:1 native threading, gives you real parallelism, but also, like N:1, cheap concurrency (at the expense of being the hardest to implement well.)

Multicore processors and the fact that single-threaded performance basically hit a wall explains why an N:1 threading models in something with the use cases of Java fell out of favor. M:N, while still "green threads", has a somewhat different set of trade-offs versus 1:1 native threads than N:1 does, though.

[cpeterso]

Rust supports both native and green threads, but defaults to native threads.

[pron]

See my blog post about a benchmark comparing the performance of heavyweight vs. lightweight Java threads in a web server: http://blog.paralleluniverse.co/2014/05/29/cascading-failure...