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?
It looks like the goal of the project is mostly to adopt the syntax of Go. Instead of using gevent, Greenlets, Coroutines, etc.. they use "goroutines"..
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 that it insults the old adopters in some way. Or that fealty has to be paid to the old adopters. At some level this becomes tiresome and unhelpful.
Stackless Python isn't a simple out of the box framework, it's a basic set of primitives. New users have to overcome many of the same problems. Using a framework above Stackless, is a huge aid in gaining the benefits which the Stackless primitives provides. Only in the later years, has 'stacklesslib' been created to formalise some of the standard practises in a higher level framework.
The benefits to new frameworks based on Stackless are obvious if you use Stackless.
Keep in mind, I am good friends with the Stackless maintainers, worked with Stackless professionally, and this project has had a lot of input from them. Richard (rmtew) is also a central Stackless figure. Richard has pretty much said everything I would have to say, but I just wanted to chime in to make explicit that goless is a tribute to stackless (and go, and gevent, and everything before it), not trashing them.
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!
The benchmarks weren't really fair. Go was using it's reflection-based select. I will publish some new benchmarks (with an idiomatic Go switch select) soon, since someone is finishing a PR with that change. I am not sure what we'll find but I am sure Go's performance will improve.
Even if it is real, Go is otherwise going to stomp Python performance-wise.
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.
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?
Hi ceptorial, I have toyed around with this a lot. Ultimately goless is just a wrapper over stackless a gevent, which bother offer monkeypatches for the stdlib. So if you want this behavior, you can just monkeypatch first, and everything should work. I decided not to wrap the monkeypatching (for now) because I did not want to get bugs about how it doesn't work :) However I should make note of this in the docs. You should make an issue or PR!
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.
20 comments
[ 5.6 ms ] story [ 61.0 ms ] threadhttp://www.stackless.com/wiki/Tasklets http://www.stackless.com/wiki/Channels
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 that it insults the old adopters in some way. Or that fealty has to be paid to the old adopters. 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 benefits to new frameworks based on Stackless are obvious if you use Stackless.
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!
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.