from Hacker News

The Future of Asynchronous IO in Python

by leonardinius on 11/26/14, 3:42 PM with 50 comments

• by Animats on 11/27/14, 5:14 AM

  It's frustrating. Many people want an interprocess subroutine call, and few OSs have the right primitives for it. (QNX does, and Windows sort of does, but the Linux/Unix world does not.) There's an endless collection of kludges so program A can call program B implemented on top of pipe/socket like mechanisms.

  OpenRPC and CORBA are out of fashion. Google protocol buffers help, but don't come with a standard RPC mechanism. HTTP with JSON is easy to do but has high overhead. Then there's the handling of failure, the curse of callback-oriented systems. ("He said he'd call back. Why didn't he call back? Doesn't he like me any more? Should I dump him?")

  The lack of a good, standardized interprocess call mechanism results in interprocess call logic appearing at the application level. At that level, it's intertwined with business logic and often botched.

• by Reef on 11/27/14, 12:59 AM

  Article suggests that a high performance framework is implemented where notification of a unavailability will be propagated "before real user tried to execute a request" (which would have 50% probability of happening if number of heartbeats per second would be equal to number of requests per second the service serves, ha ha). Also from the Article we can learn that sending a 304 with content does not work as expected (!?)

  Not only that, but there should be only one connection to database, through all traffic will go. Pulling that up through a network switch connected to a server with multiple cables, or pushing all that through a single TCP connection, with a foot note that advises against rewriting it after a few years?

  Also, everything explained there should run in a single thread, because surely it will be fast enough.

  Good luck with that.

  [if you find other funny stuff that I missed, leave them in the comment section below]

• by xorcist on 11/27/14, 12:56 PM

  > (The GIL) is there for other scripting languages too (Ruby, Perl, Node.js, to name a few)

  I don't know about Node, but I know it's perfectly possible to write "proper" multi threaded programs in Perl (and has always been since the version string started reporting support for threads, which should be a good 15 years ago).

  It's not terribly relevant to the article (because you normally don't write multi threaded programs in Python), but then why bring it up?

• by mamcx on 11/26/14, 11:33 PM

  Ok, and if we can start clean?

  (I'm in the process of build a toy language).

  Is this more a problem for a language with baggage, or is general? I wonder if for example in Go, Erlang is less of a issue...

• by rumcajz on 11/26/14, 5:05 PM

  This article raises many relevant points.

  But the real issue behind all of that is that we lack means to easily implement protocol stacks. Implementing a new protocol (especially in the user space) is a task that can easily eat months or years of your precious time.

• by theVirginian on 11/26/14, 11:42 PM

  I'm sorry to be negative but the grammar mistakes in this article were glaring.

• by notastartup on 11/26/14, 10:47 PM

  Do we really need to reinvent the wheels? Microservice, the async craze feels like, we now need to create a single wheel that is made up of many wheels, and spend an enormous time making it look and feel like a single wheel that was working fine, never mind that it serves absolutely no difference to the end user, it will make our next few years interesting because the old way of creating the wheel is boring and unexciting.

  I think that after a few years, software businesses will realize that it was an investment with questionable advantages and go right back to what was working fine for the past decade and will continue to work fine.