Crystal 1.22.0 makes every target run on a native event loop, retiring libevent

Crystal 1.22.0 Is Released

Crystal 1.22.0 ships 251 changes from 33 contributors. Every target now defaults to a native event loop built directly on the system selector—epoll on Solaris, kqueue on the remaining BSDs—with libevent demoted to an opt-in fallback. DWARF parsing was rebuilt to scan sections on demand and cache backtraces in an LRU, aarch64-linux reached Tier 1, and standard streams now exit silently on EPIPE.

libevent is still available as a fallback, but now it's strictly opt-in and becoming technically obsolete. We expect to deprecate in a following release.
  1. giancarlostoro

    Crystal might not be the most popular, but it is very interesting to me, I'm not a Ruby guy, but I was looking into other languages other than Go, Rust, etc that are natively compiled, I've dabbled with Nim, but I really wanted to try something slightly different, and I'm honestly impressed, it needs some slight polish still, maybe better funding might help, but in a different timeline under the right conditions, I genuinely think Crystal could have taken off as a really solid language. It's LLVM based, has green threads (that are insanely lightweight), has C-interop, has a comp-time macro system for AST inspection, code generation and removing boilerplate code.

    The web frameworks look interesting too, but I haven't deep dived those just yet. You really get a Rubylike language with native performance which is very interesting.

    One thing I wanted out of Nim is slightly more Python-likeness, I want regular OOP, since Crystal takes from Ruby (I believe it was originally written in Ruby, before it became self-hosting) it has sane OOP features I miss when I use Go, Rust or even Nim.

    I really feel in a different timeline, Crystal could have been something, I also feel like "Ruby" for some leaves a bad taste, but Ruby is nowhere near as awful as most people think, even though it was never for me, it was still one of the nicest ecosystems I ever worked with long before Go got its package management situation situated.

    Edit one more thought: I believe the Windows installer / Windows s […]

  2. burlesona

    It’s sad that we don’t write code anymore, it takes a lot of the joy of stuff like this away.

  3. rubiquity

    I may be one of the few to use Crystal in anger for long running programs but unfortunately we had to do away with it because of longstanding issues in the runtime where exceptions at the wrong time during I/O bring the runtime to a halt. It's been a few years so I don't have the github issue off the top of my head anymore. I'd like to think that if they could redesign the language again they would not have exceptions and destructors/finalize.

    It's a great language for CLIs though. I'm glad to see the team still pressing on.

  4. todotask2

    I used Crystal for a year before moving on to Go, which I value for its faster build times. Bun also keeps improving at fast pace and constantly reduce memory usage which can be useful on budget server.

  5. sumnole

    For those that don't know: Crystal is like a typed Ruby with the performance and concurrency flow of Go.

More from this day

2026-10-22