一直以來OpenStack都只是用Python編寫的，別的語言不是沒用只是用到的很少，核心部分幾乎都是Python，現(xiàn)有人提議讓Go語言也用在API服務(wù)方面。

在新版本Newton出爐的周期中，技術(shù)評估委員會接到了一份把Go語言作為OpenStack官方開發(fā)語言的提議。隨后進行了許多討論，這里不過多贅述過程，只是談?wù)剮c討論的結(jié)果。

決議是暫時拒絕讓Go作為官方開發(fā)語言，但表示未來可以接著討論，我覺得Go被拒絕可能有以下幾方面的原因：

1.技術(shù)委員會成員擔(dān)心增加新的語言會對社區(qū)造成的影響。會不會對社區(qū)帶來分裂，會不會形成一個孤島，會不會給新入門的人帶來額外的門檻？

2.技術(shù)委員會的一些成員認為如今對社區(qū)中的一些方面缺乏信息，研究和工作。 Go代碼如何在整個社區(qū)中共享？ 認證怎么做？ 消息層怎么弄？ 如何產(chǎn)出版本？ 如何維持分支的穩(wěn)定？

3.提議Go語言的團隊除了自己的項目以外根本就沒做過跨項目的任務(wù)，這不由得引起了懷疑，使得許多技術(shù)委員會的質(zhì)疑是否能夠順利完成。

接受一門新的語言需要哪些條件呢？

我先聲明，我所說的不代表技術(shù)委員會而僅代表我個人意見，從而方便交流，好會讓整個社區(qū)的人發(fā)表意見，無論是同意或者反對我的想法。

討論期間我最關(guān)心的是第一部分，主要是因為我覺得向“Big Tent”的遷移還沒完成。我也不知道怎么才會讓我覺得這遷移已經(jīng)完成了，我能肯定的是我們在解決大的變化發(fā)生前需要解決的問題。

言歸正傳，我越來越喜歡給許多東西設(shè)定期望，尤其是一些能帶來改變的請求。把預(yù)期列出來之后，就能讓相關(guān)的人了解到他們正在向哪一個方向行進，并且找到改變可能會面臨的問題。

我對第二個問題遠沒有第一個問題那么擔(dān)心。它會對參與討論這一變化的團隊表現(xiàn)出很強的承諾，因為這涉及到未來對社區(qū)所有成員使用和參考的基礎(chǔ)知識庫。我以為第二部分的工作可能有些超綱，但并不是這樣。通過研究怎么共享代碼，怎么測試代碼，怎么輸出代碼，怎么做認證庫等，我們在設(shè)定未來實際工作中需要用到的基礎(chǔ)的東西。

無論如何，我上面提到的“基礎(chǔ)的東西”是什么呢？我將在下面不太詳盡的列表中簡單談一下：

為新語言定義分享代碼和庫的方式

Oslo Team負責(zé)維護整個OpenStack社區(qū)需要經(jīng)常用到的庫。這些庫包括消息庫（oslo.messaging）,i18n庫（oslo.i18n），數(shù)據(jù)庫層庫（oslo.db）等關(guān)鍵庫。

這些庫本身并不能讓Oslo組的人忙起來，它們是為了收集以前在社區(qū)中存在于許多項目中的重復(fù)性的公共代碼。這個代碼現(xiàn)在由Oslo移除，穩(wěn)定和發(fā)布。

我覺得作為一個社區(qū)，這是無可避免的。一旦越來越多的項目使用相同的語言就會出現(xiàn)共享代碼的需求。 因此，我覺得我們需要更好地定義一個編程語言的代碼怎么在社區(qū)共享，這個挺重要的，哪怕是在編程語言被接受之前就很重要。

我覺得提前做一些事情不意味著將來沒事可做，我們都知道會有許多為預(yù)料到的事情和發(fā)生變化的事情，我覺得這些工作能涉及到大部分初始化的工作。

關(guān)于OpenStack基本服務(wù)的基本庫

這可能看起來像一個相當(dāng)高的目標(biāo)。雖然想搞清楚代碼如何共享是一個很困難的需求，但我認為這離OpenStack服務(wù)的最低要求還差很遠。

集成在生態(tài)系統(tǒng)中的OpenStack服務(wù)至少需要以下任意一個庫：

·keystoneauth / keystone-client

·oslo.config

·oslo.db

·oslo.messaging

如果在使用數(shù)據(jù)庫或者消息隊列抽象庫的時候沒有任何消耗的話，很可能提供的抽象層是錯的，從而導(dǎo)致糟糕的API。從另一個方面說，認證層是幾乎所有OpenStack服務(wù)都會用到的部分，應(yīng)該可以很方便使用才對，但這不是說這件事本身很簡單。

通過處理這些庫中的任何一個，都可以測試CI作業(yè)，通過這些作業(yè)來確保新項目的基礎(chǔ)設(shè)置是正確。

定義可交付項如何分布

OpenStack的發(fā)布過程幾乎完全是自動化的，發(fā)布過程中涉及到的所有可交付項都是由社區(qū)自動產(chǎn)出并由發(fā)布團隊來管理的。最后，將每個交付項生成壓縮包。

目前使用Python編程語言（以及其他幾門編程語言）的時候 ，這些壓縮包因為只包含這些源代碼所以還很簡單。對于像Go這樣的編譯型語言，我們就得考慮壓縮包里要壓縮什么了，壓縮編譯過的二進制代碼嗎？是不是應(yīng)該加入源代碼呢？如果要包含二進制代碼，是不是也應(yīng)該考慮兩種不同的壓縮包呢？一個是二進制代碼，一個是源代碼。

維護穩(wěn)定分支部分的工作怎么辦？

穩(wěn)定的分支在社區(qū)經(jīng)常被遺忘，維護這些穩(wěn)定分支的團隊得到的感謝比較少。然而穩(wěn)定分支的代碼運行在許多OpenStack云環(huán)境下，它們對于向后兼容的后端遷移修復(fù)非常關(guān)鍵。

每一門語言都有自己發(fā)布庫的方式，管理兼容性的方式。當(dāng)為社區(qū)加入新的編程語言，與原有的其他團隊之間的合作是至關(guān)重要的。

為新的語言設(shè)置CI管道

還有就是與基礎(chǔ)設(shè)施組討論設(shè)置CI管道。

這個任務(wù)可能是許多工作的基礎(chǔ)。為了解決之前的許多任務(wù)，有必要設(shè)置CI作業(yè)，這涉及與基礎(chǔ)架構(gòu)團隊協(xié)調(diào)。后者是至關(guān)重要的。 基礎(chǔ)設(shè)施團隊的參與對于添加任何新語言都至關(guān)重要，他們的反饋將在許多決策中發(fā)揮重要作用。

回顧一下為Python語言做的一些基礎(chǔ)工作，其實是大多數(shù)項目都需要做的事情。我希望致力于加入新語言的團隊可以做一些通用性的事情，為以后跨多個項目的時候使用。

比如會有以下幾方面的通用性工作：

·Lint checkers

·Doc builders

·Release Pipelines

要做的似乎還有很多

把上面提到的方方面面都做到的話的確需要許多人力和時間。不幸的是，涉及到的許多團隊真的騰不出手來做別的事情了，所以我覺得大部分工作將會由各組里多語言感興趣的人來貢獻出來的。無論如何，這些工作勢必耽誤每個團隊的工作時間，即使是大部分的研究，文檔和補丁都是由有興趣的團隊來自愿完成的。

整個社區(qū)花了多年時間讓Python處于目前的狀態(tài)。我不指望一個團隊工作一個禮拜來把新的語言代碼加入到已經(jīng)用了六年的Python體系中。然而，機制已經(jīng)建立，團隊也已經(jīng)存在，在一起協(xié)作下，上述的問題可能會在合理的時間點得到解決。

我希望這是個循序漸進的過程，這就是我為什么強調(diào)需要經(jīng)過以上幾個步驟的原因。人有流動性，即使是做過承諾有時候也不管用，我認為做這是最重要的是先做，然后在漸漸接受這門語言。

最后，即使存在一個形式良好的添加新語言的過程，我仍然推薦優(yōu)先使用Python而不是其他語言。這與語言偏好無關(guān)，只是與我們社區(qū)中現(xiàn)有的知識的傳播有關(guān)，我相信這種知識是無價的，將這些知識變成一種新的語言需要幾年時間，相比之下優(yōu)化則是一個更容易的任務(wù)

創(chuàng)新對很多項目都很重要。我們也相信不可能永遠保持原樣，語言的變化，項目的興起，項目的消亡等等。加入新語言這回事兒也是社區(qū)變化 的一部分，我也希望OpenStack社區(qū)盡可能以最好的方式擁抱變革。但我希望是以一種相對保守的方式。我相信本文中提到的這些任務(wù)將會幫助大家未來以更快、更安全的方式來增加新的語言。

當(dāng)然，以上都是我的個人觀點，我現(xiàn)在越來越癡迷于明確預(yù)期。因此，我會起草并提交一份正式文檔到技術(shù)委員會。