https://ibb.co/w6gQWwJ

What other details could be added? I have some experience with using Node.js as a systems language, so I can add that. I don't have experience with Go or Rust, so I can add that.

Thanks to the use of symbolic inclusion, I can very easily modify this sketch

On Sunday, 26 January 2020 at 18:50:05 UTC, James Lu wrote:
> https://ibb.co/w6gQWwJ
>
> What other details could be added? I have some experience with using Node.js as a systems language, so I can add that. I don't have experience with Go or Rust, so I can add that.
>
> Thanks to the use of symbolic inclusion, I can very easily modify this sketch

It's pretty difficult to capture in a couple of dimensions.  And whether you should use D very much depends on who you are and what you are trying to achieve.

I think the people at Weka really know C++ pretty well.  And the build problems they had with D in the beginning are pretty hard to top.  But I don't think the technical leadership would say "well, we should have used C++".

So one of the more prominent examples of successful use of D within the enterprise happens to have conditions that were quite extreme in relation to your reasons not to use D, and yet their lived experience was quite different.  An anomaly like that might make one think about what's missing.

You don't necessarily need to port C++ libraries to use them.  D does have extern (C++) - it's by no means perfect and has rough edges but it is usable.  DPP will work for some things.  If you're really good with C++ you can write tools to generate wrappers automatically using libclang, libtooling or cling.

And supposing you did have to do a one-off port or writing of manual bindings/wrappers.
 That's an upfront cost that in economic terms can be amortised over the life of the project.

Of course not everyone is in a context where it's possible to think in economic terms; there are social factors at work often.  Even then though, one way to address those is to have skin in the game.  If someone voluntarily does a lot of preparatory work or work that takes away the technical risk and perceptions of that then social factors might in some cases fade away.   Only quite unusual people would do that, it is true.  But people adopting D in the enterprise at this point are not entirely ordinary people.

I think D is unusual in its range.  So a comparison of D versus C++ might be appropriate in some cases, but in others it's D versus C++, python, Perl, bash and VBA!

If someone doesn't think they should use D, they probably shouldn't use D.  I think you can only persuade people when they are coming towards you anyway, or at least it's much easier that way.

On Sunday, 26 January 2020 at 18:50:05 UTC, James Lu wrote:
> https://ibb.co/w6gQWwJ
>
> What other details could be added? I have some experience with using Node.js as a systems language, so I can add that. I don't have experience with Go or Rust, so I can add that.
>
> Thanks to the use of symbolic inclusion, I can very easily modify this sketch

In my almost 10 years of using D I have not come across any compiler bugs that I couldn't easily work-around tbh.

Even more so today I rarely get experience one and I have multiple different types of D projects with thousands of lines of code.

And that's despite me almost exclusively using Windows which is often the platform left behind by the D community.

Like every time I see someone reporting a bug for the compiler here on the forums it's always some obscure scenario that isn't a scenario you usually get into and often there are work-arounds.

That isn't to say D doesn't have problems etc. but I think your little graphic is exaggerating a lot about the state of D.

On Monday, 27 January 2020 at 03:05:57 UTC, bauss wrote:
> Like every time I see someone reporting a bug for the compiler here on the forums it's always some obscure scenario that isn't a scenario you usually get into and often there are work-arounds.
>

The threat profile of compiler bugs is rarely "we can't move forward with this functionally", but that's not the problem - the problem is "we assumed this works and now our code crashes in production and makes us look bad." And work-arounds rely on you remembering to apply them - not every compiler bug is a crash at compiletime. D has had more than its fair share of miscompilation bugs.

And those obscure scenarios are usually reductions of more complex but individually plausible projects. Of course it looks obscure with the business case filed off.

On Monday, 27 January 2020 at 05:54:20 UTC, FeepingCreature wrote:
> On Monday, 27 January 2020 at 03:05:57 UTC, bauss wrote:
>> Like every time I see someone reporting a bug for the compiler here on the forums it's always some obscure scenario that isn't a scenario you usually get into and often there are work-arounds.
>>
>
> The threat profile of compiler bugs is rarely "we can't move forward with this functionally", but that's not the problem - the problem is "we assumed this works and now our code crashes in production and makes us look bad." And work-arounds rely on you remembering to apply them - not every compiler bug is a crash at compiletime. D has had more than its fair share of miscompilation bugs.
>
> And those obscure scenarios are usually reductions of more complex but individually plausible projects. Of course it looks obscure with the business case filed off.

C++ has compiler bugs too, D isn't alone in that domain.

In fact GCC has more open bugs than D currently does. (According to a quick search.)

I would say that D probably has more "critical" bugs though, so I'll give that one.

But I do think this is still biased towards C++ and isn't being fair on D.

On Monday, 27 January 2020 at 05:54:20 UTC, FeepingCreature wrote:
> On Monday, 27 January 2020 at 03:05:57 UTC, bauss wrote:
>> Like every time I see someone reporting a bug for the compiler here on the forums it's always some obscure scenario that isn't a scenario you usually get into and often there are work-arounds.
>>
>
> The threat profile of compiler bugs is rarely "we can't move forward with this functionally", but that's not the problem - the problem is "we assumed this works and now our code crashes in production and makes us look bad." And work-arounds rely on you remembering to apply them - not every compiler bug is a crash at compiletime. D has had more than its fair share of miscompilation bugs.
>
> And those obscure scenarios are usually reductions of more complex but individually plausible projects. Of course it looks obscure with the business case filed off.

C++ has compiler bugs too, D isn't alone in that domain.

In fact GCC has more open bugs than D currently does. (According to a quick search.)

I would say that D probably has more "critical" bugs though, so I'll give that one.

But I do think this is still biased towards C++ and isn't being fair on D.

On Sunday, 26 January 2020 at 18:50:05 UTC, James Lu wrote:
> https://ibb.co/w6gQWwJ
>
> What other details could be added? I have some experience with using Node.js as a systems language, so I can add that. I don't have experience with Go or Rust, so I can add that.
>
> Thanks to the use of symbolic inclusion, I can very easily modify this sketch

I don't agree with the picture in my opinion. I think that D and C++ have about the same complexity for beginners. You can program very C like in both C++ and D. However, when you start to tread into more complex territory, this is when the complexity of C++ exponentially increase. C++ projects tend to become spaghetti faster. D reduces this complexity compared to C++.

Big projects with a lot of files will probably benefit from D as D is more compact, readable and requires less files. The libraries of D are usually more convenient as well.

The reason I wouldn't use D in project is stability and availability of D programmers. All D compilers have bugs and are not as stable as GCC or Clang and I would not use D for mission critical projects and in this case C/C++ is a better choice for now.

It also depends on the projects. C/C++ is still king in low level programming and D has hard times to compete here. With applications it depends. D is held back by not having a true multi platform GUI library. C++ has Qt for example. When it comes other types of programs then D is really a viable option.

The picture is kind of simplistic and therefore cannot explain the complex decisions why a project should use C++ or D.

On 1/27/20 12:52 PM, IGotD- wrote:
> Big projects with a lot of files will probably benefit from D as D is more compact, readable and requires less files. The libraries of D are usually more convenient as well.

I have two implementation of one project in D and C++. D version contains less files and their content is shorter (less boiler plate code) and D version has a bit more functionality. Making proof of concept in D (in my domain at least) is more pleasant and productive due to meta programming.

> 
> The reason I wouldn't use D in project is stability and availability of D programmers. All D compilers have bugs and are not as stable as GCC or 

I completely agree to low availability of D programmers but don't agree to statement about stability. Both D and C++ compilers have bugs. I stumbled only once at gcc bug but that was a real problem. D compiler bugs were much more easy to solve/workaround.

On Sunday, 26 January 2020 at 18:50:05 UTC, James Lu wrote:
> https://ibb.co/w6gQWwJ
>
> What other details could be added? I have some experience with using Node.js as a systems language, so I can add that. I don't have experience with Go or Rust, so I can add that.
>
> Thanks to the use of symbolic inclusion, I can very easily modify this sketch

I dont understand this representation. Easy Hard, should give a kind of vector.
In my opinion this stinks. You don't get if something is best.

On Monday, 27 January 2020 at 10:12:06 UTC, drug wrote:
> On 1/27/20 12:52 PM, IGotD- wrote:
>> Big projects with a lot of files will probably benefit from D as D is more compact, readable and requires less files. The libraries of D are usually more convenient as well.

clip

>
> I completely agree to low availability of D programmers but don't agree ....

If I were managing a D project I personally wouldn't have any qualms about hiring skilled C++ developers who expressed a willingness to learn D.  I bet in many cases it would only be a matter of weeks before they were more productive in D than they were with C++ for most run-of-the-mill coding tasks. Writing more advanced code might take longer. While D certainly has some differences to C++ I think the skill sets are highly transferable.