The Future of Asynchronous IO in Python
medium.com
The Future of Asynchronous IO in Python
1–10 of 51 posts
Re: The Future of Asynchronous IO in Python
#2This 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.
Re: The Future of Asynchronous IO in Python
#3This 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.
Well, for many protocols it easy. I had written (a useful subset of) mysql protocol parser in a weekend. Sure, this is in Python, so reimplement it in C is much harder, still not years or so. Many protocols: mongodb, redis, memcached, beanstalk, etc, are much simpler.
There are protocols that take months and years, but they are not so ubiquitous (with the obvious exception of HTTP, which is really complex and ubiquitous). So they may be developed after basic tools are in place.
Re: The Future of Asynchronous IO in Python
#4Do 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.
Re: The Future of Asynchronous IO in Python
#5Do 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 unexc…
What does Javascript have to do with anything? The article is about Python. It's about how we build the server-side, not the client-side.
Re: The Future of Asynchronous IO in Python
#6Ok, 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...
Re: The Future of Asynchronous IO in Python
#7I'm sorry to be negative but the grammar mistakes in this article were glaring.
Re: The Future of Asynchronous IO in Python
#8Do 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 unexc…
What does Javascript have to do with anything? The article is about Python. It's about how we build the server-side, not the client-side.
What do microservices have to do with JavaScript?
Re: The Future of Asynchronous IO in Python
#9Article 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]
Re: The Future of Asynchronous IO in Python
#10Ok, 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...
The entire premise of this article is that the author has adopted the microservices disease and is suffering from not having asynchronous IO. You'll never hear an Erlang programmer even talk about microservices because they are a solution to a problem that doesn't exist in Erlang, or any sufficiently concurrent language for that matter[0]. Oh, and microservices clearly create other problems, such as messaging.
0 - I do hear Go-lang users talk about microservices, which is weird. Because they have decent concurrency primitives to where they shouldn't need to split web applications up into microservices.