Well put, Clay. Totally Agree. On Fri, May 8, 2015 at 10:19 AM, Clay Gerrard <clay.gerr...@gmail.com> wrote: > > > On Thu, May 7, 2015 at 5:05 PM, Adam Lawson <alaw...@aqorn.com> wrote: >> >> what sort of limitations have you discovered that had to do specifically >> with the fact we're using Python? > > > Python is great. Conscious decision to optimize for developer wall time > over cpu cycles has made it a great language for 20 years - and probably > will for another 20 at *least* (IMHO). > > I don't think you would pick out anything to point at as a "limitation" of > python that you couldn't point at any dynamic interpreted language, but my > list is something like this: > > Dynamic Interpreted Runtime overhead > Eventlet non-blocking hub is NOT OK for blocking operations (cpu, disk) > OTOH, dispatch to threads has overhead AND GIL > non-byte-aligned buffers restricts access to O_DIRECT and asyncio > > *So often* this kinda stuff just doesn't matter. Or even lots of times even > when it *does* matter - it doesn't matter that much in the grand scheme of > things. Or maybe it matters a non-trivial amount, *but* there's still other > things that just mater more *right now*. I think Swift has been in that > last case for a long time, maybe we still are - great thing about > open-source is redbo can publish an experiment on a feature branch in gerrit > and in-between the hard work of testing it - we can pontificate about it on > the mailing list! ;) > > FWIW, I don't think anyone should find it particularly surprising that a > mature data-path project would naturally gravitate closer to the metal in > the critical paths - it shouldn't be a big deal - unless it all works out - > and it's $%^&! tons faster - then BOOYAH! ;) > > But I'd suggest you be very careful not to draw any assumptions in general > about a great language like python even if this one time this one project > thought maybe they should find out if some part of the distributed system > might be better by some measure in something not-python. ;) > > Cheers, > > -Clay > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
-- Regards Huang Zhiteng __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
