大膽推測:未來的王者,或屬於C#

大膽推測:未來的王者,或屬於C#

這個世界,自古是用戶驅動資本,資本驅動變革,變革造就生態。

最後更新 2022/4/16 下午10:33
邪恶的二进制
預計閱讀 10 分鐘
分類
.NET
標籤
.NET C#

這個世界,自古是用戶驅動資本,資本驅動變革,變革造就生態。

遙想當年,DOS 程式設計師瘋狂鄙視拖滑鼠操作電腦的行為,彷彿可視化操作,就是在離間程式設計師與機器之間的關係,所有的程式設計師都以了解多少中斷指令為榮,覺得這就是未來的密碼,但後來大家都知道,可視化的 Windows 系統風靡世界,老百姓沒人願意麻煩,選擇了它,然後程式設計師不得不改行,學習 Windows 下的程式設計,改為背誦 Windows 下的訊息類型。

是原來的 DOS 技術棧不好嗎? 我覺得 TC2.0 也很好用,但沒有用,一個技術棧、或者叫生態,必須有承載的抓手才行,很遺憾,可視化的作業系統革了第一代 DOS 技術棧的命,或者說底層技術和使用者選擇革了第一代 DOS 技術棧的命, 以此為代表的 Tourb 系列,很優秀的情況下,不知不覺就沒人用了,這一點,很像科達。

Windows 作業系統的橫空出世,引來了 PC 時代, 單機遊戲,家庭影音,工程計算等等, PC 時代的需求,造就了 PC 時代的單機程式的型態, 以此 VB、VC、VF、Delphi 大顯身手,拼單機性能優化,開發簡潔度,以一個程式論英雄,關鍵是,使用者關心和喜歡這些,那個時代,如果魔獸爭霸啟動要個 1 分鐘,那肯定就沒有後面魔獸世界什麼事情了。那些技術,就是那時候的生態,現在不用了,不是這些技術過時了,而是承載這些應用層的使用者模式過時了,換句話說,過時的是 PC 的時代,而不是這些技術,其實有一些底層技術,當年的研究成果目前依舊為大佬所用,只是普通應用層開發人員不用而已。

Html 誕生於 1990 年,Java 誕生於 1994 年,為什麼這些語言在開始的 10 年間不溫不火,用得人也少,那是因為它們是為下一代而生,雖然具有前瞻性,但是決定他們地位的底層時代還沒有來。當時很多用的人,也是抱著嚐鮮的態度去用,用完就一陣愜意吐槽,與 C/C++相比性能太差,啥也不是云云, 現在看,群眾的眼睛,也未必是雪亮的。

時間一晃到了 2007,智慧型手機橫空出世...

老百姓告別了大哥大,突然發現這個東西可以,我喜歡,比電腦高級、方便,還顯檔次,於是不懂技術的老百姓們再一次決定了 IT 技術的新時代,即網際網路時代的到來!

網際網路時代的兩大特徵:

一、前端設備多樣化、版本碎片化 ;

二、互動業務複雜化、服務端業務承載巨量化;

這兩個特徵引發的新訴求,直接把曾經在 PC 上橫著走的技術棧(VB、VC、Delphi 們)打懵了。

面對客戶端: 那些一個個貌似能精確到指令級調優的靜態編譯程式,一下子要編譯好幾個版本,甚至好十幾個版本才行,而且部署還經常因為系統環境缺斤少兩而報錯,然後使用者一陣罵,什麼破玩意。

面對服務端:之前在互聯、通訊,承載巨量資料處理、集群化關聯上,由於不是重點,並沒有相應的研究。

然後大家就懂了,你很優秀,但是我們不需要你了,那個時代的英雄們,該落幕了。

反觀 Java 和 Html,這兩位小兄弟,由於一開始就跨平台的設計,而且本身就為通訊載體的設計,在網際網路時代,諸多優點立馬顯現,於是,鹹魚翻身,青銅變成了王者,那時候還沒有人把 Java 捧上天,更沒有人對 Html/JS 盲目崇拜,但是大佬們都開始研究,研究它們怎麼更好地落地為網際網路時代,好用的解決方案,於是新的生態開始形成...

微軟這次似乎有些後知後覺,雖然比爾蓋茲最後也看到了未來,90 年代末開始瘋狂挖人,但是直到 2002 年,才出了.NET 1.0 第一個版本,關鍵是它面向這個時代的底層用途,Java 已經實現。

競品之間,如果大致相同,那就不是降維打擊,不是降維打擊,那就拼細節!

PK1: 面向 PC,.Net 完勝 Java。 (但是無關緊要,因為 PC 時代要沒了)

PK2: 跨平台, .Net 慘敗 Java。 (大家都說 .Net 跨平台是罪過,其實不是,那時候 Windows 平台在網路伺服器上的表現太差才是罪過,收費 + 不穩定,誰用?)

PK3: 面向行動端,.Net 完敗 Java (特指,2002-2016 這個時代)

PK4: 有以上三點,往下還重要嗎......

於是,大的環境理所當然趨向於 Java, 很多人開始學 Java, 屬於 Java 的王者時代終於來臨。

於是在中國, 一個很神奇的邏輯開始產生,Java 強,是因為學 Java 的人多,Java 的生態好, Java 可以抄的解決方案多.....

但是技術領域,話語權永遠在底層技術上,單純的應用層生態上,再怎麼優化、豐富,也是量變,不是質變。

底層技術造就新的使用者型態,引發底層革命,同時就會毫不留情地革了應用層技術的命,不管你願意還是不願意都是如此; 而不幸的是,Java 和 C# 以及後面的 Python、GO 都只是應用層語言,其實本身在面對時代的降維打擊時,都沒有話語權。

2008 年,雲概念開始產生,而後人工智慧, 2020 年疫情爆發,又引發了虛擬化的熱潮, 目前,元宇宙的概念如火如荼,這說明,這個躁動的世界,又開始要變了。

未來,肯定是一個高度人工智慧化的雲世界!

為什麼這麼說呢?

第一、百姓們不喜歡聰明的機器嗎? 答案肯定是熱烈歡迎。

第二、百姓們不喜歡更加真實的虛幻體驗嗎? 答案肯定是非常喜歡,甚至沉迷不拔。

第三、靠目前的框架,每個公司自己實現人工智慧應用現實嗎 ? 答案肯定是不現實,未來只能調用智慧雲供應商的雲端接口。

第四、人工智慧支撐起的未來物聯網世界,你不嚮往嗎? 答案是打死我都不信,我反正是很嚮往。

於是乎,你會發現,未來寫程式,慢慢開始傾向於調用雲端接口實現功能, 然後慢慢甚至開始調用雲端界面、雲端功能、雲端系統...

你可能會問,大佬們為什麼這麼願意發展雲? 兄弟們,雲可是按次數、按時長收費的,你的用戶量一上來,這麼盆滿缽滿,而且還有競爭門檻的事情,誰不願意幹,資本為何不願意砸錢?

所以,我們現在看到了國內外大佬們在雲領域、人工智慧領域的瘋狂廝殺,而且現在感覺好像沒我們太多的事,那只是因為他們地位還不穩,基礎還不牢,所以還不敢露獠牙太早。

回歸主題,真正的未來世界來到時,我們需要什麼樣的語言?

答案肯定是與智慧化雲時代契合的語言, 然後回頭再看,面對未來時代,Java、C#,Html5 現在所有的跨平台優勢,還重要嗎? 我想未必,因為這些優勢會淪為曾經的 C/C++ 靜態編譯的性能優勢一樣, 很棒,但是不重要。

2010 年, 微軟開始搞 Azure 雲平台, 2016 年,微軟開始搞.NET Core ,跨全平台, 然後貌似一下子願意犧牲版權、放棄只對 Windows 加持,然後好像突然變得開源、包容、免費了,而且還不遺餘力優化性能,一個版本一個版本持續更新,目前都更新到.NET 6,然後立馬又搞.NET 7, 為什麼?

有人說那是微軟為了抗衡 Java, 佔領開發市場。

這麼說,對,也不對,表象上是對的,但是實際上,現在這種環境下,不計成本對抗 Java,有什麼好處, 賠本賺吆喝?

而且,有沒有發現,在.NET Core 包括新的.NET 5, .NET 6 ...的版本中,微軟對雲端開發支援的比重在快速增加,高調宣傳, 在開發工具層面,微軟甚至是要抱著賠本也要打造好的決心,甚至在行動客戶端,.Net 也開始幾乎全平台支援,甚至包含 iOS 這種封閉的系統,微軟都不放過, 而在服務端,.NET Core 性能的持續優化,框架打造有目共睹,不斷提升...

顯然,近幾年畫風突變的.Net 戰略是有深層次原因的, 這是微軟在為未來的雲時代、元宇宙時代做鋪墊,現在與 Java PK 勝敗與否,微軟甚至都不是十分在意,關鍵是打好基礎,立足未來

人工智慧的雲時代到來, 現在所謂的服務端,將淪為雲時代的接口調用客戶端, 現在基於網頁的 2D 客戶端,很有可能被基於虛擬現實的新的 3D 瀏覽器代替!

所以前後端又一次面臨新的革命,在那個時代,眾雲雲集,虛幻與現實交錯, 現在的 Html5 和 Java 沉澱的厚厚的生態還重要嗎? 只能再套用一次台詞:對,很優秀,但是不重要

於是,C# 與 Java 又一次站在了同一起跑線,而這次,甚至 C#還佔了些先機,Html 可能最慘,因為它所依賴的 2D 瀏覽器生態在 3D 化世界可能都會被邊緣化,沒有了土壤,Html 可能被徹底革命掉。

而這一次比拼,細節發生了根本變化:

細節 1: 跨平台 C# 平 Java

細節 2: 簡潔高效 C# 勝 Java

細節 3: 雲生態 C# 勝 Java (.NET Core 內建對雲支援)

細節 4: 3D 層生態 C# 勝 Java (C#低迷時代,就是靠 Unity 3D 的開發,支撐起了一片天)

相比之下,優勢如此明顯, 未來,持續性的戰略加持,國外大佬們重新實踐,全新的元宇宙生態,便會悄然崛起,而當這一生態傳導到咱們這邊,有可能你會驚奇地發現,呃,這一次的王者,竟然是 C#了。

當然,萬事萬物都在發展,每種技術也都會自我革新,還是那句話,至於最後誰是所謂的王者,其實還是得看誰承載的技術底層,更貼近用戶,更引領未來!

語言好壞,與語言有關。

語言成敗,與語言無關!

本文來自轉載

原文作者:邪惡的二進制

原文標題:大膽推測:未來的王者,或屬於 C#

原文連結:https://zhuanlan.zhihu.com/p/499713602

繼續探索

延伸閱讀

更多文章
同分類 / 同標籤 2026/2/7

AOT使用經驗總結

從專案建立伊始,就應養成良好的習慣,即只要添加了新功能或使用了較新的語法,就及時進行 AOT 發布測試。

繼續閱讀