User narratives on switching to D

[We can clean up formatting later. I am not so good with wiki].

Story 1: please state your agreement to use your name if you don't mind it being included. (It would make the account more vivid if so):

Before I was mainly using C++ for my work(and dabbled in Rust, but never ended up switching to it) D's C-like syntax inspires familiarity to the point where I truly believe that D is easier to port C code to than C++ because you can write D in a "cleaned up" C for the most part, and slowly turn it into D whereas C++ is essentially a completely different style. Not too many languages can really claim this, and IMO it's a huge boon.

D provides native performance directly on comparison with C/C++ while being much easier to jump in and bash out a few quick ideas(Phobos helps a lot with this.)

Phobos offers far more than the C++ standard library as well. It's nice not to have to go hunting for libraries, C++11 helped with this a little I guess but it just feels like "it's there," whereas Andrei/Walter seem to actively be working towards "you should always be using Phobos or it should be fixed."

Also, D's metaprogramming system is actually usable. I use CTFE to do a ton of precomputations at compiletime, I even recently learned that the compiler can unroll foreach loops in switches(! that's cool - D has a lot of neat tricks that nobody really seems to discuss,) I feel like I'm always learning new tricks in D, and not in the C++ way.

The ability to use C libraries with barely any fuss(!), I ported a C's library's headers to D in about 10 minutes using htod and a bit of manual touchup. This is a `killer feature` in my opinion.

Ranges/functional programming in general, C++ really has nothing on this. I think C++17 might be getting ranges but when I reviewed the paper they seemed far uglier and an afterthought(like most of C++), I've written large parts of my programs in purely functional style and LDC optimizes it to the equivalent imperative code.

D's operator overloading is extremely well designed IMO,(it just goes with the rest of the 'make D work the way you want it to' feeling of the rest of the language)

D(md) compiles pretty fast, I think it used to have a bigger advantage here over C++ before Clang became popular but it's still pretty darn fast and makes for python-esque edit-run-debug editing style. I went from compiling my projects on the university servers to my home desktop(and it compiles faster.)

I think D's best quality is probably how approachable it is for C/C++ programmers compared to i.e, Rust which has a (weird) ML influence. I wouldn't be surprised if you could get a C or C++ programmer up to speed in D in an afternoon, at least enough to be efficient in it.

D is of course not all roses, shared still feels half implemented and left to rot(D's memory model in general.) TDPL is aging, and there's not too much other literature on D - but Ali's book is very good. The compiler situation feels odd, LDC and GDC have very few contributors despite being better than dmd at optimizing and providing a lot of extra perks - i.e, LDC lets you use all of the LLVM sanitizers like the thread, memory, etc. ones, and LDC provides in-depth optimization analysis thanks to LLVM.

But comparatively, this list is not so bad.

I feel like I could write a book on why I use D, so I'm going to stop now : )

==

Story 2 "In D, if you have a bug, you are 100% certain that you can resolve it yourself. You have all the C/C++ tools available to go all the way down to the memory and debug anything you want. You have statically typed language that allows huge projects to breathe very healthy and increment features at low cost.

Nothing beats D in my opinion. It's 20 years ahead of everything out there. All you need to do, is know how to use it and understand it enough to resolve any bugs you come up with."

Natively compiled: Moore's law predicts that the burden in advancements in computing speed will migrate into software. This may be enough to rule out increasingly the use of managed language for developments where cost is important and more than 1 server will be needed. Compiling vs interpreting can make all the difference between requiring 1000 servers vs 10 servers.

Template metaprogramming: This is the first reason I've chosen to use D in the first place. The idea that I could write code that writes code, and make it statically typed and safe. C++ has this but the errors are insane, the static if is not there, CTFE is just starting to pick up, there's no traits or very limited compile-time reflection (ie. static if(__traits(compiles, { some_operation(); })). The compile time is also much slower, there's simply too many legacy features in the language that have made it suffer in the long run. Even a package manager like dub is something nobody can agree on, because the community is so divided.

Overall, it would take decades for the most powerful language C++ to reach the current state of D in terms of compile-time capabilities. This is important because preprocessors are the only alternatives and they suck for larger projects.

I started off as a C, C#, Javascript & PHP programmer with 6 years of experience, building mostly e-commerce and information systems on a contractual basis. One day, I decided I had enough and wanted to invest my time in a faster web engine because I was tired of seeing all those slow and bloated libraries that can barely serve 10 requests per second when they're put to any practical use.

I decided to go for C++ and learn everything I could about writing an integrated solution. I found interesting libraries but everytime I wanted to add a feature, I'd have to import another library and it again became bloated but in terms of code base. Nothing seemed to work together (Qt & Boost?).

The D programming language came up frequently in search results when looking for C++-related concepts, and I saw everything I needed in Phobos. The language features seemed similar at first but I quickly realized how much more convenient the language was as a whole and it felt much like a managed language overall.

Even the vibe.d library was much more advanced than what I could find with an open source license that allowed static compilation at the time (1 yr 1/2 ago), so I went forward with that and worked my way through. The most interesting part is that everytime I had a problem, I never had to google the error from the compiler because it was quite straightforward. I did have to debug the memory a lot but all the tools from C/C++ work for that.

So now I can build a full web application/server executable in less than 2mb packed, and it runs faster than anything out there. It's standalone, works cross-platform, etc. I really have to put the blame on the language for the speed at which this very large project was finished. I completed the STL-equivalent memory library, TLS/crypto security library, the low-level async TCP library, the HTTP/2 implementation and the integration of everything in a web application framework within about 10 months. I learned the language for about 6 months through that coming from a background more familiar with managed languages. I can't say D isn't meant for large projects, it's a really fucking solid language that was built for the future."

=

Story 3 (hedge fund guy)

Coming back from lunch, the first speaker was Andy Smith, talking about using D in the world of financial software. Download his slides here.

He got interested in D because of Walter and Andrei's names and took a look. He said he wrote a bit of code that didn't work and asked for help on the #d IRC channel on freenode and was surprised to find that somebody on IRC actually meant it when he said he'd help rewrite the example so it works and explain it - Andy said this left him with a good impression of the community.

After this experience, he started using D at work. His company wanted to rewrite their infrastructure to take advantage of new computer hardware and he was going to use D for the prototype, but it ended up working well right into production.

D scores highly on all requirements they had: it was correct, testable, reliable, modifable, productive, and performant.

Among other wins in the language were: fast builds, easy testing, C syntax is easy learning, low level functions, the standard library, the module system helps with changes Editor's note: I'd also point out how much static typing helps in modifying code, and he found no nasty language surprises.

In Phobos, he loved having the modules for: getopt, json, DateTime, atomics, bitops, csv (he specifically called out how nice the Struct[] population functions are) and loved how well they worked and that they were easy to use.