On Saturday, 23 November 2019 at 23:21:49 UTC, Nick Sabalausky (Abscissa) wrote:
> I did started working on a couple DIPs for them, though.

Can you share a link to DIP draft?
I'd like to read how it would work.

Thank you,
Alexandru.

On 2019-11-23 10:51, Sebastiaan Koppe wrote:
> This is my proposal for porting D runtime to WebAssembly. I would like to ask you to review it. You can find it here: https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d

What will happen to code that uses TLS? Will it be promoted to a global variable or will it fail to compile?

-- 
/Jacob Carlborg

On Sunday, 24 November 2019 at 18:46:04 UTC, Jacob Carlborg wrote:
> On 2019-11-23 10:51, Sebastiaan Koppe wrote:
>> This is my proposal for porting D runtime to WebAssembly. I would like to ask you to review it. You can find it here: https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d
>
> What will happen to code that uses TLS? Will it be promoted to a global variable or will it fail to compile?

LLVM errors out saying it can't select tls for wasm. We could modify ldc to not emit TLS instructions under WebAssembly.

But yeah, right now, you need to __gshared everything.

I know.

On Saturday, 23 November 2019 at 09:51:13 UTC, Sebastiaan Koppe wrote:
> This is my proposal for porting D runtime to WebAssembly. I would like to ask you to review it. You can find it here: https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d

This proposal is so perfectly balanced between value and implementability that I can find nothing to add or remove.

I'm interested, what's your motivation in doing all this? If I understood correctly, your primary motivation to write Spasm was to write better optimized front-end programs than you get with JS frameworks. But wouldn't it be easier to just use Rust since it has already implemented all this?

On Sunday, 24 November 2019 at 20:42:24 UTC, Sebastiaan Koppe wrote:
>
> LLVM errors out saying it can't select tls for wasm. We could modify ldc to not emit TLS instructions under WebAssembly.

No need do make that rule WASM-specific. Do this for all programs that have thearding disabled.

On Saturday, 23 November 2019 at 09:51:13 UTC, Sebastiaan Koppe wrote:
> This is my proposal for porting D runtime to WebAssembly. I would like to ask you to review it. You can find it here: https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d

Thanks for putting this together, it looks very carefully thought out.

On this particular part:

> Exceptions can be thrown but not catched. A thrown exception will
> terminate the program. Exceptions are still in the proposal phase.
> When the proposal is accepted exceptions can be fully supported.

This would suggest that there may be some benefit in D providing improved support for return-type-based error propagation (as with `Result` from Rust), no ... ?

On Monday, 25 November 2019 at 09:01:15 UTC, Dukc wrote:
> On Saturday, 23 November 2019 at 09:51:13 UTC, Sebastiaan Koppe wrote:
>> This is my proposal for porting D runtime to WebAssembly. I would like to ask you to review it. You can find it here: https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d
>
> This proposal is so perfectly balanced between value and implementability that I can find nothing to add or remove.

Thanks!

> I'm interested, what's your motivation in doing all this? If I understood correctly, your primary motivation to write Spasm was to write better optimized front-end programs than you get with JS frameworks.

That is a fair question. Spasm has been very successful if you look at rendering speed. It (almost) beats everything else out there [1]. Well, that is not surprising since everything is known at compile time; it literally compiles down to the same code as if you issued low-level dom calls manually. I am very happy about that.

With regards to developer experience it is behind. First of all you have to deal with betterC. This alone is already a hurdle for many. Second is the DSL, or lack of it. It doesn't come close to something like e.g. SwiftUI. In fact, I wrote a (unfinished) material-ui component library on top of spasm and I was struggling at times.

So it became clear to me I need to have druntime available. It will allow people to use the (almost) complete set of D features and it opens up some metaprogramming avenues that are closed off right now. With that I will be able to create some nice DSL, in line with JSX/SwiftUI or <insert-your-favorite-declarative-framework>.

There are plenty of opportunities here. It is not unfeasible to connect spasm to Qt, or dlangui, and create a cross-platform UI library, something like flutter.

On the other hand, I am very excited about WebAssembly in general. It is certainly at the beginning of the hype curve and I suspect some very exciting things will appear in the future. Some of them are already here right now. For instance, you can target ARM by compiling D code to wasm and then use wasmer to compile it to ARM. With D connecting itself to the wasm world it exposes itself to a lot of cool things, which we mostly get for free.

As an example, it is just a matter of time before a PaaS provider fully embraces wasm. Instead of having docker containers you just compile to wasm, which will be pretty small and can boot in (sub) milli-seconds (plus they don't necessarily need a linux host kernel running and can run it closer to the hypervisor.)

There are tons of possibilities here, and I want D to be a viable option when that day comes.

So it is not just about frontends anymore.

> But wouldn't it be easier to just use Rust since it has already implemented all this?

All the rust frameworks for web apps that I have seen rely on runtime techniques like the virtual dom. As a consequence they spend more cpu time and result in bigger files. That may be perfectly fine for most (and it probably is), but I wanted to squeeze it as much as I could. Maybe it is possible to do that in rust as well, I don't know. D's metaprogramming seemed a more natural fit.

[1] except Svelte, which is a little bit smaller in code size, and a tiny bit faster. But they build a whole compiler just for that. Lets wait for host bindings support in wasm and measure again.

On Monday, 25 November 2019 at 12:19:30 UTC, Joseph Rushton Wakeling wrote:
> On Saturday, 23 November 2019 at 09:51:13 UTC, Sebastiaan Koppe wrote:
>> This is my proposal for porting D runtime to WebAssembly. I would like to ask you to review it. You can find it here: https://gist.github.com/skoppe/7617ceba6afd67b2e20c6be4f922725d
>
> Thanks for putting this together, it looks very carefully thought out.

Thanks!

>> Exceptions can be thrown but not catched. A thrown exception will
>> terminate the program. Exceptions are still in the proposal phase.
>> When the proposal is accepted exceptions can be fully supported.
>
> This would suggest that there may be some benefit in D providing improved support for return-type-based error propagation (as with `Result` from Rust), no ... ?

Yes, definitely. But what do you mean with improved support? Like better pattern matching over either types?

On Monday, 25 November 2019 at 12:52:46 UTC, Sebastiaan Koppe wrote:
> As an example, it is just a matter of time before a PaaS provider fully embraces wasm.

This sounds interesting, I've been pondering about serverless FaaS (function as a service), where you basically (hopefully) get functions triggered by NoSQL database updates and not have to bother with your own webserver.

I see that CloudFlare has support for webassembly in their workers, but for Google Functions I only see Node10, but maybe they can run webassembly as well? I haven't found anything definitive on it though...

https://blog.cloudflare.com/webassembly-on-cloudflare-workers/
https://cloud.google.com/functions/docs/

> Instead of having docker containers you just compile to wasm, which will be pretty small and can boot in (sub) milli-seconds (plus they don't necessarily need a linux host kernel running and can run it closer to the hypervisor.)

Yes, but the biggest potential I see is when you don't have to set up servers to process data.

Just throw the data into the distributed database, which triggers a Function that updates other parts of the database and then triggers another function that push the resulting PDF (or whatever) to a service that serves the files directly (i.e. cached close to the user like CloudFlare).

Seems like it could be less hassle, but not sure if will catch on or fizzle out... I think I'll wait and see what happens. :-)

On Saturday, 23 November 2019 at 23:21:49 UTC, Nick Sabalausky (Abscissa) wrote:
> On 11/23/19 3:48 PM, Sebastiaan Koppe wrote:
>> On Saturday, 23 November 2019 at 15:23:41 UTC, Alexandru Ermicioi wrote:
>>>
>>> I was wondering whats your position on Fibers?
>> 
>> I am not going to support them in this initial port. And to be

> I did started working on a couple DIPs for them, though. Interestingly, I just found out today about C++'s proposed coroutines and was shocked by how similar they are to what I was designing; even right down to details like how the existence of a yield instruction is what triggers the compiler to treat the function as a coroutine, and the requirement that a coroutine's return type be a special type that includes the state information.
>
> Still, a few differences, though. For example, unlike the C++ proposal, I'm hoping to avoid the need for additional keywords and heap allocation. And I also started a secondary DIP that builds on the coroutine foundation to make a much cleaner user-experience using the coroutines to generate ranges (what I would expect to be the most common use-case).

Hi Sebastiaan,

If you are looking at the C++ coroutines I would recommend looking into the  proposal for "First-class symmetric coroutines in C++".

The official paper can be found here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1430r1.pdf

There is also a presentation with some nice animations explaining the proposal here:
https://docs.google.com/presentation/d/1B5My9nh-P2HLGI8Dtfm6Q7ZfHD9hJ27kJUgnfA2syv4/edit?usp=sharing

There paper is still in early development, for example the syntax has changed since then as well as some other pieces.

If you are interested I can connect you with the author of the paper who can explain it with more details.

Georgi