Indeed, while there is communication that the situation with merging external pull requests should improve, the reality is that it's easier to land a patch in Linux, than in Zig.
Maybe I'm wrong, but I'm really skeptical about projects like this. 200000 lines of code addition in 3 months, basically 2000 lines per day. I don't think any human brain is capable to handle such cognitive complexity, unless the code is all plain data get/setters, which any framework is certainly not. For me a good way to use LLM is to learn how to build something big by writing a tiny one with it. But this only gives a shallow understanding of a big system. For any critical complex system you want to maintain for a long time, LLM is in no way a good choice.
> Managing a codebase written by an LLM is difficult because you have not cognitively loaded the entire thing into your head as you do with code written yourself.
Wow you really nail the point, that's what I felt but I did not understand. Thanks for the comment.
I'm wondering if this scheduler is for something like user-space threads. And What is the relationship between such scheduler and go runtime for goroutine and JVM for Java virtual thread?
In this example, the kernel is doing the task switching. They are "real" threads. The userspace component is informing the kernel which tasks should be run.
goroutines and Java virtual threads are a separate idea. The application saves its state and then yields back to a scheduler in the application.
