On Thursday, 26 November 2020 at 11:06:11 UTC, Guillaume Piolat wrote:
> The _one_ factor that made C++ win against its competition - despite its shortcomings - is by far that it could already compile your C code. So it's an easier sell if you can just change the compiler.
>
> You can't convince to change language someone who has already an existing codebase, it would just make life worse in most of cases.

This could also be the killer feature for D, as Atila has said. While one can't yet automatically generate D headers for an arbitrary CPP codebase, I don't think that either Rust or Go are as far in C++ interop as D currently is.

On Thursday, 26 November 2020 at 13:01:28 UTC, Dukc wrote:

> This could also be the killer feature for D, as Atila has said. While one can't yet automatically generate D headers for an arbitrary CPP codebase, I don't think that either Rust or Go are as far in C++ interop as D currently is.

Swift is going for C++ interoperability as well [1]. I assume they're going to do it the same way as the C interoperability, by using the Clang compiler.

[1] https://github.com/apple/swift/blob/main/docs/CppInteroperabilityManifesto.md

On Thu, Nov 26, 2020 at 2:15 PM Jacob Carlborg via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Thursday, 26 November 2020 at 13:01:28 UTC, Dukc wrote:
>
> > This could also be the killer feature for D, as Atila has said. While one can't yet automatically generate D headers for an arbitrary CPP codebase, I don't think that either Rust or Go are as far in C++ interop as D currently is.
>
> Swift is going for C++ interoperability as well [1]. I assume they're going to do it the same way as the C interoperability, by using the Clang compiler.
>
> [1]
>
> https://github.com/apple/swift/blob/main/docs/CppInteroperabilityManifesto.md


https://wiki.dlang.org/Calypso

On Thursday, 26 November 2020 at 09:19:48 UTC, Andre Pany wrote:

> I assume every developer has another opinion what is the most import thing missing in D.
> (I never ever faced any performance issues with GC and I am super satisfied with Visual Studio Code.

About GC, I use D as scripting language mainly, and never noticed GC problems.  GC is, indeed, a must for scripting (Thanks D for GC)

Integration in VSCode :

- "reflection/autocomplete": This is one of the most appreciated features in development IDEs and a really good way to learn about the language and it's existing libraries (learn on demand :-) ).  This is a must because the competence with other "similar" productive languages that offer a powerful tool chain (Not only Rust or Go, I consider Python and Typescript natural D competitors).

- Debugging support:  how can I inspect structured data/objects friendly? printing to the console or assigning properties to temporal vars is not a productive way:  may be a good tutorial about how to inspect in D using VSCode will be appreciated from experienced D developers (Linux, pls :-) )... in my opinion, this is a next DConf must!!! (Like the one in 2014).

I know I'm very reiterative with this features (you can find me in other forum posts arguing about the same)... In my very personal opinion, D usage will grow as soon as it will integrate on VSCode IDE as well as typescript does. I wish I had the time and experience to help on this particular point.

> From my point of view the most important thing is to get the community (all of us) to speak more loud about D. Advertise D, create more blogs, try to get D in the company's they are working...

I agree

Personally, I add references to D using any excuse :-) (in spanish, sorry)

i.e.:
https://es.quora.com/Por-qu%C3%A9-la-mayor%C3%ADa-de-los-desarrolladores-estudian-solo-lenguajes-muy-simples-como-JavaScript-y-Python-en-lugar-de-aprender-un-lenguaje-verdadero-como-C-2/answer/Antonio-Cabrera-52

On Thursday, 26 November 2020 at 09:49:51 UTC, Ola Fosheim Grostad wrote:

> Isnt await just syntactic sugar for a promise/future?

No, not really, but it's used together with promises or they're used under the hood.

> If you can provide an example of what await should expand into then I might be able to add it to my experimental D compiler and you could then write a DIP.

Async/await is basically a coroutine. It allows a function to be suspended and resumed. Here's an example of how the code could look like in D:

async int foo()
{
    await sleep(1.seconds); // simulate work that takes long time
    writeln("foo");
    return 1;
}

async int bar()
{
    writeln("bar");
    return 2;
}

async void main()
{
    auto a = foo();
    auto b = bar();

    writeln("main");
    writeln(await a + await b);
}

The output of the above would be:

bar
main
foo
3

The control flow is something like this:

1. `foo` is called
2. `foo` is awaiting for `sleep`
3. `sleep` returns a promise which is not fulfilled
4. This causes `foo` to suspend (return) and control comes back to `main`
5. `bar` is called
6. `bar` has no suspension points (awaits) so this is more or less a synchronous function
7. "bar" is printed
8. `bar` returns a fulfilled promise with the value `2`
9. Control comes back to `main`
10. "main" is printed
11. `main` awaits `a`. If the `a` promise is not fulfilled at this point `main` is suspended
12. `foo` is resumed at some point in the future
13. "foo" is printed
14. `foo` returns a fulfilled promise with the value `1`
15. `main` is now resumed since `a` has been fulfilled
16. `main` awaits `b`
17. `b` is already fulfilled, which means `main` doesn't have to suspend
18. The addition is performed
19. "3" is printed

I'm not entirely sure on when `foo` will be resumed. Probably decided by a scheduler in the runtime.

To have the full experience of async/await, an event loop in the runtime is necessary and non-blocking IO.

When a function is suspended, all its state (stack and registers) need to be saved. When it's later resumed, the state need to be restored. I'm not entirely sure how async/await functions are different from fibers, which already exists in the D runtime.

--
/Jacob Carlborg

On Thursday, 26 November 2020 at 12:01:57 UTC, Ola Fosheim Grostad wrote:
>
> I dont think this is the case. You are just reading the general forum and not the learn forum :).

I read both but the activity in the learn forum is pretty low.

On Thursday, 26 November 2020 at 08:57:18 UTC, Daniel Kozak wrote:
>
> Maybe metaprograming?
>

This definitely. When I program C++ I kind of avoid meta programming because I know I will run into trouble or don't exactly know how to do it. In D it's more like "hey I can do this with meta programming" and then I just do it, this while I'm an amateur when it comes to D.

On Thursday, 26 November 2020 at 14:18:55 UTC, Jacob Carlborg wrote:
> On Thursday, 26 November 2020 at 09:49:51 UTC, Ola Fosheim Grostad wrote:
>
>> Isnt await just syntactic sugar for a promise/future?
>
> No, not really, but it's used together with promises or they're used under the hood.
>
>> If you can provide an example of what await should expand into then I might be able to add it to my experimental D compiler and you could then write a DIP.
>
> Async/await is basically a coroutine. It allows a function to be suspended and resumed. Here's an example of how the code could look like in D:

Ok, we need something that respects shared/nonshared. If aync/await involves multiple threads then we need something principled.

Maybe some runtime level thing that can offload computations but is as easy to use as await. Perhaps even offload to the GPU.

But I guess people want it for I/O.

Clearly a case where a library solution has to come first.

> When a function is suspended, all its state (stack and registers) need to be saved. When it's later resumed, the state need to be restored.

This should be possible with LLVM stop points.

On 27/11/2020 3:45 AM, IGotD- wrote:
> On Thursday, 26 November 2020 at 12:01:57 UTC, Ola Fosheim Grostad wrote:
>>
>> I dont think this is the case. You are just reading the general forum and not the learn forum :).
> 
> I read both but the activity in the learn forum is pretty low.

Of the many places I monitor for questions, Discord is the most active.

On 2020-11-26 15:55, Ola Fosheim Grostad wrote:

> Ok, we need something that respects shared/nonshared. If aync/await involves multiple threads then we need something principled.

That varies between implementations. You can either do single threading. Or have multiple threads (as many as the computer has cores) with one event loop per thread. Each async function can only be executed on a single thread. Or multiple threads with a single event loop and the async functions can run on multiple threads. That is, run on one thread, be suspended and be resumed on another thread.

For example, Erlang was initially only single threaded. In 2006 it started to take advantage of multi-core.

Go will automatically create a new thread if calling a C function or a blocking system call.

> Maybe some runtime level thing that can offload computations but is as easy to use as await. Perhaps even offload to the GPU.
> 
> But I guess people want it for I/O.

Yes, that's the main reason. If you don't have anything to wait for, there's not much point in suspending a function.

> This should be possible with LLVM stop points.

Yes. C++20 got support for coroutines, which also means support in LLVM.

-- 
/Jacob Carlborg