整理 | 彭慧中 责编 | 屠敏
出品 | CSDN（ID：CSDNnews）

Ruby语言曾在2013至2015年期间非常流行，但随后流行度下降。早在3年前就在业界传出过**“Ruby及Ruby on Rails已死”**的言论，然而时至今日，连GitLab的CEO Sid Sijbrandij都发文表示：Ruby on Rails仍然是GitLab的坚定选择。那么，这项正走向没落技术究竟具有何种魔力？

“两全其美”的Ruby on Rails

Ruby on Rails（官方简称为Rails，亦被简称为RoR），是一个使用Ruby语言写的开源Web应用框架。Rails的设计原则包括“不做重复的事”（Don’t Repeat Yourself）和“惯例优于设定”（Convention Over Configuration），因此一经发布便被不少开发者及大厂采用。

不过，回忆最初创建Ruby on Rails的经历，创始人David Heinemeier Hansson称因受PHP、Java两种语言的影响，在开发时有些犹豫不决。一方面，他不喜欢Java的运行速度低且灵活性低，因为这会让Web框架变得复杂和难以使用，但Java结构的完整性却让他欣喜不已。另一方面，他喜欢PHP的“新手友好”，但又不太喜欢PHP导致Web框架混乱不堪的结构。

这似乎很难做到两全其美。要么选择“新手友好”但杂乱无章的PHP，要么选择结构良好但难以使用的Java。

这好像就是在曾经的服务器类操作系统（如Unix）和客户端操作系统（如Windows和MacOS）之间进行抉择，前者稳定但难以使用，后者简单易用但经常崩溃。

在过往尝试的过程中，似乎每个人都接受了这种“非黑即白”的选项，直到后来乔布斯带来了NeXTSTEP操作系统，它在稳定的Unix基础上推出了漂亮的、平易近人的、光滑的图形用户界面。如今，“服务器级”的Unix不仅可以运行漂亮的GUI桌面，还可以运行大多数手机和智能手表。

因此，事实证明操作系统的“简单易用”和“不稳定”实际上并无关联，而网络框架的“新手友好”和“结构混乱”也是如此，它们彼此独立。

想通了这一点，由David Heinemeier Hansson创建的Ruby on Rails应运而生，这正是一款极其“新手友好”并且具有良好结构的网络框架。而Ruby也被证明是Ruby创始人用Rails来实现上述要求的理想载体。

Rails与GitLab不谋而合

当GitLab的联合创始人Dmitriy Zaporozhets决定建立GitLab时，他选择了Ruby on Rails，尽管当时他主要使用PHP。Dmitry的选择或许有先见之明，又或许只是偶然，但Rails确实为GitLab提供了非常好的服务，其中很大一部分原因是David成功地实现了他对Rails的目标：简单易用且结构良好。

Rails使GitLab能够开发出模块化的单体。模块化单体则是一个结构良好、架构完善、高度模块化的程序，以单一进程的方式运行，并且保持这种尽可能“枯燥”的方式。

模块化单体将GitLab的以开放为核心业务模式从一个漂亮的理论变成了现实。因为，为了获得开源的真正“好处”，贡献者所提供的源代码必须具有吸引力。为了在面对各种来源的贡献时保持架构的完整性，并在开放和封闭的组件之间保持清晰的分界线，这样的代码必须具有非常好的结构。而通过模块化单体，用户和其他第三方开发者为核心产品贡献了附加功能，同时兼具无与伦比的创新速度和可扩展性。

**Rails框架的组织化、结构化风格与GitLab的核心使命相一致。**因为Rails是精简的，所以任何人都可以加入GitLab并参与进去，这使得它从一开始就对GitLab的CEO Sid Sijbrandij具有特别的吸引力。

"我们的使命是每个人都能做出贡献。而Ruby on Rails恰好‘新手友好’，它遵循所有的原则与习惯，并且没有其他扩展等各种花哨的内容。我认为，GitLab的首要价值是提供了一个非常好的开源代码库。而次要的价值则是提供了这样一套“枯燥”的解决方案：不做任何花里胡哨的事情，以便让每个人能够在这个代码库之上进行创造。真的很感谢Ruby为我们提供了这样一个稳定的生态系统。”Sid说道。

虽非完美，但“瑕不掩瑜”

尽管Rails是非常好的技术，但依然存在美中不足之处，**其中之一就是性能。**然而大多数代码库中只有一小部分对性能的要求较高。对此，GitLab的开发人员已经通过多种方式来改善性能，包括用Go重写代码和使用Vue框架。Go被用来解决影响加载时间的其他问题，并减少内存使用。而VUE被用来重写频繁访问的页面，如问题和合并请求，因此它们加载得更快，改善了用户体验。

Sid表示：“Ruby是服务于开发者的，而不是为了在生产中运行它。对于那些经常被攻击的、对性能要求高的，或是那些必须在系统IO上等待很长时间的部分，我们用Go进行了重写。与此同时，我们仍然在努力使GitLab占用更少的内存，因此，我们需要启用多线程。尽管它不会让开发速度变得快得惊人，但至少会减少一部分内存的使用。”

参考资料：https://thenewstack.io/why-were-sticking-with-ruby-on-rails-at-gitlab/