I’ve begun exploring Rails on Crystal (as in compiling Ruby on Rails apps) and Crystal on Rails (as in authoring apps with .cr and .ecr with ActiveRecord, HotWire and more). Early progress: https://intertwingly.net/blog/2026/04/10/Railcar.html ; let me know if there is interest or if there be dragons that I am not aware of.
this is super interesting I will be keeping an eye on this.
Sam, one of my favorite things about your work is how you’re bringing Ruby to languages that are not Ruby, which is just so fitting for someone with your last name.
That said, this project looks great! I feel like, as long as you’re not being too clever with your Rails code and you’re sticking mainly to Rails conventions, this should be feasible. Someone porting their Rails app to Crystal would probably still need to manually migrate some of the functionality provided by gems (payment processing, error reporting, PDF generation, linting, etc), but the core Rails functionality could very well be portable automatically with what you’re doing, especially if people stick to Rails conventions.
I also like that you position Railcar as a tool to aid in transitioning a Rails app to Crystal. I think a lot of teams working with Rails would love to use Crystal for additional performance, but migrating is hard despite the syntax being so similar. This seems like an ideal tool for that use case. I’m excited to see this!
Thanks!
The basic idea is that if you parse a Rails application bottoms up and couple that with Crystal’s type inferencing/semantic analysis you can go far. Schemas are typed, Models use schemas, Controllers use models and embed views. If there are any remaining gaps, perhaps rbs may help, and of course conversion to Crystal is always a possibility.
What’s really exciting to me is that once you have a fully semantically analyzed AST, you can pretty much emit in any language. I’m currently exploring Python. My explorations with JavaScript continued to hit problems with a lack of proper type information.
As to gems, if we can enumerate popular gems, filters could be written to convert calls to popular rails gems to equivalent shards.
For the Rail apps that “behave” (and it will be a discovery process to determine what that means) the target environments can compete directly. Do you want to run at CRuby speeds and memory usage or at Crystal speeds and memory usage? Ecosystems are also important, and in the case of JavaScript the ability to run everywhere is also a factor.
I also anticipate two modes: one way transitions and keeping the source in Ruby and keeping your options open.
Hopefully for Crystal this will be a net positive. I’m certainly using the AST and semantic analyzer in ways that they weren’t intended, and willing to contribute back anything I produce.
I don’t expect many people to want to migrate from Crystal to Python, but I plan to explore other languages too. Collectively hopefully the message will be: easy to port your Rails app to Crystal, and no lock in.