Why hasn't D started to replace C++
quora.com
quora.com
Levien's Xi video today being yet another example.
edit: As for why, languages are more of a battleground than a substrate. If you have a choice between Swift (Apple), Rust (Mozilla), Go (Google), or D (Walter Bright), most people are going to flock to one of the bigger forces.
Golang is a kind-of underwhelming riff on Pascal, but I use it anyway for network stuff. Why? Google has given it an instant ecosystem with plenty of well tested libraries, docs, and howtos. Never underestimate the ecosystem.
C still seems to spawn new software because people are working directly with hardware and don't wish to code using straight assembly. I'm thinking computer engineering related fields. Robotics for example.
C++ falls into an uncanny valley, it is neither high level language with all of the benefits (e.g. programmer efficiency, certain security guarantees, lower barrier to entry) or a completely low level language (or at least it isn't if you want to benefit from most of C++'s advantages over straight C; you'll avoid a garbage collector but not a lot of "magic" behind the scenes).
C++ carved out a space with 3D gaming for a while but with many development houses moving to licensed game engines or targeting mobile platforms C++'s benefit may be waning.
The data does support this supposition[0].
I am surprised this is still true in 2018. GCC and Clang on x86 with -fno-rtti and -fno-exceptions produce almost identical code for similar programs in C and C++.
If what you say is true, I suppose there aren't enough compiler devs paid to optimize C++ for those platforms.
Clang/LLVM is not even close to supporting something lower bit.
You buy the compiler from the same vendor that is selling you the hardware.
Even if it is based on gcc, it happens to be a fork with changes they don't easily release. Some of them are now transitioning to clang, because the license makes it easier to keep doing so.
Many of them are still mostly C89 (not 100% ANSI C compliant due to hardware limitations) with a few C99 features.
There are lots of high-level, cost free niceties that C++ provides that I miss when I have to fall back on C. Generics and RAII alone are quite nice.
but to be a player
there will always be systems written in different languages for different reasons, or for small advantages of one language over the other
there is a place for C# and Java , a place for rust and go, a place for F# and Clojure, a place for Pythong and Tcl/Tk, etc ..
D from the little i know of it, is a nice language, I dont think it will ever dominate anything or replace anything .. but it definitely has a place .. or deserves to have a place
I'm just not sure that middle ground between C++ and Java/C# is terribly compelling, and has also been swamped by later entries like Rust, Swift, and Go, which additionally have major backers.
D is generally a much better Go (especially if you add fibres to it), but it doesn't have Google-brand behind it, so Go ate it's lunch in distributed systems space, while Rust is much better suited to be a serious competition to C++.
why ?
The code generation for DMD has fallen a bit behind, mostly because I spend my time on other issues these days :-(
Where do people get this from? D compiles down to the same machine code that every other compiled language does and it has similar language semantics to C++. In some cases D is _faster_ because its richer type and effect systems allow for more opportunities for optimization.
All of D except the backend was open-sourced in 2011, I'm pretty sure. Even before that, Walter Bright accepted patch submissions.
if(foo)
bar();
baz();
A language design bug copied from C. A feature that is good only to add a class of bugs to programs in your language with zero benfit. Perl wasn't tasteless enough to copy that. D designers were, does that convince you they have the right taste to design your systems language?Alexandrescou is exactly the kind of C++ person D is designed for (and now by). Is the code more important or the data transformation being performed by that code? Garbage collection, same as golang with the same perception that it's a replacement for java/python/ruby/perl not C nor C++ - this will be the perception and they will say "yeah but ..." sure, but that perception is not devoid of merit. "You don't need ..." nup, as an engineer I decide that, I don't want it imposed.
Low level access to raw hardware, zero cost convenient abstractions, no runtime cost imposed by the language, consistent, easy to get right (or at least harder to get wrong, less gotchas). Whatever replaces C & C++ will tick those boxes unless hardware changes dramatically. People believe that D doesn't.
Then there's just practical stuff like using facebook's linter - well you can't, it just doesn't work. https://github.com/facebookarchive/flint Is the D version even there? Too hard, too alpha, the overhead of a new language needs more to sell it. I haven't yet programmed a line of Rust or Go but both look more compelling.
Slow compile times, a sea of compiler options, pragmas, swamps of macros and templates, and the complete lack of understanding among coworkers of OO concepts like virtual functions or inheritance.
Can totally sympathize with Linus' contempt for C++.
edit: Notice dingo_bat is getting downvoted on this. How about responding with why you dislike C++ instead of the downvote?
C++ jammed so many different concepts into the built-ins, catering to all yet pleasing none. Last I checked, exceptions were still kind of a mess. Places I know that still use it have their own peculiar commandments as to what is halal and what is haraam. I do not blame them.
Just stick to 'struct's instead of 'class'es, use ctor/dtor for RAII, pure virtual functions to declare interfaces and single-level inheritance to implement them and, perhaps, an occasional template to replace a macro - and you still basically have C, but it's now far less verbose and more pleasant to use.
Most C++ code I've ever written has at least had some issues with memory or threading, even with the best discipline I've had with C++. I think this is an experience many people share and probably a reason why a lot of folks are so excited for memory-safe alternatives like Rust.
As far as a lack of ide's goes. There isn't many. I like dlang ide. It has everything I need, though it can be kind of buggy. I also don't mind Vim with dlang plugins. But I don't think they can compare to large established ides for other languages.
I can also understand why it doesn't really pick up for large projects the way c++ is.
There isn't much in the way of libraries, there is no tutorials or help aimed towards beginner programmers, which is too bad because I think D is way better for beginners than Java or C, it teaches the same important concepts as both languages while providing a fairly strict compile time checking and a far less ridiculous syntax than java. With the option to not have to learn OOP stuff until you understand basic programming. It also makes it a lot harder to shoot yourself in the face the way C does.
The standard library docs and most other documentation I've seen for D is fairly technical and not very inviting even for non beginners. Most libraries have little to no documentation and many haven't been maintained.
The only real, understandable learning resource I could find is:
Which is a great book, but also nearly the only readily available one to learn from.
It is too bad because there are definitely lots of benefits to C++ it's just they're not quite worth the tradeoffs.
I love D but tbh I disagree. I think an optimal-ish progression for learning programming languages is:
Python (basic programming&computer knowledge, algorithms) -> C (low-level knowledge) -> ASM (optional, only if you want to learn extra low level knowledge) -> C++ or Java (to learn modern OOP concepts. D's are a bit too complex and the error messages aren't as good and thus off-putting to a beginner) -> D (amazeballs metaprogramming) -> LISP (amazeballs metaprogramming and FP)
Neither C, D, nor Java should be beginner languages. They're too big and fancy. (To be fair, python does this too, but it does a bit better job of hiding it, and exposes an api that can be leveraged to teach people programming even if they don't understand how it works.)
In the end I ended up learning lua as my first real language where I finally knew how to use programming to make things. I experimented with a few functional programs in lua and learned enough about OOP and luas metaprogramming to design my own classes and start working on some small games and bigger projects.
Eventually I started to run into lua's limitations (every number is a floating point number, the classes I designed couldn't be serialized properly, there wasn't really a way to debug a lua program, lua's tables and metatables are kind of weird) and most of the answers I looked at pointed to needing to understand C and use lua's c bridge to get the kind of functionality I wanted from lua.
That was when I rediscovered D and all the things that confused me about it before just made sense this time. I have been also trying to learn C along side it just because it seems like it's something I should know. But I've been writing most of my stuff in D lately, even smaller programs just because I find it has the balance between lower level and higher level stuff I need and can use for what I know.
CppCon 2015: Kate Gregory “Stop Teaching C"
Plus being a subset of C++, there is hardly any value in learning C as such, instead of good C++ idioms.
In fact, my university already in the mid-90's never teached C, only C++ with a professor that was insightfull to have its own set of type safe abstractions, the usual array/string/containers set, while teaching us about RAII, years before C++98 and STL were a standard.
There were system programming assignments in C, it was expected that any student would be able to think and know how to apply C++'s C subset for the assignment.
To say this is to miss the point entirely. A machine runs not C++, but C. To learn how to use, e.g., std::vector (to cite a random example) is to learn a high-level programming concept which could be learned in any language but not to learn how the machine works. To learn how to use a char* in c++ is a complete waste and not different from learning how to use a char* in c.
CPUs don't run C, and unless we are speaking about a PDP-11, the ANSI C abstract machine surely doesn't expose how this mobile phone CPU/GPGPU works.
When I want people to actually know how computers work, I teach them Assembly.
C isn't a special snowflake in the realm of systems programming languages, there are plenty of languages, some even older than C with the same low level capabilities.
Had AT&T been allowed to sell UNIX at the same price the as other OS vendors were selling their products instead of giving it almost for free to US universities, we wouldn't be talking about C nowadays, and probably also not about C++.
That's just not true. You see something like assembly, which seems so low-level and implementation-focused, and then you see java with all its high-level complexity and it seems like it's fundamentally something different. C bridges that gap, because you can see all the ways in which it's exactly the same as assembly, yet all the ways in which it's exactly the same as java. If you truely want to understand a computer on every level from silicon to state-machines (idk, it was the first thing that came to mind), C belongs on that stack.
What makes c special is not its capabilities, but rather its lack of abstraction.