Jumping off the tech debt ship early is a good thing.
3341958508617
Technical debt was never about the framework you are using. Grow up.
Sahil LavingiaCreator
It ultimately is if it becomes a bottleneck to shipping.
Rich Steinmetz
Do you have a concrete example how it did become so and how the new stack will avoid that?
KIRANKUMAR AMBATI
Hey Sahil! Sounds fantastic. I'm happy to contribute. Already keeping an eye on github issues but do you want me to take a look at something specific?
Steven R
I agree! There's a reason why Google decided to incorporate AppScript (JavaScript) into the Google Productivity Suit. You can now customize google sheets, docs, and slides to do what you want them to do. With a little CSS and JS, you can make a sheet fun to use (almost).
Erkhembayar Gantulga
Thanks for being transparent and making your tools open.
I'm happy to contribute!
Kristjan Rang
If you're using AI to write the whole thing, what difference does it make if it is writing TypeScript or Ruby?
Sam Livingston-Gray
I've been working with Rails since 2006, with the vast majority of that time cleaning up and maintaining legacy Rails apps. I don't disagree with the assertion that using Rails "is a form of technical debt" as long as it's clear that the definition of "technical debt" is congruent with Ward's original framing: a deliberate choice to achieve short-term speed trade by deferring necessary work. In fact, I'd argue that that's what makes Rails great: it lets companies throw more stuff against the wall faster. If they crash and burn, they never have to do the deferred work. And if they survive long enough, they can afford to hire somebody like me to retool their codebase for the long haul.
Having cleaned up a lot of codebases written by reasonably smart people, I'm really not looking forward to encountering the kinds of messes folks are currently busy making with "AI"—or, as I recently heard it referred to, "expensive graphics cards that guess sentences."
Coincidentally, this also crossed my timeline today: https://www.cio.com/article/3540579/devs-gaining-little-if-anything-from-ai-coding-assistants.html
Trusting an LLM to guess the correct sentence in a programming language seems risky, but as long as you're still writing extremely good tests, it might work out okay.
Trusting an LLM to write both the tests *and* the code? Good luck with that.
Curtis Miller
Having just returned from a Rails conference, I'm excited by the direction Rails is taking, both from a technical perspective and a community one.
I've seen countless people over the last 18 years decide to switch to something else, for a multitude of reasons, only to confide later that they enjoy their job much less now than when they were using Rails.
For me it's not just about the technology, but also about my own happiness as a developer. If this new stack + AI provides that for you, then I'm happy for you and wish you the best of luck!
10 comments
Jumping off the tech debt ship early is a good thing.
Technical debt was never about the framework you are using. Grow up.
It ultimately is if it becomes a bottleneck to shipping.
Do you have a concrete example how it did become so and how the new stack will avoid that?
Hey Sahil! Sounds fantastic. I'm happy to contribute. Already keeping an eye on github issues but do you want me to take a look at something specific?
I agree! There's a reason why Google decided to incorporate AppScript (JavaScript) into the Google Productivity Suit. You can now customize google sheets, docs, and slides to do what you want them to do. With a little CSS and JS, you can make a sheet fun to use (almost).
Thanks for being transparent and making your tools open. I'm happy to contribute!
If you're using AI to write the whole thing, what difference does it make if it is writing TypeScript or Ruby?
I've been working with Rails since 2006, with the vast majority of that time cleaning up and maintaining legacy Rails apps. I don't disagree with the assertion that using Rails "is a form of technical debt" as long as it's clear that the definition of "technical debt" is congruent with Ward's original framing: a deliberate choice to achieve short-term speed trade by deferring necessary work. In fact, I'd argue that that's what makes Rails great: it lets companies throw more stuff against the wall faster. If they crash and burn, they never have to do the deferred work. And if they survive long enough, they can afford to hire somebody like me to retool their codebase for the long haul. Having cleaned up a lot of codebases written by reasonably smart people, I'm really not looking forward to encountering the kinds of messes folks are currently busy making with "AI"—or, as I recently heard it referred to, "expensive graphics cards that guess sentences." Coincidentally, this also crossed my timeline today: https://www.cio.com/article/3540579/devs-gaining-little-if-anything-from-ai-coding-assistants.html Trusting an LLM to guess the correct sentence in a programming language seems risky, but as long as you're still writing extremely good tests, it might work out okay. Trusting an LLM to write both the tests *and* the code? Good luck with that.
Having just returned from a Rails conference, I'm excited by the direction Rails is taking, both from a technical perspective and a community one. I've seen countless people over the last 18 years decide to switch to something else, for a multitude of reasons, only to confide later that they enjoy their job much less now than when they were using Rails. For me it's not just about the technology, but also about my own happiness as a developer. If this new stack + AI provides that for you, then I'm happy for you and wish you the best of luck!