Is there a future where we can see WebAssembly as part of D? Seeing Rusts backbone already producing wasm is impressive.

WebAssembly currently does not support a GC ...so it fair the assume that this will be the main issue for LDC?

I see the move towards one language for back and front-end as the future.

On Thursday, 6 July 2017 at 15:34:08 UTC, Wulfklaue wrote:
> Is there a future where we can see WebAssembly as part of D? Seeing Rusts backbone already producing wasm is impressive.
>
> WebAssembly currently does not support a GC ...so it fair the assume that this will be the main issue for LDC?
>
> I see the move towards one language for back and front-end as the future.

I'm just curious how it doesn't support GC? Like if you can allocate and free memory then you can have a GC.

On Thursday, 6 July 2017 at 17:19:34 UTC, bauss wrote:
> I'm just curious how it doesn't support GC? Like if you can allocate and free memory then you can have a GC.

Currently there is no native GC build into WebAssembly. This is planned for the future.

If your language is designed around allocating and freeing memory manually, you have no issue with WebAssembly. C/C++/Rust ...

But you can not program in D fashion ( where the GC takes care of things ). It means you need to write the allocation and freeing all the time for any code that targets WebAssembly. hat also means no std library etc ... Think of it as writing pure @nogc code ( what currently breaks like half the standard library ).

WebAssembly has plans for a native GC build into the design for the next version so that languages that have there own GC, can target this and not run into the issue of manually allocating and freeing. Think C#, Go, ...

The other option is for the language to have there own GC included that targets WebAssembly into the compiled wasm file but that adds overhead. And is more work for the language to support. That is why a lot of languages that have GCs are on the fence and are waiting for the default GC.

GC are nice and well but at times having a pure no-gc language does have its advantages ;)

On Thursday, 6 July 2017 at 17:19:34 UTC, bauss wrote:
> On Thursday, 6 July 2017 at 15:34:08 UTC, Wulfklaue wrote:
>> Is there a future where we can see WebAssembly as part of D? Seeing Rusts backbone already producing wasm is impressive.
>>
>> WebAssembly currently does not support a GC ...so it fair the assume that this will be the main issue for LDC?
>>
>> I see the move towards one language for back and front-end as the future.
>
> I'm just curious how it doesn't support GC? Like if you can allocate and free memory then you can have a GC.

People usually point to this design doc:

https://github.com/WebAssembly/design/blob/master/GC.md

I don't know much about GC or their IR, but I get the impression it's more about integrating with the browser's GC, so you can seamlessly pass objects to javascript.  I believe people have written their own GCs that target webasm, so the D GC can likely be made to do the same.

On Thursday, 6 July 2017 at 18:26:18 UTC, Joakim wrote:
> On Thursday, 6 July 2017 at 17:19:34 UTC, bauss wrote:
>> On Thursday, 6 July 2017 at 15:34:08 UTC, Wulfklaue wrote:
>>> Is there a future where we can see WebAssembly as part of D? Seeing Rusts backbone already producing wasm is impressive.
>>>
>>> WebAssembly currently does not support a GC ...so it fair the assume that this will be the main issue for LDC?
>>>
>>> I see the move towards one language for back and front-end as the future.
>>
>> I'm just curious how it doesn't support GC? Like if you can allocate and free memory then you can have a GC.
>
> People usually point to this design doc:
>
> https://github.com/WebAssembly/design/blob/master/GC.md
>
> I don't know much about GC or their IR, but I get the impression it's more about integrating with the browser's GC, so you can seamlessly pass objects to javascript.  I believe people have written their own GCs that target webasm, so the D GC can likely be made to do the same.

Wow, quite an opportunity for D I'd say. A D frontend able to interop with the myriads of existing Javascript libraries, using the browser's GC and its DOM as GUI toolkit. Coupled with a vibe.d backend. Frontend and backend sharing D files describing their common interface.

On Thursday, 6 July 2017 at 18:26:18 UTC, Joakim wrote:
> so you can seamlessly pass objects to javascript.  I believe people have written their own GCs that target webasm, so the D GC can likely be made to do the same.

You would have to emulate the stack...

On Thursday, 6 July 2017 at 22:58:36 UTC, Ola Fosheim Grostad wrote:
> On Thursday, 6 July 2017 at 18:26:18 UTC, Joakim wrote:
>> so you can seamlessly pass objects to javascript.  I believe people have written their own GCs that target webasm, so the D GC can likely be made to do the same.
>
> You would have to emulate the stack...

WebAssembly has linear memory that you can scan just like normal memory. C programs use it for those values on the stack that it needs a pointer to. For other values they are put on the safe stack, you can only read the value not the memory backing it.

So there is a problem of pointers going on the safe stack so you need to make sure to not optimise those pointers to the safe stack.

But in short, the D GC will work just fine, just need to be a bit carefull with pointers on the stack.

Cheers, Jakob.

Here is some nice stuff:

https://youtu.be/MiLAE6HMr10?t=32m5s

DotNetAnywhere compiled to webasm = C# in browsers. *lol*

Funny thing being, that it compiles down to a 250k download, what is actually much less then some of the angular 1/2/4 code that we have at work.

And people at work wonder why i am a strong advocate for WebAssembly... O_o