Ruby 评论 Why I wouldn’ t use rails for a new company

lgn21st · 发布于 2015年09月28日 · 最后由 ritayy 回复于 2016年03月27日 · 10105 次阅读
3
本帖已被设为精华帖!

Scribd 在全球所有使用 Rails 网站中,做到了流量排行第三,最近该网站的创始人 Jared Friedman 写了一篇文章,告诫所有初创公司为什么他不会在选择 Rails:

Why I wouldn’t use rails for a new company

作为国内最早的一批 Ruby 程序员,RubyChina 社区的管理员,目前仍然靠写 Ruby/Rails 代码混饭吃的人,当我看到这篇文章,内心其实是拒绝的。但是静下来想了想,文章中的观点并非不可接受,这取决于你选取的角度。对方站在自己的角度表达了观点,想法,看这个技术世界的样子,那么如果不能尝试理解对方思考的角度,就自燃无法接受对方的观点了。

我试着不带有价值判断的眼光,去尝试理解 Jared 的角度,然后在作出自己对事实的判断。Scribe 创建于 2006 年,基于 Rails 0.7 创建。2006 年的 Rails 远远没有现在的成熟度,在当时选择 Rails 意味着:

  1. 这不是一个安全的选择,而是一种赌博
  2. 团队是否能跟随框架和技术的脚步共同成长
  3. 会不会持续有人会转而使用这项技术,于是将来能招聘到足够的工程师

Jared 认为这三点中,第三点是最重要,之后的结果是:

  1. Rails 一度成为了硅谷湾区初创公司的 Default Web Application Stack
  2. Scribd 的技术团队伴随着 Rails 的发展,已经成长为流量第三大的 Rails 网站
  3. 大批有天赋的 Java,PHP,ASP.NET 程序员在早期看到了 Rails 的趋势,因为 Scribd 作为早期提供 Rails 工作机会的公司,在招聘中处于优势,于是持续招募到了不少优秀的人

Jared 在 2006 年选择站在技术的风口浪尖,作了个赌博,于是才有今天这样一个多赢的结果。所以作者角度是从赌博出发,建议初创的技术型公司把眼光放长远,不要去选择今天看起来很安全的技术,应该选择未来三年可能会成长起来,且会有大量有天赋的开发者未来三年内会选择并切换过去的技术,在这个过程中,你要保证团队能够跟随技术发展同步成长即可。

我觉得这个观点挺开脑洞的,不能说没有道理,但是我所了解的大多数技术公司通常不会从这个角度去做决策,可能也不是没有,比如七牛云存储的老大许式伟一直就是国内最主要的 Golang 布道者之一,Strikingly 的 CTO 郭达峰,一直活跃在国内推广 React.JS 的一线。这就要看你信什么了,不管你信奉乔帮主,还是其它什么人,能做成一家公司从来都不是那么简单的事,所以有信念很重要,还是得选择信奉一些什么。

作者的建议

其实并没有明确的建议。Jared 提出了三个 Ruby/Rails 的问题:1) 语言的运行效率很慢 2) 框架发展到了瓶颈期,优势不再 3) 对开发者的吸引力下降。然后通过 Google Trends 展示出一些新语言,以及工作职位的趋势,

从当前的数据和趋势看 Node.JS 目前正处于领导位置,可是选择 Node.JS 或者 Golang 或者其他新兴的语言框架,就如同 2006 年的时候选择 Ruby/Rails 么?这里提到的每一个,其实都不是。

作为一个 Rubyist,我怎么看文中提到的问题

关于 Ruby/Rails 的性能问题

Jared 在文章中说的其实都是对的,这些都是事实,必须要承认。Ruby is slow,Jared 知道,我知道,你知道,所有的 Rubyist 都知道,问题是性能真的那么重要么?

抛开具体的场景谈问题,都是耍流氓!如果你要处理的是 CPU Intensive 的问题,那么你应该用 C 语言(或者C++)。如果你面对的问题是 I/O Intensive 的话,那么语言的性能并不是问题的关键,编程范式和架构才是。在 Web 应用的场景下,大家其实应该关心的问题是如何把 HTTP 请求处理的平均时间优化到 200ms 以内,如果你对 Rails 处理 HTTP 请求的过程非常熟悉的话,你还会仅仅纠结于 Ruby 语言的性能么?如果你已经充分优化了架构,缓存,数据库访问后,仍然对 Ruby 的性能感到沮丧的话,我真的要恭喜你,你已经成功了!此时你的项目应该已经 C 轮了吧,赶紧用钱去砸,不要纠结。

Scribd 在 2006 年用的 Ruby 比现在的版本要慢得多,那个时候的 Scribd 看重 Ruby/Rails 的到底是什么?我猜答案应该是 Just Enough -- 在平衡性能的同时,给了你极佳的开发效率,完整的生态系统,帮助你实现各种可能性,以期应对快速的发展和变化。这本质是一种 Tradeoff,是一种折衷,优先确保开发层面上的效率,而后才是性能。那么用性能换开发效率是不是一个最优决策?答案是看场景,在场景合适的情况下,这就是最佳策略。当时间推移,场景变迁后,是否还应该继续坚持这个策略,答案当然是 NO!

当业务发展需时,其他语言或者框架更加符合场景的话,Go for it!

关于 Rails 框架发展到了瓶颈期,优势不再

当年 Rails 升级到 3.0 的时候,我们称其为 The Great Rails Refactor ,这一次升级的改变幅度巨大,以至于 Rails 3.0 发布后很久,大量的项目都无法及时跟进。在这之后的 Rails 每一个版本更新依然保持废弃掉一些老旧功能并同时带来新的东西,但是向后兼容问题已经大幅改善了:

  • 3.1 (August 2011) - Asset Pipeline, jQuery, CoffeeScript, Sass, reversible migrations,
  • 3.2 (January 2012) - faster development mode, ARel explain queries
  • 4.0 (June 2013) - Turbolinks, Russian Doll Caching
  • 4.1 (April 2014) - Spring, Action Mailer previews, enums
  • 4.2 (December 2014) - Active Job, asynchronous email delivery, web console
  • 5.0 (No Timeline) - Turbolinks 3, Rails API, ActionCable

高速发展的事物其本身都承载着一种叫做 growing pains 的东西,我们姑且称之为成长期阵痛。这是一个好东西,如果一个事物的这种 pains 在削减,那么我们会认为它变得成熟。受到这种成长期阵痛影响最典型的可能是 Github,直到 2014 年底, Rails 3 发布四年后,Github 终于把项目代码从 2.3 升级到了 4.1,整个升级过程耗时 6 个月。

有一种观点认为像 Gihtub,Twitter,或者 Scribd 等都不是 Rails 应用的典型项目,这些项目体量巨大,为了满足自身需要,对 Rails 本身做了大量的扩展与二次开发,导致因为无法跟随一些 Rails 开发的最佳实践,于是每次当考虑升级的时候,发现升级所耗费的成本远远高于新版本所带来的好处。我认同这个观点,这本质仍然是一个 Tradeoff,是一种折衷。选择始终遵循 Rails 的一整套最佳实践,会给你的项目带了较好的向后兼容性,降低升级的成本。为了解决具体场景下的问题作一些特化处理,从而增加升级的成本。 Rails 给出的建议是选择前者。

选择对的框架去解决对的问题就不会错。Rails 仍然是流行的 Web 开发框架之一,作为一个现象级的框架,被其他框架争相模仿,这些框架不仅仅克隆了 Rails 的功能,还克隆了 Rails 框架背后的思想,经过经年累月的发展,这些框架相对于 Rails 的差距在缩小,因为后发优势的原因,在 API 向后兼容方面做得比 Rails 更出色。

如果另外一种框架比 Rails 更稳定,优秀,且更符合你的需求的话,Go for it!

对开发者的吸引力下降

Ruby/Rails 一度能成为硅谷湾区初创公司的 Default Web Application Stack 其实并不仅仅是因为技术本身,语言框架背后的设计思想和哲学给开发者带来的影响其实更大。

Ruby somehow enables programmers in a special kind of way that is so hard to explain to the ‘unwashed masses’.

体验过 Rails 开发的人,特别是从其他语言转过来的开发者,比如 Java,ASP.NET,甚至 Python 开发者,在学习 Ruby/Rails 的第一感受往往是能感受到某种快乐。感到快乐非常重要,这种快乐来自语法层面赋予开发者最大限度的自由和灵活,以及 Rails 框架深层的 DNA 中包含的对代码品质优雅的追求,以及想方设法集成大量的最佳实践,让开发者在使用框架过程中感受到方便快捷,和无微不至的实用主义。于是很多开发者尝试过 Ruby,写过 Rails 之后发现再也回不去了。

有人说 Ruby/Rails 自带鸡汤,效果肯定不会长久,兴趣和偏好必须能经受市场考验。话没错,那就不撒鸡汤,回归现实。对于每一个开发者来说,拥有,维持自己的核心竞争力很重要,先掌握一技之长,然后最大限度的发展自己的技能树之外,另外一件重要的事情就是能有效的把握市场需求,Rails 虽然已经不是当下最热门的技术,但是其市场需求依然非常旺盛,掌握良好的 Ruby 编程经验和技巧依然可以确保你衣食无忧。接受并认可 Ruby/Rails 背后的哲学思想的价值,并不妨碍你学习新的东西,所以为了维持自己的核心价值,应该不断发掘并学习你感兴趣的新东西。

当另外一种语言更加能激发你的兴趣,并让你相信值得为之投入的话,Go for it!

Ruby 语言的未来

其实 Ruby 是一门非常保守的语言,近些年 Ruby 最大的变化来自于从 1.8 升级到 1.9 这一版升级,包括重写了底层虚拟机,系统原生线程支持, 新的字符 Coding 处理,更好的 GC,以及一些向后不兼容的语法变化等等,这一步Ruby 用了五年,相对于 Perl 5 到 Perl 6 用了 15 年,Python 2.7 到 Python 3.x 目前看来仍然遥遥无期。

1.9 之后的节奏是小步快速迭代,并尽可能向后兼容,尽可能不引入任何破坏性的变化,所以整个社区都推荐直接用最新的 Ruby 稳定版,不纠结。目测 Ruby 未来仍然会坚持把满足语法设计作为第一优先级,其次才是性能。从过往的经验看,这个策略是 Ruby 成功的要素,所以 Matz 才会一直坚持 20 年不动摇。

现在市场上很难买到单核 CPU,连手机都进入了 8 核时代,人们比以往任何时候都更加关心 Ruby 的 Concurrency 能力。回到 2012 年 Ruby 2.0 正式发布的时候,大家欢欣雀跃因为 Ruby 抛弃了多年的 Green Thread,取而代之的是直接使用操作系统原生线程,似乎原生多线程编程的威力终于要被释放了,当时 Matz 被问到何时能去掉 GIL 时,Matz 很腼腆的回答 I don't consider myself as the threading guy。就是否移除 GIL 这个问题到现在已经三年过去了,Ruby 的核心团队已经明确的表示不会移除,于是人们批评核心团队在 GIL 问题上太过保守,可是核心团队决定保留 GIL 其实是为了最大限度的保护程序员,保护程序代码的安全。

Ruby 会继续打磨并引入新的语法,性能会持续得到优化,但是在 Concurrency 这个方向上何去何从呢?Matz 最新的公开演讲提到,会引入更多的抽象并发模型,可能会尝试性的把 Actor model / Event-driven loop 引入到语言核心中,也可能会引入 Ownership model 以确保并发中的共享内存安全问题,Matz 的新语言 Stream 则在尝试通过管道的方式实现并发,会支持更多的 immutable 类型的对象,但是这一切都仍然处于试验中,核心团队不承诺任何东西,我们只能拭目以待。

如果你为了追求更好的 Concurrency 编程选择其他语言,Go for it!

共收到 71 条回复
15816

以前个公司也换到 Go,用 Rails 时每月要给 AWS 交 8000 多美金!可惜我只会写 Ruby 只好换公司。

看公司做什么也很重要。反正合适你(公司)的就好。

13505

python不是已经有3.3的版本了么

6224

语言太慢绝对是瓶颈。Rails的杀手锏,开发效率被追的优势剩下的不多,运行效率却依然很不怎么样。

拿06年和15年的java web开发对比,那时候rails的开发效率可能是java框架的10倍,但java的运行速度也可以是ruby的10倍。只是大部分网站也确实用不到这种性能优势。而9年过去后,java的web框架经过多年努力和投入,rails的开发效率尽管还可以甩spring一大截,但肯定没有一倍那么多了。然而ruby的运算效率差距依然在5倍以上。

18858

一次吃饭时和饭店老板闲聊,他说“股农都是买涨不买跌”

3962

“New Company“不应该纠结语言/框架,用熟悉的那个就行,过多的考虑并发/性能问题是过早优化。

A87c18

Why is ruby so slow? Some people will point to language design characteristics, which are part of the story, but I think the deeper reason is that ruby does not have a serious corporate sponsor.

1

#7楼 @rubyu2 Matz 现在受雇于 Heroku(Salesforce 旗下),领导 Matz Team,这个团队用于专心开发推广 Ruby。所以 Ruby 有一个严肃的企业赞助商 Salesforce。

https://www.new-bamboo.co.uk/blog/2011/07/12/translation-of-matz-q-a-article-after-joining-heroku/

Mr Matsumoto (Matz going forward): When I last met Mr Marc Benioff (CEO of Salesforce.com) he asked me how he could support the development of Ruby.

So I told him that I want to improve the situation which the majority of Ruby Core developers face, that they are either doing their work in their own spare time or they worry about their job security.  

He said he could provide us some support and that’s why I decided to join Salesforce.com through Heroku (Note: Several members of Ruby Core are currently under negotiation to join Heroku).
78

难道没人跟我一样,找项目做的时候是看写起来快不快乐的吗?

A87c18

https://ruby-china.org/topics/27492

Points 1 and 2 are unarguably correct. Rails isn't hot any more and is not evolving at the pace it used to be. But this isn't a bad thing. It's a sign that Rails has matured, it's now an adult framework and not the spotty teenager who grows taller by an inch every month.

http://www.bootstrap.me.uk/bootstrapped-blog/why-you-should-use-rails-for-your-new-company

文章后面的讨论更有意思些。

Paweł Nowak9

I think you are agreeing with Jared even if you don't know it. The main point in Jared's blog post is that being a hotness, being the first, was everything that Rails had going for it. The performance issues always existed with Ruby, the architectural issues in Rails have been extensively discussed for years at this point. The only thing that kept Rails ahead of everyone else was the fact there was nothing quite like it, it was literally years ahead of everything else. However, times are changing. There are many alternatives out there as good as Rails, others innovating more than Rails, and many of them in better VMs and runtimes than Ruby (disclaimer: I don't consider Node.JS better than Ruby). Seriously, in the last 10 years, things changed dramatically, from the number of CPUs to web development itself. Ruby is horribly delayed in the concurrency game. Rails is playing catch up with Action Cable, APIs, ES6 and others when compared to alternatives in Clojure, Go and Elixir, like Phoenix. So when you agree Rails is becoming stable, you are agreeing that Rails lost its main competitive advantage. At this point, you should be considering and evaluating other alternatives. It doesn't mean you'll necessarily replace Rails, but for your own sake, you should be looking at them.

Fred Heath

Hi Pawel. Yes, there are many alternatives out there as good as Rails, or may be even better. But Jared's first argument is that we should switch because these frameworks have more rising mind-share and will cover our needs better in 3 years time. My argument is that if you're a start-up and you worry about which tech you should be using 3 years down the line then you're either extremely confident or extremely naive and neither is a good thing. Rails is a proven start-up bootstrapper and until something comes that blows it out of the water, switching would be an un-necessary risk. Jared's second argument is that we should switch because Ruby is slow. I have hopefully shown that this is largely irrelevant. In most Rails apps I've worked on, latency is 90% of the time caused by some db transaction or some external service call, not by Ruby itself. If you need something like parallel processing of massive data sets then you wouldn't be using Rails in the first place, so I find this to be a moot point. Same with concurrency. I am very familiar with concurrency and its issues, but since I've been using Ruby I never had to worry about it because I didn't need to. For web apps I let the web/app server stress about it. For non-web apps I get by with forking processes and avoiding shared resources or using Redis or a queue. It's seriously never been an issue. For the record, I am evaluating other alternatives, namely Elixir and Phoenix. But these are a complement to Rails, not a replacement. Rails will be my default choice for building something quickly, unless there is a specific need for elixir's performance. YAGNI.

6224

#9楼 @ashchan 快乐分很多种,比如写起来、跑起来、升级起来,甚至如作者所说还包括招人时是否快乐,与写ruby的人合作是否快乐。

157

赞同 LZ, 十字螺丝钉用十字螺丝刀, 一字的就用一字的.

从个人倾向来说, 如果一件事 几个语言包括 Ruby 都能干, 那肯定选 Ruby. 因为它趁手,用着舒服,写着快乐 😄

713

Rails就像是自行车,这个问题就像是家里是不是要买辆,有经济实力的,一开始就奔驰宝马没问题

但钱少的,还是先买个自行车好了.甚至你说自行车不能跑长途怎么办?需要的时候再买个好车呗

Rails其实上解决了没有钱买奔驰宝马但又要近距离出行的问题

594

#13楼 @azhao 说的太好了!

7456

他不会再选择 Rails

594

2008年的时候Rails听起来很酷。 一项技术成熟的时候,就代表他已经过时了。

329

For me and my team, Ruby/Rails just works. That's enough. 喷Ruby过气的,根本不考虑PHPer的感受,人家怎么也是”世界上最好的语言“啊

239

#12楼 @raven 莱文兄说话还是那么犀利。

239

#9楼 @ashchan

让写代码变成一种爱好。

所以不纠结用啥, 关键开心。

11363

#4楼 @swachian "语言太慢绝对是瓶颈" 非常赞同。

正常情况下在8时-22时配置合理的硬件系统可以运行良好,但在某些情景下比如秒杀、比如群发或推送后的10分钟内流量洪峰来的时候,”语言的性能“就成为巨大的瓶颈了。由于语言的限制即使做了极致的优化,可能效果还是不如一个新手用性能更好的语言做实现的。

硬件可能很便宜,云服务器扩展也很方便,对于大公司来说可能有无数的解决方案(比如kaminari作者所在公司那种动态启停几百个节点的做法),但对于很多小公司来说可能并不便宜,实现也并不简单;对于很多客户来说并不愿意为了你的实现多投入那么多的资源。

最开始看到15分钟写 Weblog 实现的时候惊艳我的是scaffold(代码生成)以及 ActiveRecord,后来是语言的特性和活跃的社区(丰富的插件)。现在我仍然喜爱,我们有的产品也还 完全 在用 Ruby/Rails,也更明白了其实无论什么语言和框架,最终以合适的代价创造出有价值的 东西 才是最重要的。

11222

楼主其实已经反复暗示了他觉得更好的语言,看看每个大段的结尾就知道了。😄

12260

原来在推广go - - !

11222

@lgn21st 我还以为是GO....

6224

#13楼 @azhao 英文作者认为不合适的就是用自行车出行的阶段选用rails。不过他给的推荐也并不能让人感觉眼前一亮。rails进入平台期,亮点少了ruby的性能瓶颈依然,而从node到go也各有各的问题。所以中文文主比来比去发现还是php真的不错。又有大公司投入又有小公司用。

11363

#22楼 @rei 虽然没用过AWS但是听说过这类方式。 我们还和做集成、大数据方面的伙伴公司测试过Openstack啊,DigitalOcean等服务商的动态创建之类的方案。小公司为了存活下去还是很看重成本控制的。 所以有的压力大的就模块重写了。

2474

如果你为了追求更好的 Concurrency 编程选择其他语言……快来试试Elixir……

https://soundcloud.com/elixirfountain/elixir-fountain-2015-09-25-dave-thomas

3

#26楼 @swachian 隐藏得这么隐晦都能被你发现,厉害 :plus1:

A87c18

#8楼 @rei 惭愧,一直不知道 :plus1:

487

Scribd这种文章基本可以忽视了。

当然,文章描述的也是客观现状。现今,对于创业公司来说,除了Rails之外,确实多了不少新的选择: Node.js、elixir、go、scala等。 如果时间再回到2006年,我就不信Jared还会说,我不会用Rails去创业,因为他没得选。

当年Ruby之父Matz,通过摩尔定律看到,未来硬件成本必然很低廉,所以创造了以人为本的Ruby,但是他没有看到的是CPU的发展瓶颈,没有预料到多核时代,更没有预料到互联网的飞速发展,所以性能是Ruby与生俱来的缺陷。所以,那些不用Ruby的人的理由也很简单也很唯一: 性能不行。 但是你用天生并发的语言做的应用就没有性能问题了吗?

今天看到一句话 「你用了号称最先进、最新潮的语言,你也做不出一个 Whatsapp 这样被$190亿收购的公司啊!」,深感认同!语言只是工具,要做一个伟大的公司,跟你用什么语言关系不大。

我们是程序员,快速掌握任何一门语言去谋生是我们的职业天赋。其他人用不用Ruby无所谓,没有公司用Ruby也无所谓, 因为我们是Rubyist,不管用其他什么语言,Ruby这位程序员最好的朋友都一直在我们心中,影响着我们。

P.S 看完Matz对Ruby3.0的公开演讲,感觉Ruby的未来还是有很多可能性的。

96

从今年开始就再也没有碰过 Rails 了,感觉 Rails 已经老了,该退休了。十年前 REST http request/response 的模式看起来那么美,但是现在时实时应用的时代了,大家可以了解一下 meteor 的 data on the wire 的概念。

如果 https://github.com/peatio/peatio 项目中使用 pusher 实现的那部分功能,用 meteor 实现是不是会很简单呢?

A87c18

#32楼 @blackanger 视频也看过了,多线程的处理也是很难的,完全解决会是个漫长的过程。不过就语言发展来看,近几年来Ruby更新速度还是非常乐观的。

3

#33楼 @happypeter 能委托给第三方专业服务解决的问题,应该全部委托出去,只是这个策略在天朝不适用。

1801

skandhas :plus1: 技术是为了推动产品和服务产品的;合适的场景要选择和适合的工具,我认为语言也是一个工具,使用那种语言应该基于你要做什么东西,而不是选择语言来作某个东西。

96

也许Ruby on Rails未竟的使命可以有Elixir的Phoenix来达成啊

9800

月经贴,鉴定完毕。。

15139

只有我一个人看到 自燃 么…… 还有 streem。

10401

不知良辰怎么看

96

#35楼 @lgn21st 对这个是完全赞同的,但是“实时性”的部分应该是内嵌到一个框架的最深处的,成为框架的默认的。所以,过时的不仅仅是 Rails ,还有 Ajax/Pjax/turbolink 等这些所有基于非实时框架做成的实时 Hack 。

世界变了,最大的一个特点是网速变了。十年前,当我们请求一个页面等个三五秒认为是正常的时代,Rails 默认的这种 Http 请求模式显然是没有问题的,因为最大的痛在于等待时间而非页面刷新。但是到了今天,web 应用应该是”无刷新为默认“的,也就是”类原生应用为默认“,道理很简单:网速上来了,用户体验要在平滑性上来拼了。Rails 从基本架构上不是为这个时代而生,所以改进也没有必要了,慢慢淡出娱乐圈才是正道。

说起”编程快乐“,这个依然是最重要的。但是用用 meteor 就会发现,Rails 输掉的同时是两个极端:易用性和强大性。

3

#42楼 @happypeter 你的这个 淡出娱乐圈 的提法我不敢苟同,也不反驳,好自为之吧。

2466

ror这种用动态语言做的框架,项目规模一大就不行了。比起静态语言,写的时候很开心,重构起来就直接等死了。

A87c18

#44楼 @rasefon

比起静态语言,写的时候很开心,重构起来就直接等死了。 会么?你直接一锤子否定了 Rails ,从你这句话推断而来,过去 Rails 火也是不合理的。

A87c18

@pynix 哈哈 @msg7086 不是你一个人,哈哈。

2466

#45楼 @rubyu2 我指规模大的项目。

6699

怎么没人提 tradeoff 拼错...

3

#48楼 @offspring 谢谢指正,已经 fix 了。

12277

很中肯的一篇文章,给楼主点赞。

  • 我99年开始编程,但是接触rails不久,却受益匪浅,并且会作为爱好一直实践下去。
  • rails吸引我的,其实是背后的web最佳实践的设计哲学。脱离道的层面谈术是没有意义的,何况语言都会不断的发展,喜欢就好,适合就好。
  • 从哲学层面上看,世间的事没有最的(不限定范围的话),我们很多时候都是在“比较适合”中随机选择解决方案;从商业角度上来说,选择什么技术真的无所谓,能赚钱或者省钱就好。

觉得现在的技术环境真好,有这么多可选项,很幸福了哈哈;喜欢且适合,就上呗。

1090

#44楼 @rasefon 规模大的项目用什么语言重构起来都不会轻松的。没写测试的才真的是等死。没写测试,就别往语言上找理由。那是活该!

96

他说的很有道理啊。现在用Rails已经不能吸引Hipster了,当然不划算啦。

流行的东西就是这样,每过一段时间就会有一些老掉牙的东西被当作新时尚。

我赌2016年流行的Web框架采用的是PHP语法,在BEAM上运行

19606

没有人说Ruby3.0是在模仿elixir吗?类型检查,Actor,|>,Elixir有的Ruby3都要有,而且语法也是高度相近。

1342

ruby 2.0是20周年发布,3.0会是在30周年的时候发布么

7733

#53楼 @cuebyte 哈哈,大家互相借鉴,有啥不好

9313d8

#42楼 @happypeter

html css 等 为基础的web技术设计的时候显然没考虑平滑性。要体验好,平滑,Flash 是首选。从网速更快,体验更好来看,也应该是 Flash 最佳,那么问题来了,为何现实不是这样呢?

因为现实需要妥协,

越是新的技术,比如 golang,实际使用肯定需要比成熟技术更多的妥协。坑不仅仅是技术上的。

极端,如果追求成熟,坑少,人好招,那么 rails 显然不是首选。

新公司到底用还是不用 rails?

即,新公司如何面对:1) 语言的运行效率很慢 2) 框架发展到了瓶颈期,优势不再 3) 对开发者的吸引力下降。

新公司面对的问题是生死,如果这三点足以要命,还是不要用的好。

Jared Friedman 的 Scribd 流量是 rails 第三,我真不好理解这意味着神马,我也有点rss新闻订阅,但没怎么听说 JF 和 Scribd,也懒的查查,

一般牛掰的人说手里的家伙,都是往low里说,比如我们用小米和步枪的架构,或 php java python 都用一些。

JF这哥们让别人也不用 rails 真是牛逼吹大了!!!

你们感受一下:

xi:小札,你们这网站打不开,还做上市,用的是神马技术?

小札:回主席,我们用 php ,坊间说 php 是世界上最好的语言,不过您可别用,因为有三,

  1. 效率慢
  2. 发展卡住了
  3. 不是世界潮流

xi: 蛤蛤蛤蛤,好的狠,欢迎来华,来走我们社会⚠注意道路,原因有三

  1. 我们体制效率高
  2. 我们有世纪梦想
  3. 我们有七个信心

====================over==继续哄娃睡觉

96

#57楼 @robbin 真的到ruby性能瓶颈的项目不多吧,现在不少项目还选用php和python,这两个的性能和ruby比起来也半斤八两吧

4087

#58楼 @redvoilin

PHP是比较纯粹的Web模板语言,不是一个full-stack的web框架,使用PHP的项目,往往被迫在早期架构扩展的时候就引入了后端编程语言,逐渐就迁移过去了,PHP只做模板了,所以不太存在可扩展性的问题。

Python和Ruby都一样,可以做full-stack,可以支撑相当长一段时间的架构扩展,代码逐渐积累到庞大的规模。而一旦发展到大规模应用,需要更高的可扩展性的时候,迁移还是不迁移,都会变得异常痛苦。

Python比Ruby好的地方是应用领域更加广泛,Web不行还可以干点别的,Ruby就尴尬了,除了homebrew,puppet,大概找不到太多其他领域广泛应用。

1704

任何时候都不能脱离实际场景瞎扯哪个好哪个坏啊。

17424

太捍卫一门语言,不灵活,属于大多程序员的死穴。 Swift的出现就正实了,近期人性化语言的发展要远远高于前几年。 Go,react, swift,.... 都属于年轻的活跃,有后台的支持的语言。 走向也不定。 相比,ruby 和rails 比较老了。活跃量也在下降。 突然间发现自己的表达能力太差了。

17424

补充,近期我反而觉得 windows 的发展异常。 反而成了一个 不定棋子。

244

基本同意robbin

15

#62楼 @davidzhu001 鲍尔默那10年 MS 基本在原地踏步,这两年看起来想吃春药,希望不是回光返照。

17424

最近我感觉有种智能 大突破的局势 @huobazi 。3d技术如果成熟了。编程走入现实就容易了。到时候可能虚拟编程会进入现实编程的风波。

756

没必要一刀切,要么用要么不用,别忘了 Rails 中的部件是可以拿出来单独用的。例如用 ActiveRecord 开发一个 microservice 就是一种别的语言都难以望其项背的愉快体验。

96

这哥们刚刚创立Scribd的时候,连iPhone都没出来,mobile app根本都没成为主流,web application作为应用的载体地位比今天要重要一些。而Rails恰好是一个全栈的 web 框架,选择它当然是顺理成章的事情。

但放到今天,Scribd或者其他的任何一个公司,开发一个应用首先都必须考虑 mobile app 的问题,也就是相对于全栈的web application,首先需要考虑设计一个所有端都能使用的 API service,性能问题/响应速度在这个场景下相对2006年更重要,因为重点变成了返回轻量的JSON数据而不是渲染一整个页面,界面的工作是丢给客户端来做的。Rails和Ruby在这个场景下并不比新生的各种工具更有优势。ES6 标准出来之后,解决了Javascript语言原生的一些劣势,加上各种前端框架的火爆,可以预见整个JS的生态环境会更加的欣欣向荣,可以比较好的应对并发问题的Node在这些前提下的确大有可能会得到更广泛的应用。

其实作者的分析是非常有道理的,他并没有说他回到2006年不会选择Rails,而是现在他再成立一家公司不会选择Rails。如果我对 Node, Ruby, Go 的熟悉程度差不多,而我今天需要从头起一个主要作 service 为移动端服务的API,我也不会选择Ruby/Rails。

23203

北京某公司招聘ruby工程师3名,2年以上工作经验,大专以上学历,坐标北京朝阳,年薪15万左右,有意者发简历至1937823048@qq.com

3

#68楼 @mrwjcok 查了一下后台,该用户已经被 Ban,这种搭车招聘的行为在本社区明令禁止,看见一个 Ban 一个,绝不姑息!

20265

Ruby on Rails 新手, 看了那篇文章以及上面的一些评论。起初还是有些难受。 作为一个从零开始的Web开发者,直接入手Ruby on Rails, 不敢对其他框架和语言作评论, 但是Ruby 以及Ruby on Rails 给了我继续编程的信心, I Love her.

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册