In the D community, we have a strong belief in D's potential as a suitable and favorable alternative to C and C++ for areas commonly served by C/C++. This isn't surprising, since that's exactly how D was originally designed and envisioned.
To help facilitate that, D has always been designed to easily interface and directly link with C code. More recently, major improvements have also been made in interfacing D with C++. Naturally, one major benefit of this is to provide D with access to the wide array of existing C/C++ libraries. But the other key idea here is to help encourage D uptake. How? By making it easier for existing C/C++ projects to include D portions without the entire project needing to be ported.
This C/C++ interoperability is a fantastic feature for D to offer, and is essential in encouraging and facilitating migration to D. Building off this, we have Deimos, to offer D projects ready-made bindings to C/C++ libraries. Other projects in code.dlang.org may offer to auto-generate D bindings or wrap existing Deimos bindings with D-centric benefits and simplifications. All of this, we hope, will make D appealing enough and entice C/C++ users to try out D in their projects - and potentially, commit more fully down the road.
But we're overlooking a key part of the picture. We're looking at something backwards:
Our whole approach to giving D inroads into the C/C++ world relies on convincing C/C++ users to actually try out writing D. Even before they do that, they must actively decide to go learn some D. We've had some success, but as many of us have learned, this can be a significant uphill battle. The status quo is strong with programmers (and understandably so).
Take our existing focus, offering C/C++ libraries to D projects: What if we flipped that around and started using D's C/C++ interoperability to offer D libraries to C/C++ projects?
Think about it: If a D library came with its own C/C++ bindings, then it may as well be a C/C++ library as far as most C/C++ users are concerned. Then just slap into a C-world-compatible makefile into the library, which auto-detects a D compiler and, if none, does an automatic project-local download/install of DMD/LDC/GDC (this could all be offered to D libraries via a single D tool up on code.dlang.org), or even just include precompiled library binaries, and done: on any platform D supports, C/C++ users can use your D library just as if it were another C/C++ library.
That gives D inroads into C/C++ projects without requiring any C/C++ user to ever have to touch one line of D. Then, later, when coders wonder how the library they use works so efficiently and reliably, and is developed so productively - they can glance into the lib, see how simple it really is compared to a C/C++ equivalent, and see how much easier still it would be to use the library from D. Nice, D has just marketed itself.
tl;dr (In my day we called that a "summary"): I propose free C/C++ bindings with every D library! The D community should strive to offer them as a standard matter of course. Tools should be created to help D library authors offer their own C/C++ bindings. This will take us much farther into the C/C++ domain than merely offering C/C++ libraries to D users will.
3 comments for "We're Overlooking A Key Part of C/C++ to D User Migration"
More comments over on the D forum/newsgroup:
http://forum.dlang.org/thread/n8tc1l$93p$1@digitalmars.com
I think D is a brilliant language, and certainly has its area of application; but as far as replacing C++, I don't think this is ever going to happen. One fundamental difference is that D embraces garbage collection. This is definitely not going to appeal to C++ developers. Without going into debates about performance, C++ developers are used to writing programs with more or less predictable performance. I know that D allows non-garbage collected objects, but the standard library is fully based on garbage collection. Moreover, with the new improvements in C++11/14/17, C++ developers will find little incentive to switch.
"One fundamental difference is that D embraces garbage collection."
That's not entirely accurate. D fundamentally embraces manual memory management too, always has. (Although, historically there were some unfortunate limitations there in the past. But as I explain below, the ones that haven't already been addressed *are* in fact being addressed.)
What many C/C++ users have perceived as fundamentally embracing GC is really just D *offering* GC by default and including language-level support for GC and some features GC helps open a door for.
"I know that D allows non-garbage collected objects, but the standard library is fully based on garbage collection."
"Fully" based on GC is inaccurate. There is considerable support in the std lib for non-GC memory management, and it's only growing. Historically, there was a lot (not all) in the std lib that did rely on GC, but one of the big pushes in D for some time has been to reduce and minimize the std lib's reliance on GC.
D's ranges in particular (which have been a common part of idiomatic D for for quite some time) are a major part of that reduced reliance on GC (They even do a lot to reduce reliance on heap memory in the first place).
And now there's also a @nogc attribute being used by the std lib devs (and others) to transitively guarantee a function doesn't allocate GC memory (which also prevents collections during the same section of code, as collections are triggered by allocations - but GC collections have always been disableable anyway).
Certain core parts of the custom allocator system has begun appearing in the std lib, too.
D's philosophy has ALWAYS been that the GC should be optional. Unfortunately, in the past, there were some issues hindering that from being a practical reality (like overreliance on GC by the std lib). That led many people to misunderstand D's intent, and even erroneously associate D with mandatory GC. But now, many of those issues have already been addressed, and the remaining ones are being addressed.