Well, others might have said `i, s:` is not an independent label.
220 karma · joined August 28, 2015
D is safer and more productive. It's a joy to write in D because most of the time it feels like whatever you think, you code. This is unlike C++ where you fight the language all the time. C++ is not a productive programming language. I say this with experience: I coded in C++ as an "expert" for many many years, including these last couple of years. It's not fun to write in C++, which translates to another kind of loss of productivity.
C++ is a burden and liability for companies but no CTO will be blamed for chosing it because it's popular. I can list so many popular things and persons that worth nothing but I will refrain from getting political.
Yes, on paper, there are way more C++ programmers out there than D programmers. But I interview these C++ programmers occasionally. Most of them don't even have an inkling that they don't know C++ at all.
How about engineering with C++? That is such a difficult task. I went over header file hygiene with a colleague a couple of months ago. The number of points that you should pay attention to is mind boggling: Don't #include unnecessarily, do forward declare as much as possible (but what can be forward declared is hard to understand even for experienced programmers), #include your own API header first to prove that it's complete (and good luck!), don't forget header guards, don't reuse header guards, etc. etc. This is just efficient header file usage! We haven't started coding yet!
My friends, the emperor doesn't have clothes. C++ simply is not a tool that is designed well. People who choose it do so because they have to or they are masochists. (True story: I asked a relatively young Google meetup presenter once why he was using C++ instead of a modern language and he said "because it is hard".) C++ separates the elite from the masses; I used to strive to be a C++ elite; I am not interested a bit anymore; I want to write useful programs with D; and I do.
D is niche only because humans are populists. We are not encouraged to use tools (or products) that are designed better. We follow popular leaders. It takes one some time to find his or her own voice to reject bad products and use only good ones. I am extremely lucky to work for a company that allows me to use D to write useful products.
I still take the same joy from programming that I did when I first learned it.
Then there is the human aspect of it: I want to be associated with real people isntead of snobby elites. (Remember how C++ was marketed at around 2000? "Yes, C++ is hard but it was never meant to be for normal programmers anyway." Ha ha ha! I am old enough now to reject that mentality. Bad design is bad design my friends; you can't defend it by blaming the user for not being elite.)
I can go on and on...
Now it's my turn to ask: Why would anyone choose C++ for their projects despite the production costs that it brings? None of your programmers really know it; they introduce hidden liabilities in the projects, their source code become non-refactorable monsters. Why waste that money on C++ when you can produce products easily. Products that just work...
I mean... Modules versus header files, 13 times faster compilation, introspection, unittest, etc. etc. etc. Okay, it's more like death by a thousand cuts but once you produce with D, you can't even touch C++ anymore. I am in that state...
On the other hand, D's dstrings are more like text because they are not only UTF-32 but also random-accessible code points. (D does not address multiple representations of graphemes at language level. For example, at language level, ğ is different from "g and combining breve" but there are std.uni and std.utf modules that help.)
I am not aware of a common issue like that but D has bugs.
> Also importC isn't what you think it is
That's contrary to my tests: I installed libplot on my system, 'import'ed its .h file to my D source code, called C functions from D, linked with -L-lplot and it worked.
> not importing foreign C libs you've installed on your system
Maybe you mean something else with "importing" but I installed a foreign C library on my system and it just worked without any hand-written D bindings for it.
As I understand it, for safe-by-default to work, either all C libraries would have @trusted D bindings written, or all of them would have to be assumed to be @trusted. Most of the community wanted explicit @trusted annotations, Walter and others favored assuming them to be @trusted (or was it assumed @safe?) was the way to go. So, no safe-by-default at this time. :/
Don't forget the -betterC compiler switch please. ;)
I don't know Zig yet.
I had an opinion long time ago that nobody should use C anymore; I would suggest C++ at least because it has constructors and templates. D's [Better C](https://dlang.org/spec/betterc.html) would be my go-to at this time.
C++ is getting better but it's still very difficult to get right: It depends mainly on programmer attention e.g. to follow 400+ [guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines).
Rust is "different" but it has the borrow checker as a safety tool. D's [live functions](https://dlang.org/spec/ob.html) and other [memory safety](https://dlang.org/blog/2022/10/08/dip1000-memory-safety-in-a...) features are closing the gap there.
> major selling point
I am copying slide 59 here: D provides competitive advantage by helping happy programmers produce correct programs pragmatically.
Slide 8 lists what D does not have, which can explain why D has not gained popularity that it deserves. For example, nobody can sell D as "Google's language" or "Apple's language".
D's advantage over Rust is its familiar syntax and semantics. C, C++, Java, C#, Python, etc. programmers feel at home once they learn some differences. I heard others say "D is what C++ should have been" and "Compiled Python".
I did use Rust for a brief period in a project where the experienced Rust programmer among us was throwing '&' characters here and there to make the code compile, seemingly randomly in many cases. Personally, I remember fighting with impedance issues with the many different string types of Rust. All of this spells a steeper learning curve to me.
I think D is familiar to programmers of many other languages.
The speaker was proud and beaming for showing how powerful C++ is and the audience was in awe.
I was incredulous! Jaw open! The "solution" was horrible with a bunch of workarounds for a bunch of shortcomings. It was a "the emperor does not have cloths" moment for me.
Boost Spirit may be better today with newer C++ features; I don't know.
The following example is similar to C macros because it generates code as string and mixes it in as code but you can combine templates as well. This example generates a struct definition.
(Edit: formatting)
import std; // Entire package for brevity
auto memberDef(string type, string name) {
return format!" %s %s;"(type, name);
}
auto memberDefs(string[] members...) {
return (members
.chunks(2)
.map!(pair => memberDef(pair[0], pair[1])));
}
auto structDef(string name, string[] members...) {
return format!q{
struct %s {
%-(%s%)
}
}(name, memberDefs(members));
}
unittest {
mixin (structDef("Foo", "int", "i", "double", "d"));
auto f = Foo(42, 1.5);
assert((f.i == 42) && (f.d == 1.5));
}
void main() {
}One thing C++ will never have is D's `static if`, which allows injecting declarations into scopes. Bjarne Stroustrup and others closed that door: https://isocpp.org/files/papers/n3613.pdf
They consider investments for their minimal costs as well.
* We don't have templates. Hm. Let's bad mouth them. Let's say templates are too difficult. Agreed.
* We don't have exceptions. Hm. Let's bad mouth them as well. Agreed. That one is easy.
* We don't have much abstractions. Hm. Let's convince new college graduates that they can't handle abstractions anyway. Mwahaha. But waait! New college graduates are actually smarter than us. I know... But we will convince them that they are not. Mwahaha.
There is more but I think I've just earned enough down votes with that much already. :)
But there is one sales sentence I will never forget. Go people said "No major systems language has emerged in over a decade"[1] As a person who was very much into D at that time (and I still am), and as a person who knows how "major" D is, that sentence from the Go people make me see them as either ignorant of the programming language scene or deceitful. Cheap sales tactic at best...
Disclaimer: I used Go professionally for 1 year for a product in the microservices space in 2017-2018. The only thing Go had going for it was the libraries that were already written at least for that space. Whatever we needed was already written for us; we had to wait at most 2 weeks for something that we needed to pop up. There was nothing else in the language that made me want to write in Go.
[1] https://web.archive.org/web/20091114043443/http://golang.org...