DConf 2019 in London

- 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.

It's GPGPU functionality with an absolute minimum of boilerplate. Unfortunately it does not seem to be in active development.

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.

You _can_ get things done in modern C++, it just takes longer and is buggier. In my experience, anyway.

Rust has macros, which D doesn't, but D's metaprogramming is superior.

They're both fine choices.

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.

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.