https://rillabs.com/posts/crystal-concurrency-easier-syntax-...
Crystal pretty much provides the same (great) concurrency functionality with light-weight threads and channels etc, but with a cleaner syntax and in my experience less gotchas around closing channels in the wrong place and order etc.
The main downsides compared to Go I've seen is:
- (As mentioned) Compile times
- Far less compelling cross-compilation story
Tbh, I prefer it that way round than try to retrofit multi-core onto a model that wasn't designed for it. But yes, single-core feels a bit behind the curve in 2022.
Crystal's concurrency is based on fibers (green threads) which works very well even on a single thread (it scales to multiple threads, as well)
And for many use cases with high parallelization and little shared state (including web applications such as a search engine), multi-threading isn't necessary. Synchronization overhead is a serious performance killer. You can get much more performance out of running N processes with a single thread instead of a single process running N threads.
because a lot of beginners complain that Crystal's fiber doesn't work on multiple cores/multiple threads and then give up using it, it's probably not as important as people think.
Even many beginners mistakenly believe that the Crystal language does not support the creation of operating system native Thread， this is a huge misunderstanding for Crystal.