為什麼沒有新的支持底層達到類似C++這種程度，而易用性達到C#的語言出現？

01-06

之前的描述：
有些玩家麻煩看完問題再做評價！！！我寫都不覺得麻煩，看都嫌麻煩？
下面是問題原文描述（完了還有一個補充更新的 helloworld 常式描述這個原始的問題描述）：
vm語言(java,C# 類似的等等)大行其道的今天，程序員們嘗盡了vm語言的各種好處(內存管理,語法精簡幹練，特性先進)。而最大的好處莫過於開發效率的提升（從個人到團隊）。然而，vm語言也存在著種種限制，比如對底層的支持幾乎為0。基本上C#這種語言最低也就支持到系統API層面了，而且PInvoke也有點繞，遠沒有標準的dll或者lib調用來得直接效率。
剛開始學C#的時候就覺得為何C#不能像C++那樣呢？是真的不可能嗎？

好多年了一直在關注C#的變化，直到近期終於等到了 .net native。
然而，.net native 要跑在Desktop環境似乎困難重重。
雖然看FAQ中似乎有希望，但是微軟的話能相信幾何還是很難說。
Microsoft .NET Native 常見問題

伺服器/桌面應用是否將受益於 .NET Native 和/或雲中的編譯器？
桌面應用是我們策略中的非常重要的部分。最初，我們的重心是 Windows 應用商店應用與 .NET Native。從長遠來看，我們將繼續改進所有 .NET 應用程序的本機編譯。

另一個顧慮，儘管.net native 似乎有跡象表明C#似乎距離底層能夠更進一步。
然而從.net native 的實現來說。雖然我不懂編輯器也不太懂語言底層。單就從官方給的這張圖來說，單憑我這門外漢的感覺也太複雜了，簡而言之就是實現太繞！
App IL + FX -&> MCG　-&> Interop.g.cs -&> CSC -&> Interop.dll -&> Merge -&> IL transform -&> NUTC -&> RhBind -&> .EXE(摘自csdn 某博客)
(截圖來自 Inside .NET Native)

如此之繞的結構即使.net native 出來了恐怕也很難。
想像一下其實一個典型是 XNA 就繞了不少灣路，雖然想法不錯，然而最後以停止更新，不推薦使用宣告失敗。
也就是說即使.net native 做出來了也可能因為對底層依然不夠友好，對其他語言不夠友好，而導致 native化的效果非常有限。(移動平台省電問題另說)
其實在我關注C# 的 native 的同時也已經將目光放眼於其他語言。
包括 golang dlang（go語言,d語言）
其中d語言是我比較喜歡的風格更接近於C++java。
然而d語言由於缺少大公司做後台支持，發展相對緩慢(升D2版本時候D1 被徹底推翻)。
而之前傳出的M#語言(據小道消息是會開發新的操作系統M系統的語言) 最近也沒戲了。而且編譯器也就是現在的開源編譯器 dotnet/roslyn · GitHub 基本上也就是是M#沒戲了。
難道將C#做成C++那樣底層就真的很難嗎？如果我們真的很想調用個 local native 的dll或者靜態的.lib 或者引用個.h 又或者想用C# 開發個驅動。
放眼望去在不久的將來誰能扛起這面大旗呢(底層的支持+高級的語法)？

是C# native 還是 D語言？或者go語言？swift ？還是一顆藏在暗處默默奮鬥還未發光的新星語言？
|
2015-12-29 更新問題描述：
感謝給位答主參與討論,其實我的要求一點不過分，寫個helloworld.cs 你就懂了：
using System,System.Text,System.io;//調用C#類庫的命名空間 using stdlib.h,dx11sdk/d3d.h,std,iostream,winmm.lib; //注意這句！！！ //(當然這裡像include winmm.lib 這種也可以考慮放在在C# dll 引用的地方) namespace myapp { public static class class1 { static void main() { var csharpstring ="C#字元串"; System.Console.WriteLine("C# Helloworld!"); //調用C#原生類庫 @C.cout &<&< "C HelloWorld!!!" &<&< endl;//直接調用C類庫的函數 @C{ cout &<&< @#csharpstring&<&< endl;// 直接調用C的函數輸出 C#的變數！ } //內嵌asm @C { mov eax,0x789;//asm不是很懂隨便寫了點 mov edx,0x689; xor eax,edx; ... } Console.WeiteLine("write done!press any key exit!"); Console.Readkey(); } } }
實現上面這樣的有多難，Golang 暫時做到了！！！！

樓主你一定沒有寫過編譯器吧

問你個簡單問題，假如你想讓某個有 GC 功能的語言方便地調 native，那麼兩者之間互相戳的指針要怎麼處理？如果你 GC 還是那種分代、會移動對象的怎麼辦？

如果不用 GC 的話，那不就回到 C++ 的老路了嗎？說好的易用性呢？

提問者自己先定義清楚什麼叫做底層支持吧。

所謂的什麼VM語言底層支持為0類似的觀點我聽多了，就是沒有一個人能說清楚他所說的底層是什麼。

如果你要直接讀寫內存區域，那還要VM幹什麼。

受限的直接內存操作C#也不是不能做。

你說要無縫調用C++、C的介面，也不是沒有相應的介面層來解決。

就算是unmanaged pointer也能在C#裡面進行操作，只是通常用不到。

.NET Native解決的是內存佔用和耗電的問題，和底層訪問沒啥關係。

你說的什麼對其他語言不夠友好，我就真的奇了怪了C#和Java這種只差沒把介面文檔給整合在Assembly裡面的東西的介面到底還要如何友好？

===================================================================

補充一點好了，提問者問題中的底層支持其實指的是和C/C++的互操作性。

而這個問題是個歷史悠久的歷史問題了，我只能說互操作性的問題出在C/C++那邊而不是C#這邊。

自從Windows誕生以來微軟就在嘗試解決這個問題，每一次的嘗試都被噴成什麼試圖在語言里加入私有標準私有技術什麼的，如果你真的在意這個問題應該去看這個東西：

Visual C++ 語言參考 (C++/CX)

而不是指望C#能夠自動識別出來那個什麼char*到底是個什麼東西。

這是什麼弱智的問題……支持不支持底層和語言是什麼樣子毫無關係，問題是這個語言為什麼場景設計，以及這個語言希望支持什麼功能

重點是，有很多功能之間是相互矛盾的。比如說，你要易用性就不能複雜，不能複雜就必須把底層徹底封裝起來；比如你要GC要託管那就不能讓用戶自己直接分配和讀寫內存；你要追求最大性能那就不能有GC之類的功能，因為那些功能都是要常駐運行的，而這些東西最終都是需要佔用計算時間和資源的啊。

這就好像你找女朋友，漂亮的女生追的人必然就多，性格開朗的一定很早就交過男友，漂亮又聰明的必然要求你條件不能太差，等等……所謂你不能又讓馬兒跑又讓馬兒不吃草啊。

說回你的問題，你所要的條件是互相衝突的。比如C++11現在為了易用性把很多底層的東西封裝起來（比如智能指針之類），易用性的確好了，但有很多保守派就覺得傳統沒有這些東西的C++更好，一樣的。

你說你不懂編譯器也不懂語言底層，正是因此你才會問這個問題的。懂了你就不會問了。

看到題主的問題我覺得LLVM都快要哭了。

想做到zero runtime overhead的編程語言都比C++好不了多少。至於什麼D語言啊Rust啊都是越長越丑，還帶出來一大堆複雜的概念。

所以其實很簡單啊，看上去易用的東西其實是設計上的偷懶導致的，是要交稅的。

當然這話換個方式說也一樣，你看C++不也交了幾十年的兼容稅了嗎？

所以我覺得題主屬於想太多而並沒有動手過。不然也不會把最後那幾門完全不相關的語言列出來了。

就是這樣。

這樣的語言是奇葩。

首先語言和語言的表達能力上差異根本沒有想像的那麼大，c#等你覺得好用的語言有什麼獨有的特性是c/c++所不具備的，自動垃圾收集？做同樣的事情恐怕代碼行數都不少反多，不要把語言中針對特定領域增強的部分，特別是庫拿出來說話。

低層的核心是接近硬體，是給整個系統提供服務，希望語言較少的運行時負擔，儘可能高效。你以為就算c#內置彙編了就能幹些啥？一個用戶空間的程序最多搞點優化啥的罷了。連這種都不怕麻煩，那早該換語言才是。

說到底，你需要的東西不是語言層面去解決的，而是底層本身，是做系統和編譯器的那幫子的事。那些把棍子打到c/c++的人真是搞錯了對像。

rust，D。

maopao-691515082/coc-lang

我來給題主點正能量吧，雖然只是完成了前端和後端Demo，實際還有很多需要改進的項，但是可運行

沒有 VM，又要像 C#，那隻能建議題主玩玩 Vala 了（逃……

說白了，不就是互操作么，不就是想讓C#能夠理解C++對象，C++能理解C#對象，原生的C++是不可能實現的，因為兩種語言的類型結構完全不一樣。

最初的COM介面就是為了幹這種事情，之後微軟的一系列C++拓展也是為了幹這種事情，C++/WRL，C++/CX，用他們寫的dll，能夠生成winmd，其中就定義了C++類型如何映射到C#。

如果用原生C++，還可以通過寫MIDL(Microsoft Interface Definition Language)的方式告訴C#如何處理這些原生的C++對象。

說了這麼多，其實沒有什麼是不行的，你只需要告訴A語言，B語言的東西是什麼，相當於A語言的什麼，如何調用，其實就行了。

PInvoke本質上也是定義函數簽名，告訴託管環境如何調用非託管的東西。

不過，說起自動化，我覺得，要是能夠通過分析C++源代碼文件，自動生成MIDL，或者是通過頭文件自動生成PInvoke代碼，自動分析類，結構體，函數，並在C#中定義等價的結構體，這樣的話也算是完成了題主的心愿吧，也不用我拼死拼活寫一些Wrapper了。

不過，鑒於託管內存和非託管內存之間交互採用複製的方式，大量使用PInvoke性能也不會好。

如果託管內存與非託管內存能夠直接指針指過來指過去，嗯，我覺得離程序崩潰也沒多遠距離了。

rust/swift/objective c

nim lang

微軟有把C#直接生成機器碼的啊，但是那需要操作系統有獨特的支持，所以那群Researcher們又寫了一個操作系統，來跑那個特別的C#。

所以你要是不喜歡.Net Native，那所有的類似.Net Native的做法你都不會喜歡。話說實現的繞跟你又有什麼關係，你又不是微軟員工。追求易用性的其中一個前提，就是你別管他怎麼實現。

我是提問者，本來想更新一下問題描述的，但是奈何不得超過3000字，我怎麼看也沒3000字啊。。。

2016-12-16 更新:目前我已經轉golang, 基本已經能夠滿足我的要求了。。。可以在裡面嵌入C/C++代碼一起編譯。。。。且不需要 framework 且本身可以跨平台。且golang簡單，特性尚可，缺點雖然多，但是相比 .net 每次都要帶個framework 類似蝸牛要帶個殼。想想 golang 美多了，這就夠了！！！儘管golang帶GC。但是至少用起來已經比較開心了。。。

其實 C++ 用了 Qt 易用性完爆 Java，所以語言易用性是與使用的類庫有關的。

既然對C++戀戀不捨，還是用C++吧。

知乎上的人把C++黑的一無是處，把題主這樣有選擇恐懼症的孩子就嚇到了，其實不然。

如果拿出幾天的時間看一下現代C++，特別是C++11，就會發現如果按照best practice，基本不會出錯。看@陳碩老師寫的linux服務端c++多線程編程那本書幫助挺大，陳老師說2004之後沒見過內存管理出問題的C++代碼，可見shared_ptr的巨大貢獻。

別猶豫了，開始學C++吧，這門熱度一直排前三的編程語言不是浪得虛名的。

讓你們不喜歡Objective-C現在後悔了吧，現在我教還有Swift，騷年，我看你骨骼精奇，入不入教？

歡迎你加入蘋果的懷抱。objective-c

swift完美滿足題主要求……

C++ 11

vala呀好像是先轉成c再編譯歡迎用elementoryos