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 support for Crystal is a newer addition if I'm not mistaken, so it took a while before it got proper Windows support. Well, I just googled it, it started in 2023... but still, that's fairly recent by my book. I think any programming language should strive to work across the "big three" as soon as possible to increase adoption. Go took off the moment it came out for Windows and was formally released.
>It can often outperform hand-optimized Rust in worst-case parallel workloads (p99), despite Rust having a number of pretty huge advantages...
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 :)
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.
If you mean pre-packaged jobs in that specific language, you're correct. However, if you're a Rubyist needing native performance, it's another tool in your toolbox.
Yea but that doesnt help with companies still hiring for language specific roles. Also you gotta be able to check LLM generated code which requires proficiency in the given language.
Agreed. I saw the announcement and had an inkling of the excitement I got the first time I tried Crystal, years ago. I remembered how exciting new languages were to learn, and putz around with.
Then I remembered I could open [coding agent of choice] and it'd nearly oneshot whatever I would want to try in Crystal. I got a little disheartened.
Some languages for me were never meant to be 'used in production', but were a creative & learning space instead.
I mean maybe but... There's nothing forcing you to use Claude or what have you to play around is there? I mean an employer might force you to use it but you don't have to in your free time. That's one way I comfort myself lol
You’re right. But the treat was having a hobby that was also professional development. People in other industries have to take courses, study through dreary textbooks… I got to do something I enjoy and get professional benefit. That’s the shine we’re rapidly losing.
As someone who also feels that with new languages, I simply cannot relate to this idea that LLMs take that away somehow. To me, the limiting factor of all these langauges was (no shade to Crystal not really the case there these days) most of them have terrible or no docs, have terrible onboarding, have rough edges that may or may not be fixed.
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.
So 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!
What a ridiculously negative comment. Obviously ragebait, but I'll bite anyways.
Did you forget that until five minutes ago humans used to read the code? And they needed to understand it? Yes, there was an actual desire for great Ruby-like syntax without the implications of using it, like its performance characteristics and the need for an interpreter.
Yes, it didn't go mainstream. Should we all abandon every project we've ever worked on because they're not "relevant"?
The challenge for Crystal is that we also have TruffleRuby which gets you the elegance and Ruby interop. To me Crystal feels like it's at the same time too different to Ruby to benefit from the similarity and too similar to create its own viable niche.
HN is full of cynical comments like the above. We should be celebrating people trying things and doing things differently... I can almost guarantee you that the person who posted this cynical comment is not working on anything particularly relevant or useful.
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.
Prior to LLMs, Crystal was my language of choice when I needed a distributable binary. It works great for this, and for the kind of packages I was writing - mostly agent-daemons lurking in servers - the networking worked great. The only real alternative was golang, which I've never really liked and has (had?) a more complicated linking story too. The typing worked well too, if used with discipline - if it compiled, I could be pretty confident it would work. I still have systems deployed running Crystal agents, in production, without issue or memory leaks, for years.
LLMs though - I confess they've changed the calculus. Now I no longer have to look at the language, and obey its stupid ideas about error handling, I just use golang for its better library support. But I still have a soft spot for Crystal!
great that aarch64-linux support is now promoted to Tier 1! finally, I can convince my CTO to port some of our services in crystal for those cheap hetzner machines.
what does this language excel at in particular? havent heard of it before and didnt find a clear use case / mission statement on the webpage. unless I'm missing where to find it. just curious to learn more.
Crystal is for when you want to write C with Ruby-ish syntax. It's been around for awhile, all the way back to when Ruby was required to get VC funding.
In my opinion, it doesn’t excel at anything beyond being pleasant to read. Maybe if Go hadn’t come along, it would have gained more traction and developed a better concurrency runtime. Very few companies are publicly using it.
Plus, since 00s Ruby = Ruby on Rails, so it didn't appeal to ruby (on rails) developers back then.
It's somewhat similar to Ruby, but it categorically is not Ruby. If you want fast compiled Ruby, TruffleRuby is actually Ruby and relatively compatible with MRI.
I surely don't want a fast compiled Ruby for the tasks I would use crystal for though.
Like every one else I also used ruby for almost everything back then, usually some hundred of lines or less for processing stuff. but for tasks that run for several hours using ruby was a frustrating experience. slowness and memory consumption aside, the duck typing system and lazy evaluation of method meaning you can run to typo after hours of running session. sure, you can fix it by write the code more carefully, running smoke tests beforehand and other stuff, but it still a chore, and when you write code all days it makes you sloppier.
having a strong typed compiled language helps it immensely, and with crystal you don't have to sacrifice the easiness of programming. and you can compile it to a portable binary and run it everywhere, no need to reinstall a huge toolchain again. (yeah rust or go can also do that, but not for ruby level expressioness language)
I'm sure crystal is not the ideal language for everything you want to use, and ruby is still helpful for what you use daily. but for some tasks, crystal surely has it own advantages. you can write very capable CLI programs without have to install a single library!
You're free to like Crystal of course, but for me even for long running tasks (almost my entire desktop, including my wm, terminal, editor are Ruby - I still use Ruby for almost everything; if anything, for more than ever), the Ruby ecosystem beats the steadily diminishing performance gap between MRI and an AOT compiled language to the extent that even going to TruffleRuby where I could keep almost all of my code, is rarely worth it for me.
But my main point was that people who do want a fast Ruby should be aware that Crystal isn't a Ruby in any meaningful sense - if you like Crystal for Crystal, by all means use it.
Could also use Matz's Spinel Ruby compiler. That's Ruby with static types using RBS but you have to give up some metaprogramming to get it.
I love the idea that we could get ractors written with Spinel and compiled ahead of time. I also love the idea that I can use Ruby for self contained binary tools.
(And for the sake of avoiding confusion, Crystal is also a great project. I'm really pleased to see them continue making progress).
They have an interactive mode right now (crystal i), but it's not very comprehensive. You cannot use certain libraries with it etc.
Shouldn't be terribly hard to make it good though. Some time ago, I added a JIT REPL in a few afternoons with Claude, ending up with roughly the same performance as their compiler, and with it working reliably with all the libraries I tested. But since they don't want LLM contributions in Crystal, I just left it as an interesting experiment and started working on my own language instead.
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 support for Crystal is a newer addition if I'm not mistaken, so it took a while before it got proper Windows support. Well, I just googled it, it started in 2023... but still, that's fairly recent by my book. I think any programming language should strive to work across the "big three" as soon as possible to increase adoption. Go took off the moment it came out for Windows and was formally released.
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...
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 :)
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.
Which means you can have fun trying new languages with every new project :)
If you ask Claude create me a Crystal controller for Kubernetes, good luck with that.
Then I remembered I could open [coding agent of choice] and it'd nearly oneshot whatever I would want to try in Crystal. I got a little disheartened.
Some languages for me were never meant to be 'used in production', but were a creative & learning space instead.
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.
So 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!
It isn't interoperable with Ruby and I don't know of any reputable companies using Crystal.
It just looks like Ruby, but it isn't Ruby and it is a compiled language? OK?
I am not sure why I should learn this language?
Did you forget that until five minutes ago humans used to read the code? And they needed to understand it? Yes, there was an actual desire for great Ruby-like syntax without the implications of using it, like its performance characteristics and the need for an interpreter.
Yes, it didn't go mainstream. Should we all abandon every project we've ever worked on because they're not "relevant"?
Kagi uses Crystal for their search backend [1]. How they feel about that today and whether that was the right call are, of course, separate questions.
[1] Previous thread: https://news.ycombinator.com/item?id=38421149
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.
LLMs though - I confess they've changed the calculus. Now I no longer have to look at the language, and obey its stupid ideas about error handling, I just use golang for its better library support. But I still have a soft spot for Crystal!
In my opinion, it doesn’t excel at anything beyond being pleasant to read. Maybe if Go hadn’t come along, it would have gained more traction and developed a better concurrency runtime. Very few companies are publicly using it.
Plus, since 00s Ruby = Ruby on Rails, so it didn't appeal to ruby (on rails) developers back then.
Like every one else I also used ruby for almost everything back then, usually some hundred of lines or less for processing stuff. but for tasks that run for several hours using ruby was a frustrating experience. slowness and memory consumption aside, the duck typing system and lazy evaluation of method meaning you can run to typo after hours of running session. sure, you can fix it by write the code more carefully, running smoke tests beforehand and other stuff, but it still a chore, and when you write code all days it makes you sloppier.
having a strong typed compiled language helps it immensely, and with crystal you don't have to sacrifice the easiness of programming. and you can compile it to a portable binary and run it everywhere, no need to reinstall a huge toolchain again. (yeah rust or go can also do that, but not for ruby level expressioness language)
I'm sure crystal is not the ideal language for everything you want to use, and ruby is still helpful for what you use daily. but for some tasks, crystal surely has it own advantages. you can write very capable CLI programs without have to install a single library!
But my main point was that people who do want a fast Ruby should be aware that Crystal isn't a Ruby in any meaningful sense - if you like Crystal for Crystal, by all means use it.
Could also use Matz's Spinel Ruby compiler. That's Ruby with static types using RBS but you have to give up some metaprogramming to get it.
I love the idea that we could get ractors written with Spinel and compiled ahead of time. I also love the idea that I can use Ruby for self contained binary tools.
(And for the sake of avoiding confusion, Crystal is also a great project. I'm really pleased to see them continue making progress).
https://github.com/matz/spinel
Shouldn't be terribly hard to make it good though. Some time ago, I added a JIT REPL in a few afternoons with Claude, ending up with roughly the same performance as their compiler, and with it working reliably with all the libraries I tested. But since they don't want LLM contributions in Crystal, I just left it as an interesting experiment and started working on my own language instead.