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.

==

Story 4 (Sönke Ludwig/vibed) http://arsdnet.net/this-week-in-d/mar-15.html Sönke Ludwig is the primary developer behind DUB, the D package manager, and the vibe.d web framework, which was recently chosen to be bundled alongside the reference dmd compiler.

- How did you first come to start the vibe.d project and why? Was it your first D project or were there other attempts before?

- I first heard about D, I think, in a magazine article around maybe 2005 and got all ears immediately. My growing dislike for C++ (lacking an overall better alternative) grew over the years and the cleaned-up syntax and the module system of D alone were huge selling points. However, things were still too unstable back then: platform support was lacking and I didn't feel ready to ditch the concept of "const" (which didn't exist before D 2.x), so that the starting shot for me was when the first 2.000 alpha of DMD was released back in 2007.

My first large D project was the conversion of my C++ game engine and GUI framework to D. Bit for bit, going over the course of multiple years, finally the D version had more features than the old C++ code base - at about half the number of code lines and those were also much shorter on average! This framework also forms the basis of most of my current commercial projects. I'd like to publish parts of it one day, maybe using some kind of dual-licensing scheme, when I have enough time to properly maintain it.

Vibe.d was born later, in 2012, when a few friends and I wanted to start a project that was partially web based. In terms of scalability, node.js was the hip new thing and one of us already had experience with it, so we first went with that. However, using JavaScript meant that we had to rewrite and maintain parts of the D code in JavaScript, and more importantly, programming with node.js was really awful due to the callback-based API.

Then I remembered D's "Fiber" class, which was inherited from Tango's runtime during the D1->D2 transition. This was the missing piece of the puzzle to an I/O system in D that could be made better in almost every aspect. So we decided that we'd put some concentrated effort into this to make the development of the project more bearable. Two months later, the first public alpha version was born.

- Could you talk about your experiences with D in building vibe.d, ie things you liked about D when writing vibe.d and things you had to work around?

- In general, D has always been very pleasant to work with, including when developing vibe.d. I have never experienced this level of productiveness for medium to large scale projects with any other language so far. However, hitting compiler bugs and regressions of all sorts was common, and finding workarounds/reproducible cases and reporting bugs at times diminished a lot of the productivity gains. However, although there is still something that breaks with almost any new beta release of DMD, this has gotten much better over time and isn't so much of an issue today anymore. It can still be a little difficult to maintain compatibility with a range of D compilers (vibe.d tries to support 2.065-2.067 ATM), especially since using new language features can be very tempting!

Speaking of which, one of the most useful additions to D would be things like proper "scope" and isolated (a.k.a. "unique") references. Those would enable the memory-safe use of faster programming paradigms, such as using stack-allocated classes, or accessing objects from different threads without the need for costly locks or atomic operations. These are things that vibe.d could greatly benefit from, but memory safety is too important for network services to go this route without language-based verification. (ED: This has since been added in std.typecons)

- Please tell us a bit about yourself: who you are, what programming languages you used before D, and your experience first discovering and using D.

I grew up and still live in northern Germany near the city of Lübeck, which is also where I graduated in bioinformatics a few years ago. My first programming experiences began in my early teenager times when I got my first 386DX, running DOS/Windows 3.1. I discovered qbasic.exe soon after playing around with some simple batch files and began creating all kinds of little GUI and 3D-Graphics based DOS applications.

The experience of the direct feedback back then got me hooked. After some tinkering with TurboBasic - boy, was that fast - and another BASIC based Windows IDE (CA Realizer) around '95, a friend of mine gave me a CD with Borland C++ 5.0, which I then discovered step by step in a completely naive and trial/error based way (What is a "pointer"? Why does it crash now?). The next thing I remember are some bad memories involving Visual C++ 6 and tons of cross compiler compatibility macros, and discovering all of the details of the C++ standard that I wouldn't ever have wanted to know about.

In these times, I created a big number of small programs, discovering the darkest corners of the Windows API, network protocols, hardware interfaces, OpenGL and other random things. I also tried out a lot of other programming languages, including most of the popular scripting languages and a short trip to OCaml, but I've mainly stuck to C and C++ for actual projects (still preferring C over C++ due to many factors). W32DASM was also one of my favorite tools at the time, without going into details of what kind of 1337 things that was used for, but it also helped me learn the details of x86 assembly.

Then, during my time at the university, I worked for Nik Software, a former company which specialized in software for professional photographers, later bought out by Google. There I managed the creation of the company-wide cross-platform core library, providing higher level concepts needed for almost all products. This included an image-filtering framework capable of transparently using multi-core CPUs and GPUs to filter images of arbitrary sizes and a custom GUI framework, which allowed us to maintain a single code base for all platforms, while having the ability to implement advanced GUI concepts that were more or less impossible with other GUI frameworks at the time.

For my masters thesis back in 2011, I created a compiler in D for an image filtering-specific DSL, which was able to translate to GPU shader code (GLSL or HSL), to C++ code and, thanks to LLVM, directly to machine code at runtime. It was then integrated into the company's core library to form the basis for new filters. This was the fist piece of software in the company which was written in D (controlled through an extern(C) interface). The language made this a very pleasant and an extremely efficient endeavor (apart from some friction caused by the C interfaces to the host application and to the LLVM libraries). I intentionally tried to keep the D code simple, without excessive use of advanced meta-programming and other "bleeding edge" features, so that the chance of running into compiler bugs was as low as possible (there have still been quite some of these, and getting 64-bit builds to work on Windows also still was a challenge at the time).

What do you love and/or hate about D? This is more general than the specific vibe.d-related question above.

- I basically love the initial (D1) design choices - the clean and easy to parse syntax (field access, templates, slices, foreach etc.), the module system and the low compile times. Also D's meta-programming abilities, including CTFE and the more recent support for user-defined attributes, are superb and, I'm sure other D programmers know this feeling as well, it's sometimes really hard for me now to force myself into doing things with certain other languages that could have been done much more efficiently in D, even when talking just about a few lines of code more or less.