I’m a Crystal newbie and I’ve only been learning it for a few months.
In my newbie opinion, it feels like a combination of the best parts of other languages
But it does that really well.
Because I’m still a beginner, some of my opinions might be inaccurate. I’d really appreciate any corrections.
It has graceful syntax like Ruby. When I’m learning it, it honestly feels like I’m learning a human language.
It’s flexible but still safe. Crystal’s type inference system is truly genius. Even though I’m still a beginner, I can already tell the compiler has saved me from who knows how many runtime errors.
It combines Go-like concurrency with a Ruby-style syntax, and writing concurrent code this way is genuinely enjoyable.
Powerful macros (although I still haven’t learned macros yet hahaha :D)
There are probably many more advantages of Crystal that I haven’t discovered yet.
But at least for me right now, I really feel this language is a genius combination of great ideas, and an impressive piece of development built on top of them.
Writing Crystal code is really enjoyable: flexible syntax, but still safe.
If this language had a bigger community or stronger company backing, it would be perfect.
I truly think Crystal is an absolutely great language, but one of the reasons it struggles is that it doesn’t have a strong supporter like Go has with Google.
Maybe Crystal also needs a breakout moment, just like Ruby had with Rails.
Or maybe someone will build an awesome tool in Crystal that suddenly goes viral on the internet. If that happens, Crystal could finally get more attention and visibility.
Because honestly, the language itself is not bad at all. It just doesn’t have as strong a background or ecosystem behind it.
All in all, I really like this beautiful language, and I’ll keep learning it.
This is a project I wrote recently to practice Crystal and get more hands-on experience with it:
The backing situation is real — Crystal runs on two companies, 84codes at €22k/month and Manas.Tech at $5k/month. No foundation, no diversified membership, no answer to the “who do we call?” question that a security or compliance team will accept. Rust has AWS, Google, Microsoft, and Huawei at the table. Crystal doesn’t have that, and pretending otherwise doesn’t help the conversation.
The ecosystem holes compound this. SAML doesn’t exist anywhere in the Crystal shard ecosystem. Oracle and MSSQL drivers don’t exist. Windows tooling is still officially “Preview” — and for anyone doing security work specifically, the absence of Windows authentication protocol support in the shard ecosystem is a serious problem. Most enterprise environments are Windows-first, and compliance teams are already asking hard questions about language longevity and supply chain security. shards has no audit command, no CVE database, nothing equivalent to npm audit or cargo audit. That conversation gets uncomfortable fast.
The gaps are real, but the direction is right. 2024-2025 has been Crystal’s most productive stretch in years — execution contexts, async Windows I/O, paid enterprise support via Crystal Compass. The trajectory is good. The language itself has never been the problem.
The breakout moment framing is correct, but it needs to happen in the right domain — somewhere static binaries, zero runtime dependencies, and C-level performance matter more than ecosystem depth. Security tooling with a focus on network and Windows authentication protocols feels like the best path forward right now. For Crystal to have a real future, it needs to differentiate itself from Ruby and avoid falling into the trap of becoming just another web framework or backend automation language.
I truly feel that Crystal shouldn’t just be overlooked and buried.
At my university, I’m probably the only person using Crystal right now. I’m trying to spread the language and let more people know about it and its advantages.
Note: I have no experience with either of those shards. So I can’t say if they’re actually good. But they exist at least.
I don’t even know what that is. Active Directory & Co?
IMO such platform specific libraries might be less relevant for Crystal. For software that’s explicitly and deeply tied to a specific operating system, maybe a more native toolchain might be better for optimum API availablility (for example via the .NET platform on Windows).
Crystal is great for cross-platform applications. The general idea is if an app builds on Linux, it should be expected to build on macOS, Windows, FreeBSD, etc. as well.
I stand corrected: those do exist, and I should have been more precise. My statement was about production-viable, actively maintained shards rather than existence alone.
On SAML: spider-gazelle/crystal-saml I actually found this one in my research but noted it has no release yet by the maintainer’s own admission. That’s not a usable shard, that’s a work in progress. The atlantis/saml reference is unclear it doesn’t appear in any tracked Crystal shard registry I can find. I stumbled across this maintainer when searching for NTLM
On Oracle: crystal-odbc is a unixODBC wrapper, not a native driver. It also requires a specific unixODBC version as an external system dependency. That’s a meaningful distinction in enterprise environments where you don’t always control what’s installed on the host.
On MSSQL: crystal-tds exists and is the most legitimate of the three — pure Crystal TDS implementation. But it’s a single maintainer with 12 stars, 2 forks, and a self-documented restrictions list in the issue tracker. That’s not something you’d stake production infrastructure on.
Looking at it from even a compliance lens: Existence and production viability aren’t the same thing. A shard with no release, a wrapper around an external dependency, and a single-maintainer project with documented restrictions aren’t the same as having first-class enterprise database support. The gap I was pointing to is still real, it just has some placeholders in it.
On Windows authentication protocols:
NTLM
Kerberos
SPNEGO
SMB2/3
DCE/RPC
krb5
That’s what I mean. The building blocks that make AD interaction possible at the protocol level. Right now there’s nothing in the Crystal ecosystem that covers any of that stack in a serious way. For security engineers working in enterprise environments, that’s the gap that actually matters — not just “Windows tooling is Preview” but the complete absence of the authentication primitives that Windows-first environments are built on.
I’d also disagree slightly on the .NET framing. The value of implementing these protocols in Crystal isn’t to compete with native Windows tooling — it’s to have a cross-platform, dependency-free implementation that security engineers can deploy anywhere without a runtime. That’s the same reason Impacket exists despite .NET being a more native choice. A stripped static binary carrying a full NTLM/Kerberos/SMB2 stack is a different tool for a different context. For example: a red teamer dropping a single binary onto a compromised Linux host and authenticating against a DC without installing anything, an incident responder working in a minimal live environment with no package manager, a penetration tester in an air-gapped network where outbound package installation isn’t possible.
And it’s not just security engineers who benefit. Systems administrators scripting AD interactions from Linux management hosts, DevOps engineers automating identity workflows across hybrid environments, developers building cross-platform software that needs to authenticate against AD without bundling a runtime, compliance and audit tooling authors querying AD state from non-Windows infrastructure. All of them benefit from a dependency-free native binary that just works regardless of what’s installed on the host.
This is exactly the domain I think Crystal should be moving toward. But it would require quite a lot of work to start replicating those libraries offered by other languages into reusable shards.
Frankly, I think your view of what’s missing is coloured by what you want to use Crystal for. We’re a few that’s managed a decent career with minimal exposure to the technologies you mention.
I doubt that Matz saw Rails coming, or really wanted Ruby to be a “web framework language”, but you can’t steer these kinds of things.
Like it or not, the web is a pretty big part of computing these days, so latching on to that in some way might not be a bad thing. Or AI, perhaps.
You’re not entirely wrong about my perspective being shaped by what I want to build. I won’t argue against taking an interest in the language because I want to build tooling that requires libraries touching things at a system level, something Crystal should be able to do extremely well given its C-level performance. But I’d disagree on the framing that wanting system-level AD authentication support is somehow a niche interest that colors a view unfairly.
Enterprise web applications authenticate against Active Directory constantly. SSO, SAML, Kerberos-backed tokens, LDAP directory lookups. The moment a Crystal web app gets deployed in a corporate environment, it runs into exactly the authentication stack I’m describing. That’s not pulling Crystal away from the web; it’s asking for the infrastructure that makes Crystal web apps viable in environments where compliance and security auditing actually happen. That also translates directly to more business for Crystal Compass, real contracts, and a whole category of engineers who currently have no reason to look at Crystal at all.
On the steering point, Matz almost certainly didn’t anticipate that Ruby would become one of the primary languages of the security research and penetration testing world through Metasploit. That wasn’t a detraction from Ruby’s identity as a web language. It expanded the community, brought in contributors with different backgrounds, and produced infrastructure that benefited the language overall. Nobody looked at Metasploit and said Ruby should have stayed focused on Rails.
It’s also worth asking how other languages actually broke through. Go didn’t take off because it was the most expressive language. It took off because Google needed something that compiled fast, ran fast, and made concurrency manageable for infrastructure work. Docker was written in Go. Kubernetes was written in Go. Suddenly Go had a story and an audience that wasn’t just “another systems language.” Rust took a similar path. Mozilla needed memory safety without a garbage collector for browser engine work, and that specific constraint produced something no other language offered. The security and embedded communities latched on because Rust solved a real problem they had, not because Rust marketed itself at them.
Crystal has the syntax of Ruby with the performance of C and no runtime. That’s genuinely unusual. The question isn’t whether Crystal should try to be a web language or a security language. It’s what problem does Crystal solve that nothing else solves as cleanly. Right now the answer is a readable, type-safe, zero-dependency binary that you can drop anywhere and run. That’s a compelling story for security tooling, for infrastructure scripting, for any context where you want Python-level readability without Python’s deployment overhead. The security angle isn’t a detour. It might be exactly the kind of niche that gives Crystal its Docker moment.
The shortage of libraries we face today will likely cease to exist in the near future.
If you load an AI agent’s oven with the relevant specifications, papers, and reference implementations, and let it bake for one night to a few days, the library you need will be ready — probably of higher quality than what a skilled developer could produce in a month of hard work. This trend should become increasingly clear a year from now, because the majority of today’s libraries are built on foundations that humans have built by hand over many years, which places inherent limits on their complexity.
When that situation arrives, what will matter is not whether a library exists, but how readable and usable the baked library is. Equally important is whether there are people willing to invest the resources needed to do the baking. On the former point, Crystal may well have an advantage.
That said, I suspect some new obstacle will emerge to take the place of the old one. One example that comes to mind is large companies pouring money into next-generation libraries many times more complex than today’s, or entirely new operating systems tightly coupled to specific hardware. Humans have a tendency to push complexity to its limits. It is easy to imagine that such next-generation technologies would disrupt the relatively simple era in which porting a library from another language into Crystal takes only a few days of AI agent baking.
There will no doubt be other hurdles we cannot yet imagine.
So while I believe we will still face some form of shortage, I expect it will look very different from the one we face today.
I agree with you, opening Crystal to new niche communities is only positive.
LavinMQ, which is arguably the most successful Crystal project, is an infrastructure project, not a web project. And Crystal is brilliant in the infra space.
This is really cool for me, I deploy some little project on my server, and just need compile then drop to server and it can run without anything! really enjoyable
@xalynn Crystal in my startup is now the default language for everything. We are building a new open source cloud computing orchestrator, Airsailer
In my opinion, Crystal is already an excellent and mature language and it is up to each one of us to build what we need.
About popularity and being ready for enterprise use-cases, it is just a matter of time (“when”, not “if”). Companies that understand Crystal is a competitive advantage, they will be ahead and build what is missing for them.
I knew nothing about gRPC, but I realized that I absolutely needed it to do what I wanted. So, although I was not very excited about it, I spent the last two days baking a library for Crystal in the AI oven.
What I actually did was just put in the reference implementation and the instructions, check on it from time to time, make sure the fire was still going, taste it once in a while, and hit the AI again and again to make it move faster. Every time I use tokens, it costs money, and on top of that, it is addictive, so it even feels a little like an arcade. What a strange time we live in.
Anyway, I need to be careful not to lose sleep. Health is very important. I need to stay strong, turn off the computer, and go to bed. Our brains are not made of silicon. They are very fragile.
Crystal is actually a perfect language for a startup. Startups are often not yet constrained by the same compliance and audit requirements I mentioned, although they do still apply. Enterprise customers and investors start asking hard questions about security posture, dependency chain auditability, and language longevity well before a formal regulatory body gets involved.
That pressure grows as companies scale. The compliance and integration questions become blockers and show stoppers for wider adoption in ways that people may not realize unless they’ve been on that side of the table during conversations with mid and C-level management. On this point, I’m thinking more about Crystal Compass, Manas Tech, and the target audience they’re marketing their services towards. The service becomes a lot easier to sell when the hard questions have answers that satisfy frameworks like SOC 2, ISO 27001, and SLSA. There are others, but those are the big 3 unless you’re in a niche domain where PCI DSS or HIPAA could also apply.
“when” will probably depend heavily on the community and the timing depends on the ecosystem catching up. The shards need to reach a maturity level that can survive scrutiny and integrate cleanly with existing enterprise infrastructure. Both are very doable, it just requires sustained contribution and community review work. The Core team has their hands full and their time is constrained, so this is where the community needs to carry the load.
