4 ms·

>That implies a level of sophistication and abstraction that simply doesn't exist today, and probably won't for a while. >For this to work you either need an u

>That implies a level of sophistication and abstraction that simply doesn't exist today, and probably won't for a while. >For this to work you either need an ultra-sophisticated compiler what will transparently auto-async your code at compile time (as realistic as a unicorn at this point) or a heavy runtime which will have performance implications. I may be misunderstanding this point, but if I'm not, it seems like gevent managed to do this for Python a decade ago and it still works well today. I still use gevent for new code because it gracefully sidesteps this function-coloring problem. (I know people don't normally associate "monkey-patch" with "graceful", but they somehow made it work. I guess this falls under the "heavy runtime" approach, but it doesn't feel heavy at all.)

simias 6y ago
Right, maybe "heavy" was a bit too strong, I was more thinking from the point of view or Rust which aims to have a small, mostly optional runtime.
lmm 6y ago
gevent is difficult to use when interoperating with code outside its runtime (e.g. if you have a callback that gets called from a C library) and you lose control over where you yield, so you'll never get as high throughput as blocking code in the scenarios where that's appropriate. It's effectively just making all your functions async, like JavaScript or indeed Erlang.
- meowface 6y ago
  >gevent is difficult to use when interoperating with code outside its runtime (e.g. if you have a callback that gets called from a C library) True, but is this not also the case when using Python's native async/await functionality? The difference is that async/await doesn't even work with previous pure-Python code which performs any I/O, either. There are thousands of ordinary third-party libraries which basically have to be tossed out the window and rewritten from scratch, despite none of them using any C extensions. gevent works well with almost all of those old libraries.
  - lmm 6y ago
    > True, but is this not also the case when using Python's native async/await functionality? Yes indeed. > The difference is that async/await doesn't even work with previous pure-Python code which performs any I/O, either. There are thousands of ordinary third-party libraries which basically have to be tossed out the window and rewritten from scratch, despite none of them using any C extensions. Hmm, yeah. I sometimes wonder about a language style where functions are monadic by default, and I guess being able to monkeypatch the internals is a way to achieve the same thing - rather than introducing a syntax for a "programmable semicolon", we can just monkeypatch the actual semicolon. Introducing effectfulness into code that wasn't written to accommodate it worries me, but I guess gevent usually works in practice. I guess a language like Frank is a more principled way of doing that kind of thing.
    - meowface 6y ago
      Yeah, monkey-patching is pretty much what it sounds like: a monkey ripping stuff out of and bolting stuff onto everything with a wrench. But despite how incredibly ugly and complex it sounds and how much any decent programmer shudders at the thought of it, in practice it seems most people never really run into issues with it if they're using pure-Python non-asyncio libraries. And the external API they provide is really clean; you generally don't have to think about any of the internals. You just use everything exactly like you already would and pepper in straightforward abstractions like gevent.Pool and gevent.spawn. Internally, it might be the antithesis of Pythonic, but the external interface and developer experience is very Pythonic.
- ghostwriter 6y ago
  > and you lose control over where you yield you don't [1] [1] https://www.gevent.org/api/gevent.html#gevent.sleep https://www.gevent.org/api/gevent.html#gevent.sleep
  - lmm 6y ago
    You do. You can add extra yield points but you can't inspect or remove the ones that have been added in by the runtime.

simias 6y ago

Right, maybe "heavy" was a bit too strong, I was more thinking from the point of view or Rust which aims to have a small, mostly optional runtime.

lmm 6y ago

gevent is difficult to use when interoperating with code outside its runtime (e.g. if you have a callback that gets called from a C library) and you lose control over where you yield, so you'll never get as high throughput as blocking code in the scenarios where that's appropriate. It's effectively just making all your functions async, like JavaScript or indeed Erlang.

meowface 6y ago
>gevent is difficult to use when interoperating with code outside its runtime (e.g. if you have a callback that gets called from a C library) True, but is this not also the case when using Python's native async/await functionality? The difference is that async/await doesn't even work with previous pure-Python code which performs any I/O, either. There are thousands of ordinary third-party libraries which basically have to be tossed out the window and rewritten from scratch, despite none of them using any C extensions. gevent works well with almost all of those old libraries.
- lmm 6y ago
  > True, but is this not also the case when using Python's native async/await functionality? Yes indeed. > The difference is that async/await doesn't even work with previous pure-Python code which performs any I/O, either. There are thousands of ordinary third-party libraries which basically have to be tossed out the window and rewritten from scratch, despite none of them using any C extensions. Hmm, yeah. I sometimes wonder about a language style where functions are monadic by default, and I guess being able to monkeypatch the internals is a way to achieve the same thing - rather than introducing a syntax for a "programmable semicolon", we can just monkeypatch the actual semicolon. Introducing effectfulness into code that wasn't written to accommodate it worries me, but I guess gevent usually works in practice. I guess a language like Frank is a more principled way of doing that kind of thing.
  - meowface 6y ago
    Yeah, monkey-patching is pretty much what it sounds like: a monkey ripping stuff out of and bolting stuff onto everything with a wrench. But despite how incredibly ugly and complex it sounds and how much any decent programmer shudders at the thought of it, in practice it seems most people never really run into issues with it if they're using pure-Python non-asyncio libraries. And the external API they provide is really clean; you generally don't have to think about any of the internals. You just use everything exactly like you already would and pepper in straightforward abstractions like gevent.Pool and gevent.spawn. Internally, it might be the antithesis of Pythonic, but the external interface and developer experience is very Pythonic.
ghostwriter 6y ago
> and you lose control over where you yield you don't [1] [1] https://www.gevent.org/api/gevent.html#gevent.sleep https://www.gevent.org/api/gevent.html#gevent.sleep
- lmm 6y ago
  You do. You can add extra yield points but you can't inspect or remove the ones that have been added in by the runtime.