For those that don't know: Crystal is like a typed Ruby with the performance and concurrency flow of Go.
Mainly because normal Ruby is an awesome language to write code, and it is also a language that's tried and lost the spotlight because its performance is really, really low, even when compared only with other interpreted languages.
But then Python got a second wind in performance with better rewrite in Rust integration, but it looks like with the latest DHH keynote, Ruby might also go down that path.
My opinion is that I/O and concurrency ease of use and performance continues to be Ruby's weak point vs other interpreted languages. Which also happens to be Go's very few strong points.
I'm not up to date, but the scheduling engine was far behind Go in terms of parallelism. Crystal was always quite good at concurrency.
But Go is popular because it's so good at parallelism (and relatively safe with a garbage collector).
I know Crystal has been working on this for the last few releases, but I'd be surprised if it's matching Go on parallelism.
Go's runtime is quite the engineering feat.
It can often outperform hand-optimized Rust in worst-case parallel workloads (p99), despite Rust having a number of pretty huge advantages...
In the previous release (1.21) we enabled Execution Contexts as a parallelism engine. https://crystal-lang.org/2026/07/12/releasing-execution-cont...
It's even more flexible than Go because you can tune different contexts for specific workloads. Go still has more advanced optimizations and overall better thread-safety in libraries. But we're working on that...
My main critique - which I'm sure you're aware of - is that the hardest part of doing this is predicting what your workload is actually going to be like. That's what Go does so well. It can get almost anything right without you needing to hand-tune it.
While I have you - are y'all planning to implement FSMs and thunks (for recursion) at any time in the near future?
This is something Go is unlikely to ever do unless it becomes a Go2 language.
I don't know enough about your runtime to know if it's remotely feasible given the choices you've made.
If only it had a few more features from 1970's languages, designed outside Bell Labs, or even those from Limbo that it still doesn't support.
Happy International Caps Lock Day!!1
On other note, who the hell decided kibi, mebi, gibi are good prefix names? that's the reason no one uses them (me too)
https://en.wikipedia.org/wiki/Kilobyte
The metric prefix "kilo" is always lowercase. I don't know how you got a capitalized "K", but that's not how it works.
I will say this comes with the asterisk that it heavily depends on what your concurrent system/problems looks like!
...but more often than not when dealing with web problems and network IO, the shape of concurrency/parallelism I need looks exactly like Goroutines, and even as someone who uses Rust/tokio daily: the Go runtime is an incredibly engineered system that usually beats Rust in my experience for application dev tasks.
Anyways, I love Crystal's syntax around concurrency! I wish we lived in a world where it had tons of Google engineers optimizing the runtime :)