On Sunday, 24 November 2019 at 17:53:18 UTC, Paulo Pinto wrote:
> On Sunday, 24 November 2019 at 13:47:42 UTC, Guillaume Piolat Now if the metric is having GUI toolkits in C++, like those from the 90's, then yeah it pretty much lost it, with Qt, WinUI and wxWidgets being the last ones standing.

Basically all GUI engines are written in C/C++, but thanks to current CPUs and JIT compilers you are basically better off using a high level language that can do hot updates (updating the GUI of a running application).

Also, several typical C projects transition to C++. I expect that trend to continue, even if the transition ratio isn't overwhelming:

https://www.openhub.net/languages/compare?utf8=%E2%9C%93&measure=projects&language_name%5B%5D=cpp&language_name%5B%5D=c&language_name%5B%5D=-1&commit=Update

On Sunday, 24 November 2019 at 17:54:56 UTC, Paulo Pinto wrote:
> On Sunday, 24 November 2019 at 15:30:10 UTC, Jab wrote:
>> On Sunday, 24 November 2019 at 13:01:13 UTC, Guillaume Piolat wrote:
>>> [...]
>>
>> There's a big update every 6 years, with a minor update every 6 years, but an update every 3 years.
>>
>>> [...]
>>
>> I think a big part of that was because of MSVC. They weren't C++11 compliant for a long time. Now you do have clang on Windows and I think even chrome/firefox use it as their compiler of choice on Windows instead of Microsoft's compiler. Back then there wasn't really any other C++ compiler on Windows worth using. Both clang/MSVC are kept up to date pretty quickly now.
>
> Other than Intel, PGI and Codegear.

Like I said, no other C++ compiler on Windows worth using.

On Sunday, 24 November 2019 at 23:18:29 UTC, Jab wrote:
> On Sunday, 24 November 2019 at 17:54:56 UTC, Paulo Pinto wrote:
>> On Sunday, 24 November 2019 at 15:30:10 UTC, Jab wrote:
>>> [...]
>>
>> Other than Intel, PGI and Codegear.
>
> Like I said, no other C++ compiler on Windows worth using.

If one doesn't care about performance of generated code nor RAD tooling, naturally they aren't worth using.

On Monday, 25 November 2019 at 06:03:37 UTC, Paulo Pinto wrote:
> On Sunday, 24 November 2019 at 23:18:29 UTC, Jab wrote:
>> On Sunday, 24 November 2019 at 17:54:56 UTC, Paulo Pinto wrote:
>>> On Sunday, 24 November 2019 at 15:30:10 UTC, Jab wrote:
>>>> [...]
>>>
>>> Other than Intel, PGI and Codegear.
>>
>> Like I said, no other C++ compiler on Windows worth using.
>
> nor RAD tooling, naturally they aren't worth using.

If you care about RAD, you're your using the wrong language never mind the compiler.

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.

On Tuesday, 26 November 2019 at 22:42:45 UTC, Laeeth isharc wrote:

> 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.

Maybe Atila can answer better, why the LLVM JIT machinery is not already suitable for that?

I remember that for newCTFE was discarded for startup performance problems, but if the use case is different ...

On Tuesday, 26 November 2019 at 22:42:45 UTC, Laeeth isharc wrote:
> [snip]

Thanks. That was interesting.

On Saturday, 23 November 2019 at 19:35:55 UTC, Mark wrote:
> I can perfectly imagine a C# programmer (even library author) saying "I love generics, extension methods and lambda expressions, but that's good enough for me. I can live without `static if` and a full CTFE engine". That said, it's not like I've done a survey among the C#, Java, C++, Go, Rust, or Swift crowd. Maybe most programmers (or at least library authors) in these languages *do* wish for D-level MP support in their language. But that's a question that needs to be investigated; the answer is not obvious at all IMO.

C# and Java have extremely powerful runtime reflection and code generation capabilities. It may not be well known, but there are frameworks out there that look at classes in other libraries at runtime and dynamically generate new bytecode to wrap those for various purposes. Some versions of JBoss did this to inject authorization checks in EJBs: they'd create a new anonymous implementation of the EJB's interface that wraps every function with such a test that forwards to the actual EJB implementation.

In most cases, however, you get away without explicit code generation. You can quite easily call unknown methods through reflection or query and change the values of variables. All of this can also ignore all access specifiers as it bypasses the compiler.

These features are really, really powerful cannons. Also, nothing prevents you from aiming them at your own feet. It's a good thing that they are generally used very sparingly (except when they aren't).