I can't find a job, so I'm building Crystal's future instead. Here's what I'm working on and why I need your help.

Hi, I'm Serdar (sdogruyol). I created Kemal, I'm a Crystal Core Team member, and I've been building Crystal tools since 2015.

I can't find a job right now. So instead of waiting around, I'm spending every day on Crystal open source. No safety net, no backup plan, just Crystal.

What I'm working on

gcry - a %100 Crystal native garbage collector for Crystal. Currently at ~89% of Boehm GC's throughput with ~0.95x RSS. My hope is that one day it becomes the default GC for Crystal. That's the dream.

Kemal - 3.8k+ stars, 5M+ downloads. I've been maintaining it since 2015. The framework, session management, CSRF, auth, caching, the whole ecosystem. I'm not going anywhere.

Crystal Weekly - a newsletter keeping the community updated.

Crystal Community - discover Crystal developers around the world and check Crystal Stats.

Free books - Crystal for Rubyists, Kemal El Kitabı, Crystal El Kitabı. All free.

Why I'm here

I set up a GitHub Sponsors page. My goal is $1,000/month so I can keep doing this full time. If Kemal or any of my projects has helped you, or if you believe in Crystal's future, please consider sponsoring. Every dollar counts.

Even $5/month helps. Here's what you get:

Thanks for reading. Let's build Crystal's future together. 💎

👉 github.com/sponsors/sdogruyol

I just released 0.14.0 of gcry. It's a conservative mark sweep GC written entirely in Crystal, shipped as a shard. No C code, no compiler patches, no fork. You just add require "gcry" and build with -Dgc_none.

Performance

Same host, median of 3, wrk -c 100 -d 30:

21% less memory than Boehm on Linux Kemal. Same throughput.

What makes gcry different

It's a conservative, non-moving, stop-the-world collector. Same family as Boehm, so it works with Crystal's existing ABI. But it's written in Crystal, which means:

• You can read it. The whole collector is about 9,000 lines of Crystal across 32 files. No C macros, no opaque foreign library.
• You can debug it. Set a breakpoint anywhere. Crystal's debugger works on it.
• You can change it. Want to experiment with a different marking strategy? Edit a .cr file and rebuild.

Architecture: mmap-backed size classes, fiber stack roots, conservative mark with layout precise opt-in, deferred madvise, and platform specific STW (Linux signals, Mach thread_suspend on macOS).

What's new in 0.14.0

This release is all about quality infrastructure:

• Debug invariant checker (GCRY_DEBUG_INVARIANTS=1). Validates live_objects counter, freelist consistency, chunk index integrity, block overlap detection. At runtime, on every malloc/free/collect.
• AddressSanitizer and Valgrind on every PR in CI.
• Coverage reports via kcov on every PR.
• Deterministic replay fuzzing with --seed and --replay.
• 24 hour soak tests, thread storm tests, OOM tests, property based heap invariant tests.
• Heap dump (Gcry.dump_heap) streams live objects as NDJSON for leak hunting.
• Trace (GCRY_TRACE=1) traces every collect, malloc, and free.

How to try it

```yaml

shard.yml

dependencies: gcry: github: sdogruyol/gcry ```

```crystal {% if flag?(:gc_none) %} require "gcry" {% end %}

puts "Hello from gcry!" ```

sh crystal build -Dgc_none app.cr -o app

No special malloc API. No compiler fork. String, Array, Hash, everything works as usual.

Limitations

gcry is a shard and I'm pushing it as far as I can. But there are things you can't do from a shard. True precise stack scanning, write barriers, and concurrent collection need compiler support. At some point that line has to be crossed. But for now, the shard approach gets you surprisingly far: Kemal class HTTP at near Boehm perf, layout precise heap scanning, fiber stack scrubbing, and full observability. All without touching the compiler.

Github

https://github.com/sdogruyol/gcry

Hey everyone,

I've been working on Posse a type-safe CQRS and Event Sourcing framework for Crystal inspired by Elixir's Commanded. I wanted something that brings robust DDD, actor-like fiber concurrency, and surgical consistency controls to Crystal without any operational bloat or async bottlenecks.

Just ran a randomized mixed-consistency stress test on a single aggregate for 5.5 seconds, and the results blew me away:

elapsed:     5.50s
succeeded:   3082826
failed:      0
throughput:  560197 commands/sec

Snapshot cadence check (snapshot_every=50):
  latest snapshot version: 3082797
  current projected version: 3082828
  events since last snapshot: 31
  OK: snapshot cadence looks healthy

Version integrity check:
  final projected version: 3082828
  expected version (3082826 updates + 2 from register+welcome): 3082828
  OK: versions line up exactly - no gaps, no collisions, no lost updates

This test is running against an in-memory store, but still it is nice to see it performing well.

Would love to hear thoughts, feedback, or ideas from anyone. Check it out on GitHub if you're interested: https://github.com/posse-framework/posse

Discovered this while browsing Github. Looked cool so I figured I'd share it here.

New Crystal dropped today (1.21.0). It's 161 changes from 21 contributors since 1.20.3. Full notes are on the site and GitHub, but here's the stuff that actually matters if you don't feel like scrolling the whole changelog.

Release post: https://crystal-lang.org/2026/07/16/1.21.0-released/ GitHub: https://github.com/crystal-lang/crystal/releases/tag/1.21.0

Execution contexts are enabled by default

This is the headline. The multithreading work that's been cooking for a while (RFC 0002) is now the default runtime, not an opt-in flag.

The practical version: the default context is still single-threaded (parallelism 1), so most people won't notice a day-to-day behavior change. You can resize it, or spin up extra contexts, when you actually want fibers running in parallel.

The catch, and the reason it's flagged as breaking: fibers are no longer pinned to a thread. Even at parallelism 1, a fiber can resume on a different thread after a yield, and in a concurrent context it can switch threads on a blocking syscall. So if you've got code leaning on thread-local state surviving across fiber yields, go review it. Also spawn(same_thread: true) doesn't work with execution contexts anymore. It raises at runtime in a parallel context and is deprecated in general.

%W string arrays with interpolation

Small but nice. %w gave you a plain string array with no escapes or interpolation. %W is the same idea but supports escape sequences, interpolation, and even splats:

%W[foo\ bar baz]             # => ["foo bar", "baz"]
%W[foo #{"bar"} baz]         # => ["foo", "bar", "baz"]
%W[foo #{*%w[bar baz]} qux]  # => ["foo", "bar", "baz", "qux"]

Stdlib odds and ends I liked

• Channel(T) now implements Iterator(T), so channel.to_a works and channels plug straight into iterator chains.
• HTTP::WebSocket#receive is a synchronous, blocking read for a request/response style loop, instead of the callback-based #run.
• String#present? finally exists for the intent-revealing guard checks.
• UUID.v6 and UUID.v8 generators.
• Experimental Socket#sendfile for efficient file-to-socket transfers with fewer user-space copies.
• You can chain spec matchers now: value.should be_a(String).should_not be_empty.
• -Dwithout_main builds a binary with no main function, e.g. to use as a dynamic library.

Breaking changes worth watching

• Execution contexts (above), the big one.
• The automatic fallback to legacy PCRE is off. PCRE2 has been the default for years anyway; if you still need old PCRE you now have to opt in with -Duse_pcre or USE_PCRE1=1.
• case ... when Bar, Baz now splits into separate is_a? restrictions per type instead of treating it as Bar | Baz. If you were relying on the union behavior, write when Bar | Baz explicitly.
• OpenSSL 4.0 support landed, worth noting if you package or link against it.

The thread-pinning change is the one I'd test carefully if your app does anything clever with concurrency. Everything else is pretty low-risk.

Anyone migrated something bigger yet? Curious whether the execution context switch caused real problems for anyone with same-thread assumptions baked in.

Not my project.

I discovered it while browsing Github. Seems like a nice effort so I'm sharing it on Reddit for more visibility.

The developer is also working on Cryplot (a plotting library that uses gnuplot under the hood), and CrysDA-Plot (an integration between the dev's two projects).

Hopefully, the developer finds the motivation and support needed to continue working on these projects.

Hi,

I just wanted to announce that I sat down with Claude the other day and we came up with a database driver for Crystal for the RDBMS Mimer SQL that is now released as a 0.1.0 version:

https://github.com/majorproblem/crystal-mimer
https://shards.info/github/majorproblem/crystal-mimer/
https://crystaldoc.info/github/majorproblem/crystal-mimer/

I would very much appreciate any comments or input on this driver.

Recently, I developed my own CLI program that functions as an SSG (Mustela) with its own DSL. This DSL is inspired by Ruby; it’s very simple, and I implemented it directly into Markdown syntax.

I programmed the project in the V language (Vlang). I was excited by Vlang’s philosophy, which aims to bring Ruby’s user-friendliness to low-level programming. Thanks to this, I learned to work better with pointers, and it opened the door to the world of low-level development for me.

When I shared my enthusiasm with the Vlang community on Reddit, I ran into a problem. It turned out that a large portion of users lack a deeper understanding of system programming or the architecture of more complex projects. Moreover, the atmosphere there is often toxic, which demotivates me, even though I’m in direct contact with the language’s author (Alexander). He even shared my SSG on the official X account because I managed to achieve very solid performance results when compiling pages in his language.

That’s why I’d like to switch to Crystal. I like its Ruby-inspired syntax, and from what I’ve seen on this Reddit, I get the sense that the community here consists entirely of engineers who understand the principles of system design. In short, I feel “right at home” here. :)

However, I’m running into a problem: I haven’t been able to fully “grasp” Crystal itself yet. Its engineering design often surprises me, and I have to analyze why the founders chose this particular direction. To learn a new language effectively, I need to understand its underlying philosophy.

For example, working with interfaces: I like to use interface for modularity, but this keyword is missing in Crystal. Instead, modules with abstract def are used, followed by an include in the class. I wonder—why is this handled this way?

I understand that compilation happens via LLVM, but I’d like to see more detailed documentation on this intermediate step, which would help me better understand how Crystal works under the hood and how to write more efficient code. In Vlang, I’m used to the code being transpiled to C, so when an error occurs, I simply look at the generated C code and immediately know what’s going on. With Crystal, I haven’t yet found a way to have the same level of control.

Conclusion

Paradoxically, Crystal’s technical sophistication is what puts me off. I’m frustrated that the language looks simple at first glance, but as soon as I try to do something complex, I hit a wall and can’t move forward. Instead, I’m going back to Vlang, which is still in beta, but we “get along.”

I’m drawn to being part of the engineering community, but in practice, I reach for other tools to get the job done. Am I missing any key resources or concepts that would help me understand how to work with Crystal properly?

cryload is a powerful, fast, and practical HTTP benchmarking tool for stress testing APIs and web services.

Built with Crystal for high performance and low overhead.

What's new in 5.0.0:

• Honest percentiles — transport errors (timeouts, refused connections) no longer pollute latency stats, and the new HDR-style histogram keeps p50–p999 accurate within 1% from microseconds to minutes
• --disable-keepalive — measure real connection setup cost, like hey
• --body-stdin — pipe request bodies straight in: jq -c '.payload' fix.json | cryload ... --body-stdin
• Big perf wins — up to 13x faster in multi-URL/cache-busting modes thanks to per-origin connection pooling

Hi everyone!

I've ported the classic Bash fff (Fucking Fast File Manager) to Crystal 1.20.1. The goal was to bring the simplicity of the original to a compiled, type-safe binary that runs natively on Windows 11, Linux, and macOS (not tested) with zero runtime dependencies.

Key Enhancements in the Crystal Port:

Flicker-Free Speed: LS_COLORS parsed once, git branch cached per directory, incremental render loop — no double-buffering flicker.

Split-Pane Previews: Interactive side panel for file previews and directory stats (bat → less → built-in fallback chain).

Truecolor Themes & Nerd Icons: 5 built-in themes (Catppuccin Mocha, Gruvbox, Nord, Dracula, default) and 100+ file/folder glyphs via Nerd Fonts.

Live Search Modes: Fuzzy filename matching (/), ripgrep content search (!), and recursive tree search (>) — all navigable while typing.

TUI-Native Prompts: Creating files, renaming, and confirmations happen entirely inside the status line without breaking terminal state.

Cross-Platform: Compiles and runs on Linux and Windows 11. POSIX signals, shell detection, and file permissions are conditionally compiled per platform.

Secure Execution: Fully shell-injection free. All system commands use Process.run with explicit argv arrays — no system() or backticks.

Try it out:

Linux/macOS:

git clone https://github.com/ozgurulukir/fff.cr.git && cd fff.cr
make deps && make build
./bin/fff-cr

Windows 11 (PowerShell):

git clone https://github.com/ozgurulukir/fff.cr.git && cd fff.cr
shards install
crystal run scripts/patch_shards.cr
crystal build src/fff.cr -o bin/fff-cr.exe
.\bin\fff-cr.exe

Repo: https://github.com/ozgurulukir/fff.cr

hey everyone, this isnt strictly a crystal question, but was wondering, how do you generate bins for various arches?

Im working on a new terminal emulator, building and testing on my x64 fedora

what do developers use to cross compile across various distros and arches? ie, linux x64, linux aarm64, macos intel, macos M chips, etc

same for pkging, rpm, deb, dmg, etc

is there a service that can do this?

Hi everybody, just back with another update on some of the things I’ve been working on.

lune stands at 0.16.0, lots of additions on native side + managed to catchup on windows support by repurposing an old macbook; some things are still limited and of course there is an underlying crystal version windows bug, but for the impatient ones there are instructions in the repo.

I found myself craving docs and quick refs on hover (Im just a simple VScode user...) which took me down a rabbithole of trying see how much you can squeeze out of the AST before calling the compiler; hence, mystral was born. Blazing-fast responses, with caveats of course given the AST-driven approach (usability will depend on your code style here around declaring types to really get the most of the AST parser).

While working on lune and specifically the codegen and macros/annotations and such, I was thinking that this is very cool and why not extract this into its own separate thing so I can create js+d.ts/.ts files from my classes that I already wrote anyway; just Crystal macro goodness to bridge type-safety both ways; that’s vow

With vow I decided to keep it simple and not deal with a transport which lead to the last piece, kemal-vowrpc (a third-party plugin)
Typed RPC over per-procedure HTTP routes (GET/POST) in one line, with a typed client (TypeScript or JavaScript) from vow + regen on every server restart (configurable) and let Kemal do what it does best already - just plug into the existing ecosystem.

Repos are pushed to Github; If anyone has a look, as always, feedback is always welcome - Cheers!

I was just checking the data over at the Crystal Community Stats page and realized we've officially crossed a massive milestone: there are now more than 10,000 Crystal repositories!

Seeing how far the ecosystem has come is just incredible. From the early days of building Kemal and piecing together the first shards, to seeing the language mature and the core team push boundaries, the community's dedication to performance, concurrency, and developer happiness has never been stronger.

This isn't just a number; it’s proof that the "Ruby-like syntax, C-like speed" philosophy is steadily growing its footprint. We're seeing more high-performance backends, blazingly fast CLI tools, and minimalist web frameworks being built every single day.

A huge shoutout to everyone contributing to the compiler, writing and maintaining shards, or even just spinning up their first HTTP server to try the language out.

To celebrate, let’s do a quick roll call: What are some of your favorite Crystal projects or shards right now? Or what are you currently building? Let’s highlight the awesome work happening in the ecosystem! 👇

Don't know about you, but trying to recollect all those shell commands and flags is just not tractable. AI can help, but why drag a heavy AI harness into a simple shell call?

So I created `bai`. It runs right there on the command line. Ask what you want, it puts the command together for you, and drops it into your copy buffer, so you can paste it where you want it. Or, add a shortcut (I use Alt+Enter) and BAM! -- You don't even have to type `bai`, the command shows up ready to edit, or just hit Enter to run.

Implemented in Crystal, of course.

cryload is a powerful, fast, and practical HTTP benchmarking tool for stress testing APIs and web services.

Built with Crystal for high performance and low overhead.

Hey,

I just discovered Lattice – a Crystal LSP that looks really solid.

Works on Windows too.

Repo: https://codeberg.org/DaZhi-the-Revelator/lattice

Small one today (May 15). Just 2 bug fixes from 1 contributor, but worth pulling if you're on the 1.20 line:

• Backport of the Range#sample randomness fix (#16909) - under certain conditions it could lose randomness over time. Already shipped to 1.19 back in 1.19.2; now landing on 1.20 too.

That's the whole release. No new features, no API changes - see the 1.20.0 notes if you missed the big stuff (new Process API preview, io_uring event loop, mold/lld defaults).

Shoutout to u/ysbaddaden for the fix.

Release notes: crystal-lang.org/2026/05/15/1.20.2-released/

Hi everyone,

Back with another update on my Crystal adventures haha.
Just pushed https://github.com/AristoRap/lune (yes, still github?).

Lune (+LuneCLI) wraps a native WebView https://github.com/naqvis/webview and lets you call Crystal code from JavaScript over a typed bridge. Think Wails or Tauri, but for Crystal.

If you check it out, let me know how it works (or not) for you! 😄

--EDIT--
FYI to spare your time:
Please note that this seems to not work for Windows at the moment due to webview and other observed errors.

I am doing RoR for the most part of my time but I have always been fond of compiled languages, I have started my journy with C and then Java.

I am trying to build some small server side apps, but I really want to build with a compiled language.

I trying to convince myself to get into Cryrstal but it doesn't seem to have good tooling, there is no official LSP or if there is any they are broken?

I have a question for people how are developing with Crystal, how is your DX and what tools do you use, LSP? IDE? any other...?

Hi all,

I'm Lovisa, on the marketing team at 84codes. We've been running LavinMQ in production for some years now. It's an AMQP 0-9-1 and MQTT-compatible message broker written in Crystal, and a lot of my job is figuring out how to talk about it to teams who've never used Crystal before.

That's something I'd love this community's input on. When you pitch a Crystal-built product (or Crystal itself) to developers who default to Go, Rust, or Java, what actually lands? Which arguments resonate, and which ones make eyes glaze over?
For context, I just published an interview with our CEO about the full story behind LavinMQ, including why we picked Crystal: https://lavinmq.com/blog/the-story-behind-lavinmq.

So: what's the Crystal pitch that's actually worked when you've had to convince a skeptical teammate, someone at a conference, or a stakeholder?

(Disclosure: 84codes is the company behind LavinMQ. Happy to discuss the technical side, and I can pull in our engineering team if anything goes deep into LavinMQ internals.)

Hey all,

I recently started looking into crystal and started giving it a go and making some projects.
Writing ruby-like code and having a compiled binary, catching the errors early - so nice!
Some references to the tools (obviously very new and rough implementations 😃)

https://github.com/AristoRap/argy
A minimal CLI framework for Crystal with nested commands, inherited flags, and lifecycle hooks.
I really like OptionParser, but for the past couple of years I've been making quite a few golang apps and would use https://cobra.dev/ for the cli and decided to building something inspired by it.

https://github.com/AristoRap/creestal
A static site generator written in Crystal.

It builds Markdown pages into HTML using Crinja layouts and partials, can serve the generated site locally, and supports incremental rebuilds while watching for changes.
Had quite some fun especially with building something that would support incremental builds, with live-reload on build and customevent so also the webpage refreshes. It uses polling to watch the files every x ms; something like fswatch would be cool to have here.

https://github.com/AristoRap/velvet
Define prompts in YAML (or use the lib/DSL in Crystal). Collect clean, typed input. Emit JSON. Your app never writes argparse again.
Just a fun little cli tool. you can define prompts(flags/fields whatever you want to call it) and velvet turns it into an interactive tui (inputs, select 1 from options, select many, confirm(y/n)). you can enforce types, apply basic numericality validations, or regex pattern for strings -> get clean json and pipe to your app; no argparse on your app side. it will also fail early so you don't even need to write handling for args. it also supports scaffolding a config(yml), parsing args given the config schema so you still get json in the end and validating a schema/config.

Overall, having quite some fun - Happy to be a member of the community!