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