11–20 of 21 posts
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? http://www.stackless.com/wiki/Tasklets http://www.stackless.com/wiki/Channels
"microthreads", channels, and the select statement predate go at least by a couple of decades in Alef, Plan9's libthread, Limbo, Newsqueak, etc.
Earlier quoted context omitted.
They are something new. They're a solid more approachable packaged solution which includes them in a form more available to the general programmer. And popularised by Google. Yes, these things have been used in the past. No-one denies that, and there are copious references where Stackless was based on Limbo. Every time something new comes up which uses old technology, there's always those who have to assume it means…
> At some level this becomes tiresome and unhelpful. It would help, if those promoting the new old technology would present it as bringing back something from the past, instead of a magic new technology.
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 dif…
I'm pleasantly surprised to see pypy beat go by an order of magnitude in the select_default benchmarks. Could it be a bug, or is it real?
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? http://www.stackless.com/wiki/Tasklets http://www.stackless.com/wiki/Channels
It's really quite a simple library, as all the hard work is done by gevent/stackless and most of the hard API decisions were copied from Go. I'm not smart enough to invent this stuff from scratch!
I'm pleasantly surprised to see pypy beat go by an order of magnitude in the select_default benchmarks. Could it be a bug, or is it real?
That's not a statement of pride or fanboyism or whatever... it's just the nature of the two languages.
However, I have recommended and continue to recommend that if A: you are using Python B: you want something Go-like and C: Python's performance is currently good enough for you, Stackless/gevent/perhaps this library is a much better solution than translating tons of code to another language. You can get a lot of the bang-for-the-buck with this approach without incurring huge rewrite costs. If you're starting from scratch with Go-like needs, Go is a better starting place IMHO, but Stackless/gevent is definitely "good enough", no sarcasm.
It is, IMHO, a very underestimated library in the Python community. And yes, I know lots of people know it exists... this is a statement of my yet-higher opinion of it.
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:
* consistent formatting for all code
* superior distribution story
* compiler magnitudes faster and more effective than pylint
* programs run faster and use far less memory
* far simpler semantics make it easy to read
* higher quality standard components (net/http, eg)
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.