Does Ruby on Rails still make sense?

原始链接: https://tech.dirkjonker.nl/does-ruby-on-rails-make-sense/

LLM 写代码并不会让框架、库、语言或 Rails 过时。Rails 仍然提供结构、安全更新、性能改进、生态支持和可预测的导航,帮助人类和 LLM 在不必重新发明底层管道的情况下构建产品。用 Rust 完全重写并非易事:它可能改变行为、引入 bug、扰乱用户,并需要大量测试,尤其是对 UI 密集型应用而言。通常更好的做法是优化现有应用并更新依赖。Rails 还提供实用的开发优势,例如即时代码重载和 REPL 工作流,并且 LLM 已在其上训练。作者仍对有针对性的重写持开放态度——可能是用 Go 提升后台性能或用 Svelte 做前端——但认为没有理由替换核心的 Rails 应用。最终,必须由负责人解释软件决策,而目前 Rails 仍然是构建和维护商业软件的明智且高效的选择。

讨论串在辩论,随着LLM编写更多代码,Rails是否仍值得使用。支持者引用了约定、可读性、生态系统、久经考验的模式,以及对代理的防护栏。怀疑者指出动态类型、升级摩擦、性能,以及在类型化语言中更强的AI结果;一些人报告迁移到Rust或Go。其他人认为框架和抽象仍然有用,完全重写往往不必要。总体而言,Rails仍适用于许多CRUD应用,但AI改变了通常的开发者体验与性能权衡。
相关文章

原文

Someone asked me, given that LLMs exist and likely keep improving, whether I thought Ruby on Rails still made sense? The implication being of course that writing code is now extremely cheap and you can build anything you like in any language, so why not choose to rewrite everything in Rust? I thought this was a great question and obviously it's one that's on every curious developer's mind.

The answer is simple: yes, I do think Ruby on Rails or frameworks in general still make sense. For the same reasons they always have: providing structure, not reinventing the wheel, security updates, free performance improvements and new features on updates to name a few benefits. Everything that was created to make a human more productive to write code will also make an LLM more productive. And for the same reason, libraries still make sense. And programming languages. And databases. And operating systems. Because if they didn't, we would all be writing everything in Rust from scratch, not just the final application on top.

The fact that an LLM now writes the code does not mean any abstractions we made before are suddenly less important or less useful. I didn't like having to write my own plumbing in Rust when I attempted a rewrite-in-rust and I wouldn't like an LLM to spend many tokens on it either, at least not in the process of writing my software. When we build a product for people we should be focused on solving their actual problems rather than writing job queues and ORMs and I believe that still holds true for a situation where an LLM writes 100 percent of the code. The framework provides a predictable structure to easily navigate a project, reason about it, debug it and extend it. And of course LLMs have been trained on frameworks and their usage as well.

Many people have shown that you can burn a bunch of tokens to rewrite things into several different languages. Does this now mean that it's actually trivial to rewrite an entire application into another language and that it just takes a bunch of money to burn? I'm not convinced, at least not yet. Different programming languages, frameworks and their surrounding ecosystems were all created under different constraints and took different design directions. This means that switching to another language means you have to make all kinds of decisions you never thought you had to make. The LLM will just make a random decision in order to reach its goal: to create a functionally equivalent programme that passes the same tests.

But will a full Rust-rewrite truly behave the same way? A lot of behaviour could actually be caused by the framework, libraries or programming language itself. Using a different programming language means a lot of this behaviour has now already changed, even if the business logic you write on top is computationally equivalent. Perhaps it fixes some bugs from the original application that a user already relies on today. Or it could introduce subtle new bugs that don't occur in the original framework but do in another. In any case I think there would be a high probability that users will be impacted by any rewrite, probably in a good way if the application got faster, but probably also in a bad way, when it suddenly behaves differently.

Which is why I think a full rewrite to Rust - especially when you are dealing with a user interface - is hard. Not because of writing the code but because you have to test it thoroughly. Our users are the kind that use our application for many hours every day. They have become very familiar with all its quirks and features and rely heavily on them to get their job done. When we move some pixels around or change an icon or a description, we immediately get complaints. Will a rewrite still work in exactly the same way? How can you be sure? Will it be worth it, or will you annoy all your users to the point where they won't trust your decisions any more?

So why even think about rewriting it in Rust when you can ask the LLM to simply... improve the performance of your existing application? There are so many ways you can optimise software and most of them don't require switching programming languages. As a bonus, it is much less likely that you change any behaviour when you simply instruct the LLM to "make it faster".

Actively developed frameworks, libraries and programming languages get improvements and security checks on a regular basis. The use of LLMs will just accelerate that even more. Just by updating your dependencies you get all of that for free, without having to test it yourself. This was already the case before and continues to be the case today. Perhaps in the near future, a new Ruby version will make all your existing code run 10x faster and use 10x less memory?

I also think there is still value in being able to look at the code and ask questions about it. If often reveals those decisions that the LLM never asked you about. It could have been some existing code or structure that was copied over in the assumption that all existing code is probably correct. Or the wording in your prompt was perhaps ambiguous, but not ambiguous enough to trigger a question for you to clarify. Eventually you would find out by testing. Or your users would find out and complain about it to you. In any case I prefer to avoid these situations by looking at the code. And the code being Ruby and the framework being Rails means I already know which parts are most important to look at when the agent proposes a giant batch of changes.

There are other advantages to using Ruby that you won't get with Rust. It allows for instant reloading of changed code meaning you won't have to wait for compilation to test any changes. You can use a REPL to play with code, inspect data or run scripts easily without a full compile and/or deploy cycle. I've seen coding agents use these features quite often to quickly diagnose issues.

Having said all of that, I am definitely excited and thinking about the possibilities of rewriting parts of our software in a different programming language, indeed mostly for performance reasons, but also out of curiosity and because it would be something new for me to learn. For me this would be the Go programming language because of its simplicity and fast compile times. I do not enjoy writing lots of Go myself as I find it rather verbose and repetitive, but I won't have to write much of it anyway. And it is so easy to read, even if you have little experience writing it. Go also compiles quite fast, allowing for relatively fast iteration and deploy, especially compared to Rust. Rust would obviously perform even better but comes with the downsides of slower compilation and harder to read code. In most cases the performance of Go should be more than sufficient anyway. I have some use cases where Go would be used in the background, avoiding the need for complicated interoperability with the existing Rails stack.

On the frontend I quite enjoy Svelte and I like the hot reloading capabilities in development, which is nice when you are experimenting with styles and layout. Switching the frontend over (from HTMX) to Svelte however would mean some fairly big breaking changes. Ideally you would use SvelteKit and run Node on the backend, which basically means a full rewrite in JavaScript. Or the Rails backend would need to supply data as JSON or GraphQL. I don't particularly like this kind of frontend/backend split as it leads to the dreaded spinners and pulsating grey placeholders everywhere while waiting on the numerous http requests that will be made to the backend. Perhaps when the LLM takes cares of both the backend and the frontend anyway, it can also just take care of those issues though.

To get back to the decision of whether to let LLMs rewrite everything in Rust: in the end a person is responsible for the software and will have to explain the decisions being made. And when that person is me, I choose to continue building our current application in Rails, at least for the time being. Is there other exciting tech? Yes. Does it solve more problems than Rails does? Probably not. Would I still use Rails for new projects? Definitely. Although I would be more tempted to try out something new and see what that would look and feel like. Would I choose Rust for anything? Maybe if I wanted to build something where performance would be more important than anything else, but I don't think it's a great fit for most run-of-the-mill business software.

In conclusion, does Ruby on Rails still make sense? Yes, I think it does.

联系我们 contact @ memedata.com