In case WASM is future of WEB/EmbeddedVM Dlang should ride the wave.
This means not only compile to WASM/WASI by compilers but bring to it Dlang-RT (bytecode it not useful without some RT).
When Dlang can generate same program for WASM as for terminal (with same RT not only "u can use templates only") it will lead a lot of people to Dlang, it will lead business too with money cause they want it, they ready to pay for it.
No?

On Monday, 27 May 2019 at 12:33:16 UTC, KnightMare wrote:
> In case WASM is future of WEB/EmbeddedVM Dlang should ride the wave.
> This means not only compile to WASM/WASI by compilers but bring to it Dlang-RT (bytecode it not useful without some RT).
> When Dlang can generate same program for WASM as for terminal (with same RT not only "u can use templates only") it will lead a lot of people to Dlang, it will lead business too with money cause they want it, they ready to pay for it.
> No?

Do you know about e.g. Spasm?

https://forum.dlang.org/thread/lhkhbtpkbliddonfwliv@forum.dlang.org

Also, this year there are two GSoC students working on WASM related topics (runtime hook conversion + independence of D from the C standard library).

See also: https://github.com/dlang/projects/issues?q=is%3Aissue+is%3Aopen+label%3Agsoc19

I understand that maybe I looks as troll and raise next holy war, maybe I still have adolescent maximalism..
But
How much can you say "It is not for such things"?
Dlang not for WEB. Its not for GUI. Its not for mobiles.
Its not for DB-ORM/network/FPGA/AI. (We have wrappers to some libs, use it boy)
Well, main area is terminal tools only.
With best UFCS/CTFE/GC/Exceptions/mixins/OOP/FP/InternalAsm/SSEtypes.
(Sounds like "mountain gave birth to a mouse").
And we want to add bare-metal RT to this without GC.
Well, how many developers need bare metal RT from all possible programming tasks in the world? 0.001%? 0.01%? Maybe 0.1% not more. Do they have another tools for such thing? C/rust? Probably has.
What the future of D? Replacement C/C++ in bare metal/terminal tools? It won't happen. It will be used but will not replace.
Do we hear some excuse "Yes, I know but I like do such job" or roadmap to heaven/communism/orAnotherSomethingGreat?
What will happened with Dlang after.. hmm.. bus factor with leads? Does Dlang has another lovely dictators who will continue to lead the flock to a bright future?
(Will we remain a small sect of lovers of Mars and not Snickers?)

3 men can write collections lib (like STL) that will be enough for bare metal without using GC in one year. So this is not future big target.

D can bypass Kotlin/Native, rust, C++, Go, Swift in many fields when you set goals correctly.

WASM is one of great target. (Yes, I still remember VM/Flash is bad, VM/Silverlight is bad, pure HTML5/Js are Rulez! Oh, we need some VM for WEB)
LDC can generate WASM code, give to it RT, port Dlang-RT/GC to WASM/VM that can be embedded in any app, that can execute logic in browsers with their WASM/VM.
Yes, is big task and some big corp with big wallet will write GC for WASM.
Will Dlang be ready run it program in WASM enironment from the box?

LLVM can generate platform code at runtime. Is it time to move the DMD to LLVM? Then Dlang can be used for writting VMs.

Can this/new runtime run on mobile devices? This is another great target: run Dlang on mobiles. ("LDC can generate code for Android" sounds like "LDC can generate WASM code" - it doesn't helps to run this code on VM or device, code is useless without RT or OS integration, its just pure obj file).

On Monday, 27 May 2019 at 12:33:16 UTC, KnightMare wrote:
> In case WASM is future of WEB/EmbeddedVM Dlang should ride the wave.
> This means not only compile to WASM/WASI by compilers but bring to it Dlang-RT (bytecode it not useful without some RT).
> When Dlang can generate same program for WASM as for terminal (with same RT not only "u can use templates only") it will lead a lot of people to Dlang, it will lead business too with money cause they want it, they ready to pay for it.
> No?

With WASI that is definitely possible. LDC can already target WASM and once WASI becomes standard I am sure it will be supported by LLVM.

On Monday, 27 May 2019 at 12:53:20 UTC, Seb wrote:
> Do you know about e.g. Spasm?
> https://forum.dlang.org/thread/lhkhbtpkbliddonfwliv@forum.dlang.org

I read about Spasm now. I dont ready to talk about, need time to understand and to try it.

>
> Also, this year there are two GSoC students working on WASM related topics (runtime hook conversion + independence of D from the C standard library).

Yes, GSoC is great idea: people will meet D and they will do useful work.

>
> See also: https://github.com/dlang/projects/issues?q=is%3Aissue+is%3Aopen+label%3Agsoc19

On Monday, 27 May 2019 at 12:53:20 UTC, Seb wrote:
>
> Do you know about e.g. Spasm?
>
> https://forum.dlang.org/thread/lhkhbtpkbliddonfwliv@forum.dlang.org
>
> Also, this year there are two GSoC students working on WASM related topics (runtime hook conversion + independence of D from the C standard library).
>
> See also: https://github.com/dlang/projects/issues?q=is%3Aissue+is%3Aopen+label%3Agsoc19

It seems that Spasm and similar are actually workable solutions, assuming that we stick to BetterC subset. Do you know how plausible it would be to ever enable WASM for non BetterC code?


*cough* *cough* sometimes I feel like D should have been BetterC from the start *cough*

On Monday, 27 May 2019 at 12:33:16 UTC, KnightMare wrote:
> In case WASM is future of WEB/EmbeddedVM Dlang should ride the wave.
> This means not only compile to WASM/WASI by compilers but bring to it Dlang-RT (bytecode it not useful without some RT).
> When Dlang can generate same program for WASM as for terminal (with same RT not only "u can use templates only") it will lead a lot of people to Dlang, it will lead business too with money cause they want it, they ready to pay for it.
> No?

I had some spare hours a couple of weeks ago, so I started porting druntime to WASI. It is far from complete and at some point I definitely need some druntime expert to help me out when I invariably get stuck.

Or you can just use betterC and write D with WASI right now.

https://github.com/skoppe/ldc/tree/wasi
https://github.com/skoppe/druntime/tree/wasi
https://github.com/skoppe/phobos/tree/wasi

On Monday, 27 May 2019 at 14:01:46 UTC, JN wrote:
> Do you know how plausible it would be to ever enable WASM
> for non BetterC code?

Certainly possible. dscripten (and dscripten-tools) is proof of that. The hard part is the GC.

On Monday, 27 May 2019 at 14:01:46 UTC, JN wrote:
> Do you know how plausible it would be to ever enable
> WASM for non BetterC code?

It is more tedious than it is difficult, but I think real usefulness is kinda blocked on stuff from the wasm side (interop with the real world) and on the D compiler side (efficient small code).

> *cough* *cough* sometimes I feel like D should have been BetterC from the start *cough*

Crippled D would have been a mistake. This stuff is extremely niche.

On Monday, 27 May 2019 at 14:38:00 UTC, Adam D. Ruppe wrote:
> On Monday, 27 May 2019 at 14:01:46 UTC, JN wrote:
>> Do you know how plausible it would be to ever enable
>> WASM for non BetterC code?
>
> It is more tedious than it is difficult, but I think real usefulness is kinda blocked on stuff from the wasm side (interop with the real world) and on the D compiler side (efficient small code).

proxies of outer objects in wasm space will solve interop from inside.
in case of nonmoveable GC in WASM host can invoke inside objects directly (we had ref to it somehow).
in both cases JIT/dynamicCompilation(as in LDC) will be very helpful.

GC will appear in WASM in some future. most probably with compact/move ability.
so access to object need to pin object first. its not native Dlang behavior.

in case Dlang community will write GC/RT for WASM interop can be 10x faster and whole bundle will be most independent for development. and Dlang progs can host WASM as VM/script engine.

so next things are desirable:
- platform independent RT. most probably in some bytecode style (LLVM-IR?). versioned (as I described in few hours ago).
- dynamic codegeneration and compilation, JIT (LLVM will helps too)
with 2 such things Dlang will rise to heaven - scripting, protocol adapters, dynamically types interop, serialization from and to different formats, so formatters, ORM in runtime with schemas from DB-connection, GUI scripts as QML...
(and we will get C#? :) )