微軟是如何使用C#重寫C#編譯器並將其開源的

Roslyn是C#和Visual Basic.NET開源編譯器的代號。這篇文章將介紹它是如何從微軟過去的十年至暗時刻走出來,成爲開源跨平臺的C#和VB公共語言引擎。

我於2005年加入微軟,也就是在.NET 2.0發佈之前,當時微軟內部已經開始在討論Roslyn項目,這個項目是關於使用C#重寫C#編譯器。這對於一門編程語言來說是一件很正常的事情,證明語言已經開始成熟。但我們的動機則更爲實際:作爲C#的創建者,我們並沒有使用C#編程,而是用C++!

要重寫一個用戶已經使用了好幾年的編譯器,關鍵問題在於用戶會希望新編譯器的行爲方式與舊編譯器完全相同。爲C#開發新的編譯器意味着需要匹配舊編譯器的缺陷。我說的不只是已知的缺陷,也包括那些未知的缺陷,以及開發人員已經發現並嚴重依賴的無意識行爲,這些通常是在不知情的情況下發生的。

多年來,這些挑戰導致我們無法開始這個項目。

雖然使用C#編寫新的C#編譯器會給語言團隊本身帶來很多好處,但這樣能給用戶也帶來價值嗎?新編譯器如何給現有的用戶帶來幫助?也許唯一關心是否使用C#編寫C#編譯器的人就是編譯器開發團隊本身。

但與此同時,我們面臨着另一個越來越嚴重的問題:基於C#的不同工具之間的存在大量的重複性工作。除了編譯器,我們的姐妹團隊在爲Visual Studio提供C# IDE支持,他們必須通過編寫大量的代碼(他們當時主要也是在用C++)來理解C#的語法和語義。

除此之外,還有很多來自微軟和其他公司的工具,如StyleCop、CodeRush,等等。這些工具都需要實現與C#源代碼文本相關且對用戶來說有意義的功能,並且都存在一些微妙的錯誤。它們對一些概念的理解處於不同的水平上,而且需要做出不同的折中和權衡。所有人都需要花費大量的精力來理解代碼。

最後,我們提出了我們的價值主張:我們只需要一個C#代碼庫,並把它共享給任何一個想要基於代碼庫構建工具的人!可用工具的增加將給用戶帶來價值,特別是現有工具質量的提升。我們將語言正確性和性能方面的需求集中在同一個代碼庫上,並努力提升質量以及添加大量的功能。我們將會構建出一個語言引擎!這將爲C#代碼提供統一的公共API:我們將重新定義“編譯器”的含義。

當然,既然你在爲C#社區構建API,它就應該是使用C#實現的.NET API。因此,使用C#“引導”C#的老想法藉助這個機會得到了實現。

可以說,Roslyn的誕生就是始於這種開放的心態:向世界開放C#語言的內部開發工作。在微軟的封閉文化中,這本身就是一個大膽的主張:我們會免費分享這個知識產權嗎?我們會助力那些工具開發商更好地與我們展開競爭嗎?

我們希望增強生態系統併成爲世界上最好的工具語言的想法最終贏得了勝利。我們想要的是C#和.NET的長期增長,而不是爲了短期變現和保護微軟資產。因此,雖然說不上是開源,承擔Roslyn項目的成本和風險對於微軟來說也是一個重大的抉擇。

當然,你不一定只是構建這些東西。Roslyn有着雄心勃勃的願景,充滿了技術挑戰,我們花了五年時間才實現。

在我們構建初始版本時,Roslyn仍然是一個閉源項目。從2009年項目啓動以來,我們一直希望我們的編譯器是開源的,但微軟還沒有爲開源做好準備。開發私有代碼並提交專利的文化代表了微軟自20世紀70年代以來的工作方式——雖然變革已經在悄然發生,但速度比我們團隊所希望的要慢。

事實上,曾經有一段時間,我們感覺公司正朝着完全相反的方向發展。

Windows 8項目幾乎佔據了整個公司的資源。因爲採用了新的編程模型,其觸角已經觸及到開發者工具和語言團隊的內部,所有的東西都被極端地保護起來,而且不僅僅針對外部,甚至也針對公司內部。例如,我們當時開發的異步功能融合到Windows 8的編程模型中,我甚至不敢在內部發表設計說明,因爲擔心會意外泄漏有關Windows 8的信息讓自己陷入麻煩之中!這給創新造成了一個糟糕的環境,對於我們開放C#編譯器的願望來說,這當然不是什麼好兆頭。

最終,在Windows 8步入正軌之後,微軟開始轉型並找到了新的方向。它的核心理念變得與原來完全不一樣了,也就是我們今天所知道的微軟。開源運動現在開始在微軟內部佔據一席之地。

F#已於2010年發佈,基於開源許可,並提供了自己的基礎——F# Software Foundation。圍繞它而成長起來的一個充滿活力的社區讓我們所有人都感到羨慕。我們的團隊強烈要求爲Roslyn提供開源許可,最後,在公司範圍的出現了一個致力於實現這一目標的基礎設施。

2012年,微軟成立了Microsoft Open Tech,一個專門關注開源項目的組織。Roslyn轉到了Microsoft Open Tech之下,並正式成爲開源軟件。Roslyn是一個非常適合開源的候選項目:開發者都是內部有名的開發者,而且項目本身很獨立,沒有太多的依賴,不太有可能造成許可衝突。

2014年4月,在舊金山舉行的微軟“Build”開發者大會上,Anders Hejlsberg將Roslyn作爲開源項目進行展示,並於4月3日基於Apache 2.0許可發佈在了CodePlex(微軟之前的開源託管平臺)上。

與此同時,.NET Foundation成爲包括Roslyn在內的.NET項目的家。

開放爲微軟帶來了是一股清新的空氣!在我們開始從CodePlex的開放性中獲得好處的同時,微軟也理順了其餘的開源障礙。今天,開源已經成爲我們團隊工作的一個直接且不可或缺的部分。

此外,在其他方面,微軟意識到我們不需要控制一切。很明顯,我們可能不需要CodePlex了,Roslyn加入到了從CodePlex遷移到GitHub的項目行列,GitHub是當時事實上的開源之家。不僅僅是源代碼,就連構建過程都搬到了GitHub上:它不只是個發佈代碼的地方,我們把它當成工作的地方。

C#語言設計和編譯器實現的流程現在是完全開放的,有很多微軟以外的實體或個人參與,包括由外部貢獻者構建的全語言功能。C#的價值是巨大的,不僅僅在於通過添加新功能和錯誤修復來發展項目,還包括我們通過開源提供的即時反饋閉環來獲得見解和發展路線修正。

這是一段漫長而瘋狂的旅程,在我看來,這是微軟在過去十年中所經歷的一個巨大的變化。Roslyn從至暗時刻走出來,開放思想讓它茁壯成長,並通過開源的力量演化成了現在這種具有廣泛用途的項目。

Roslyn和C#語言設計相關資源:

https://github.com/dotnet/roslyn

https://github.com/dotnet/csharplang

查看英文原文:https://medium.com/microsoft-open-source-stories/how-microsoft-rewrote-its-c-compiler-in-c-and-made-it-open-source-4ebed5646f98

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章