Both suck, but I'll take threading (acutally I'll take Erlang's processes the most) but if I had to choose between the two, I'll take threads.
> but wait 'till you have curl handles and say mysql handles and blah 'andles and foo andles. Fork andles!
Yup. If I have an event driven program can I use another library that is not built on the same event driven framework?
The answer is usually no. Even if it has the nice internally composible "futures/deferreds" feature.
An operation that is non-blocking will return some kind of a future/promise/deferred thingy. Those bubble all the way to the top through the API. It means you need to have 3rd party libraries and support code that knows about them.
This is the case with Twisted (which is a nice framework) but it means having to have a parallel universe of libraries for everything (because they have to return deferreds or being able to be passed in deferreds).
>Yup. If I have an event driven program can I use another library that is not built on the same event driven framework?
This is why my original post suggested that people need to start demanding better of their languages. This is a total non-issue in haskell because the "event driven framework" (that's really over-stating it, they are just relatively simple libs) is part of the language runtime. So everything uses it. I get concurrency and parallelism with the scalability of an event loop just by doing:
> but wait 'till you have curl handles and say mysql handles and blah 'andles and foo andles. Fork andles!
Yup. If I have an event driven program can I use another library that is not built on the same event driven framework?
The answer is usually no. Even if it has the nice internally composible "futures/deferreds" feature.
An operation that is non-blocking will return some kind of a future/promise/deferred thingy. Those bubble all the way to the top through the API. It means you need to have 3rd party libraries and support code that knows about them.
This is the case with Twisted (which is a nice framework) but it means having to have a parallel universe of libraries for everything (because they have to return deferreds or being able to be passed in deferreds).