自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

編程語言Ruby如何還能再活25年?

開發(fā) 后端
今年早些時候,Ruby 舉行了 25 周年慶,而Ruby 已經(jīng)發(fā)展成熟,Ruby 的流行部分來自 Ruby on Rails(RoR)Web 應(yīng)用框架的成功,但RoR 不再是超級明星了,它面臨著激烈的競爭,大家懷疑它是否能夠再活 25 年。

編程語言Ruby如何還能再活25年?

【編者按】全球 Ruby 社區(qū)是友善與支持的代名詞,人們用“Matz 人很好,所以我們也很友好”來形容它。多年來 Ruby 語言一直很流行,特別是那些需要處理大量繁重工作的初創(chuàng)公司。今年2 月份的時候,Ruby 舉行了 25 周年慶,而Ruby 已經(jīng)發(fā)展成熟,Ruby 的流行部分來自 Ruby on Rails(RoR)Web 應(yīng)用框架的成功,但RoR 不再是超級明星了,它面臨著激烈的競爭,大家懷疑它是否能夠再活 25 年。

以下為譯文:

軟件是如何誕生的?這也許不是大家希望在編程大會上聽到的主題演講者所提出的第一個問題,但這是來自日本的,Ruby 編程語言的創(chuàng)始人,和藹可親的松本行弘(Yukihiro Matsumoto,被稱為 Matz),在為期兩天的年度 Bath Ruby 大會上,與 500 多位 Ruby 開發(fā)者交談時提出的第一個問題。

2 月份的時候,Ruby 舉行了 25 周年慶,盡管 Ruby 的第一個版本 0.95 是于 1995 年 12 月正式發(fā)布的。針對自己的哲學(xué)問題,Matz 建議說軟件在命名時誕生。在 Ruby 誕生兩年前的 1993 年 2 月 24 日,東京和社交媒體舉行了盛大的慶?;顒?。 Matz 說他想用一個寶石命名,他很風(fēng)趣地說:“Ruby 很短,Ruby 很漂亮而且昂貴,所以我給自己的語言起名叫做 Ruby。”

然而,Matz 近五年來第一次來到英國,并不僅僅是為了吃個生日蛋糕。Ruby 可能已經(jīng)發(fā)展成熟了,但是大家仍然懷疑它是否能夠再活 25 年。就像它的創(chuàng)造者一樣,Ruby 語言非常討人喜歡,擁有忠實(shí)的追隨者。比如,它的語法可讀性非常高,但是表達(dá)方式非常簡潔,且是一種動態(tài)的、反射式的、面向?qū)ο蟮耐ㄓ镁幊陶Z言,它直觀且易于學(xué)習(xí)。Ruby 不想限制使用者,或者引用 Matz 經(jīng)常說的一句話:“Ruby 旨在讓程序員開心。”

但并非每個人都很開心。由于 Ruby on Rails(RoR)Web 應(yīng)用程序框架的成功,多年來 Ruby 語言一直很流行,特別是那些需要處理大量繁重工作的初創(chuàng)公司。這一顯著的優(yōu)勢使得 Ruby 在 2012 年的 RedMonk 語言排行榜上飆升至第五位,該排行榜結(jié)合了 GitHub 和 Stack Overflow 上語言的排名來評估語言的流行度,后來 Ruby 的排名下降到了第八位。

RoR 雖然很受歡迎,但并不是它的巨星,它面臨著激烈的競爭,因?yàn)橐?guī)模伸縮等問題已成為互聯(lián)網(wǎng)公司更為關(guān)注的問題。例如,Java 的框架 Node.js 變得很流行,因?yàn)樗幕卣{(diào)函數(shù)可以用更少的內(nèi)存來處理大量的連接。

編程語言Ruby如何還能再活25年?

自2012年以來,在RedMonk排名中,Ruby在排名前十的編程語言中緩慢下滑。且一直在第十名上下擺動,這反映了Ruby已經(jīng)發(fā)展成熟以及Ruby on Rails Web應(yīng)用程序框架優(yōu)勢的減弱。

很明顯,Matz 知道任何編程語言的使用都是由語言社區(qū)以及生態(tài)系統(tǒng)(RoR 是一個令人驚訝的例子)發(fā)展而來的項(xiàng)目和框架推動的,而通常不是語言本身。Ruby 也不例外,即使 Ruby 贏得了很多用戶的喜愛。因此,在 Bath Ruby 大會上,盡管對于在自己的語言中犯下的錯誤他表達(dá)了遺憾,同時他也想明確前進(jìn)的方向,解決那些造成開發(fā)人員放棄 Ruby 的性能和規(guī)模問題。

Matz 解決關(guān)鍵問題的方法也表達(dá)了他看到的兩個關(guān)鍵趨勢:可擴(kuò)展性,以及他所稱的更聰明的伙伴。

為了解決可擴(kuò)展性并創(chuàng)造更高的生產(chǎn)力,Matz 認(rèn)為:“更快的執(zhí)行速度,更少的代碼,更小的團(tuán)隊(duì)是提高生產(chǎn)力的關(guān)鍵。”

盡管計(jì)算機(jī)的運(yùn)行速度越來越快,但這還不夠,Matz 說:“我們需要更快的執(zhí)行速度,因?yàn)槲覀冃枰幚砀嗟臄?shù)據(jù)和更多的訪問。我們很接近內(nèi)核性能的極限了。這就是為什么 Ruby 3.0 的目標(biāo)是比 Ruby 2.0 快三倍”,Matz 稱之為“Ruby3x3”。“說起來簡單,”Matz 承認(rèn) Ruby 1.8“太慢”,這是一個錯誤。

笹田耕一在 YARV(Ruby 的另外一個虛擬機(jī))上的工作改進(jìn)了 Ruby 1.9 的性能,Matz 說:“從那時起,我們一直在努力提高虛擬機(jī)的性能,但這還不夠。”

JIT 時代

為了進(jìn)一步提高性能,Ruby 進(jìn)一步引入了 JIT(即時編譯)技術(shù),該技術(shù)已為 JVM 和其他語言使用。Matz 確認(rèn)說:“我們已經(jīng)創(chuàng)建了這個 JIT 編譯器的原型,Ruby 2.6 可能會在圣誕節(jié)那天發(fā)布。”

2.6 預(yù)覽版本 1 中可以看到 MJIT 的初步實(shí)現(xiàn)。目前已經(jīng)可以利用–jit 選項(xiàng)檢查并將 Ruby 程序編譯成本地代碼,但 Matz 說該選項(xiàng)還“未經(jīng)優(yōu)化”,不過至少“對于 CPU 密集型任務(wù)來說它的運(yùn)行速度比 Ruby 2.0 加快兩倍”,他認(rèn)為這“十分有希望,且 JIT 編譯器的性能提高還有很大的空間。”特別是對于 CPU 密集型的任務(wù),Matz 相信他們能夠?qū)⑿阅芴岣呷丁?/p>

根據(jù) John Hawthorn 在 MJIT 代碼中評論,目前的 JIT 編譯器原型使用了一個非同尋常的方法:利用 C 編譯器、GCC 和 LLVM Clang 來實(shí)現(xiàn),盡管 Ruby 代碼是單線程的,但 MJIT 是在第二個線程內(nèi)編譯的。

Shannon Skipper 提供了關(guān)于 MJIT 工作原理的最清晰的概括:

  • “通過 MJIT,某些 Ruby YARV 指令被轉(zhuǎn)換為 C 代碼并放入一個.c 文件,該文件由 GCC 或 Clang 編譯為.so 動態(tài)庫文件。然后在下一次 RubyVM 看到相同的 YARV 指令時,可以使用這個緩存的根據(jù)動態(tài)庫預(yù)編譯好的本地代碼。”

Matz 還認(rèn)為,可擴(kuò)展性應(yīng)該意味著創(chuàng)造更少的代碼,他風(fēng)趣地說,因?yàn)?ldquo;更多的代碼意味著更多的維護(hù)、更多的調(diào)試、更多的時間、更低的生產(chǎn)力,以及更多的噩夢。”

然而,更少的 Ruby 代碼并不意味著語言的語法將會發(fā)生重大變化。很大程度上是因?yàn)?Ruby 幾乎沒有改變的余地,Matz 說:“我們使用了所有字符。所有字符都被用到了。”

作為自由發(fā)展的代表者,他也不打算為了自尊心而改變語法,并看到現(xiàn)有的 Ruby 程序遭到破壞,所以他很謹(jǐn)慎地說:“我們不會對 Ruby 語法做出太多改動。”

根據(jù) Matz 的說法,處理可擴(kuò)展性并提高生產(chǎn)力的工作應(yīng)該由小團(tuán)隊(duì)來擔(dān)任。引用亞馬遜 CEO Jeff Bezos 的“兩個披薩原則”:“如果團(tuán)隊(duì)人數(shù)眾多,兩個比薩都不夠吃,那么說明你的團(tuán)隊(duì)太大了。”坦白說,這可能要看團(tuán)隊(duì)里都有誰,以及他們愛不愛吃披薩(開個玩笑)。但是 Matz 說這個原則是經(jīng)驗(yàn)之談,“團(tuán)隊(duì)越大,所需要的溝通就越多,而溝通本身就是成本。”

更多抽象

近年來,人們一直在激烈的爭論,關(guān)于需要更多的 Ruby 抽象來為開發(fā)人員提供服務(wù),以便他們構(gòu)建適合不同領(lǐng)域的應(yīng)用程序,所以很高興聽到 Matz 說 Ruby 需要“更多抽象”,并提到 Ruby on Rails 以模型-視圖-控制器(MVC)抽象為例。Ruby 的創(chuàng)始人并不認(rèn)為它們是完美的,“但它們提供了對未來生產(chǎn)力至關(guān)重要的抽象。”

Matz 詳細(xì)闡述的一個關(guān)鍵抽象是關(guān)于一個名叫 Guild 的并發(fā)抽象項(xiàng)目。

Matz 承認(rèn):“我對 Ruby 的設(shè)計(jì)感到遺憾的一件事是線程……它太簡陋了。”但是 Ruby 的成功也有壞處:太多人使用該語言,所以 Matz 認(rèn)為已經(jīng)來不及刪除線程了。

他說,“我認(rèn)為可以包含一個新的抽象概念,并且阻止更多人使用線程。”Matz 還告訴 Bath 的與會者:“Guild 是 Ruby 的一次實(shí)驗(yàn),可以提供更好的方法,Guild 完全是獨(dú)立的。”

“基本上 Guilds 之間沒有共享的狀態(tài)。這意味著我們不必?fù)?dān)心狀態(tài)分享,所以我們不必關(guān)心鎖或互斥。Guild 之間通過通道或隊(duì)列進(jìn)行溝通。”

Matz 預(yù)計(jì)將在 Ruby 2.7 或 2.8 中發(fā)布 Guild 的并發(fā)抽象。

Ruby 的另一個代碼項(xiàng)目是 Steep。這是對 Ruby 的靜態(tài)類型分析的嘗試,Matz 解釋說:“分析 Ruby 的類型信息很困難,因?yàn)?Ruby 是一種動態(tài)語言,所以你可以隨意使用所有類型。”Ruby 的某些子集可以是靜態(tài)類的,所以 Matz 說他們可以添加這些靜態(tài)類型的檢查,這“有點(diǎn)像 Type 的用戶定義的類型信息。我們將盡可能推斷類型,并從外部類型定義文件或運(yùn)行時的配置文件類型分析中獲取信息……”

Matz 表示,通過這種分析,開發(fā)人員可以在編譯時檢測到更多的錯誤,“我們無法實(shí)現(xiàn) 100%的安全檢測,Ruby 不可能做到,但是我們可以檢測到 20-40%的錯誤,”Matz 說與完全不檢測相比這是個巨大的進(jìn)步。

松本還談到了 Ruby 要成為“聰明的伙伴”以及程序員最好的朋友。“現(xiàn)在我們已經(jīng)開始使用智能計(jì)算機(jī)了,比如 RuboCop [靜態(tài)代碼分析器]就是一種可以幫助你的方式,”不過,Matz 對許多放聲大笑的觀眾說,他也“不是很喜歡 RuboCop 的默認(rèn)規(guī)則。”Matz 建議,將來在編譯成功程序的時候,“Ruby 可以建議‘你給這個方法傳遞了個字符串,但是其實(shí)它期待一個整數(shù)。’”在主題演講結(jié)束后,Matz 詳細(xì)闡述了他對編程互動的期望,他同意這些聽起來很像 Tony Stark 的 Jarvis。Matz 說他很想看看“人工智能與我互動,幫助我建立更好的軟件。”

注意版本變更的幅度

版本變更可能使得軟件無法按照預(yù)期工作。過去的錯誤讓 Matz 很擔(dān)心,他說:“過去我們的版本變更很大,例如在 1.8 和 1.9 之間的變更很大,并且引入很多破壞性的變更,所以在五年中我們的社區(qū)分裂成了兩個。”

盡管以往發(fā)生過這樣的事情,比如 Python 2 和 Python 3 就是典型的例子,Matz 認(rèn)為這是一個悲?。?ldquo;我們不會再犯這種錯誤,所以我們會不斷改進(jìn)。我們會在 2.6 中加入 JIT 編譯器,而不是等到 Ruby 3.0。將來我們會在 Ruby 2.7-2.8 中加入一些并發(fā)抽象類型,但是不會出現(xiàn)有破壞性的變更……我們將保證每個 Ruby 2 的程序都可以在 Ruby 3 中運(yùn)行。”

一改 Ruby 目前逐步衰落的情況不是一件易事,Matz 似乎也明白這一點(diǎn)。在發(fā)表主題演講的早上,當(dāng)看到最近 Stack Overflow 的開發(fā)者調(diào)查結(jié)果時,他的微笑一下消失了,“Go 和 Rust 是最受歡迎的語言,不幸的是 Ruby 不在其中。我相信 Ruby 會在將來重振雄風(fēng)。人們喜歡新技術(shù)。十年前在 Rails 的帶動下 Ruby 炙手可熱?,F(xiàn)在 Ruby 雖然不算熱門,但它很穩(wěn)定。”

然而,Ruby 已經(jīng)跨越了鴻溝進(jìn)入了成熟階段,Matz 不會放棄:“Ruby 是一種很好的語言,可以幫助你提高工作效率,我希望 Ruby 可以永遠(yuǎn)如此。這意味著我們不斷改進(jìn),所以我們不能停下來。”

在日本外舉行首屆 Ruby Hack Challenge 大會正是我們前進(jìn)的一步,此次會議上周在 Cookpad(一家以分享菜譜為主的網(wǎng)站,廣泛使用了 Ruby 開發(fā)的平臺)新的國際總部 Bristol 舉行。這些挑戰(zhàn)是讓有抱負(fù)的代碼提交者學(xué)習(xí)如何擴(kuò)展 Ruby 的功能、修改 bug 和提高 Ruby 性能的機(jī)會。

Cookpad 的 CTO,Bath Ruby 大會的主辦方 Miles Bathroffe 說,此次會議主要是為了 Ruby 解釋器,該解釋器說明了計(jì)算機(jī)是如何運(yùn)行 Ruby 編寫的程序的。

此次會議的目標(biāo)之一是允許參與者直接為下一版本的 Ruby 解釋器貢獻(xiàn)代碼。

隨著 Ruby 3 的發(fā)布日益臨近,非官方計(jì)劃是在 2020 年,很明顯 Matz 希望繼續(xù)提供一種工具,幫助程序員專注于編程有趣和令人愉快的方面。

與松本行弘(Matz)談話的時候,我注意到兩件事情。首先,他會盡一切努力讓 Ruby 存活下來并發(fā)展;其次,他非常享受自己在做的事情。他對 Ruby 及其社區(qū)充滿熱情,而他的外表看起來很簡樸:編程是一件有趣的事情,在過去的 25 年中他玩的很開心,現(xiàn)在他已經(jīng) 52 歲了,他希望在未來的 25 年中,可以繼續(xù)快樂地為這門語言工作,這個他夢寐以求并在 17 歲時在一個筆記本上寫下的語言。

責(zé)任編輯:未麗燕 來源: 程序師
相關(guān)推薦

2010-03-10 19:46:07

Python編程語言

2015-10-09 10:30:38

TIOBE編程語言排行榜

2017-02-24 19:08:48

PythonPHPRuby

2020-05-07 10:02:46

編程語言JavaC語言

2020-12-08 11:01:42

JavaScript編程語言開發(fā)

2022-07-25 17:44:59

編程計(jì)算機(jī)

2014-11-26 10:49:32

編程語言

2015-02-09 09:51:06

2009-07-21 10:04:57

Scala編程語言

2009-10-05 09:46:12

編程語言排行榜Ruby

2012-11-09 08:58:29

Ruby編程語言動態(tài)語言

2014-11-26 09:40:02

編程語言Ruby

2014-09-16 13:40:23

諾基亞

2020-01-21 22:08:05

編程語言PythonJava

2009-01-12 08:48:04

2012-11-07 09:41:30

2017-10-09 08:45:13

編程語言Amazon AtheSharePoint

2016-05-09 10:35:50

編程語言排行榜Ruby新高

2012-08-23 09:28:01

編程編程語言

2023-03-22 14:04:00

編程語言PythonPHP
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號