Why do C++ programmers are not interested in D?

[Laeeth isharc]

On Wednesday, 20 November 2019 at 02:56:35 UTC, jmh530 wrote:
> On Wednesday, 20 November 2019 at 01:19:32 UTC, Laeeth Isharc 
> wrote:
>> [snip]
>>
>>
>> It won't be that fast and for our purposes we used it in a way 
>> that is easy but will add more overhead.  However for lots of 
>> things just being able to call C++ libraries without manual 
>> work opens up a lot and later if it matters you can make it 
>> faster.  So we can call quite a lot of C++ from D using cling 
>> already and more will follow in time.  We will open source 
>> when ready.
>>
>
> Any additional details you can provide on this, I would find 
> interesting. For instance, are you using a D interpreter and 
> then Cling as the C++ interpreter to get the C++ code working 
> in the interpreter? I wouldn't think you would need Cling if 
> you're compiling ahead of time.
>
> Also, I noticed jupyter-wire at the symmetryinvestments 
> repository as a replacement for jupyterd. Is this meant to be 
> infrastructure that some other tool will build on? Thanks.

Right now we have a DSL written in D.  And cling is used at 
runtime to load a C++ library and register the types and 
functions.  Maybe it's binderoo inside out but without auto 
reloading.

It's a bigger project to make it just work for D and we will do 
that in time and open source when ready.  Probably generating D 
bindings and wrappers.  If anyone wants to be paid to work on 
that part time we are hiring.

You can do crazy things like generate c++ code at runtime in D 
and just call it.  Like string mixins but for C++ and at runtime.

Atila wants to have a D interpreter or JIT.  I think that would 
be very powerful, particularly if you could allow incremental 
compilation like with cling.

I had a crazy thought of repurposing the ctfe back end written by 
Stefan Koch for that though I guess it would need better memory 
management in DMD first.

It feels to me that it's an ambitious project though not an 
enormous one to have D being able to just call C++ by parsing 
headers and vice versa (via introspecting on D side and compiling 
generated cpp headers as a string at runtime / startup).

At that point you have C++ libraries and can incrementally 
replace a C++ codebase with D.  Maybe not quite zero overhead but 
for us make it work then make it fast.

Jupyter wire allows you to write Jupyter kernels in D.  We use it 
for our DSL.  You could hook up to drepl now and if we had a D 
interpreter you could use that instead.

Sebastiaan Koppe just created a pull request to add Jupyter 
widgets to Jupyter wire.  He has also written a simple widget in 
D compiling to web assembly.  Somebody wrote part of a widget in 
Rust and it was a tech talk in itself that drew a lot of interest.