D on quora ...

[Walter Bright]

On 10/6/2017 1:39 PM, Laeeth Isharc wrote:
> Perception is so important when people are making decisions about something they 
> don't know.  (As Walter says, you have to write tens of sloc in a language to 
> really see it's benefits.  They won't be so evident if you write D like the 
> languages you know).

I've nearly finished converting the Digital Mars C++ front end from C++ to D. 
Amusingly, it looks line-for-line almost identical to C++ (the biggest change 
being exchanging "->" for "."). But I deliberately made as few changes as 
possible, because if I introduce a bug doing that, it will be much easier to 
find by comparing the C++ source with the D source.

To aid in this, I do it function-by-function, running the test suite after each 
function is converted. The idea is to use `git bisect` to isolate any conversion 
bugs not covered by the test suite.

So the end result has all the flaws of the C++ version. But once in D, I can 
start taking advantage of D (like nested functions) to structurally improve it. 
It'll always show its C++ inheritance, though.


> So I think the GC series has been very helpful.
> 
> But it might also be helpful to be very explicit on the functions that can and 
> can't be called with nogc (I mean a top level overview in the docs) because it's 
> one of the remaining sources of FUD that people say "yeah but you can't use 
> large parts of the standard library without the GC".
> 
> And for things that are useful and easiest done with GC it would be nice to have 
> an alternative that doesn't depend on the GC - if for no other reason than to 
> address objections.  So the answer is then "yes - you're right, these X 
> functions depend on the GC, but there are similar ones that don't".  (Walter 
> already started that for functions that use the GC for purely legacy reasons but 
> I mean for more difficult cases too.  I know Weka wrote their own versions of 
> some std.algorithm functions for example).  Many things aren't much work, but 
> when you have a lot to do, even small frictions can have big consequences.
> 
> So it's also a documentation question - it's not that easy from the outside last 
> time I looked to see just how easy std.experimental.allocator is to use.

One of the motivations for -betterC is to make D usable without any reliance 
whatsoever on the D runtime library, including the GC. You still get a long list 
of benefits from using D over C++. (The translation above is relying on -betterC.)