On Monday, 27 January 2020 at 00:19:56 UTC, Laeeth Isharc wrote:
> [...]
> 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.
>
> [...]

I want to add a "scope of usefulness" axis and a "LANGUAGE for PURPOSE" icons to the picture.
> [...]
> 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!
> 
> [...]

I agree with the sentiment that "D vs. Not C++" sentiment. I would rewrite the Node.JS game I maintain in D instantly if there were a trustworthy concurrent moving gc available, and if I could get a standalone compiler binary to run without entering sudo.

On Monday, 27 January 2020 at 05:54:20 UTC, FeepingCreature wrote:
> [...]
> 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.
> [...]

I imagine 'we need to urgently ship this feature to unblock another team, but compiler bugs stop us' might be a common scenario too.

On Tuesday, 28 January 2020 at 00:15:55 UTC, James Lu wrote:
> On Monday, 27 January 2020 at 05:54:20 UTC, FeepingCreature wrote:
>> [...]
>> 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.
>> [...]
>
> I imagine 'we need to urgently ship this feature to unblock another team, but compiler bugs stop us' might be a common scenario too.

Just stay at a version of the compiler you know works and then only upgrade once you can actually afford to spend time fixing such quirks.

On Tuesday, 28 January 2020 at 00:15:55 UTC, James Lu wrote:
> On Monday, 27 January 2020 at 05:54:20 UTC, FeepingCreature wrote:
>> [...]
>> 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.
>> [...]
>
> I imagine 'we need to urgently ship this feature to unblock another team, but compiler bugs stop us' might be a common scenario too.

I'm sceptical, have you honestly been in this situation yourself?

From my experience using D in production we have never had a compiler bug that blocked our work. We upgrade the compiler every 6 months. The last bug encountered that meant we could not upgrade was in 2015 -- can't remember or be bothered to check the exact version. It did not block us because we always test the new compiler before pulling the switch, as we do for our C++ and Python code as well.

Cheers,
Norm

On 1/27/20 8:55 PM, Craig Dillabaugh wrote:
> 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.

I'm totally agree to you too. But this is a workaround and doesn't negate low availability of D programmers. This complicates hiring a bit but this complexity is reasonable I think.

On Tuesday, 28 January 2020 at 00:14:30 UTC, James Lu wrote:
> if I could get a standalone compiler binary to run without entering sudo.

You can: https://dlang.org/install.html

Bastiaan.