6 ms·

Show HN: Runloom – Go-style coroutines for Python free-threaded

47 points by Uptrenda 2mo ago

ksdme9 2mo ago
How does this compare with gevent?
- korijn 2mo ago
  Exactly this is very reminiscent
- Uptrenda 2mo ago
  Gevent runs in a single thread. Runloom lets you use every single thread at once and run millions of fibers.
Onavo 2mo ago
Is Python about to have its Project Loom moment?
hsnewman 2mo ago
Why not just use Go?
- foxygen 2mo ago
  Because you are have an existing app in Python. Because you need some library that is not available in Go. Because you prefer Python. All are valid reasons.
  - vorticalbox 2mo ago
    then why not just use threads/processes in python?
    - foxygen 2mo ago
      Because they are not the same as Go-style green threads/coroutines?
      - regular_trash 2mo ago
        Clearly lol. I think a good-faith interpretation of the question is: "What kinds of things is go's concurrency model suited for where the normal pythonic alternative is cumbersome/less desirable"
- 7bit 2mo ago
  Someone desires attention ..
- Uptrenda 2mo ago
  I want to use Python.
simonw 2mo ago
This is an intimidating amount of code! 12,303 lines of C and 244,740 lines of Python, which looks to be a ton of monkeypatching plus huge amounts of test code. Only one commit added all of that, just two hours ago. The published numbers are impressive, but its hard to evaluate how much trust can be put in a project of this complexity at this early stage.
- Uptrenda 2mo ago
  I've restored the git history. This show hn probably would have gone much better if I knew you could add a text section to the link. I had written up a whole post to explain the project and why the code exists. Only for that to get like 3 upvotes and disappear into the void. Then I posted this and it got more attention but had no context since I never planned it. The project has a few goals: (1) see how far I can push AI -- this project is extremely complex -- an n:m work-stealing stackful runtime for Python with multiple I/O backends. If I can reasonably get such a project stable fully vibe coded. Then that sells the model to me at least. (2) scale Python's networking as there is a huge gap between Python and Go. Most people don't think of Python as their first choice for networking. But I love python, i think its extremely elegant. So what if we could add a runtime extension that improved python networking. That's the work so far at least. It was about 2 - 3 months of testing and the commits now show the history.
  - simonw 2mo ago
    Nice! Having the history makes it easier to evaluate all the work you've put in, this is really impressive.
    - Uptrenda 2mo ago
      thanks a lot, thats kind of you to say. Claude definitely deserves a lot of credit too even though its a tool. It would have taken me years to do all that coding.
- tfrancisl 2mo ago
  250k lines of code in one commit is reason enough to disregard the project entirely, IMO. Vibe code if one wants, but that is just madness...
ebeirne 2mo ago
This is a seriously impressive project. I see your pitch is M:N work-stealing across real cores on free-threaded 3.13t/3.14t which i think is only possible because nogil now exists. which makes gevent seem lackluster in comparison
bigwhite 2mo ago
Why not just use Go, haha?
OutOfHere 2mo ago
Does your code have a significant dependency on the version of Python? How easy will it be for you to maintain your code to support Python 3.15, 3.16, etc.? Is it too dependent on the implementation of Python 3.13 and 3.14 or its low level aspects? What is all the Python code doing?
- Uptrenda 2mo ago
  It depends on Python >= 3.13t, no-gil (so it can use real OS threads without locking.) It's been tested on 3.13t and 3.14t. As far as I know future versions of Python beyond that aren't planned for release for a number of years. But the extension code is fairly isolated. E.g. getting the extension to work on 3.14t from 3.13t took about 5 minutes. We're not reaching deep into the interpreter because the interface for extensions is well-defined already. For the Python code you've really got 3 ways to use this extension: 1. You can use the main API. No monkey patching stuff. You use things like channels and the optimized serve API (this is what had the highest number in bench marks.) Here, you're using the projects APIs for networking. 2. Monkey patching. You use regular Python code inside the fibers. So you can write stuff like socket.socket ... and its patched to call runloom networking functions. You can see this points back to (1) but it has an overhead on top. You get to use libraries you're familiar with. 3. AIO bridge. This is to get asyncio code running on the scheduler. When you use the asyncio bridge it only uses a single thread. The main purpose of this is kind of like: "try out the project with your existing code." It also served the duel purpose of helping to find bugs in the runtime. Since I could reuse literally millions of test cases for the bridge. tl; dr, (1) for a new project trying runloom -- learn the APIs. Or (2) if you mostly don't want to bother learning anything new / optimising anything. It might be a little slower but it will work. (3) you can mostly ignore. Unless you want to try asyncio code on it for the hell of it.
  - OutOfHere 2mo ago
    I propose separating #1 (the main API/SDK) into a separate core package. This will be easier, smaller, and cleaner to maintain, and will meet the needs of many users with new projects. It will satisfy the purity criteria. I don't like the idea of monkeypatching even if it makes things convenient to use, because this risks being hell to maintain. You won't know of all the hidden bugs in it until a million users have used it. As for the AIO bridge, single core execution is hell anyway, and so I don't like that idea either. Can you point me to the documentation and examples of the main API/SDK?
OutOfHere 2mo ago
Very cool. Just a few days ago, I had noted a proposed spec for a biologically-inspired high-level concurrency model where no user-facing channels/send/recv are required. The user secrets proteins, defines their receptors, and the system handles the rest. Unlike you, I don't have an implementation, but now with GPT 5.6 released it's within reach. The actionable spec prompt is at https://gist.github.com/impredicative/a0dd4ac68cd05e9d3855dca3cd147d55 https://gist.github.com/impredicative/a0dd4ac68cd05e9d3855dc...
zooler 2mo ago
[dead]

47 points by Uptrenda 2mo ago

ksdme9 2mo ago

How does this compare with gevent?

korijn 2mo ago
Exactly this is very reminiscent
Uptrenda 2mo ago
Gevent runs in a single thread. Runloom lets you use every single thread at once and run millions of fibers.

Onavo 2mo ago

Is Python about to have its Project Loom moment?

hsnewman 2mo ago

Why not just use Go?

foxygen 2mo ago
Because you are have an existing app in Python. Because you need some library that is not available in Go. Because you prefer Python. All are valid reasons.
- vorticalbox 2mo ago
  then why not just use threads/processes in python?
  - foxygen 2mo ago
    Because they are not the same as Go-style green threads/coroutines?
    - regular_trash 2mo ago
      Clearly lol. I think a good-faith interpretation of the question is: "What kinds of things is go's concurrency model suited for where the normal pythonic alternative is cumbersome/less desirable"
7bit 2mo ago
Someone desires attention ..
Uptrenda 2mo ago
I want to use Python.

simonw 2mo ago

This is an intimidating amount of code! 12,303 lines of C and 244,740 lines of Python, which looks to be a ton of monkeypatching plus huge amounts of test code. Only one commit added all of that, just two hours ago. The published numbers are impressive, but its hard to evaluate how much trust can be put in a project of this complexity at this early stage.

Uptrenda 2mo ago
I've restored the git history. This show hn probably would have gone much better if I knew you could add a text section to the link. I had written up a whole post to explain the project and why the code exists. Only for that to get like 3 upvotes and disappear into the void. Then I posted this and it got more attention but had no context since I never planned it. The project has a few goals: (1) see how far I can push AI -- this project is extremely complex -- an n:m work-stealing stackful runtime for Python with multiple I/O backends. If I can reasonably get such a project stable fully vibe coded. Then that sells the model to me at least. (2) scale Python's networking as there is a huge gap between Python and Go. Most people don't think of Python as their first choice for networking. But I love python, i think its extremely elegant. So what if we could add a runtime extension that improved python networking. That's the work so far at least. It was about 2 - 3 months of testing and the commits now show the history.
- simonw 2mo ago
  Nice! Having the history makes it easier to evaluate all the work you've put in, this is really impressive.
  - Uptrenda 2mo ago
    thanks a lot, thats kind of you to say. Claude definitely deserves a lot of credit too even though its a tool. It would have taken me years to do all that coding.
tfrancisl 2mo ago
250k lines of code in one commit is reason enough to disregard the project entirely, IMO. Vibe code if one wants, but that is just madness...

ebeirne 2mo ago

This is a seriously impressive project. I see your pitch is M:N work-stealing across real cores on free-threaded 3.13t/3.14t which i think is only possible because nogil now exists. which makes gevent seem lackluster in comparison

bigwhite 2mo ago

Why not just use Go, haha?

OutOfHere 2mo ago

Does your code have a significant dependency on the version of Python? How easy will it be for you to maintain your code to support Python 3.15, 3.16, etc.? Is it too dependent on the implementation of Python 3.13 and 3.14 or its low level aspects? What is all the Python code doing?

Uptrenda 2mo ago
It depends on Python >= 3.13t, no-gil (so it can use real OS threads without locking.) It's been tested on 3.13t and 3.14t. As far as I know future versions of Python beyond that aren't planned for release for a number of years. But the extension code is fairly isolated. E.g. getting the extension to work on 3.14t from 3.13t took about 5 minutes. We're not reaching deep into the interpreter because the interface for extensions is well-defined already. For the Python code you've really got 3 ways to use this extension: 1. You can use the main API. No monkey patching stuff. You use things like channels and the optimized serve API (this is what had the highest number in bench marks.) Here, you're using the projects APIs for networking. 2. Monkey patching. You use regular Python code inside the fibers. So you can write stuff like socket.socket ... and its patched to call runloom networking functions. You can see this points back to (1) but it has an overhead on top. You get to use libraries you're familiar with. 3. AIO bridge. This is to get asyncio code running on the scheduler. When you use the asyncio bridge it only uses a single thread. The main purpose of this is kind of like: "try out the project with your existing code." It also served the duel purpose of helping to find bugs in the runtime. Since I could reuse literally millions of test cases for the bridge. tl; dr, (1) for a new project trying runloom -- learn the APIs. Or (2) if you mostly don't want to bother learning anything new / optimising anything. It might be a little slower but it will work. (3) you can mostly ignore. Unless you want to try asyncio code on it for the hell of it.
- OutOfHere 2mo ago
  I propose separating #1 (the main API/SDK) into a separate core package. This will be easier, smaller, and cleaner to maintain, and will meet the needs of many users with new projects. It will satisfy the purity criteria. I don't like the idea of monkeypatching even if it makes things convenient to use, because this risks being hell to maintain. You won't know of all the hidden bugs in it until a million users have used it. As for the AIO bridge, single core execution is hell anyway, and so I don't like that idea either. Can you point me to the documentation and examples of the main API/SDK?

OutOfHere 2mo ago

Very cool. Just a few days ago, I had noted a proposed spec for a biologically-inspired high-level concurrency model where no user-facing channels/send/recv are required. The user secrets proteins, defines their receptors, and the system handles the rest. Unlike you, I don't have an implementation, but now with GPT 5.6 released it's within reach. The actionable spec prompt is at https://gist.github.com/impredicative/a0dd4ac68cd05e9d3855dca3cd147d55 https://gist.github.com/impredicative/a0dd4ac68cd05e9d3855dc...

zooler 2mo ago

[dead]