Event driven development is the worst kind of programming because of the extensive use of callbacks and state maintenance/tracking. You never know the control flow by reading the source.
You have to maintain state all the time and keep track of inconsistent/impossible states.
That to me is not cleaner or easier.
I work in one of the big corps, and it never fails, event driven servers tend to be way more buggy.
Python out of the box doesn't have coroutines but you can always use gevent for that.
Python threads are real pthreads, now they are not optimal and should not be used in high load servers, because pthreads are not that light weight when you are running 10k of them. Creating servers based on python threads is as clean as coroutine threads but slower. Hence, coroutines are always favorable over them.
That's interesting. The conventional wisdom I've seen and read is that multi-threaded servers are generally more buggy and harder to reason about than using a single select loop with callbacks. Callbacks are more difficult to maintain state with, but they don't have race conditions and locking issues.
I agree that if you can get coroutines in your language, then perhaps that's the ideal path to take.
You have to maintain state all the time and keep track of inconsistent/impossible states.
That to me is not cleaner or easier.
I work in one of the big corps, and it never fails, event driven servers tend to be way more buggy.
Python out of the box doesn't have coroutines but you can always use gevent for that.
Python threads are real pthreads, now they are not optimal and should not be used in high load servers, because pthreads are not that light weight when you are running 10k of them. Creating servers based on python threads is as clean as coroutine threads but slower. Hence, coroutines are always favorable over them.