Thread from a programming perspective is pretty much anything, that shares memory and has an implicit context switching. Which is very different from other, mos

Thread from a programming perspective is pretty much anything, that shares memory and has an implicit context switching. Which is very different from other, mostly event-loop based, concepts, that don't give up control implicitly. It is very important not to mix them. Even something that looks like a thread, but can only switch context when there is a special keyword, is not a thread anymore, and unlike a thread is very precise of what can and cannot be executed out of order and access memory willy-nilly. I actually implemented a C-dialect DSL once, that did basically this, i.e. added to C reenterable functions with heap allocated context and an event loop to run them. I eventually abandoned the project and the idea, as synchronous code isn't that good to work with. Even Erlang's "synchronous" processes receive messages in an event driven fashion. I think you didn't have a pleasure to work with event loops in languages with first-class functions, that's why you think they are on the same boat with green thread. They are not, of course. There are no trade-offs. You have multiple scopes to share memory from, one for each handler, that can execute only atomically, one for all handlers created by that function, that may execute out of order, and a global scope of course. You can compose functions, give them names and what not. You can even have a console, like Erlang does. I've tried like a dozen of concurrency models, you cannot really convince me, that threads are any good for that.