On Monday, 25 November 2019 at 13:28:17 UTC, Ola Fosheim Grøstad wrote:
> 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.

This is already doable with dynamodb, or kinesis streams. Or google's dataflow.

Using wasm just makes that more seamless (and faster).

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

Node has good wasm support, I don't know how you would get the wasm binary in, but it probably can be done.

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

I rather not setup servers for anything.

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

You don't have to wait for that. That future is already here. The in and output could also be distributed storage, event streams or some queue.

The problem, however, is often when using those tools you get pushed into a small set of supported programming languages. Like AWS' glue that focuses on Scala or Python, or google's functions that only support js/python and go. Understandable, but I rather choose my own language. Wasm makes that possible.

On Monday, 25 November 2019 at 13:00:23 UTC, Sebastiaan Koppe wrote:
> Yes, definitely. But what do you mean with improved support? Like better pattern matching over either types?

Yes, that sort of thing.  And maybe a move towards trying to use this kind of error handling in newer editions of the standard library (I'm reluctant to push too strongly on that, but I get the impression there is some inclination to move in this direction, as a reflection of wider design trends).

On Monday, 25 November 2019 at 13:52:29 UTC, Sebastiaan Koppe wrote:
> You don't have to wait for that. That future is already here. The in and output could also be distributed storage, event streams or some queue.

Yes, I am most familiar with Google Cloud. Earlier this year Google Functions was not available in European datacenters IIRC, but now it is at least available in London and Belgium. So things are moving in that direction, somewhat slowly. It is annoying to not have Google Functions when working with Google Firebase, so if webworkers is possible then that could make things much better (even for simple things like generating thumbnail images).

> Like AWS' glue that focuses on Scala or Python, or google's functions that only support js/python and go. Understandable, but I rather choose my own language. Wasm makes that possible.

Let's hope there is a way for other services than CloudFlare. CloudFlare Workers look cool, but their KV store has very low propagation guarantees on updates (60 seconds).

On 11/25/19 7:52 AM, Sebastiaan Koppe wrote:
> 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.)

As someone who does web application development, all of this sounds awesome. I would LOVE to have a real programming language to do the client-side stuff.

-Steve

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

On the GC part. It says "The only unknown part is how to dump the registers to the stack to ensure no pointers are held in the registers only."

Please correct me where I'm wrong, but on the level of WebAssembly there are no registers, there is an operand stack outside the address space, there are local variables to the current function, again outside the accessible address space of program's linear memory, and there is the linear memory itself. So scanning the stack becomes a really hard (should I say impossible?) part. What some compilers do is they organize another stack manually in the linear memory and store the values that would otherwise be on the normal stack, there. Which means in case of D you'll have to seriously change the codegen, to change how local variables are stored, and to use a kind of shadow stack for temporaries in expressions that may be pointers. Do you really have a plan about it?

On Monday, 25 November 2019 at 18:44:01 UTC, thedeemon 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
>
> Please correct me where I'm wrong, but on the level of WebAssembly there are no registers, there is an operand stack outside the address space, there are local variables to the current function, again outside the accessible address space of program's linear memory, and there is the linear memory itself. So scanning the stack becomes a really hard (should I say impossible?) part. What some compilers do is they organize another stack manually in the linear memory and store the values that would otherwise be on the normal stack, there.

Yeah, that accurately describes the situation. I will update the wording in the document to use 'stack', 'shadow stack' (also sometimes called 'user stack') and the local variable. Thanks.

One solution that I employed in spasm's experimental gc is to only run it directly from javascript. This way there can't be anything hiding in the stack or in a local variable. Although that approach doesn't work for all use cases.

> Which means in case of D you'll have to seriously change the codegen, to change how local variables are stored, and to use a kind of shadow stack for temporaries in expressions that may be pointers. Do you really have a plan about it?

Well, no, not fully. That is why I said 'unknown'. But there must be a solution somewhere.

LLVM already puts pointers to stack or local variables in the shadow stack. As well as for structs-by-val that don't fit the stack. We could adjust LDC to nudge LLVM to maintain live roots on the shadow stack as well.

Go's approach is to put everything on the shadow stack. (see: https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0_Nv3OUwjEY5qVCxCup4/preview#heading=h.mjo1bish3xni)

There is also the possibility of a code transformation. Binaryen has a spill-the-pointer pass that effectively gets you go's solution (but only for i32's) (see: https://github.com/WebAssembly/binaryen/blob/master/src/passes/pass.cpp#L310)

I am favoring the first option, but I don't know how hard that would be. Will update the document with this info.

Thank you for questioning this.

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

An alternative idea, would be to use emscriptens fork of musl to have a full C-library. AFAIK this includes threading.

LLVM is supposed to support TLS in wasm since version 9.

On Monday, 25 November 2019 at 13:50:20 UTC, Georgi D wrote:
> 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

Thanks for that. It would be great, but I don't have time for that at the moment.

On Tuesday, 26 November 2019 at 09:18:05 UTC, Thomas Brix 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
>
> An alternative idea, would be to use emscriptens fork of musl to have a full C-library. AFAIK this includes threading.
>
> LLVM is supposed to support TLS in wasm since version 9.

Yes, indeed. https://reviews.llvm.org/D64537 gives a good overview.

I believe it is best to first actually have a version of druntime on wasm, rather than eagerly pulling in all the latest features. I find the scope I set in the proposal to be quite reasonable.

Adding tls, threading and exception handling would be much easier after this work is done and merged. And it would also be something others might want to contribute to.

On 2019-11-23 09:51:13 +0000, Sebastiaan Koppe said:

> 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

Not sure if you are aware of this:

https://wasmtime.dev/

Maybe it helps or gives some inspiration.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster