IIRC stackless python implemented microthreads and channels before go existed - thats the whole point of stackless python - so whats the benefit here on top of that?<p><a href="http://www.stackless.com/wiki/Tasklets" rel="nofollow">http://www.stackless.com/wiki/Tasklets</a>
<a href="http://www.stackless.com/wiki/Channels" rel="nofollow">http://www.stackless.com/wiki/Channels</a>
What tulip should have been.<p>Being a long time gevent user, I found goroutines pretty familiar and even unspectacular (no pool.map?!). What really converted me to Go was all of the other ways I found writing Go programs to be more pleasant and less error prone than Python programs:<p>* consistent formatting for all code<p>* superior distribution story<p>* compiler magnitudes faster and more effective than pylint<p>* programs run faster and use far less memory<p>* far simpler semantics make it easy to read<p>* higher quality standard components (net/http, eg)<p>What I traded for this was a 10-20% drop in productivity, which I was fine with. I use Python for all sorts of quick & dirty tasks still, including some batch processing where there's a big discovery phase, but I write all my software in Go.
The big question is whether this mimics the "non-blocking" behavior of goroutines - if you block in a goroutine with a select on a channel in Go (or rather, if you do ANY synchronous operation, including network calls, channel operations, etc.), Go will automatically context switch off the goroutine and run another one. But if you have a tasklet that selects on a channel, will Goless/Stackless automatically run a different tasklet, or will that tasklet stall a thread (or worse, the GIL)? What if the tasklet is doing a synchronous HTTP call or waiting on a future to complete?