This is how Crystal’s multithreaded scheduler works. That’s what I meant when I said Crystal’s concurrency was modeled after Go’s.
The scheduling of workloads is already production-grade and it’s faster than Go. The article mentions improving it, which is great, but the scheduling of work was never the reason it isn’t yet the default in Crystal.
This trivializes the efforts folks have put into implementing multithreading in Crystal. Those efforts long predate this thread. The work you “encourage Crystal lang to research” has already been done and continues to be refined. It was even linked in the blog post you’re replying to.
Keep in mind that Crystal is developed by a small team, most of whom aren’t getting paid to work on it. Just because something isn’t fully implemented in a release yet doesn’t mean several smart people haven’t already been thinking about the problem, from multiple perspectives, for a long time.
One thing I’ve learned in my own interactions with the Crystal core team is that, no matter what I’m about to suggest, someone on the team has probably already been rolling it around in their mind for years. Maybe they’ve got branches or entire repos dedicated to that idea already. Even when I’m arguing with them or I think they’re wrong, I do try to keep in mind that they’ve probably thought more about the problem space (and how a solution might fit into the broader Crystal ecosystem) than I have, because the ideas I’m bringing up usually aren’t specific to my use cases. And when you consider that multithreading in Crystal has probably been the most requested feature to be mainlined since I first got into the language back in 2016 or so, it’s important to keep that in mind in this discussion, as well.