- famously powerful metaprogramming and compile-time introspection
- a familiar, but not ugly syntax
- comes with a package manager
- simple-to-use build tools with dependency discovery
- mostly-optional garbage collector (great for 90% projects!)
- interfaces with C and C++
- memory safe
C++ still has:
- header files
- a preprocessor
- infamously hard-to-parse syntax
- decades of legacy cruft
- fun things like design-by-SFINAE
My biggest reason to use D is that it works great for both small scripts (one program can be one file and is ran with one command, or even a shebang), and large projects (with packages / dependencies etc.). Similarly, if idiomatic D is too slow, you can optimize it by going as low as C or inline assembler without having to call-out to a lower-level language.
Source: using D for almost everything since 2006, while also maintaining a few C++ projects.
Looking past the feature comparisons, it's simply a pleasure to program in D. It's easy to write code in D, it looks good once written, it's easy to refactor, and it performs as well as the equivalent C or C++ code.
The features are designed with an eye towards simple things should be simple, code should not have to written twice, the layout of the code should match the layout of the problem being solved (not the language), drudgery should be eliminated, and common bugs should be impossible.
I've just had a bit of fun updating the SPIR-V backend to use https://github.com/KhronosGroup/SPIRV-LLVM-Translator instead of the old one which wasn't being updated. I'm in the process of adding clspv as a backend for Vulkan Compute shaders (in turn as a basis for targeting Intel's ispc compiler optimisations). Most of that fun involves bashing CMake around that head to try to get it to talk properly with pkg-config (I hate them both).
When I hear about fast compile times, like e.g. for Pascal, immediately comes to mind - how good is optimization of the resulting executable? AFAIK, the back-end, not the front-end/parsing, takes most time when compiling C++. So in case of GCC or LLVM based D compilers, the time should be similar?
C++ 11, 14 and 17 have all closed the gap with D in terms of features, but IMHO even when those features exist in C++ they're a lot harder to use and a lot easier to shoot oneself in one's foot.
You _can_ get things done in modern C++, it just takes longer and is buggier. In my experience, anyway.
Totally agree. It's been a while since I have last used D but my experience is that it hits a sweet spot between classical C-like compiled programming languages and scripting languages. If you need both, scripting and performance, D is a good pick. If you are already familiar with C or C++, getting into D is not that hard.
Disclaimer: Nowadays I am more enthusiastic about Rust than D, but I still consider D to be a very solid and nice language.
I am not completely up to date with D at the moment, but I hope the following is still accurate:
Both D and Rust are fast when it comes to run time. Rust is more explicit about allocations because of the borrow checker. A typical case is string handling. In D you do not need to think much about gluing strings together. In Rust, you have to use more explicit code to say: Yes, I really want the extra allocation.
Rust makes you more conscious about lifetimes. That can be a good thing. You will get better runtime performance, but I also think that it promotes simplicity which in turn makes it easier to understand the code in the future (every variable has a clear owner).
D gives you speed with a pleasant syntax. Rust gives you robustness and the language-design of a community. D's design addresses the unsafety of C and C++ and makes it a lot harder to shoot yourself in the foot. Not as hard as Rust, but pretty hard.
Rust feels much more like a universal language, that not only focuses on the niche of C and C++. D has a clear focus on the C/C++ world, but it is still a suitable language for scripting. I used it a while instead of Python to write file processing scripts. Why did I stop doing this? Mostly because I moved to a new place that was very biases towards Python. I did not think much about it back then but I could probably have kept writing D.
Both are good languages. I think Rust is still more difficult to pick up, but the learning resources are getting better every day. If you want to use one of the two languages in a project with a team that is unfamiliar with both languages, D is probably the safer choice unless you have very strong reliability requirements.
I think both languages are worth learning. And both are good choices in the domain of C and C++.
I would position D on a spectrum between Go and Rust.
Go is roughly where you would end up if you trimmed down D to its bare bones: a pretty fast GC language with a native runtime that can do some memory manipulation if needed, where the focus is on providing a single idiom that works for every task.
D is more like the C++er's take on that idea. It has templates, it has annotations galore, lots of convenience features, lots of low level features, and it's gradually repositioning to depend less on the GC and get some similar "manual but safe" memory functionality of Rust. It can be a bit intimidating, but you can be productive with it relatively quickly if you write Go-like code, and add the extra stuff in gradually. That gives it leverage as a language that really grows with your project and lets you go into fine-grain detail where you need it.
Rust is like Go in that it's at an uncompromising extreme of the memory-safety spectrum. Borrow checking(and its resulting patterns, which are typically considered idiomatic in modern C++) is in at the core and it's not going away. This makes it great for code that needs to scale out to the extremes of something like a web browser, where the codebase cannot "do one thing well" anymore and needs tight control over resources, concurrency, and safety all in the same package.
There are reasons to find any of these three unfavorable - the harshest critics might say Go is "braindead", D is "a mess", Rust is "too strict". I believe all three are here to stay.
I would also lump in Zig here as a second axis of the equation. Where the other languages all have ambitions about memory safety, Zig makes no bones about being unsafe: it aims to be a direct replacement to C, which cleans up every other aspect - areas where the standard is unclear, where more checks around boundary conditions are possible, and where modernization would be of immediate help, e.g. a compilation system that does not involve the C preprocessor or header files. Zig isn't hostile about memory safety - there's willingness to explore it, but the approach is conservative. This positions it as the ultimate "low-level library" language, where the programmer goes in with a straightforward goal and can reasonably expect to know what every last byte does.
Rust achieves memory safety without a tracing GC. D has traditionally relied on the GC for that, but now there's [DIP1000](https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md). D can however be used without a GC if needed.
Rust has macros, which D doesn't, but D's metaprogramming is superior.
Honest question: is it the case in practice though? Last time I checked D, you could disable the GC in theory, but in practice many things would fail to work, most importantly their standard library. As this been fixed since then?
Yes, it's the case in practice: I've written a lot of @nogc code. Some parts of the standard library require the GC, but not all of it, and the parts that I usually use are fine (std.algorithm, std.range, ...).
Since allocators landed, it's been a lot easier, and I've written a library that does C++-style smart pointers for D:
Is D being used/backed by a major software company or a major open source initiative? Looking at the trends so far, seems like it takes the backing of a giant for a programming language to succeed.
Sociomantic, Symmetry and Weka.IO are large very heavy users. Symmetry has supported development with an "Autumn of Code". The backing is much more diverse and its been that way for a long time.
Yes, 300GBP is typical for a tech conference in London. Cost of venues and catering can be astronomical, so even with that ticket price it may be difficult to run a conference.
Some community conferences are half of that (and depend on sponsorships), but OTOH there are also plenty of "serious business" conferences that are 10x more expensive.
The conference would not be possible without the substantial contributions of sponsors, in particular Symmetry Investments. The D Language Foundation does not make a profit off of it. I pay my own expenses to attend, for example.
Is catering a big portion of the ticket price? Surely one can venture outside to nearest starbucks, pret, other-fancy-coffee-shop-5metres-away, and dozens of other eateries? Or the food delivery service apps. I'd be pissed off if shitty non-choice catering was going to eat into the ticket price more than 15gbp.
Sponsors pay the booze after usually. So what's left after speakers, token tickets, and venue fees?
The point of the catering isn't just to fill your stomach, it's to have lunch with people who are interested in what you are interested in, ie. to network. If you don't see the point of that, then yeah it's really not going to be worth it for you.
I've been to a few regional conferences so perhaps out of touch, but in those scenarios it's usually either yawn yawn buffet or in most cases a bag with some posh sandwich etc.. in with sponsor logos all over it. I get what you're saying but I can't help but start picturing a table cloth lunch with waiter service as you discuss the merits of the last talk over a fine wine on a table for two/three? perhaps this happens at build? strangeloop?aws:invent? How much of a ticket price is attributed to catering in either scenario?
Aside from keeping the conversations going, keeping lunch on the premises makes it easier to round everyone up after and decreases the likelihood that people are disruptive by streaming in after the post-lunch talk starts. And it's pretty much expected. I would be dismayed if DConf sent me outside for lunch on my own dime.
London has good air service connections for most of the world, so higher costs running the conference in London is more than offset by lower travel costs by the participants.
- fast compilation times
- a module system
- famously powerful metaprogramming and compile-time introspection
- a familiar, but not ugly syntax
- comes with a package manager
- simple-to-use build tools with dependency discovery
- mostly-optional garbage collector (great for 90% projects!)
- interfaces with C and C++
- memory safe
C++ still has:
- header files
- a preprocessor
- infamously hard-to-parse syntax
- decades of legacy cruft
- fun things like design-by-SFINAE
My biggest reason to use D is that it works great for both small scripts (one program can be one file and is ran with one command, or even a shebang), and large projects (with packages / dependencies etc.). Similarly, if idiomatic D is too slow, you can optimize it by going as low as C or inline assembler without having to call-out to a lower-level language.
Source: using D for almost everything since 2006, while also maintaining a few C++ projects.
The features are designed with an eye towards simple things should be simple, code should not have to written twice, the layout of the code should match the layout of the problem being solved (not the language), drudgery should be eliminated, and common bugs should be impossible.
It's GPGPU functionality with an absolute minimum of boilerplate. Unfortunately it does not seem to be in active development.
I've just had a bit of fun updating the SPIR-V backend to use https://github.com/KhronosGroup/SPIRV-LLVM-Translator instead of the old one which wasn't being updated. I'm in the process of adding clspv as a backend for Vulkan Compute shaders (in turn as a basis for targeting Intel's ispc compiler optimisations). Most of that fun involves bashing CMake around that head to try to get it to talk properly with pkg-config (I hate them both).
Is there a reason why you believe that to be true?
> So in case of GCC or LLVM based D compilers, the time should be similar?
They are not: https://atilanevesoncode.wordpress.com/2018/12/31/comparing-...
You _can_ get things done in modern C++, it just takes longer and is buggier. In my experience, anyway.
Disclaimer: Nowadays I am more enthusiastic about Rust than D, but I still consider D to be a very solid and nice language.
Both D and Rust are fast when it comes to run time. Rust is more explicit about allocations because of the borrow checker. A typical case is string handling. In D you do not need to think much about gluing strings together. In Rust, you have to use more explicit code to say: Yes, I really want the extra allocation.
Rust makes you more conscious about lifetimes. That can be a good thing. You will get better runtime performance, but I also think that it promotes simplicity which in turn makes it easier to understand the code in the future (every variable has a clear owner).
D gives you speed with a pleasant syntax. Rust gives you robustness and the language-design of a community. D's design addresses the unsafety of C and C++ and makes it a lot harder to shoot yourself in the foot. Not as hard as Rust, but pretty hard.
Rust feels much more like a universal language, that not only focuses on the niche of C and C++. D has a clear focus on the C/C++ world, but it is still a suitable language for scripting. I used it a while instead of Python to write file processing scripts. Why did I stop doing this? Mostly because I moved to a new place that was very biases towards Python. I did not think much about it back then but I could probably have kept writing D.
Both are good languages. I think Rust is still more difficult to pick up, but the learning resources are getting better every day. If you want to use one of the two languages in a project with a team that is unfamiliar with both languages, D is probably the safer choice unless you have very strong reliability requirements.
I think both languages are worth learning. And both are good choices in the domain of C and C++.
Go is roughly where you would end up if you trimmed down D to its bare bones: a pretty fast GC language with a native runtime that can do some memory manipulation if needed, where the focus is on providing a single idiom that works for every task.
D is more like the C++er's take on that idea. It has templates, it has annotations galore, lots of convenience features, lots of low level features, and it's gradually repositioning to depend less on the GC and get some similar "manual but safe" memory functionality of Rust. It can be a bit intimidating, but you can be productive with it relatively quickly if you write Go-like code, and add the extra stuff in gradually. That gives it leverage as a language that really grows with your project and lets you go into fine-grain detail where you need it.
Rust is like Go in that it's at an uncompromising extreme of the memory-safety spectrum. Borrow checking(and its resulting patterns, which are typically considered idiomatic in modern C++) is in at the core and it's not going away. This makes it great for code that needs to scale out to the extremes of something like a web browser, where the codebase cannot "do one thing well" anymore and needs tight control over resources, concurrency, and safety all in the same package.
There are reasons to find any of these three unfavorable - the harshest critics might say Go is "braindead", D is "a mess", Rust is "too strict". I believe all three are here to stay.
I would also lump in Zig here as a second axis of the equation. Where the other languages all have ambitions about memory safety, Zig makes no bones about being unsafe: it aims to be a direct replacement to C, which cleans up every other aspect - areas where the standard is unclear, where more checks around boundary conditions are possible, and where modernization would be of immediate help, e.g. a compilation system that does not involve the C preprocessor or header files. Zig isn't hostile about memory safety - there's willingness to explore it, but the approach is conservative. This positions it as the ultimate "low-level library" language, where the programmer goes in with a straightforward goal and can reasonably expect to know what every last byte does.
Rust has macros, which D doesn't, but D's metaprogramming is superior.
They're both fine choices.
Honest question: is it the case in practice though? Last time I checked D, you could disable the GC in theory, but in practice many things would fail to work, most importantly their standard library. As this been fixed since then?
Since allocators landed, it's been a lot easier, and I've written a library that does C++-style smart pointers for D:
https://github.com/atilaneves/automem
Isn't D memory unsafe by default?
Yes, but it only takes this to guarantee it:
void main() @safe { // ... }
Sociomantic, Symmetry and Weka.IO are large very heavy users. Symmetry has supported development with an "Autumn of Code". The backing is much more diverse and its been that way for a long time.
Disclaimer: I contract to Symmetry.
Some community conferences are half of that (and depend on sponsorships), but OTOH there are also plenty of "serious business" conferences that are 10x more expensive.