聽說 Ruby 性能不好，為什麼還有這麼多人推薦 Ruby 呢？

01-16

我了解大家覺得 Ruby 靈活，可是應該用靈活和快速開發來換性能嗎？況且貌似 Ruby 的 bug 尋找比較麻煩。
本來打算學些 Ruby 玩玩，大家幫我解惑一下。

性能問題屬於成功後的煩惱，而開發效率是在項目第一天就面對的問題。

大多數項目還沒有來得及遇到性能問題就死掉了。

　　借用《Programming Ruby》推薦序中的一段話來回答你吧（順便也推薦一下這本書）：

事實上，執行性能與開發效率是軟體開發中的一對矛盾，所有的程序設計語言都必須面對這個矛盾，作出自己的選擇。

　　在當時，大多數新語言的選擇是上下通吃。它們一方面提供了豐富多彩的高級抽象，另一方面又提供了強有力的底層操作能力，希望由此實現高性能與高效率的統一。C++、Java、C#和Delphi都是走的這條路線，甚至VB從5.0開始也強化了底層操作機制，並提供了編譯模型，不落人後。

　　Ruby實現了最純粹意義上的面向對象，讓Smalltalk、Perl和Lisp的靈魂在新的軀殼裡高歌。相比於Python，Ruby的思想更加清晰一致，形式更加靈活；相比於Perl，Ruby更簡單質樸，絕少光怪陸離之舉；相比於Smalltalk和Lisp，Ruby更富有現代感和實幹氣質；相比於廟堂之上的「工業語言」，Ruby自由揮灑、輕快銳利；而相比於JavaScript和PHP，Ruby從Smalltalk繼承而來的深厚底蘊又大佔優勢。面對執行性能與開發效率的謎題，Ruby毫不猶豫地選擇了開發效率，選擇了對人腦的友好。

性能的問題，等你真正遇到了再去解決；能快速做出產品才是優先考慮的，許多網站的流量是很低的

開發效率當然可以用來換性能。這個世界上不需要性能的程序多的是。

又是一個容易引起口水的話題

樓上的各位說的都很好啦

理性地說，我們經常需要在執行性能與開發效率上做取捨，Ruby/Python這類動態語言，犧牲部分執行性能，來換取開發效率。今天程序員的成本遠比機器來得高，它們的流行就不足為怪了

有些時候，性能可能是重要的，但優化性能的途徑那麼多，語言未必是拖累性能的那塊短板，我們常常可以從演算法里榨出更多的水來。另外的時候，性能往往是不大重要的。或者它遠沒有我們想像的那麼重要，比如web開發初期，快速構建產品原型，性能是不大重要的，ROR的開發效率優勢就出來了

此外，補充一個非理性因素，程序員也是普通人，我們沒有自己想像的那麼理性，我們有自己的審美偏好，Ruby的流行，很重要的一個原因，有一群人熱愛它的設計哲學，偏好它的「There are many ways to do it.」，這不是個好壞對錯的問題，這是個選擇問題，這也是引發無數聖戰的地方，這裡同歷史上其他觀念之爭一樣，從來沒有一方會妥協，永不停息。

好比我偏好不可知論，好比我偏好Python的「There should be one-- and preferably only one --obvious way to do it.」。我不是說我是對的，我只是說我喜歡它們。

這個話題，Michael L.Scott的《程序設計語言：實踐之路》中談論過：

不同的人喜歡不同的東西，有關程序設計的大部分偏狹觀念不過是由於個人的不同口味，有些人喜歡C的緊湊，另一些人則痛恨這種東西，有些人認為遞歸地思考問題很自然，另一些人則偏偏喜歡迭代，一些人願意用指針工作，另一些人則更喜歡Lisp,Clu,ML里隱式地引用，個人偏愛的強度和多樣性，使開發出一種能被所有人接受的程序設計語言成為不大可能的事情

如果一個函數或者演算法用 Ruby 實現比較慢, 那其實你寫 Ruby 時是基本調用不到這種慢實現的.

實際你都會調用到最快的 C 實現...

看你幹什麼了。Ruby （甚至1.9）性能的確不佳（比如不如 Python），但如果是做 web 開發，本身性能並不關鍵，I/O 才是瓶頸。此外，處理 web 請求屬於「embarrassingly parallelizable」的問題，可以通過增加硬體解決 scaling 問題。此種情況下，Ruby 的動態語言特性和成熟的 Rails 框架帶來的開發效率的提升更有價值。

當然，如果你的用戶數量達到一定程度，動態語言的低效率會成為瓶頸。Twitter 後台最後改用了 Scala 以應對龐大的 tweet 數；Facebook 的 PHP 腳本也被靜態編譯成原生代碼再運行。但在那之前，側重改善應用本身的功能、特性是開發的重點，執行效率暫時不那麼要緊。

我寫了一篇 post 在這裡 http://blog.xdite.net/?p=2124

1. 真實的世界是 PHP 的效能比 Ruby 差。

2. 真實的世界是 PHP 的任何一種 Framework 效能都比 Rails 差。

3. 真實的世界是程序員的 per hour cost 遠比機器還要貴。

Ruby 與 Rails 能協助你有效大符壓低開發成本，而開發成本的降低才是讓「網站」公司存活下去的一大關鍵。絕對不是程式語言的效能。

當你的機器成本開始高於程序員的成本時，才需要考慮換框架與語言的問題。

這問題我有把握：因為 Ruby 滿足了人性較深的需求：開心。

為什麽開心？因為「親切」與「幽默」。

為什麽擁有這些特質，因為我私心認為 Ruby 是很強化人性(良善層面，如整潔、愉悅、互助)的語言。

這一切，令一些人深信，Ruby is the better language.

許多人從實用的角度切入，都很有參考價值，但我想從「使用 Ruby 很開心」這種人性點來切看看。雖說主要是為了自己開心，不過我覺得，很多事物都可以用人性面解釋，洞察會更深刻，或者說，比較能看見「隱藏世界的邏輯」(哪位牛人說的恕忘)

我想，正如人買愛車，尋找人生伴侶，不見得都考慮實用性最強或CP值最高的，而是因為：開心。

我們不一定明講，也許在解釋我們的決定時，請像用用比較「客觀」的標準來暗示他人，自己的理性與可靠。

不過啊，我們心底的小孩，還是很希望開開心心的呀。

首先(講完了很長的引言後)稍微介紹自己/答題的背景：最近開始學 ruby 。用過c, perl 與 python ，用過超過十種程式語言寫數十到數百行程式。我的簡潔性越來越挑剔。不熟抽象層次高的編程技術，如 OO, FP。因此不是大牛。但由於工作允許我挑選自己愛的程式語言(檯面原因：新、開發速度快、少 bug；深層原因：爽)，逐漸開始熟悉學新語言，篳路藍縷卻樂此不疲的感覺。所以算頭異牛吧，哈哈！

我的背景對於回答這個問題的價值在於：可以脫離對現實社會的適應度等利害關係的考量，純粹就「一個人使用程式語言的感受」來回答這個問題，好比人交朋友，學校裡的朋友交心，最深刻最觸動心弦，而出社會交的就難免利益了，駁雜了。

以下列出我對 Ruby 為何令人開心的思考

1. 根本原因：Ruby 的監護人(我喜歡這個詞)樂於助人。

a. 監護人非常重要：正如公司的領導人品格對公司影響巨大，考慮程式語言，就不能忽略他的監護人怎樣維護這個語言。

b. 比如 GvR 監護 Python 語言，產生「開明專制」的效應(PEP 提出後，最終生殺大權在 GvR 手上)，意思是這個語言很可能不會滿足每一個人的期待，但會滿足 GvR 心目中對好語言的期待。既然 GvR 是經驗豐富的編程者，也參加過 ABC 語言的開發工作，熟練設計程式語言的眉角，他心目中的好語言大概不會太差。

可以說，Python 真的不是太差的語言呢^_^

我認為 Matz 監護 Ruby 的模式，很可能在某方面也類似 Python 。比如，監護人的喜好與善意反映在語言的特質與演進上。有意思的是， Matz 曾說一段話(請原諒我找不到原文)，大意是：我打造的是我心目中理想的語言。

Matz 的處世是溫和的。引用他說的一段話：Sometimes you』ll have a hostile person come into the community. When I have a difficult conversation with someone, I have a rule: I remember there must be a reason for them to be hostile.

他是在闡釋 the community is Ruby"s greatest asset 時，有關的問題時談到這段話的，這意味到，以上答案說明了他與社群互動時，經常想到/運用以上上的原則。這可以佐證，他是善於與人互動的。

我想， Ruby 其餘的吉光片羽，或多或少，都來自於 Matz 的品格吧！

我非常想探究，這種品格與日本文化的關聯性，但那是另一個課題了。

2. 用 Ruby == 開心。

這個印象得自於

a. why the lucky stuff 那本引人 Ruby(動詞) 的藝術作品。不知怎麽稱呼他，說他是程式語言入門書，他的美學觸角遠廣於此，我個人把他當作藝術品看待，因為它充滿創意，very stylish，奇書一本。

b. Pragmatic BookShelf 出的 Ruby 書 Programming Ruby 2nd Edition 中譯版。很明顯感覺到，作者麽寫書時非常開心的，因此全書帶有自然的幽默感(不刻意搞笑)，看的時候很順心。比起看 C 或 Java 書時經常想睡覺，這種體驗是很妙的。我看的是翻譯本，有些地方卡卡的，一些妙處翻不出來可以諒解。但還是嗅得出愉悅感。

插播(why the lucky stuff 很愛乾的事，他的插播可比正文長多了)：如果一項工具能讓 user 經常發笑，它的價值真是無可限量啊！有多少人一邊工作一邊經常發笑，還可以賺錢的？？

如果我沒看過藝術品幽默工具書，用起 Ruby 來也許不會如此開心。

另外，能夠讓 user 如此開心地一邊 Ruby 一邊靈感大爆發/幽默處處開，這東東真的神啊！

3. 隨興意味：Ruby gem (功能單位，加gem等於加一掛功能進去) 的品質感覺上比較不嚴謹，偶有過時或小 bug 未修，於是得自己動手整理。

聽起來好像不妙，但也不一定。這樣說吧，想像一群熱心的朋友介紹你用一個好東西，也許東西不是排名頂尖，或者其設計沒有到爐火純青的程度，也許越用越發現一些小瑕疵。比如常有小bug；library coverage小，總有特殊需求照顧不到要DIY或上下求索；語法美麗程度不如小眾語言REBOL。但是，「想到朋友們的笑容，一用它，自己的臉上也泛起了微笑啊」。這種感覺。

在某種程度上，這可以解釋，為什麽 Ruby 擁有活躍的 community 。當然必定有其他因素，可惜我沒有參加 community ，無從分析。

幸好 Ruby 在 DIY 修理方面挺很友善，open source(可改!) ，直譯式(易改!!)，而且 class 啦 object 啦可以隨興加東西進去(鼓勵改!!!)，其妙處我體會不深，但既然寫書的人很開心地玩了給我看，我就笑笑地敞開心胸接受：雖然我還一頭霧水，但 meta programming 應該很好用，醬子。

談到 open source ，忍不住一提，他是有著強烈互助性格的一種文化。這對 Ruby 達致的人性層面，相信功不可沒啊。

4. 寫 Ruby 時，常感覺到，原來那個最簡潔的答案就是最適切的答案。這一點相當妙，大概暗示著它的設計水準相當高吧！？

5. Ruby 的作者 Matz 曾說： Ruby 像人體一樣，看起來簡單，內部卻極之複雜！這句話我當場心悅誠服了，因為簡單又好用的東西，看起來平凡，但常常要納入大量智慧才能完成的。

原文： Ruby is simple in appearance, but is very complex inside, just like our human body. https://www.ruby-lang.org/en/about/

進一步考察，以下這段介紹 Matz 的話，He has often said that he is 「trying to make Ruby natural, not simple,」 in a way that mirrors life.

如果由於 matz 孜孜矻矻， Ruby 真的有做到 natural ，就比較不該用 terse 或 simple 去形容，而是 natural to use ，好比人們使用雙手，有以下特徵：

a. 易上手

b. 上手後發揮空間大

c. 使用時行雲流水，妙趣橫生

7. Ruby 只在某些地方用括弧，不像 C, C#, Java 類語言，以及考慮到熟悉「大括弧語言」 user 接納程度的語言，保留大括弧特性。因此看起來清爽，好懂，有點到傻瓜的程度，偷偷地說，看起來不夠 geek ，無法激起 mm 崇拜牛人的慾望，哈哈。但不考慮人生中無所不在的性考量的話，光就寫程式本身的樂趣， Ruby 是難得一見唷。

回到正題，我想說的是，如果要舉手說舉手就好，要坐下說坐下就好，也許有人喜歡說成 { Action RaiseHand (void right) ; } 但，說成 RaiseHand :right，也相當不錯啊。

8. 希望：既然很多人說它簡單，那碰到困難時，會想說，如果克服這個，其他就簡單了吧(事實是，坑很多的，可是人性是極喜愛「希望」啊！而且，盼望以後會更好，加上這個盼望很可能實現的話，多麽開心呀！這是快樂的重要泉源唷！)

來 Meta 一下吧！這個回答，我自己喜歡。是期望像「元問題求索者」那樣，將答題視為一種最適切，「間中關聯性」(我又辭窮了只好自鑄怪詞)遠超過問答的思維過程，甚至能發明出新的語言(表達方式，form)，寫出一種唯獨適配該問題的「thingy; DSL」來。但，DSL有點難的，只能說這篇文章有點「Ruby風」就是，而且保證全新角度觀照。反正目前先求大家開心就好，如果這篇文有讓你笑了一兩聲，煩請出個聲呀^_^

這個問題是接近兩年前的了。

兩年里發生了很多事情：

移動 Apps 和 HTML5 興起。

JS 攻城掠地，無論是前段框架，還是後端框架。

Java 雖然不溫不火，但是 Spring 等框架為也越來越好用了。 hadoop 的興起又給 Java 注入了新的活力。

Ruby 發布了 2.0 。。

回頭看看？糟糕的程序員，還是在寫糟糕的程序。優秀的程序員？變的更加優秀了。

他們有一些在寫 ROR ，另一些？轉戰 node.js 了。

放在一個較大的時間尺度上看，不斷進步的技術團隊，才是最寶貴的。而這種學習能力，體現在對新技術的敏感上面。

我相信這才是當年一個 ruby 團隊的真正意義：如果你兩年前對新的技術都沒有興趣，兩年後也不會。

網站的性能瓶頸一般都不在程序的計算性能。

Ruby on Rails 是創業團隊最適合的選擇之一。其餘的還有包括 Node.js 等等。

原因有：

創業原則一：儘可能使用自己熟悉的技術，如果大家找不到共同點，那就找一個最容易學習的，這裡 Ruby 顯然高分勝出。
創業原則二：保障開發效率是先決條件，絕大多數創業團隊都在你去考慮性能問題前就會死掉，所以儘快出原型比什麼都重要。解決性能問題有一百萬種辦法，但這一百萬種的前提就是你要把東西先做出來。
Ruby 的效率也沒有那麼不堪，2.0以後提升是數量級的。

程序員儘可能的去做一些創造性的事情，性能提升什麼的，機器可以幫你解決！

不贊成歐大的觀點，國內的開發比國外總是會滯後一段時間，就如國外java主流的時候，國內是c++，國外python流行起來的時候，國內開始java潮流，現在國外ruby流行了，再看看國內的python現象，前幾年抱怨的python開發人員少，機會少，看看現在python招聘機會多還是少，就能想像到ruby將來會是什麼樣子，所以別那麼急於下結論

ruby寫起來舒服，和java之間的性能差距在網站初期不是問題。網站建設初期，最要命的問題是快速構建，快速上線，時間是第一要素，這也是為什麼ruby很適合創業小網站

少年, 你聽說過ruby3x3嘛?

這個問題其實很簡單，因為『早期使用者』是一些有品味的人。當時好的東西都被吸收進去了，所以聚合了更多的『准早期使用者』。在軟體這個行業程序員中的『早期』使用者決定了技術（主要是語言和架構）大的發展方向。

所以，如果說推薦你使用Ruby，我覺得不如說人家推薦你加入『早期使用者』的行列，我覺得這基本上不會錯，讓你加入有品位（區分好壞）的程序員的行列。

但是很不幸Ruby現在也被很多『早期使用者』拋棄了，它們會去選擇它們覺得有趣的所有新技術。現在的Javascript和Node.js就是New ruby and rails。你看很多人開始嘲笑Rails社區是不關好不好我們都要，而Python社區是不關好不好我們都不要……

所以，認清形勢站好隊就行了。不斷提升品味是一種追求，不過追求其它也不要問是否高尚，因為活著是為了什麼根本就不是一個哲學問題。

每一段時間都會出來類似的評論，說某某語言效率差。大家要習慣。

程序員心裡應該貫徹這樣一種理念，單獨的某一種語言的擴展能力（包括性能）永遠是有限的，一個良好的不斷改進的架構才具有持續的擴展能力。

我就不推薦。。。

跟風而已