Show HN: Runloom – Go-style coroutines for Python free-threaded
35 points by Uptrenda 6 hours ago | 15 comments

simonw 4 hours 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.

reply
CamouflagedKiwi 3 hours ago
> 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.

reply
tfrancisl 3 hours 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...
reply
ninininino 34 minutes ago
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.
reply
tfrancisl 22 minutes ago
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.
reply
ksdme9 5 hours ago
How does this compare with gevent?
reply
korijn 4 hours ago
Exactly this is very reminiscent
reply
ebeirne 2 hours 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
reply
hsnewman 4 hours ago
Why not just use Go?
reply
foxygen 4 hours 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.
reply
vorticalbox 2 hours ago
then why not just use threads/processes in python?
reply
foxygen 2 hours ago
Because they are not the same as Go-style green threads/coroutines?
reply
regular_trash 2 hours 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"
reply
7bit 3 hours ago
Someone desires attention ..
reply
Onavo 4 hours ago
Is Python about to have its Project Loom moment?
reply