5 ms·

I really wish the community had coalesced around gevent. - no async/await, instead every possible thing that could block in the standard library is monkey-patc

by btown 1y ago

I really wish the community had coalesced around gevent. - no async/await, instead every possible thing that could block in the standard library is monkey-patched to yield to an event loop - this means that you can write the same exact code for synchronous and concurrent workflows, and immediately get levels of concurrency only bounded by memory limits - you'll never accidentally use a synchronous API in an async context and block your entire event loop (well, you can, if you spin on a tight CPU-bound loop, but that's a problem in asyncio too) - the ecosystem doesn't need to implement libraries for asyncio and blocking code, everything just works There's a universe where the gevent patches get accepted into Python as something like a Python 4, breaking some niche compatibility but creating the first ever first-class language with green-threading at its core. But in this universe, we're left with silly things like "every part of the Django ecosystem dealing with models must be rewritten with 'a' prefixes or be abandoned" and it's a sad place indeed.

jeeyoungk 1y ago
I like `gevent` but I think it may have been too hacky of a solution to be incorporated to the main runtime. "creating the first ever first-class language with green-threading at its core." ... isn't that what Go is? I think out of all languages I use extensively, Go is the only one that doesn't suffer from the sync/async function coloring nightmare.
- deleted 1y ago
  [deleted]
- pansa2 1y ago
  > I like `gevent` but I think it may have been too hacky of a solution to be incorporated to the main runtime gevent's monkey-patching might be hacky, but an official implementation of stackful coroutines (similar to Lua's) need not have been. Instead, stackless coroutines were chosen - maybe on merit, but also maybe because C#'s async/await keywords were in-vogue at the time and Python copied them.
  - dontlaugh 1y ago
    Stackless Python has existed for a long time. It’s “stackful” according to your definition, the term they refer to is the C stack.
    - pansa2 1y ago
      > Stackless Python Reminds me of ANTLR - another project whose name is the opposite of what it actually does.
    - Nab443 1y ago
      Stackless python, we were not ready for it.
- igregoryca 1y ago
  > the sync/async function coloring nightmare I'm with you that function "coloring" (monads in the type system) can be unergonomic and painful. > ... isn't that what Go is? I think out of all languages I use extensively, Go is the only one that doesn't suffer from the […] coloring nightmare. Because it doesn't have Future/Promise/async as a built-in abstraction? If my function returns data via a channel, that's still incompatible with an alternate version of the function that returns data normally. The channel version doesn't block the caller, but the caller has to wait for results explicitly; meanwhile, the regular version would block the caller, but once it's done, consuming the result is trivial. Much of the simplicity of Go comes at the expense of doing everything (awaiting results, handling errors, …) manually, every damn time, because there's no language facility for it and the type system isn't powerful enough to make your own monadic abstractions. I know proponents of Go tend to argue this is a good thing, and it has merits. But making colorful functions wear a black-and-white trenchcoat in public doesn't solve the underlying problem. (goroutines are nice, though.)
  - csande17 1y ago
    One of the largest problems identified in the original "what color is your function" article ( https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... ) is that, if you make a function async, it becomes impossible to use in non-async code. Well, maybe you can call "then" or whatever, but there's no way to take an async function and turn it into something that synchronously returns its value. But in Go, it's very easy to do this; you can just do "result := <- ch" to obtain the value from a channel in synchronous code. (This blocks the thread, but in Go's concurrency model this isn't a problem, unlike in JavaScript.) Similarly it's very easy to take a synchronous function and do "go func() { ch <- myFunction() }()" to make it return its result in a channel.
    - btown 1y ago
      I remember this article in 2015 being revelatory. But it turned out that what we thought was an insurmountable amount of JS code written with callbacks in 2015 would end up getting dwarfed by promise-based code in the years to come. The “red functions” took over the ecosystem! With Python, I’m sure some people expect the same thing to happen. I think Python is far more persistent, though. So much unmaintained code in the ecosystem that will never be updated to asyncio. We’ll see, I suppose, but it will be a painful transition.
- progval 1y ago
  Erlang did it 20-30 years before Go
svieira 1y ago
Java 1.1 had green threads, so does Java 21+ (though Java 21's green threads are actually an M:N threading model not the M:1 threading model of Java 1.1).
nbsande 1y ago
While having the same code for sync and async sounds nice, monkey patching code at runtime seems hacky. Any library that wants to use a lower level implementation of network calls would need to handle the monkey patching themselves i assume.
- jerf 1y ago
  The idea would be that if this was accepted into the core as the way to go forward, it wouldn't be "monkeypatched" anymore, it would just be in core, officially supported.
happosai 1y ago
Green threads, now THAT's a buzzword I haven't heard for a long time...
icedchai 1y ago
I worked quite a bit with gevent'd code about 10+ years ago and also agree. Dealing with function coloring is incredibly non productive. This is one of the things "go" got right.
- pas 1y ago
  the sans-IO approach seems roughly correct libraries provide pure processing machines that pull data in through well defined input functions (and output through return), and then it's up to the callsite (or host code or however we want to call our code) to decide what kind of color to paint the whole thing eventually. this helps testability and composability too. (of course this is not new, there was Scala's Iteratee and there's full program interpretation ... https://zio.dev/1.0.18/overview/overview_background/ https://zio.dev/1.0.18/overview/overview_background/ )
jononor 1y ago
Agreed. I chose gevent over asyncio for a backend in 2019, and we still using it. Works pretty well. No plans to phase out gevent just yet. Though the community has clearly centered on asyncio by now. So if I were to start a new backend today, it would reluctantly be asyncio. Unfortunately...

by btown 1y ago

jeeyoungk 1y ago

I like `gevent` but I think it may have been too hacky of a solution to be incorporated to the main runtime. "creating the first ever first-class language with green-threading at its core." ... isn't that what Go is? I think out of all languages I use extensively, Go is the only one that doesn't suffer from the sync/async function coloring nightmare.

deleted 1y ago
[deleted]
pansa2 1y ago
> I like `gevent` but I think it may have been too hacky of a solution to be incorporated to the main runtime gevent's monkey-patching might be hacky, but an official implementation of stackful coroutines (similar to Lua's) need not have been. Instead, stackless coroutines were chosen - maybe on merit, but also maybe because C#'s async/await keywords were in-vogue at the time and Python copied them.
- dontlaugh 1y ago
  Stackless Python has existed for a long time. It’s “stackful” according to your definition, the term they refer to is the C stack.
  - pansa2 1y ago
    > Stackless Python Reminds me of ANTLR - another project whose name is the opposite of what it actually does.
  - Nab443 1y ago
    Stackless python, we were not ready for it.
igregoryca 1y ago
> the sync/async function coloring nightmare I'm with you that function "coloring" (monads in the type system) can be unergonomic and painful. > ... isn't that what Go is? I think out of all languages I use extensively, Go is the only one that doesn't suffer from the […] coloring nightmare. Because it doesn't have Future/Promise/async as a built-in abstraction? If my function returns data via a channel, that's still incompatible with an alternate version of the function that returns data normally. The channel version doesn't block the caller, but the caller has to wait for results explicitly; meanwhile, the regular version would block the caller, but once it's done, consuming the result is trivial. Much of the simplicity of Go comes at the expense of doing everything (awaiting results, handling errors, …) manually, every damn time, because there's no language facility for it and the type system isn't powerful enough to make your own monadic abstractions. I know proponents of Go tend to argue this is a good thing, and it has merits. But making colorful functions wear a black-and-white trenchcoat in public doesn't solve the underlying problem. (goroutines are nice, though.)
- csande17 1y ago
  One of the largest problems identified in the original "what color is your function" article ( https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... ) is that, if you make a function async, it becomes impossible to use in non-async code. Well, maybe you can call "then" or whatever, but there's no way to take an async function and turn it into something that synchronously returns its value. But in Go, it's very easy to do this; you can just do "result := <- ch" to obtain the value from a channel in synchronous code. (This blocks the thread, but in Go's concurrency model this isn't a problem, unlike in JavaScript.) Similarly it's very easy to take a synchronous function and do "go func() { ch <- myFunction() }()" to make it return its result in a channel.
  - btown 1y ago
    I remember this article in 2015 being revelatory. But it turned out that what we thought was an insurmountable amount of JS code written with callbacks in 2015 would end up getting dwarfed by promise-based code in the years to come. The “red functions” took over the ecosystem! With Python, I’m sure some people expect the same thing to happen. I think Python is far more persistent, though. So much unmaintained code in the ecosystem that will never be updated to asyncio. We’ll see, I suppose, but it will be a painful transition.
progval 1y ago
Erlang did it 20-30 years before Go

svieira 1y ago

Java 1.1 had green threads, so does Java 21+ (though Java 21's green threads are actually an M:N threading model not the M:1 threading model of Java 1.1).

nbsande 1y ago

While having the same code for sync and async sounds nice, monkey patching code at runtime seems hacky. Any library that wants to use a lower level implementation of network calls would need to handle the monkey patching themselves i assume.

jerf 1y ago
The idea would be that if this was accepted into the core as the way to go forward, it wouldn't be "monkeypatched" anymore, it would just be in core, officially supported.

happosai 1y ago

Green threads, now THAT's a buzzword I haven't heard for a long time...

icedchai 1y ago

I worked quite a bit with gevent'd code about 10+ years ago and also agree. Dealing with function coloring is incredibly non productive. This is one of the things "go" got right.

pas 1y ago
the sans-IO approach seems roughly correct libraries provide pure processing machines that pull data in through well defined input functions (and output through return), and then it's up to the callsite (or host code or however we want to call our code) to decide what kind of color to paint the whole thing eventually. this helps testability and composability too. (of course this is not new, there was Scala's Iteratee and there's full program interpretation ... https://zio.dev/1.0.18/overview/overview_background/ https://zio.dev/1.0.18/overview/overview_background/ )

jononor 1y ago

Agreed. I chose gevent over asyncio for a backend in 2019, and we still using it. Works pretty well. No plans to phase out gevent just yet. Though the community has clearly centered on asyncio by now. So if I were to start a new backend today, it would reluctantly be asyncio. Unfortunately...