February 27, 2022

On Sunday, 27 February 2022 at 10:16:23 UTC, Paulo Pinto wrote:
...

>

By the way, NVidia now has a A Team collection of C++ people,

Yes, good work is being done there, some of which can be co-opted today by dcompute pioneers. The CUB library, in particular, is worth a look. It shows how world class GPU performance can be achieved using C++. It also, much like Boost, reminds one of how fortunate we are to have D.

>

it is quite clear that C++ has won the wars of programming GPU hardware and SYSCL will cement the same for FPGA design.

Without a doubt C++ is quite popular in the GPU space, I used C++/CUDA myself for years but, even in its early/can-certainly-improve form, I much prefer dcompute.

C++ is today's safe choice for both CPU and GPU performance work but less conservative programmers/companies would do well to examine alternatives. The productivity improvement can be (was for me) substantial.

Finally, if D/dcompute is just too risky for you I'd suggest taking a look at Sean Baxter's circle variant of C++. If D/dcompute were unavailable I'd take circle for a spin.

February 27, 2022

On Sunday, 27 February 2022 at 15:17:01 UTC, Bruce Carneal wrote:

>

C++ is today's safe choice

One problem is that the people left in C++ have avoided going with either Java, C#, or any of the new native languages. The population that said no those AND to the newer native languages skews towards very conservative choices. As such no language seen as "alternative" enter their worldview because "only C++ can do it".

Even if you compete with them, the C++ competition will still won't believe there are alternatives to C++. In the real world, starting a C++ codebase today is much less cost-effective than in D, and this debt cause a lot of dividend payments, and also it costs a lot of senior C++ engineers to make sense of the most complicated programming language we have.

The only way is to displace the incumbent not convince them.

February 27, 2022

On Sunday, 27 February 2022 at 16:37:42 UTC, Guillaume Piolat wrote:

>

On Sunday, 27 February 2022 at 15:17:01 UTC, Bruce Carneal wrote:

>

C++ is today's safe choice

One problem is that the people left in C++ have avoided going with either Java, C#, or any of the new native languages. The population that said no those AND to the newer native languages skews towards very conservative choices. As such no language seen as "alternative" enter their worldview because "only C++ can do it".

Even if you compete with them, the C++ competition will still won't believe there are alternatives to C++. In the real world, starting a C++ codebase today is much less cost-effective than in D, and this debt cause a lot of dividend payments, and also it costs a lot of senior C++ engineers to make sense of the most complicated programming language we have.

The only way is to displace the incumbent not convince them.

Languages one their own are meaningless, you aren't competing with C++, you are competing with platforms and industry standards that happen to make use of C++.

Disrupting those platforms and industry standards with D, that should be the focus.

February 27, 2022

On Sunday, 27 February 2022 at 16:37:42 UTC, Guillaume Piolat wrote:

>

On Sunday, 27 February 2022 at 15:17:01 UTC, Bruce Carneal wrote:

>

C++ is today's safe choice

One problem is that the people left in C++ have avoided going with either Java, C#, or any of the new native languages. The population that said no those AND to the newer native languages skews towards very conservative choices. As such no language seen as "alternative" enter their worldview because "only C++ can do it".

Yes. It's frustrating and pointless to try to "convince" those who have made up their mind, doubly so with those who lazily prefer to predict failure for anything new rather than cheer on others working to improve upon the status quo.

>

Even if you compete with them, the C++ competition will still won't believe there are alternatives to C++. In the real world, starting a C++ codebase today is much less cost-effective than in D, and this debt cause a lot of dividend payments, and also it costs a lot of senior C++ engineers to make sense of the most complicated programming language we have.

Yes. Staying with C++, especially if you've got a very large code base, makes more sense to me than starting a new C++ project.

February 27, 2022

On Sunday, 27 February 2022 at 18:02:54 UTC, Bruce Carneal wrote:

>

...

Yes. Staying with C++, especially if you've got a very large code base, makes more sense to me than starting a new C++ project.

How do you start a new project in D for PlayStation 5/Switch/XBox or get a AUTOSAR certification for deployment of D written software?

Unless one is willing to do the work Unity has been doing with C#, or Ferrous Systems is doing with Rust, D isn't going to the choice, rather those.

February 27, 2022

On Sunday, 27 February 2022 at 19:32:47 UTC, Paulo Pinto wrote:

>

How do you start a new project in D for PlayStation 5/Switch/XBox

You get LDC/GCC to emit binary code for whatever platform they are using, and port the needed system headers (with agreement from the vendor) to your desired language. Chances are, the headers are in C or C-ABI C++ for that reason.

>

or get a AUTOSAR certification for deployment of D written software?

People are writing software for ships with D, so probably they can use D for cars.

>

Unless one is willing to do the work Unity has been doing with C#, or Ferrous Systems is doing with Rust, D isn't going to the choice, rather those.

You can write bindings for just the API you need. Plus if you go the BindBC way, it break all linking dependencies, making it really easy to port and possibly be more portable than the native vendor SDK. Bonus points: build fast and you avoid, say, an IDE lock-in.

For Auburn Sounds we translated headers and implemented VST2/VST3/AU/AAX/LV2 and Apple headers. We re-used X11 headers translated by somebody in the D community. All this work is manual and not particularly heroic, as you pay it only once. Others have done this for Java, C# or Delphi.

Writing GPGPU in D is not any more complicated than adding the DUB line for derelict-cuda or derelict-opencl really.

It's really simple, writing bindings and platform support is usually a one-time cost to pay, while using an unproductive language is a lifetime and mental cost that will close product opportunities by being annoying day-in, day-out.

If you want to use D (and you should) you are going to make the platform support as you go.

A freelancer wouldn't recoup the cost, but a product-based business will.

February 27, 2022

On Sunday, 27 February 2022 at 19:32:47 UTC, Paulo Pinto wrote:

>

On Sunday, 27 February 2022 at 18:02:54 UTC, Bruce Carneal wrote:

>

...

Yes. Staying with C++, especially if you've got a very large code base, makes more sense to me than starting a new C++ project.

How do you start a new project in D for PlayStation 5/Switch/XBox or get a AUTOSAR certification for deployment of D written software?

We're a ways out but SPIR-V looks like it has opened a path to multi-language deployments on the consoles. I've not looked at the AUTOSAR world.

>

Unless one is willing to do the work Unity has been doing with C#, or Ferrous Systems is doing with Rust, D isn't going to the choice, rather those.

I agree. If the effort involved in getting D off the ground in a new domain outweighs the perceived long range benefits then I'd expect the team tackling a new project to have chosen another language. I view such choices as an indication of where D was when those choices were made rather than as a pronouncement of permanent exclusion.

I believe that D can and will evolve to lower the costs of entering new domains: seamless/automated importC "bindings", better support in SoC environments, dcompute maturation, ... As/if it does, the economics change and we're likely to see forays into new areas.

February 28, 2022

On Sunday, 27 February 2022 at 19:32:47 UTC, Paulo Pinto wrote:

>

On Sunday, 27 February 2022 at 18:02:54 UTC, Bruce Carneal wrote:

>

...

Yes. Staying with C++, especially if you've got a very large code base, makes more sense to me than starting a new C++ project.

How do you start a new project in D for PlayStation 5/Switch/XBox or get a AUTOSAR certification for deployment of D written software?

Unless one is willing to do the work Unity has been doing with C#, or Ferrous Systems is doing with Rust, D isn't going to the choice, rather those.

Unity isn't shipping C# on consoles, they are shipping C++ code, using IL2CPP, then they compile the C++ to target the various platforms..

You guys enumerates features that competes with C/C++/Rust, why the hell the idea to compete with C#/F# came from? Someone wants to hit walls rather than profiting from D's strengths as a System language..

There is 2 visions for the languages that is clashing, sorting this out should be the priority.. it obviously prevents us to move forward..

February 28, 2022

On Sunday, 27 February 2022 at 16:56:41 UTC, Paulo Pinto wrote:

>

Languages one their own are meaningless, you aren't competing with C++, you are competing with platforms and industry standards that happen to make use of C++.

Disrupting those platforms and industry standards with D, that should be the focus.

I agree with this so much, you nailed it!

February 28, 2022

On Monday, 28 February 2022 at 01:47:47 UTC, meta wrote:

>

On Sunday, 27 February 2022 at 19:32:47 UTC, Paulo Pinto wrote:

>

On Sunday, 27 February 2022 at 18:02:54 UTC, Bruce Carneal wrote:

>

...

Yes. Staying with C++, especially if you've got a very large code base, makes more sense to me than starting a new C++ project.

How do you start a new project in D for PlayStation 5/Switch/XBox or get a AUTOSAR certification for deployment of D written software?

Unless one is willing to do the work Unity has been doing with C#, or Ferrous Systems is doing with Rust, D isn't going to the choice, rather those.

Unity isn't shipping C# on consoles, they are shipping C++ code, using IL2CPP, then they compile the C++ to target the various platforms..

You guys enumerates features that competes with C/C++/Rust, why the hell the idea to compete with C#/F# came from? Someone wants to hit walls rather than profiting from D's strengths as a System language..

There is 2 visions for the languages that is clashing, sorting this out should be the priority.. it obviously prevents us to move forward..

Unity is shipping machine code into consoles.

How that C# code got massaged into machine code is irrelevant.

C++ used to be a source translator into C until Walter shipped the first proper compiler, so what.

Whatever vision, doesn't matter if D doesn't know where it wants to be.

D had an opportunity to make it big like C# on games industry, so here is where the idea comes from.