Background: I started the UK's first dedicated Ruby on Rails consultancy in Manchester, in the Summer of 2006 (called Vagueware - still love that name). I made this decision when Rails was at version 1.1.2. It was a bit of a brave call.
I stopped writing Ruby and Rails code in anger ~6 years ago. Change in jobs, roles, etc. and for my side projects I'm mostly tinkering in python and C, and zig appeals to me, but then so does PHP which was the most productive environment I ever encountered before Rails (and DHH has talked about this inspiring him too).
Things I think make sense for Rails in the LLM era:
- Convention over configuration. If somebody asks me to add some new business logic for the User object, even if I have never seen the code base before, I'm heading straight to `app/models/user.rb` and starting to read there. That's useful for an LLM, as much as it is for a user. And that's just the start of where conventions kick in. This aids explainability, and also allows us to easily check when an LLM is heading off into the weeds - "Why is all this logic in app/controllers?"
- It felt weird to me the first time somebody said "legacy Rails app" to me, because I got into it years before it was the new hot - I have to accept I'm just old now, fine. However, what that actually means is there is a lot of good battle-hardened code and documentation on how to get things done in Ruby on Rails, and that's going to help an LLM that's seen it all, and a lot of it can be distilled into specs and agents. Awesome.
- There's a decent ecosystem of people trying to make the entire space a little better all the time, both in Ruby, and in Rails. Frameworks do that - they attract people who care about developer experience, and making the picks and shovels better, and it's great to build on top of that.
- Ruby is beautiful to read, and reading is half of what an LLM does. Ruby has semantic denseness, but... see caveats below.
In the other column:
- While Ruby is easy to read to the human eye, some cause of that beauty is shared by the English language and what makes poetry possible: semantic ambiguity. Yes, I know there's optional static typing, I know that there are things to make this better, but an LLM will make mistakes, and I shouldn't have to explain why whatever has primary key of id "4" in that table is going to have unusual pressures, and why "no such X found with id 4" has a very specific and obvious route cause to me, that's going to confuse LLMs to know end (TLDR: when you cast `nil` to an integer in Ruby, it resolves to object_id of 4... yeah...)
- I'm not sure if the future isn't in unikernels where we take our logic and ship it without dependencies - without an OS - into kernels. That doesn't fit the Ruby/Rails mindset well. It could, but right now you're looking at a pretty standard 3-tier web app architecture that may or may not be the thing we want ever 2 years from now. Architectural innovation is likely going to be the big impact thing LLMs give us, not auto-completed code.
- I personally have a really serious problem with some of the community characters. Most of them, great. It went downhill a bit in 2010s - a sort of eternal September for a lot of us who pre-dated it - but I think it's fair to say DHH's politics are very, very far removed from my own, and I find comparing people of a specific ethnic origin to wolves who should be shot for the public good to be abhorrent and repugnant behaviour. I don't want to bring politics into technology choices, but he's already done that, and I don't like his politics - especially his misguided and ignorant views of the politics of my own country.
I'd write Ruby for money and fun again. I'd think twice about writing Rails for any purpose again. I think in 10 years it'll fizzle out, or I'll be doing the circuit propping stuff up LLMs haven't been able to replace yet like the COBOL guys do now.
But I think whatever replaces it as the force it was in the 2005-2015 era is going to be very exciting, and I'm not convinced it'll be entirely AI-based, no matter how optimistic the outlook is in that space.
I stopped writing Ruby and Rails code in anger ~6 years ago. Change in jobs, roles, etc. and for my side projects I'm mostly tinkering in python and C, and zig appeals to me, but then so does PHP which was the most productive environment I ever encountered before Rails (and DHH has talked about this inspiring him too).
Things I think make sense for Rails in the LLM era:
- Convention over configuration. If somebody asks me to add some new business logic for the User object, even if I have never seen the code base before, I'm heading straight to `app/models/user.rb` and starting to read there. That's useful for an LLM, as much as it is for a user. And that's just the start of where conventions kick in. This aids explainability, and also allows us to easily check when an LLM is heading off into the weeds - "Why is all this logic in app/controllers?"
- It felt weird to me the first time somebody said "legacy Rails app" to me, because I got into it years before it was the new hot - I have to accept I'm just old now, fine. However, what that actually means is there is a lot of good battle-hardened code and documentation on how to get things done in Ruby on Rails, and that's going to help an LLM that's seen it all, and a lot of it can be distilled into specs and agents. Awesome.
- There's a decent ecosystem of people trying to make the entire space a little better all the time, both in Ruby, and in Rails. Frameworks do that - they attract people who care about developer experience, and making the picks and shovels better, and it's great to build on top of that.
- Ruby is beautiful to read, and reading is half of what an LLM does. Ruby has semantic denseness, but... see caveats below.
In the other column:
- While Ruby is easy to read to the human eye, some cause of that beauty is shared by the English language and what makes poetry possible: semantic ambiguity. Yes, I know there's optional static typing, I know that there are things to make this better, but an LLM will make mistakes, and I shouldn't have to explain why whatever has primary key of id "4" in that table is going to have unusual pressures, and why "no such X found with id 4" has a very specific and obvious route cause to me, that's going to confuse LLMs to know end (TLDR: when you cast `nil` to an integer in Ruby, it resolves to object_id of 4... yeah...)
- I'm not sure if the future isn't in unikernels where we take our logic and ship it without dependencies - without an OS - into kernels. That doesn't fit the Ruby/Rails mindset well. It could, but right now you're looking at a pretty standard 3-tier web app architecture that may or may not be the thing we want ever 2 years from now. Architectural innovation is likely going to be the big impact thing LLMs give us, not auto-completed code.
- I personally have a really serious problem with some of the community characters. Most of them, great. It went downhill a bit in 2010s - a sort of eternal September for a lot of us who pre-dated it - but I think it's fair to say DHH's politics are very, very far removed from my own, and I find comparing people of a specific ethnic origin to wolves who should be shot for the public good to be abhorrent and repugnant behaviour. I don't want to bring politics into technology choices, but he's already done that, and I don't like his politics - especially his misguided and ignorant views of the politics of my own country.
I'd write Ruby for money and fun again. I'd think twice about writing Rails for any purpose again. I think in 10 years it'll fizzle out, or I'll be doing the circuit propping stuff up LLMs haven't been able to replace yet like the COBOL guys do now.
But I think whatever replaces it as the force it was in the 2005-2015 era is going to be very exciting, and I'm not convinced it'll be entirely AI-based, no matter how optimistic the outlook is in that space.