Crystal 1.22

I would have loved Go more if they had made "lightweight" classes a thing, something feels wrong tying structs and functions, you could have added a wrapper around both to make the code more organized. I guess that's what I like about OOP, organized code. I don't even care about most OOP things, I just want to organize code in a meaningful way.

I don't think anyone who regularly uses Ruby or Python thinks OOP is a mistake, it's in how you use it and whether one likes the OOP design of the language.

So it was a gamble learning something new could just result in a brick wall dead end where you can't fix the thing, you can't get in touch with anyone who knows how (or has time), there's no docs to help you on the way, the code base is a mess and inscrutable, maybe written the a language you don't know -- maybe even the one you're trying to learn! It could be very frustrating at times, to the point I'd just pass over some interesting languages if they weren't polished enough. Which is a shame because I know there's good ideas in there, I just can't invest the time to make sense of them. Seems contradictory, but designers are not always the best communicators.

With LLMs, all this consternation is gone. Can it write the program for you? I guess... but also not really because for many niche languages with interesting features, the LLM won't do so idiomatically, opting instead to implement enough functionality to scaffold a Python-shaped solution, and then it writes that.

The neat ideas are still there, the learning opportunity is still there, the ability to leverage technology in a way the LLM can't is still there. Especially in a creative and learning space!

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.

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...

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.

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 :)

Which means you can have fun trying new languages with every new project :)

My message to the HN community: HN is literally bankrolled by YC. If Crystal doesn't deserve to exist because other languages exist, why exactly should I care about your bullshit uber-for-dogs startup, or whatever not particularly original AI crap you think you're changing the world with these days? Get real. If you want people to be open to your ideas, maybe you ought to make an effort to be open to the ideas of others, and cultivate a climate where discussing different ideas is possible. Don't treat every HN post as an opportunity to opine on how you think the work of other people is flawed.