4 ms·

> it's the easiest and most sensible solution to writing concurrent code in a way that won't become incomprehensible I don't think that async/await is necessar

by joppy 6y ago

> it's the easiest and most sensible solution to writing concurrent code in a way that won't become incomprehensible I don't think that async/await is necessarily the most sensible solution, there is also the "implicit" concurrency model used in Go, Erlang, and even Python (using gevent/eventlet). A big benefit of the "implicit" model is that it doesn't split code into async vs sync, and so you don't have two versions of every library, one for sync and one for async. In a lot of cases in fact, you can run existing Python code on gevent and have concurrency "just work", without having to spring async/await everywhere. Python's implementation of async/await is also particularly bad for teaching: not only do you now need to teach people that there are multiple ways to call functions, but async functions cannot be called from the CPython interpreter directly. (You can from the IPython interpreter though). I love concurrent programming, but I don't love the effect that async/await has on code - it makes for less re-usability, and has a more difficult mental model to grasp than the implicit style. And when you can just import and monkey-patch Gevent to get all of the benefits of re-writing your entire codebase to be async/await, why would you?

jordic 6y ago
Mostly agree around reusing existing libs, and being and split point on the community, but I also can't understand why so many detractors. It's a tool and does it's job quit well. Anyway, in my test I prefer explicit and don't like monkey patching :)
- joppy 6y ago
  I think the whole monkey patching thing is a bit of a red herring, gevent changes the python execution model enough that there may as well be a "gpython" command which runs Python - Python+gevent may as well be a different distribution of Python. But even so, is the cost of having to run a monkey patch (or some other startup script) greater than the cost of having to rewrite an entire ecosystem of libraries? I don't think so, not by a long shot. Just look at the whole "aiolibs" project to see how ridiculous this has become. Are some of those libraries better put-together than their originals? Sure. Is it worth splitting an ecosystem in half and having one half not even able to call into the other half? Absolutely not.
  - jordic 6y ago
    Someone should take care of it, but doesn't seem like a trivial problem.. btw, I also will be so happy to be able to reuse part of twisted core on asyncio services :)
- anonymoushn 6y ago
  It does something we were already doing worse than we were already doing it. In Python's case, it does it worse than we were already doing it in the same language. At least for me, this is why I don't have many nice things to say about it. It's also fine to "prefer to be explicit", but it is weird to prefer to be explicit ONLY about whether a function can do the "switch stacks" operation on your behalf (not whether it can consume random numbers from the global RNG, not whether it can create files, not whether it can do blocking I/O, not whether it can open a server socket, not whether it can send HTTP requests, not whether it can write log lines, not whether it mutates its parameters, etc.), and to be explicit about it in a way that invites bugs that don't need to be possible to write (async functions produce a value that can then be awaited, so it's a bug to not await them when you meant to, or to await them when you didn't mean to, and it's common to write such bugs when adding an await operation to a formerly non-async function that is called by other formerly non-async functions).
  - jordic 6y ago
    I must say that python3.8 does a better job detecting not awaited awaitables. Anyway,asyncio it's not new to python, the stdlib still has asyncore in it. There are still awesome web servers around (threaded) but using "asyncio" on the main thread. ZServer, medusa (look at what powers supervisor for example). The file io thing it's still a pain, but same happens on node side.. but seems there is in the way something that will fix it.

by joppy 6y ago

jordic 6y ago

Mostly agree around reusing existing libs, and being and split point on the community, but I also can't understand why so many detractors. It's a tool and does it's job quit well. Anyway, in my test I prefer explicit and don't like monkey patching :)

joppy 6y ago
I think the whole monkey patching thing is a bit of a red herring, gevent changes the python execution model enough that there may as well be a "gpython" command which runs Python - Python+gevent may as well be a different distribution of Python. But even so, is the cost of having to run a monkey patch (or some other startup script) greater than the cost of having to rewrite an entire ecosystem of libraries? I don't think so, not by a long shot. Just look at the whole "aiolibs" project to see how ridiculous this has become. Are some of those libraries better put-together than their originals? Sure. Is it worth splitting an ecosystem in half and having one half not even able to call into the other half? Absolutely not.
- jordic 6y ago
  Someone should take care of it, but doesn't seem like a trivial problem.. btw, I also will be so happy to be able to reuse part of twisted core on asyncio services :)
anonymoushn 6y ago
It does something we were already doing worse than we were already doing it. In Python's case, it does it worse than we were already doing it in the same language. At least for me, this is why I don't have many nice things to say about it. It's also fine to "prefer to be explicit", but it is weird to prefer to be explicit ONLY about whether a function can do the "switch stacks" operation on your behalf (not whether it can consume random numbers from the global RNG, not whether it can create files, not whether it can do blocking I/O, not whether it can open a server socket, not whether it can send HTTP requests, not whether it can write log lines, not whether it mutates its parameters, etc.), and to be explicit about it in a way that invites bugs that don't need to be possible to write (async functions produce a value that can then be awaited, so it's a bug to not await them when you meant to, or to await them when you didn't mean to, and it's common to write such bugs when adding an await operation to a formerly non-async function that is called by other formerly non-async functions).
- jordic 6y ago
  I must say that python3.8 does a better job detecting not awaited awaitables. Anyway,asyncio it's not new to python, the stdlib still has asyncore in it. There are still awesome web servers around (threaded) but using "asyncio" on the main thread. ZServer, medusa (look at what powers supervisor for example). The file io thing it's still a pain, but same happens on node side.. but seems there is in the way something that will fix it.