> 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.

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...

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...

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.

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.

Someone desires attention ..

I want to use Python.

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.