2019年了，C#發展的怎麼樣了呢？

C# 8.0

我估計大多數程式員對於C# 5.0之後的改進都沒有什麼太多的認知，的確從C# 5.0開始C#已經沒什麼太多東西可以從其他語言借鑒，Anders的重心也開始逐步傾斜到TypeScript，所以從5.0引入async之後C#語言發展速度開始減緩了。

C#6引入了大量的語法糖，例如?.和$””等等都是6.0引入的，這些東西極大的簡化了C#的語法，而C#7.0則進一步的引入了元組、殘破的樣式匹配支援和本地函式以及意義深遠的ref和readonly支援的擴大化，ref和readonly ref使得Span系列型別得以引入從而改善了特定場景的效能。更重要的是這些語言層面上的改進使得類庫作者可以寫出特定場景的高效能程式碼而避免引入C/C++。至於out變數宣告和throw運算式則是早就該加入的東西並沒有什麼太多的懸念。

值得註意的是7.0開始搞出了小版本號的概念，C#7事實上有四個版本，C#7.0、7.1、7.2和7.3，

C#8.0將在2019年釋出，主要的改進包括一個破壞性修改，可空取用型別，估計屆時要啟用這個特性需要加編譯引數，或者可以用編譯引數遮蔽這個特性。這個特性據說是從Kotlin借鑒過來的，這怕是C#出現18年來第二次從Java陣營借鑒（第一次是誕生）。

其他的改進則有相對完整的樣式匹配支援（雖然還很醜，而且沒有UnionType/SumType還是殘廢），以及介面預設實現方法（這個倒是Java發明的，用來取代C#當年的擴充套件方法的用途，然後被C#再抄回去）。語法層面上async stream和Range可以大大簡化特定場景的語法。

.NET Core 3.0

很明顯微軟現在將重心放在了.NET Core這一邊，當然.NET Framework歷史包袱太多，如果我是微軟的程式員也願意把精力放在.NET Core的框架開發上。結果就是.NET Framework 4.8一直難產，而.NET Core則一路高歌從1.0演化到3.0。

為了平滑的遷移現有應用程式，微軟在.NET Core上重新實現了大部分的.NET Framework的API，當然GUI的除外，儘管如此微軟還是提供了GDI的部分API的實現也就是System.Drawing。

而http://ASP.NET部分則因為歷史包袱太多被全部重寫，事實上我非常贊成這一決定。儘管http://ASP.NET Core是全部重寫的，但是Razor和MVC的大部分語法和功能被保留下來，所以原有MVC的應用也能輕鬆遷移。不過，Razor的helper功能被移除仍然讓我非常不爽。

新的TagHelper我認為是非常正確的道路，而事實上這就是十年前我的Jumony for MVC嘗試做的事情。

平臺/生態

最後聊聊平臺和生態。

事實上C#和Java就是一種語言……基本上你可以認為這兩者的親緣關係就像是JavaScript和TypeScript。所以說如果你會C#那是沒有道理看不懂或者寫不了Java程式碼的。當然反過來會有點麻煩（如果你會Kotlin的話，可能更有助於學會C#）。這就像你會TS肯定能看懂JS一樣……

所以糾結語言是沒有什麼意義的，C#和Java的主要差別在於庫函式，這也是目前阻礙兩邊程式員跨界的重要因素。Java嗶一樣的語法很多時候並不是我最難以忍受的，更難以忍受的是嗶一樣的基礎類庫。

在BCL這一塊，微軟是毋庸置疑的Top 1。當然，在網際網路時代，微軟的老派作風使得對新技術和新思想的響應速度不如開源社群，尤其是對Linux和開源社群並不明朗的態度，這使得.NET誕生的這十幾年來一直未能取代Java，甚至讓後者做大做強。

開源的精神內核是開放，作為一個老派的程式員（掐指一算入行都二十年了），我覺得開放的心態是我還能活躍在一線寫程式碼的原因。Java開源社群有很多好東西，也經過了很多專案的檢驗，.NET其實也是可以用的，畢竟，其實C#本來就是從Java改進而來，他們之間的共同點比差異多太多了。互操作性也遠比其他語言容易得多，他們都是把元資料嵌到程式集裡面的。

我現在做.NET Core的應用，用Eureka和Consul做服務發現，用apollo做配置中心，所有這些都不是C#寫的而是Java寫的，但這絲毫沒有任何問題。開源的生態本來就是開放的，在我看來，未來是各種語言混合互操作的天下，雖然和.NET最開始的願景在細節上有些偏差。但是我認為未來本來就不會用生態和語言來劃分程式員……