D已經(jīng)討論的很多了，也被很多人看好認(rèn)為會替代C++，但有了GO和RUST，D的明天很慘淡
，理由后面說
GO也討論了不少，主要優(yōu)點：簡潔的better C，interface，goroutine，channel base
d message passing，另外用CGO可以直接include C header并直接在代碼中引用C符號，
調(diào)用C庫很方便，也算是非常大的優(yōu)點
RUST已經(jīng)存在很多年但討論的不多，主要優(yōu)點：version based module system，iface
/impl，task，multi-paradigm(functional, imperative), algebraic datatype, Imm
utability, task based error handling(separation), shared box, unique box...
RUST的功能看起來有點多有點復(fù)雜不像是好事，但經(jīng)過一段時間的試用后我的直觀感受
是這玩意長遠(yuǎn)來看在大型工程領(lǐng)域應(yīng)該很好用
1. version based module system解決了大型工程中模塊的依賴問題，DLL hell和java
的jar hell很多人都經(jīng)歷過
2. iface/impl跟GO interface是類似的東西，但GO中是implicit而RUST則跟haskell t
ype class一樣是explicit，在大型工程中這個好處也很明顯
3. immutability和unique boxed pointer能一定程度減緩task間數(shù)據(jù)訪問同步的問題
4. task based error handling(separation)和erlang類似，好處不用講
...
目前RUST和C的交互比較麻煩遠(yuǎn)不如CGO方便，native mod需要自已重新聲明每個enum/f
unction，也沒有可用的binding generator，不過maillist上可以看到幾位核心人員考
慮在1.0版之前加入libclang的依賴并支持直接解析C頭文件，有了這個調(diào)用C庫會很方便
綜上所述，GO比較適合quick和dirty的處理底層事務(wù)，但由于interface的implicit等局
限用來管理大型工程可能會比較麻煩
RUST則即可做dirty工作，也可以勝任大型工程
返回來再看D，相對C++來說其實全是些表面的美化而實質(zhì)沒什么有意義的改進(jìn)，做底層
不如C/C++，做quick和dirty的系統(tǒng)級事務(wù)不如GO，做大型工程拼不過RUST，而且概念比
RUST更復(fù)雜功能集更龐大更難掌握，應(yīng)該沒什么前途

【回復(fù) guanshuiyong】
: D已經(jīng)討論的很多了，也被很多人看好認(rèn)為會替代C++，但有了GO和RUST，D的明天很慘淡
這段真是沒有道理。。。
D的quick和dirty能力堪比python/ruby。。。大型工程堪比java。。。
操作內(nèi)存啥的和c一樣搞。。。你還有啥不滿意的啊。。。
rust和d的本質(zhì)是一樣的，
但大多數(shù)人更能接受類c的語法。
我發(fā)兩張對比圖出來，大家來評一評好了。。
============================================================
use std;
fn main() {
   vec::iter([1, 2, 3]) {|i|
       io::println(#fmt("hello, %d", i));
   }
}
============================================================
import std.stdio;
alias writefln printf;
void main() {
   foreach(int i; [1,2,3]) {
       printf("hello, %d", i);
   }
}
============================================================

第一個是RUST的？有點像Ruby欸
【回復(fù) javaboy】
: 這段真是沒有道理。。。

官網(wǎng)上的。我看著也覺得像ruby...
【回復(fù) sunseraphic】
: 第一個是RUST的？有點像Ruby欸

光比語法有啥用，比比線程模型，module system，iface/impl
D的大型工程能力絕超不過C++/JAVA，但RUST卻可以更高
【回復(fù) javaboy】
: 這段真是沒有道理。。。

只是lambda比較像ruby吧
【回復(fù) sunseraphic】
: 第一個是RUST的？有點像Ruby欸

最近用幾個語言重寫一個C++的圖像處理引擎，用D寫了一半我突然發(fā)覺，我這是在干啥
呢，原來的C++就實現(xiàn)的挺好了，D不能帶來任何開發(fā)效率、執(zhí)行效率或是工程管理上的
提升，我干嘛還閑的沒事用一個跟C++差不多能力的語言重寫一遍
重寫的版本連GO都比D強多了，代碼量只有以前差不多1/4而且架構(gòu)和線程模型更清晰簡
潔，從D上我看不到任何提升
【回復(fù) javaboy】
: 這段真是沒有道理。。。

d的線程模型絕不差。
tls default，transitive pure/const，lambda closure...
寫起多線程來絕對爽的。
module系統(tǒng)d也有。。
iface/impl是啥？接口和實現(xiàn)？你是不是認(rèn)為d沒有啊？
【回復(fù) guanshuiyong】
: 光比語法有啥用，比比線程模型，module system，iface/impl
我相信絕對超得過。
只不過現(xiàn)在reference implementation 還不是production ready罷了。

我覺得D就是把很多C++用編碼規(guī)范來引導(dǎo)的東西固化到語言里去了...然后把很多C++用
庫來實現(xiàn)的東西，融合到了核心特性里去...
【回復(fù) guanshuiyong】
: 最近用幾個語言重寫一個C++的圖像處理引擎，用D寫了一半我突然發(fā)覺，我這是在干啥

D的interface和java類似吧，貌似不能從外部擴(kuò)充一個類的行為
如果說的不對請指正
javaer的哲學(xué)覺得從外部擴(kuò)充一個類不是個好主意，但我個人比較喜歡這個東西
綁死一個對象所有行為的語言，不能叫面向?qū)ο笳Z言，應(yīng)該叫面向類語言
【回復(fù) javaboy】
: d的線程模型絕不差。

確實是的，所以本質(zhì)上沒什么提升，最多語法上變簡潔了
【回復(fù) sunseraphic】
: 我覺得D就是把很多C++用編碼規(guī)范來引導(dǎo)的東西固化到語言里去了...然后把很多C++用

你拿go的線程模型跟d比，這是不公平的。
go設(shè)計初衷就是搞個詭異的語法來支持多線程io。
而D的目標(biāo)是個泛用語言，native compiled python/ruby。
我要扯出d的編譯期能力來，哪個語言都得被秒殺了。。
【回復(fù) guanshuiyong】
: 最近用幾個語言重寫一個C++的圖像處理引擎，用D寫了一半我突然發(fā)覺，我這是在干啥

這有啥不公平的，actor model和message passing顯然是未來的趨勢
誰讓D沒采用呢
當(dāng)然C++/JAVA/D都能寨一個出來，但背后的schedule是很難寨的
【回復(fù) javaboy】
: 你拿go的線程模型跟d比，這是不公平的。

D的module系統(tǒng)好像不帶版本控制吧，那和java的packge有啥區(qū)別呢
如果說的不對請指正
【回復(fù) javaboy】
: d的線程模型絕不差。

【回復(fù) guanshuiyong】
: D的interface和java類似吧，貌似不能從外部擴(kuò)充一個類的行為
這個是可以的，而且恰巧D提供了很討人喜歡的細(xì)節(jié)。
打個比方，如果d的標(biāo)準(zhǔn)類string沒提供向gbk轉(zhuǎn)換的方法，
你可以按照自己需求擴(kuò)充類而不影響別的代碼。
方法很簡單，定義一個函數(shù)
string to_gbk(string s) {
   char* data = s.data();
   // 轉(zhuǎn)碼處理
   // 。。。
   return result;
}
然后在代碼里的字符串s，
s.to_gbk() 就等價于 to_gbk(s) 了。
反過來不行，如果obj.foo()方法存在，foo(obj)是不可以的。

D能在編譯期將字符串字面量轉(zhuǎn)化/合成成符號么？
【回復(fù) javaboy】
: 你拿go的線程模型跟d比，這是不公平的。

底層不就是epoll這種api么。
這種小case了。d的基礎(chǔ)構(gòu)架很好，庫還在發(fā)展中。
過兩年肯定會有人搞個好的異步庫出來的。
【回復(fù) guanshuiyong】
: 這有啥不公平的，actor model和message passing顯然是未來的趨勢

我不是很理解問題，解釋下？
【回復(fù) sunseraphic】
: D能在編譯期將字符串字面量轉(zhuǎn)化/合成成符號么？

那說明也是可以的，但這個好像跟GO的interface一樣是implicit的，在大工程里可能會
有問題
rust里是這樣
iface ToString {
   fn to_str() -> str;
}
然后在外部
impl of ToString for int {
   fn to_str() -> str {
        ...
   }
}
然后可以這樣用
print( 327.to_str() );
基本和haskell的type class/instance一致
【回復(fù) javaboy】
: 這個是可以的，而且恰巧D提供了很討人喜歡的細(xì)節(jié)。

你比較下看，是D語言比較討巧吧。呵呵。
【回復(fù) guanshuiyong】
: 那說明也是可以的，但這個好像跟GO的interface一樣是implicit的，在大工程里可能會