摘要：既然这不是宗教，而是关于如何面对新的事物，我认为我们应该列出所有其他人认为不使用来做开发的理由。在下工作的不好这是一定的。流行度只是衡量使用率，社区活跃度的一个指标，用来帮助人们判断技术的可用性，稳定性和支持程度。不幸的是，人们混淆了和。
这是一篇赞美 Ruby 的文章！！！看完再喷不迟
请注意：这是一篇主观意识的文章。它的目的并不是要说服你使用或者不使用Ruby，或者其他任何技术。这篇文章所涉及到的环境是 Web 开发，而不是通用的编程。我想要通过这篇文章解释这些年来非 Ruby 社区对于 Ruby 的一些看法，并且提醒人们以开放的心态来面对新的事物。敬请欣赏！
我最近做了一个15分钟的演讲“我喜爱的 Ruby 语言以及它的生态系统”。很显然我的言论让忠实的 PHP，.NET 和 Java 开发者感到不安。他们对 Ruby 不是好奇，而是感觉我在批评他们热爱的技术。
既然这不是宗教，而是关于如何面对新的事物，我认为我们应该列出所有其他人认为不使用 Ruby 来做 Web 开发的理由。
1. Ruby 并没有 Java 或者 PHP 那么成熟
这是对的。Java 和 PHP 被用于 Web 开发要比 Ruby 早很多。但是你知道吗？我姥姥比 Ruby 要年长很多，但是我不认为我姥姥可以做 Web 应用。在 Web 时代，技术每几年就要更新一次，老和成熟不一定就有优势。在很多方面，Ruby 社区吸取了其他技术的教训，所以能做的更好，相比碎片化的 PHP 社区来讲。
如果你考察一门技术的标准只有时间的话，你从一开始就错了。
2. Ruby 的性能不如 .NET 或者 Java
你又说对了！除此之外，Ruby 还比 Erlang，Lua，C++ 等等都要慢，但是你不使用 Erlang 或者 C++ 是吗？Web 开发并仅仅是性能。你的应用不可能在上线第一天就有上百万的用户。你需要编码，测试，发布，并且循环这个过程，你需要快速迭代。所以，一开始开发效率大于运行效率。老拿性能来说事是愚蠢并且错误的。Ruby 的应用也能像 .NET 或者 Java 应用那样横向扩展。
3. Ruby 在 Windows 下工作的不好
这是一定的。Windows 在很多方面是伟大的，但不包括开源的 Web 开发。Ruby 以及很多源自 *NIX 的伟大技术都不能在 Windows 下工作的很好。与其撞破脑袋抱怨你已经习惯了 Windows ，不如试试安装 Linux ，让生活继续。技术的魅力在于学习新的事物，而不是呆在熟悉的环境里面一辈子。
4. Ruby 没有 PHP 那么流行
的确是这样的。技术并不是流行比赛，否则的话我们应该都用 JavaScript 来开发（目前在 Github 上最受欢迎的语言）。技术是一种达到目的的手段。流行度只是衡量使用率，社区活跃度的一个指标，用来帮助人们判断技术的可用性，稳定性和支持程度。
5. Ruby 社区高傲并且势力
嗯……这么说吧 Java 社区是顽固的，.NET 社区是封闭的，Perl 社区是古怪的，C++ 社区是一群抽烟的中年人。
我遇到过各种各样不同背景的开发者。我并不是说 Ruby 没有势力的人，但是绝对不是主流。我想很多时候是这样的一种情况：因为 Ruby 是相对比较新的技术，所以一些简单的任务例如和第三方的测试，开发，迭代都相对容易。所以当 Ruby 程序员称赞这些事情使用 Ruby 更容易的时候，他们并不是在看低其他技术，而只是在表述一种更简单的开发方式。
6. Ruby 非常顽固，不自由
这个观点不仅仅是错误，简直就是愚蠢。让我问你一个问题：编写一个 HTTP 路由组件或者图像处理类库有多少种方式？
约定优于配置，最佳实践和清晰的编码标准不会让开发者不自由。相反，它让开发者专注于重要的事情，例如业务逻辑。
Ruby 固有的约定驱动的开发方式帮助开发者提高了开发效率，但同时尊崇社区驱动的标准，使得样板文件最小化。
有趣的是，Ruby 是我知道的唯一一门语言，可以让你在任何地方，任何时间更改任何东西。人们很喜欢这些标准和约定，应为它让他们更有效率。
7. Ruby 没有 Java 和.NET 可靠
Windows 没有 NetBSD 那样安全！！！如果你考察可靠性的唯一标准就是类型检查的话，你看事情的角度就错了。
虽然静态语言严格的类型检查和编译属性让他们获得了更好的性能，但是，坦白说，在你编程生涯中，有多少 bug 是应为错误的变量类型引起的？
Ruby 用来解决这个问题的方式是宣扬测试文化。也就是说，你的代码的可靠性跟你的测试挂钩，而不是你的方法声明。
8. Ruby 缺少企业级的支持
恐怕你孤陋寡闻了吧？听说过 Engine Yard吗？没有？他们提供非常出色的企业级 Ruby 支持。
所谓的企业级支持是很久以前企业通过绑定用户销售昂贵的，可靠的，最新的技术来获得收入。但是你必须这么做吗？难道你是如此的无能，因为缺少所谓的“支持”就不去选择一项合适的技术？
让我问你一个问题：你认为微软需要多久才能发现，修复，承认，并且发布一个IIS的安全补丁？再想想，你真的认为金钱驱动的垄断企业关心你 Web 应用的安全性吗？
在以开源代码为代表的技术创新时代，为了所谓的支持选择一个封闭的，垄断的技术，就是选择了落后所有人一步。正大眼睛看看这些公司吧，Basho, Redhat, Canonical, 10gen, Cloudera, Engine Yard，他们提供开源的技术，并且提供企业级的付费支持。
9. Ruby 没有很好的可扩展性
这是很老的话题，要追溯到 Twitter 刚刚开始的时候。当 Twitter 飞速发展的时候，他们必须修改 ActiveRecord 中深层次的代码以获得在 Rails 中支持多个 MySQL 数据库。不幸的是，人们混淆了 Ruby 和 Rails。在 Twitter 这个案例中忽略了 Twitter 的快速成长得益于 Rails 的易于使用和快速开发。
任何成功的应用到最后都会遇到扩展性问题。Facebook 最后把 PHP 编译成了 C++，Twitter 转向了 Scala， Youtube 依然使用 Python，Apache 和 MySQL。没有任何两个 Web 应用是完全一样的，我们应该从成功的 Web 应用中学习经验，而不是上来就宣布某项技术的扩展性强于另外一项技术。
10. 寻找有经验的 Ruby 程序员很困难
这倒是真的，但取决于你在世界的哪个地方。比如在 Israel，.NET 和 PHP 盛行，所以找到好的 Ruby 程序员是很困难的。但是你知道吗？在那里更难找到有经验的 Javascript 开发者！
非要较真的话，我也可以说找到好的 PHP 程序员比 Ruby 更困难。因为 PHP 社区分散，用户生成的文档和不一致的 API 是的学习难度提高。
不要因为困难而放弃一样好东西，你可以自己培养 Ruby 开发者。我的意思是，如果你认为 Ruby 是正确的技术，那么为什么不多投入一些呢？
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/563.html
摘要：微服务架构模式使得每个微服务独立部署，且每个服务独立扩展，开发者不再需要协调其它服务部署对本服务的影响。微服务架构模式使得持续化部署成为可能。所以使用微服务不是必须的，而是在适当的实际，架构适应应用场景的一种改变。 近段时间离职，跟同事们讲解我之前所做的微服务相关产品，对于同事们提出的问题，做了如下整理出来，加上自己的理解，分享出来跟大家一起探讨下： 问题预览 我为什么要换微服务？能...
摘要：对于程序员来说，更意味着代码的组织，工作成员之间的协作方式。我常犯的一个错误是直接在或分支上直接，而团队是不允许这样做的。 先介绍下背景，博主由运营转行前端，入职一个月，完成了一个相对较大的模块。由于基础相对薄弱，犯下了不少错误，故想记录下来警醒自己和分享各位。 前端技术栈是 ES6 + backbone + react + antdUI,后端使用的 Ruby on Rails。 1....
摘要：对于程序员来说，更意味着代码的组织，工作成员之间的协作方式。我常犯的一个错误是直接在或分支上直接，而团队是不允许这样做的。 先介绍下背景，博主由运营转行前端，入职一个月，完成了一个相对较大的模块。由于基础相对薄弱，犯下了不少错误，故想记录下来警醒自己和分享各位。 前端技术栈是 ES6 + backbone + react + antdUI,后端使用的 Ruby on Rails。 1....
摘要：对于程序员来说，更意味着代码的组织，工作成员之间的协作方式。我常犯的一个错误是直接在或分支上直接，而团队是不允许这样做的。 先介绍下背景，博主由运营转行前端，入职一个月，完成了一个相对较大的模块。由于基础相对薄弱，犯下了不少错误，故想记录下来警醒自己和分享各位。 前端技术栈是 ES6 + backbone + react + antdUI,后端使用的 Ruby on Rails。 1....
阅读 1257·2021-11-19 09:40
阅读 3115·2021-11-02 14:47
阅读 3047·2021-10-11 10:58
阅读 3214·2019-08-30 15:54
阅读 2665·2019-08-30 12:50
阅读 1720·2019-08-29 16:54
阅读 459·2019-08-29 15:38
阅读 1235·2019-08-29 15:19
