3 ms·
Most of the stuff I work on is highly concurrent. GILs are the devil. Almost all the joy and ease you from GIL languages is lost as you try to go concurrent a
by MetaCosm 13y ago
Most of the stuff I work on is highly concurrent. GILs are the devil. Almost all the joy and ease you from GIL languages is lost as you try to go concurrent and have to use (in python for example) multiprocess and gevent ... then you start getting caught on the rough edges and poor ideas in those tools... and everything falls apart.
- dragonwriter 13y agoGIL isn't a language feature, it's an implementation feature — in Ruby, at least, this is a significant difference because there a major implementations (Jruby, most notably) without it even though it is a feature of the MRI implementation.
- MetaCosm 13y agoTrue, but JRuby comes with it own huge bag of rough edges (read: no C extensions for you without a bit PITA). IronPython is in a similar boat. That said, I do prefer JRuby to Scala.
- rdtsc 13y agoGIL is all evil. If your are dealing with CPU bound concurrency yes, GIL is there to take the fun away. But if your problem is most about IO concurrency (downloading from multiple sockets for ex) GIL is no problem. I get very nice speedup from Python's threads with a silly web crawler I wrote.
- syllogism 13y agoAnother option is to use Cython. You can declare a function "nogil", but then you can't call any native Python functions within it. It's good enough for some purposes, but not all.