I’ve recently started using Crystal after having heard so much about it but I’ve never given it a shot until now because, in my ignorance, I thought I wasn’t looking for a compiled language with a Ruby-inspired syntax. After falling in love with Elixir (another language that looks like Ruby), I installed it, read the docs and… I fell in love. It’s fun to program in Crystal! It makes me feel warm inside.
After catching up with the latest development, there’s a question that keeps looming in my head. What’s the future of this language? I say this because as a newcomer, the impression is that development has pretty much gone stale, and there’s no visibility of where and why it has stopped. I’ve come across plenty libraries that seems to have stopped being updated some time in 2019, and the feeling is that Crystal hasn’t succeeded in turning many people’s heads, and now it’s fading into obscurity…
Some examples:
I understand Windows support is supposed to be the major focus, but what’s the status of it? I’d like to be kept up to date on the language blog. It seems to be a major reason why many people skip it, from what I can hear.
What happened to multithreading? I know there’s alpha support hidden behind a feature flag, but I can’t seem to find any update on it. Is that feature dormant for the time being? I don’t need it, but supporting multiple threads these days is a sign of language maturity.
Github seems to be a little active, there’s vibrant discussion in the issues and PRs, but commits are few and far between.
Additionally, there’s a ton of PR stuck in limbo. There’s a thread about it, I know. It just seems that there’s a major bottleneck between contributing and actually landing changes on master. There’s some very small and benign PRs that have been opened for years, approved and still unmerged.
Please don’t take this the wrong way, but the impression is that who’s running the project is busy on something else and the language is close to being put on maintenance-only mode. I am aware reality might be a little more complex, but as someone that wants to see this language succeed (because I want to use it professionally), I don’t know if this is just a lull in activity, or a decline.
My hope is this post sparks some discussion and is not seen as an opportunity to bash the language or underestimate the effort of people working on it. It is meant will all respect and admiration for creating this wonderful product.
With all due respect, I don’t think there’s been a slow down. Releases · crystal-lang/crystal · GitHub had a 1.4.0 release followed by 1.4.1, both in April; previous was 1.3.2 in January.
Plus, the community has had various releases recently, e.g.:
Sorry, my focus/interests are very web-framework and Ruby/Crystal related. There’s probably other recent releases out there too; just not as much of a focus for me at the moment.
Sure, everything comes in waves; sometimes people shift their focus, tend to other priorities, need some vacation time, etc, but wouldn’t say there’s been a slow down with Crystal and the community. Of course, I’m not against any speed-ups either.
From my aspect, i think window develper (develop crystal on window?) or run crystal on windows never be a issue, I have a question, for the Rubyist, Who work on windows or use ruby on window? than, on Crystal program on window maybe a big improvement,
but, relative to, multi-thread support, more important for me anyway.
Also with the above topics, I’d be curious as to what the status is with the Crystal Interpreter. As of 1.4.1, the compiler still isn’t shipped with it enabled yet, and the github issue tracking it seems to have stalled since January. Finishing up multithreading implementation so it’s not behind a preview flag would be nice too, but I haven’t seen much discussion on what’s needed for that yet (this is more likely me not seeing the discussion though, rather than it not happening).
windows support should be way more important, because windows is still the most popular desktop OS right now, and you can’t require your clients to install WSL and bunch of complicated tools to run your code, when golang and rust and c++ and others languages can provide a portable binary that can run with a single double click.
Thanks for creating this post, I created an account just to give it a like as I have looked at Crystal for some time now and had the same exact questions.
I haven’t gotten around to trying out Crystal just yet, I will wait for Windows support before jumping on the Crystal train. Do I prefer Windows over the currently supported platforms? Hell no, but it’s the OS I’m stuck with, and I really do not like the WSL experience. I do agree with @npn that Windows support should have the highest priority because as a general-purpose language it seems really silly not to support the most general OS. Parallelism + concurrency is another important factor in my choice of language, and would also love to see stable support for multithreading as I’m sure everyone else would.
Another question I have about the language is about the OO model. It seems Crystal embraces inheritance while the modern OOP world has moved towards composition with patterns like dependency injection. What I really like with Go is its approach to OO, making it easy to work with all the way from writing code to implementing others’ code as well. Is there something similar with Crystal, making it easier to work with (or against) the possible complexity of OOP?
I’m really interested what you don’t like about WSL. As an avid user of WSL2 (I also ran Linux as my main OS for sometime), I really find it the best of both worlds.
Also, I’m pretty sure you can run Crystal on Windows, but it still needs a few highly specific things that are more to do with internal Windows knowledge. I could be wrong, but that’s what I’m remembering.
I do find that, of the requested features, the interpreter as the most important, because that could have the biggest impact on the ecosystem (smaller feedback loop). But anyone can contribute to that, not just the core team.
Are you trying to use the Windows filesystem from WSL? If so, yeah that makes sense. I never do that. I just stay inside WSL filesystem for all my work, which is the recommended approach.
Tbh, I don’t know what the big deal is using the WSL filesystem over using native Windows filesystem. Maybe I’m just biased for Linux systems.
Probably best not to get this topic sidetracked by WSL woes.
It’s apparent Windows support is very important, and I’d like to hear more about what’s the status with multithreading, which is what I’m looking forward to.
The OO model of Crystal is similar to the Ruby approach rather than a strict hierarchy seen in C++ or Java. Keep in mind that the language has always taken inspiration from Ruby, and there message-passing style OOP is a core feature.
As such, Go-style inheritance is not something that can be added to the language at this stage. It’s not a good fit IMHO, and would basically result in a totally different language.
Personally, Go-style inheritance or OOP is fine, but functional is miles better, and thankfully Crystal has some decent functional sugar to appease me.
I haven’t gotten around to trying out Crystal just yet, I will wait for Windows support before jumping on the Crystal train.
I guess you should start play Crystal as quick as possible, if you never have ruby experiences, because, i guess, it should quite hard to study for people programming use go.
Yes, in Crystal, a module can be mixin to another module, a class, or a struct, though, i am curious why the word mixin never mention in language reference.
In fact, i consider mixin is a common term, You can mixin a class into another class in Dart too, becuase no module in Dart, but, still can mixin.
For people want to know what is mixin, google search ruby module mixin, all skill study there can use in Crystal.
Hey @1player welcome to the community! I hope you and everyone else who has chipped in here have a lot of fun with Crystal. That’s what it’s meant for =)
Thanks for raising these concerns. It’s really valuable to get feedback on the perception of the project.
First of all, I think Crystal and its community is thriving quite well. Sure, it would be great if things moved faster. But I believe we’re at a healthy pace, actually. Of course, we’d like to do more, but there are so many things to do and to keep track of, and we are after all a rather small team taking care of all the daily tasks that go into developing a language. There’s also a lot going on for managing such a project which might not be highly visible (infrastructure maintenance, planning, exploration of future features).
Despite that, there has been some tremendous progress since the 1.0 release a year ago. @drhuffman12 already mentioned some evidence for community activity. But for the language itself, we got an interpreter, basic WebAssembly support, almost ready Windows support, and lots of features (improved 128-bit integer support, improved autocasting) just this year. And lots of bug fixes and refinements (which can be taken as a sign for maturing).
Windows support is almost complete (see Coordinate porting to Windows · Issue #5430 · crystal-lang/crystal · GitHub). We’re only missing some concurrency features (notably adaptation of the event loop). This is unfortunately not an easy thing to do, and requires significant work. We’re lacking contributors with deep Windows knowledge, which is also something that slows down progress. Nonetheless, Crystal is actually quite usable on Windows for any program that doesn’t need concurrent IO. Many Crystal projects are already running CI on Windows and distribute Windows builds. So there’s been a lot accomplished already.
Please see the latest big update on Windows support, in the 1.3.0 release: Crystal 1.3.0 is released! - The Crystal Programming Language
True, there is currently little activity on this subject. It’s still unclear which direction we’ll take with multithreading. The preview_mt flag apparently works quite well (AFAIK it’s used in production by many people), but its use comes with some dangers because some of the standard library APIs (as well as many third party shards) are not thread-safe. That’s why it’s still an opt-in flag.
A discussion about further details for moving on is pending, but apparently not in the near future. We consistently make our best efforts to move forward in one direction or another only when we feel confident enough that we won’t have to go back on our steps, and we’ll avoid introducing breaking changes. Confidence is of course subjective, but we’re certainly not the ‘move fast and break things’ kind of team.
Yes, reviews are going slower than we’d like. This has been a major concern for some time, and is not a recent slowdown. But we’re still making progress. Regardless, a positive result is that we’re less likely to merge things prematurely :shrug:
The problem is: reviews are hard. They require expertise on the domain and often quite some effort to get familiarized with the affected code base.
Reviews depend on members of the Core Team (most of them are volunteers) and there is a limitation to how much they can contribute. It would be nice if we could increase the number of Core Team members actively reviewing pull requests, but it is not always up to us.
I’d like to encourage everyone to participate in reviews. Even if PRs get only accepted with a required number of Core Team approvals, non-Core reviews also help to drive it forward.
Bootstrapping a programming language is definitely a rewarding endeavour, but not always an esay feat, as it takes plenty of work on multiple fronts: growing our base of contributors, gathering enough funding to keep the project going at a good speed, and doing both without compromising any of the things that were built into Crystal and that make all of us love it. We’re very thankful that you raise these concerns, and that you do so with the best of intentions. We’ll keep you posted on our progress.
And we’re looking forward to any contributions that help driving the Crystal project forward.
Where can I follow this discussion, and the list of open multithreading issues to be worked on before it’s ready for prime time? I’d like to see if I can help.
I don’t think there is really a structured approach to that yet. It’s more an open question how MT should look like in Crystal. AFAICT the main problem is with thread safe data structures. Synchronization overhead costs unnecessary performance for single-threaded programs which are still a very relevant use case. We need to develop a vision before tackling specific tasks.
