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.
> its hard to evaluate how much trust can be put in a project of this complexity at this early stage.
I don't know, I'm not finding it hard to evaluate that at all.
I've had bad enough experiences with gevent in the (now fairly distant) past, and that's a well-established project, just a subtle one with a large blast radius. This has all of those problems, plus is _much_ larger and I don't think can possibly have been tested as widely as I would want. I get maybe there's a lot of test code, but I think this kind of thing you only really know when the rubber meets the road.
I just copy pasted the work from my old repo into the main one. The main reason was hundreds of MD files and agent results were added into the repo that would have been impossible to clear from history.
This wasn't all written in one shot. I built the project over several months and spent the whole time testing it. Most of the code in the repo is QA / tests.
I had written an article that speaks about the project that I'd hoped would get upvoted (instead of this github link.) It speaks a lot about where the project aims, how it works, and the testing process, (read about my testing process at the end):
It might be worth recreating the git history from scratch in a way that excludes the markdown files - I've used Claude Code and OpenAI Codex to do that in the past with git-filter-branch. Lets you preserve the important history but clean out all the junk.
Whether they did that or had an LLM one shot it, I dont really care. Commit history is pretty important if you ever want to try fixing bugs or improving features in the future.
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
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.
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"
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/a0dd4ac68cd05e9d3855dc...
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?
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.
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?
Then if you want the fastest performance possible for a server this is the epoll-based fastest benchmark program (it calls directly into an optimized server dispatcher built into the runtime. It's designed to minimize Python call overhead while still supporting handlers):
There's an equivalent of that for TCP connections too. UDP hasn't been added yet (optimized version.) And yes -- I have to admit that the API is a mess at the moment and so are the docs. This hasn't been designed well to be user-friendly (like 10 ways to do the same thing...) I just haven't had time to do it. All my time went into testing the project. And tuning performance. So you see a mix of different approaches. But this could be fixed fairly easily in the future.
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.
> its hard to evaluate how much trust can be put in a project of this complexity at this early stage.
I don't know, I'm not finding it hard to evaluate that at all.
I've had bad enough experiences with gevent in the (now fairly distant) past, and that's a well-established project, just a subtle one with a large blast radius. This has all of those problems, plus is _much_ larger and I don't think can possibly have been tested as widely as I would want. I get maybe there's a lot of test code, but I think this kind of thing you only really know when the rubber meets the road.
[flagged]
I just copy pasted the work from my old repo into the main one. The main reason was hundreds of MD files and agent results were added into the repo that would have been impossible to clear from history.
This wasn't all written in one shot. I built the project over several months and spent the whole time testing it. Most of the code in the repo is QA / tests.
I had written an article that speaks about the project that I'd hoped would get upvoted (instead of this github link.) It speaks a lot about where the project aims, how it works, and the testing process, (read about my testing process at the end):
https://robertsdotpm.github.io/software_engineering/goroutin...
It might be worth recreating the git history from scratch in a way that excludes the markdown files - I've used Claude Code and OpenAI Codex to do that in the past with git-filter-branch. Lets you preserve the important history but clean out all the junk.
This is a good idea. I'll restore the history in the coming days. Just want to make sure there's nothing embarrassing as claude dumped so many files.
Why would you be embarassed for output by an LLM? You might be overthinking this.
Also, it would be courteous to mention in the readme just how this code came about.
Code is a liability, not an asset.
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...
It's pretty obvious that the author didn't write a single commit during development, they just squashed their commits into a single commit at the end.
Whether they did that or had an LLM one shot it, I dont really care. Commit history is pretty important if you ever want to try fixing bugs or improving features in the future.
This seems kind of like a laughable and shallow reason for you to disregard my entire project.
>book too large
>didn't read
>0/10, heh
Most of that code is from:
(1) simulating all of asyncio (not a main feature)
(2) monkey patching (not a main feature)
(3) synthetic program suite (dynamically built sample projects)
(4) entirety of the asyncio test suite in the test dir
(5) and other tests
The actual code surface for the run time is very small. The parent comment just ran a blind measure over the whole repo.
How does this compare with gevent?
Exactly this is very reminiscent
Gevent runs in a single thread. Runloom lets you use every single thread at once and run millions of fibers.
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
Is Python about to have its Project Loom moment?
Why not just use Go, haha?
Why not just use Go?
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.
then why not just use threads/processes in python?
Because they are not the same as Go-style green threads/coroutines?
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"
Someone desires attention ..
I want to use Python.
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/a0dd4ac68cd05e9d3855dc...
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?
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.
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?
great questions:
I'd say start here for some basics
https://github.com/robertsdotpm/runloom/blob/main/docs/quick...
https://github.com/robertsdotpm/runloom/blob/main/docs/cookb...
Then if you want the fastest performance possible for a server this is the epoll-based fastest benchmark program (it calls directly into an optimized server dispatcher built into the runtime. It's designed to minimize Python call overhead while still supporting handlers):
https://github.com/robertsdotpm/runloom/blob/main/benchmark/...
There's an equivalent of that for TCP connections too. UDP hasn't been added yet (optimized version.) And yes -- I have to admit that the API is a mess at the moment and so are the docs. This hasn't been designed well to be user-friendly (like 10 ways to do the same thing...) I just haven't had time to do it. All my time went into testing the project. And tuning performance. So you see a mix of different approaches. But this could be fixed fairly easily in the future.