to be honest, I've used both gevent and Go and concurrency is far more natural in Go. Sure, you can do most of what you want with gevent, and if you're using stackless or pypy you can even have channels, but implementing concurrency at the library level is a mistake. It feels bolted on. It's like how some programming languages weren't object oriented from the start, but then they bolted an object system on top of it in a later release; it feels kludgy and you notice that it's bolted on. Concurrency in Python reminds me of that. Yes, it works, but it's awkward and feels like a second-class citizen.
That seems like a better application for Python concurrency than trying to eke out more performance.
I don’t particularly like Go, but it might be worth a look for this since it’s somewhat easier to learn and may be more accessible for others to learn and maintain. I wouldn’t do a full implementation, just an exploratory project for the sake of seeing whether you’re stuck on a local maxima with Python.
I'm not sure how much it replicates the CSP model, but the closest thing I've found to Go-style concurrency in Python is gevent: https://github.com/gevent/gevent
I personally still prefer to use it in all my projects.
go concurrency is built on a similar concept (concurrent sequential processes), if I'm not mistaken. the languages aren't very far apart in this regard to start with!
Instead of using callbacks, golang embraces synchronous-style calls and makes them asynchronous by switching between goroutines (lightweight threads). gevent (for Python) does something similar. It's certainly an interesting approach IMO.
Go with goroutines and channels is a nice way to handle concurrency.
At least it was the one that was easiest for me to wrap my head around and actually improved the performance of my code without weird race conditions or bugs.
I looked at Lua briefly instead of Go, but it looks like the concurrency story is lacking. Go also has an enormous standard library which helps for quick tasks.
What? No it isn't. Go's concurrency support is fundamentally different than Python's idiomatic approach (event libraries). It's an apples/oranges comparison. If one approach is more performant than the other, I'd bet on the event library, since evented programs are more or less scheduled purely by I/O.
I like Go. I've been writing in it for a couple of weeks now and will continue to. But don't oversell it.
Yeah, this is exactly right... I have to say Go changed my thinking about concurrency. But now I want to write a very small wrapper around pthreads that lets you write in the actor style. It just adds those "affordances".
Go is more or less the actors style, except with the (discouraged) possibility of sharing mutable state... even though for some reason it doesn't seem to be advertised as such.
The reason is that I don't think Go can cover what C + Python can. C gives you more low level control and Python is still shorter (and thus quicker). I like Go a lot but I would rather program in C + Python (like I do now) than C + Python + Go.
And then the other component to this is de-emphasizing the somewhat-horrible-for-concurrency Python/C API. The library I'm talking about would have channels, and you would have one end open in Python, and one end open in C. Python and C are running in different threads. Rather than the crazy subroutine/callback hell you have now with any nontrivial Python/C binding.
So basically I want to fix the C/Python interface, which is the only reason it is awkward to program in C + Python (the languages themselves are both great), rather than adding another language that overlaps highly with both of them.
The OS is written in C, so you've never going to get past C. If there was a whole world written in Go, that might be reasonable... but I don't believe in portability layers.
I'm a huge fan of Python and gevent, and not the biggest fan of Go, but there's something to be said about built-in concurrency constructs like goroutines compared to something quite hacky like gevent (gevent.monkey.patch_all() everywhere). gevent is my favorite async networking library for Python, and I use it in almost all of my projects, but one can't deny it's basically one giant hack over CPython.
I have used Gevent a lot over the last couple years and see a lot of similarities in Go's concurrency, which I think is great.
Concurrency doesn't have to be about insane looking code!
reply