@jgaskins With the recent controversy happening in ruby over Ruby Central and also DHH, it might be an opportunity for the more followed Crystal enthusiasts to re-introduce Crystal to the ruby world.
More and more people are finding crystals. However, in my personal opinion…
I also agree that Crystal can be used as a vehicle to introduce people to a more fun way of programming, in the same way Ruby acted as during its relative heyday.
I think the current controversies will not be a great vehicle for adoption, because in many ways Crystal’s community is more vulnerable to sudden changes in the community than Ruby is.
But I think coming out of the door some day and going “hey, we’ve got really cool stuff here and it works surprisingly well compared to whatever you’ve been fighting with the last 5 years of your career” always has a lot of value
Which is kind of why Ruby and Rails did so well in the first place and why they continue to attract new people.
If you can show people “we’ll turn the next 5 years of your project into relative joy” I think at that point people start going “yeah… using this language is a good idea!”. There’s still a lot of work for the community to do in that area, I think.
Just to give a counter-example: I am coming from a Ruby context and still love Crystal. But to a certain degree you are probably right - I at least remember a time where I wouldn’t have traded the benefits of a static type system over the flexibility you have in Ruby. Just wanted to bring up my case as an example that it is certainly possible! Maybe we can find some concrete arguments to make Crystal appealing to Ruby developers specifically?
Thinking further about it - I found out about Crystal via the Ruby Weekly newsletter featuring some blog post as an excursion. My impression today is that there isn’t much content around that could be presented in places like that in the first place. So maybe the slow growth issue of this community would solve itself if we all started writing/blogging about it more. It’s certainly been on my todo-list for years now, but actually sticking to it is a different story…
I came from Ruby a few years ago, and I’ve often felt that many Crystalists think, “Why use Ruby when Crystal is better?”
But I believe that’s not a very productive way to think. It tends to create a negative mental loop—trying to convert Rubyists and feeling frustrated when it doesn’t work. Keeping your mental loop in the black is, I think, the most important thing if you want to keep going for the long run.
In a sense, Ruby users are the hardest audience to impress with Crystal, because Ruby already has so many of Crystal’s strengths. Introducing Crystal to Rubyists is like selling crystals to a jeweler.
And of course, Crystal isn’t necessarily better than Ruby. Ruby has eval and powerful metaprogramming that Crystal can’t really imitate. Its loose typing also means that old code often “just works” even after many years.
Even when you consider the overall market share of programming languages, trying to grow the user base from the already small Ruby community doesn’t seem like a strategy that’s likely to succeed. Sorry if that sounds a bit pessimistic.
Introducing Crystal to Ruby users is a good thing.
Just don’t fall into that negative mental loop.
I agree with a lot of this. While Crystal is very friendly to the developer, so is Ruby, to an extent. Ruby is arguably friendlier to the developer than Crystal. There are caveats about finding type errors after modifying the code, but I don’t think you’re going to convince Rubyists that this outweighs things like Crystal’s compilation time. Rubyists are used to hunting down NoMethodErrors, so it doesn’t seem like a big deal to many of them.
Where Crystal wins over Ruby is how friendly it is to the computer at runtime. Lower CPU and RAM usage for nearly identical code is incredible. And Crystal supports other practices that can improve those metrics even more by changing how you approach the problem — things like streaming DB results directly into JSON, where you can fetch 1M records from the database in a single query, generate hundreds of MB of JSON, while only using 3MB of RAM for the app. This simply can’t be done in Ruby. You would have to load all of the records into RAM, convert them to an array of hashes, and convert that array to a JSON string. This would require you to hold 3 representations of the data in memory at once.
My Redis shard began as an experiment to optimize a different Redis shard. I was consuming Redis streams and trying to see if there was a way to make it faster. The original service was written in Ruby and for one particular operation and it took a heavily optimized, purpose-built Ruby Redis client 6.3 seconds to receive the stream events (not process, just to receive the data from Redis), vs 186ms in Crystal. So Crystal was 37x as fast as Ruby on that particular operation.
Even if you think your app code isn’t the bottleneck, you’d be surprised at how much performance you can gain from using a language with a faster runtime. People are often surprised at how often “the DB is the bottleneck” is actually “deserializing data from the DB is the bottleneck” in disguise.
When you compare Crystal to other languages that are good for the computer (Go, Rust, etc), we can point out how much better the Crystal code is for the human and, actually, sometimes even for the computer. In a blog post comparing Crystal and Rust, I showed code for talking to Redis (which became the Redis shard I mentioned above). The Crystal code in the article is soooo much easier to read than the equivalent Rust code, also in the article, and it performs 2.8-3.1x as fast (something the Rust fans in the audience were not ready to hear), measuring strictly CPU time.
That doesn’t mean Crystal is necessarily faster than Rust, but it can be and it’ll likely be easier to work with. Even in scenarios where Crystal is “only” as fast as Rust, or Rust beats it by some margin, code readability is an important factor.
I fully agree with everything you said. When developing an app or library, people usually spend a significant amount of time reading code, so Crystal being very easy to understand and digest is a massive bonus, while not compromising on speed.
However, the core Crystal dev team, or whoever is / should be responsible for it, has been horrendous at promoting the language. It’s almost like they don’t want people to know about it. This is also quite noticeable in this thread, where they didn’t chime in at all.
A few months ago, I started learning Odin as a new programming language, and there’s literal hours of podcasts, showcase videos, examples etc. by the creator of the language talking about it. Odin is younger than Crystal, yet there is virtually no promotional content of Crystal available on the internet.
The overall PR of the language ranges from non-existent to very bad. I made this post a while ago, talking about how the motto needs a more lucrative take, and people in general seemed to agree, yet it went nowhere.
Someone who might be interested in picking up crystal takes 2 looks at the content available online, be that projects, showcases or discussions, writes off the language as dead and nopes out. Unless someone who’s actually part of the development actively goes out and promotes it, the language is just going to slowly erode away, despite the myriad of benefits it could provide to all sorts of applications.
Maybe this is just me being frustrated about the entire situation because I absolutely love Crystal and want it to be more popular, but it genuinely feels like the creators of the language do not.
I wouldn’t jump to a value judgement, but I do think the language could benefit from additional focus on developer relations. A lot of languages and ecosystems I’ve used got popular because people who aren’t the original devs advocated for it. For example:
- Java was originally heavily promoted by Sun (“write once, run anywhere” was a great tagline), but universities starting to teach it during the dot-com boom was also a critical part of its growth
- Ruby became popular outside of Japan because two guys wrote an absolutely incredible book about it in English at a time when programming books were still hugely popular
- Rails reached a critical mass in large part because some random guy in Portland was making screencasts for it every week for free on his own website before YouTube had monetized channels
- Rust became popular outside of Mozilla because of a group called the “Rust Evangelism Strike Force” (I could never tell whether the group was called that ironically, whether they named themselves that, etc) which was basically guerrilla marketing
So, it can happen even if project maintainers aren’t the ones doing it.
That may very well be, it’s not necessary for a language’s success, but the lack of it definitely doesn’t help.
As an example, execution contexts were merged into crystal main a while ago, and they are fantastic. Beyond amazing. The sort of thing that could get everyone who has ever touched multithreading excited. I genuinely cannot put into words how fun, easy and great they are.
Yet there is not even a blogpost about it on the official crystal website. Just crickets.
Like, how do we expect people to find and try crystal?
There are two ways of thinking that I often compare.
One is goal-focused thinking, where you imagine a better state, see what’s missing, and work step by step to make it real. The other is reality-based thinking, where you look at the current situation, think about what will happen if nothing changes, and take action to make that future better.
Both are important, and we need to move between them from time to time. But for me, the second one is harder.
If we apply this second way of thinking to Crystal, we could not only think about what we wish for its growth, but also look at real projects that already use it. By seeing which kinds of projects stay active and which ones fade away, we might get a better idea of where Crystal could be heading. And once we can see that direction, we might also understand what should be done next.
Ruby was never originally meant for web development. It just turned out to be useful for the web — more by chance than by design.
From what I’ve seen, Crystal projects that last often involve communication or networking. That’s interesting, because many people believe that languages with garbage collection are weak in those areas.
I’m not very good at this kind of research, but it might still be worth trying.