"The AI adoption among developers is not as rapid as you expected - the benefits are obvious. Still, the developers do not seem to be taking advantage of it, and the pace of introducing new changes has not increased much over the last few months."
The benefits are so obvious that they preclude any supporting evidence or research. They are more or less axiomatic/dogma.
Wild take - maybe the pace of introducing new changes has not increased _because_ the "benefits" are not so obvious after all.
It's genuinely strange to me that people are acting like anything is possible now, because AI.
We had the internet for decades, with the sum of human knowledge largely available, no one used it.
Now those same uninspired masses are going to use to use the magic knowledge box to produce what they could never bring themselves to learn or research? No.
Just because the LLM can spit out code that looks good to you when you know what to ask for, does not mean that it is doing the same for everyone else.
It's not even a fair comparison - the effort involved in learning and building stuff from the internet (in the pre-LLM era) is an order of magnitude higher than turning your OAI/Anthropic account into an absolute slop cannon.
I'm primarily backend dev, but want able to prompt my way into building tiny JS web apps for personal use.
Wife always wanted to write animated story books for kids, and was actually able to create a bunch with Gemini (our daughter enjoys these more than the store-bought ones, since they're tailord/personalized for her).
Believe me when I say that I am totally aware of this degree of functionality, but the reality is that the world is not burning trillions of dollars so you can generate side projects that never quite get good enough to go to market.
The sales pitch is as good or better than if someone with full understanding did it themselves. Maybe that's true for the first one or two rounds, assuming it's something that isn't novel. Beyond that it's just not true.
The premise of why AI will change the world is because Jill from accounting is going to make a custom reporting app.
Thing is Jill always could do that, she just didn’t leverage the information available.
Now Jill can make the reporting app, until it is sufficiently complex that the code collapses under its own weight or she finds that the numbers don’t actually mean what she thinks.
The thing that's changed is how time is no longer major limiting factor. Previously Jill would have had to learn enough about programming to make an app, whereas now she can write a few prompts and receive something good enough even if her lack of programming knowledge means the code is house-of-cards waiting to fall
No, she will receive something she thinks is good enough, but will have subtle bugs leading to wrong accounting without her realising, and potentially leaking all customer information all over the internet, and the entire business process grinding to a halt when she leaves
All of the growing pains listed in the article can be observed in pretty much any framework in any language. Certain patterns and designs might be more present in some environments than others but I’m yet to see a framework that still guides you at tens or hundreds of kLOC. I don’t see how Rails is an issue here. If anything, I’ve always liked how the Ruby/Rails community discusses how to get the best of their framework and object-orientation. Are there monstrous, hard to evolve Rails app? Yes but the same can be said about Spring, .NET, Django and many others.
Exactly. Early in this century, I was excited to be working on a Java shipping web app deployed to Tomcat running on Windows because it felt like cutting-edge technology! As an aside, thermal printers were fun to print shipping labels on. At the time, I couldn't quite put my finger on it, but the many thousands of lines of code in the AirbillBean (to represent a shipping waybill) handled pretty much all persisted attributes and business logic in the application--well, almost everything of consequence, unless you count my address book importers. :) The app didn't need Struts or any other framework, and the JSPs were very convoluted, all working with that AirbillBean model. This was a high-traffic app in a booming business. Later, I realized that a lot of that AirbillBean should have been pieced apart into other classes. A younger me shook my head in disgust at the sorry state of that codebase after I left. But you know what? That code served them well for years and years after I left, and hardly changed.
Rails arrived around that time, and it influenced many other popular frameworks. From what I remember of how things were back then, a lot of developers' eyes were opened by seeing a cleanly organized Rails project. I'm sure Basecamp has had to do a lot of custom refactoring beyond whatever is covered in the Rails Way. Any app that has grown as much would have to start customizing outside of the initial framework.
Today, a lot of solutions I've worked on wouldn't have even seen the light of day if they hadn't been built with Rails. I often ship complete SaaS platforms on Rails at a fraction of the cost and time of the competition because Rails makes business experiments easier and cheaper to try. Are models sometimes heavy? Yes. As heavy as that old-school AirbillBean? Not usually. But the fact is, anyone who is tasked with maintaining that would be wise to start refactoring a lot of that into other classes once complexity is increasing. But you might never have gotten to the point where you were dealing with increased complexity if you didn't start out iterating quickly with the Rails Way or something comparable. :)
Agreed. Rails created conventions around standard issues developers were running into when building web apps that solved real pain points. With those problems largely out of the way, the community set out to conquer business domain logic in the same manner, which I am convinced is not possible to the same degree because business logic is inherently rooted in the chaos of the real world.
Hard problems are where the money is made, as they say.
The author uses how models are suggested to be used "the rails way" as an example for why it doesn't work anymore, talking about business logic in the models.
But in every framework I've used, the suggested way isn't how a technology is used in reality, in production. The tutorials are almost like a different framework entirely. Years ago as an Android dev the difference was shocking between what tutorials taught you and what was done in practice.
This doesn't technically detract from the author's point but it makes it moot - you just build in the current best practice way or the way that suits your needs, and that's how it often is with languages and frameworks.
Maybe that mismatch between how people are taught initially, or how the framework is intended to be used, is an inefficiency, in which case those who design frameworks should take note.
In the case of Rails I think "the rails way" is appropriate for certain style of apps, and not so much for Shopify etc scale apps.
Most of the article deals with topic orthogonal to stack tech choices. It’s barely about the Rails Way at all. That said, I do think the Rails Guide could have a section on scaling philosophy and tradeoffs.
I've seen several Rails apps where all the mentioned signs happened, and all of them were apps that didn't use the Rails-Way.
And this is accelerated by design patterns that blow up the amount of components used. Then there's the problematic gems such as Trailblazer that cause more problems than they solve, while being difficult for both humans and AIs alike.
Reminds me of the quote from Fred Brooks: "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious".
Service Objects et al are flowcharts. Rails-way is tables.
What do you mean? The whole point of Ruby on Rails is the rails way? Also the problems you are describing are not new and the community settled on adding some sort of service layer
"The AI adoption among developers is not as rapid as you expected - the benefits are obvious. Still, the developers do not seem to be taking advantage of it, and the pace of introducing new changes has not increased much over the last few months."
The benefits are so obvious that they preclude any supporting evidence or research. They are more or less axiomatic/dogma.
Wild take - maybe the pace of introducing new changes has not increased _because_ the "benefits" are not so obvious after all.
It's genuinely strange to me that people are acting like anything is possible now, because AI.
We had the internet for decades, with the sum of human knowledge largely available, no one used it.
Now those same uninspired masses are going to use to use the magic knowledge box to produce what they could never bring themselves to learn or research? No.
Just because the LLM can spit out code that looks good to you when you know what to ask for, does not mean that it is doing the same for everyone else.
It's not even a fair comparison - the effort involved in learning and building stuff from the internet (in the pre-LLM era) is an order of magnitude higher than turning your OAI/Anthropic account into an absolute slop cannon.
I'm primarily backend dev, but want able to prompt my way into building tiny JS web apps for personal use.
Wife always wanted to write animated story books for kids, and was actually able to create a bunch with Gemini (our daughter enjoys these more than the store-bought ones, since they're tailord/personalized for her).
Believe me when I say that I am totally aware of this degree of functionality, but the reality is that the world is not burning trillions of dollars so you can generate side projects that never quite get good enough to go to market.
The sales pitch is as good or better than if someone with full understanding did it themselves. Maybe that's true for the first one or two rounds, assuming it's something that isn't novel. Beyond that it's just not true.
> no one used it.
Can you explain what you mean?
The premise of why AI will change the world is because Jill from accounting is going to make a custom reporting app.
Thing is Jill always could do that, she just didn’t leverage the information available.
Now Jill can make the reporting app, until it is sufficiently complex that the code collapses under its own weight or she finds that the numbers don’t actually mean what she thinks.
The thing that's changed is how time is no longer major limiting factor. Previously Jill would have had to learn enough about programming to make an app, whereas now she can write a few prompts and receive something good enough even if her lack of programming knowledge means the code is house-of-cards waiting to fall
No, she will receive something she thinks is good enough, but will have subtle bugs leading to wrong accounting without her realising, and potentially leaking all customer information all over the internet, and the entire business process grinding to a halt when she leaves
All of the growing pains listed in the article can be observed in pretty much any framework in any language. Certain patterns and designs might be more present in some environments than others but I’m yet to see a framework that still guides you at tens or hundreds of kLOC. I don’t see how Rails is an issue here. If anything, I’ve always liked how the Ruby/Rails community discusses how to get the best of their framework and object-orientation. Are there monstrous, hard to evolve Rails app? Yes but the same can be said about Spring, .NET, Django and many others.
Exactly. Early in this century, I was excited to be working on a Java shipping web app deployed to Tomcat running on Windows because it felt like cutting-edge technology! As an aside, thermal printers were fun to print shipping labels on. At the time, I couldn't quite put my finger on it, but the many thousands of lines of code in the AirbillBean (to represent a shipping waybill) handled pretty much all persisted attributes and business logic in the application--well, almost everything of consequence, unless you count my address book importers. :) The app didn't need Struts or any other framework, and the JSPs were very convoluted, all working with that AirbillBean model. This was a high-traffic app in a booming business. Later, I realized that a lot of that AirbillBean should have been pieced apart into other classes. A younger me shook my head in disgust at the sorry state of that codebase after I left. But you know what? That code served them well for years and years after I left, and hardly changed.
Rails arrived around that time, and it influenced many other popular frameworks. From what I remember of how things were back then, a lot of developers' eyes were opened by seeing a cleanly organized Rails project. I'm sure Basecamp has had to do a lot of custom refactoring beyond whatever is covered in the Rails Way. Any app that has grown as much would have to start customizing outside of the initial framework.
Today, a lot of solutions I've worked on wouldn't have even seen the light of day if they hadn't been built with Rails. I often ship complete SaaS platforms on Rails at a fraction of the cost and time of the competition because Rails makes business experiments easier and cheaper to try. Are models sometimes heavy? Yes. As heavy as that old-school AirbillBean? Not usually. But the fact is, anyone who is tasked with maintaining that would be wise to start refactoring a lot of that into other classes once complexity is increasing. But you might never have gotten to the point where you were dealing with increased complexity if you didn't start out iterating quickly with the Rails Way or something comparable. :)
Agreed. Rails created conventions around standard issues developers were running into when building web apps that solved real pain points. With those problems largely out of the way, the community set out to conquer business domain logic in the same manner, which I am convinced is not possible to the same degree because business logic is inherently rooted in the chaos of the real world.
Hard problems are where the money is made, as they say.
The author uses how models are suggested to be used "the rails way" as an example for why it doesn't work anymore, talking about business logic in the models.
But in every framework I've used, the suggested way isn't how a technology is used in reality, in production. The tutorials are almost like a different framework entirely. Years ago as an Android dev the difference was shocking between what tutorials taught you and what was done in practice.
This doesn't technically detract from the author's point but it makes it moot - you just build in the current best practice way or the way that suits your needs, and that's how it often is with languages and frameworks.
Maybe that mismatch between how people are taught initially, or how the framework is intended to be used, is an inefficiency, in which case those who design frameworks should take note.
In the case of Rails I think "the rails way" is appropriate for certain style of apps, and not so much for Shopify etc scale apps.
Most of the article deals with topic orthogonal to stack tech choices. It’s barely about the Rails Way at all. That said, I do think the Rails Guide could have a section on scaling philosophy and tradeoffs.
HTTP 406 "Your browser is not supported" (whatever that means) seems like a misuse of a response code, no?
In any case, I would not advise anyone to take any advice in web-development from someone who does this.
P.S. My browser is quite fine, release age wise, not that it should matter.
I've seen several Rails apps where all the mentioned signs happened, and all of them were apps that didn't use the Rails-Way.
And this is accelerated by design patterns that blow up the amount of components used. Then there's the problematic gems such as Trailblazer that cause more problems than they solve, while being difficult for both humans and AIs alike.
Reminds me of the quote from Fred Brooks: "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious".
Service Objects et al are flowcharts. Rails-way is tables.
What do you mean? The whole point of Ruby on Rails is the rails way? Also the problems you are describing are not new and the community settled on adding some sort of service layer
https://shopify.engineering/shopify-monolith http://sporto.github.com/blog/2012/11/15/a-pattern-for-servi...
i can't make out the point of this article.
Me neither
Shit talking other people’s programming style to sell consultancy hours, basically.