On Saturday, 29 October 2016 at 21:46:37 UTC, Laeeth Isharc wrote:
> Any thoughts on how much work is involved to port the runtime?  And what other changes might be involved? The chap that used the C backend for LLVM wrote a little mini runtime but I guess didn't have to worry about the version blocks in the compiler front end as much.   (don't recall what architecture he pretended to be compiling to).
>
> Glibc has obviously already been ported to run in browser by emscripten.

I have actually meant something quite different - implementing new backend for DMD which emits wasm directly (possibly by embedding binaryen). That is more work than simply using LLVM stack as-is but would result in unique marketing advantage - existing pipeline of C -> Emscripten -> asm.js -> asm2wasm is rather annoying. And native wasm backend for LLVM is in development for quite a while now with no clear ETA.

At the same time intended wasm spec (https://github.com/WebAssembly/design) is much more simple than machine code for something like x86_64. If Walter gets interested, that may be a feasible path :)

On 10/29/2016 10:30 PM, Dicebot wrote:
> At the same time intended wasm spec (https://github.com/WebAssembly/design) is
> much more simple than machine code for something like x86_64. If Walter gets
> interested, that may be a feasible path :)

I looked at it for 5 minutes :-) and it looks like typical intermediate code that a compiler might generate. It wouldn't be hard to translate the intermediate code generated for the dmd back end to wasm. What I didn't see was any mention symbolic debug information, linking, or how to connect to system services like mutexes, I/O, etc. Time risks would also be wasm is an incomplete, moving target.

Looks like a fun project, but I don't see how I could split off time to work on it.

On Sunday, 30 October 2016 at 05:53:09 UTC, Walter Bright wrote:
> On 10/29/2016 10:30 PM, Dicebot wrote:
>> At the same time intended wasm spec (https://github.com/WebAssembly/design) is
>> much more simple than machine code for something like x86_64. If Walter gets
>> interested, that may be a feasible path :)
>
> I looked at it for 5 minutes :-) and it looks like typical intermediate code that a compiler might generate. It wouldn't be hard to translate the intermediate code generated for the dmd back end to wasm. What I didn't see was any mention symbolic debug information, linking, or how to connect to system services like mutexes, I/O, etc. Time risks would also be wasm is an incomplete, moving target.
>
> Looks like a fun project, but I don't see how I could split off time to work on it.

It is not worth it, the web is dying.  I was stunned to see this chart of mobile web usage in the US:

https://mobile.twitter.com/asymco/status/777915894659964928

This isn't some third-world country with mostly 2G usage, the web numbers in those places are much worse. Combined with mobile passing even TV for time spent, there is no point in wasting time porting D to a dying platform.

On Sunday, 30 October 2016 at 06:39:42 UTC, Joakim wrote:
>
> It is not worth it, the web is dying.  I was stunned to see this chart of mobile web usage in the US:
>
> https://mobile.twitter.com/asymco/status/777915894659964928
>
> This isn't some third-world country with mostly 2G usage, the web numbers in those places are much worse. Combined with mobile passing even TV for time spent, there is no point in wasting time porting D to a dying platform.

Yes, because outside of web on mobile nothing else exists... bwahahahah

On Sunday, 30 October 2016 at 05:30:04 UTC, Dicebot wrote:
> On Saturday, 29 October 2016 at 21:46:37 UTC, Laeeth Isharc wrote:
>> Any thoughts on how much work is involved to port the runtime?
>>  And what other changes might be involved? The chap that used the C backend for LLVM wrote a little mini runtime but I guess didn't have to worry about the version blocks in the compiler front end as much.   (don't recall what architecture he pretended to be compiling to).
>>
>> Glibc has obviously already been ported to run in browser by emscripten.
>
> I have actually meant something quite different - implementing new backend for DMD which emits wasm directly (possibly by embedding binaryen). That is more work than simply using LLVM stack as-is but would result in unique marketing advantage - existing pipeline of C -> Emscripten -> asm.js -> asm2wasm is rather annoying. And native wasm backend for LLVM is in development for quite a while now with no clear ETA.
>
> At the same time intended wasm spec (https://github.com/WebAssembly/design) is much more simple than machine code for something like x86_64. If Walter gets interested, that may be a feasible path :)

Existing pipeline is string together with gaffer tape and string,  so it's hardly there yet - and add up that,  last I looked,  when you turned on O2 with emscripten it didn't always go well.

But what I meant was LLVM will have a wasm backend.   So on basis of my limited understanding,  it would be some work to make LDC produce wasm code,  and then runtime and phobos would need work.   Adam Ruppe of course had something like this working with plain javascript and dmd about four years back, including basic D wrapping of DOM etc and extern(js).  But compiler has diverged a bit from that version used,  and I guess at time there wasn't the interest or manpower to turn that experiment /prototype into something one could depend on.   But maybe someone would pick it up now more people start to be involved,  given that Walter has higher priority things to do.

And wouldn't the changes to runtime and phobos be quite similar for both dmd and ldc? I don't see how the work flow would be any different as a language user whether you used an LDC with wasm back end,  or dmd with similar.

Joakim - native on mobile is so much better (setting aside having to deal with Apple or Google)   but I guess the browser isn't going away on the desktop for a while yet.

On 10/30/2016 07:53 AM, Walter Bright wrote:
> On 10/29/2016 10:30 PM, Dicebot wrote:
>> At the same time intended wasm spec
>> (https://github.com/WebAssembly/design) is
>> much more simple than machine code for something like x86_64. If
>> Walter gets
>> interested, that may be a feasible path :)
> 
> I looked at it for 5 minutes :-) and it looks like typical intermediate code that a compiler might generate. It wouldn't be hard to translate the intermediate code generated for the dmd back end to wasm. What I didn't see was any mention symbolic debug information, linking, or how to connect to system services like mutexes, I/O, etc. Time risks would also be wasm is an incomplete, moving target.

Well, "risk" and "opportunity" are pretty much synonymous in such context :) Whoever comes first with easy to use toolchain for new platform gets all the hype - it pretty much boils down to making decision if one believes new platform is likely to succeed.

For now I am just keeping my track on relevant information to see where does it all go.

> Looks like a fun project, but I don't see how I could split off time to work on it.

No argument here, it would be premature to pay much attention to it
anyway. I will probably remind you of this topic some time next year
with more information available so that more weighted judgment can be made.

On 10/30/2016 06:35 PM, Laeeth Isharc wrote:
> But what I meant was LLVM will have a wasm backend.

Yes, but it is developed so slowly and conservatively, that coming up with own proof-of-concept backend may be a chance to win early interest. They may speed up greatly though when WebAssembly design gets closer to MVP stage, but I am checking that regularly.

> So on basis of my
> limited understanding,  it would be some work to make LDC produce wasm
> code,  and then runtime and phobos would need work.

Most likely you would need a quite different runtime as most system/libc level stuff will not be available in browser sandbox but the very same browser APIs will need to be exposed instead. Most likely whatever emscripten does for C should be fairly adaptable even outside of LLVM stack.

But right now it is mostly irrelevant because runtime requirements have not been defined in WebAssembly at all, only low level byte code stuff. It is all in very early stages really.

On Monday, 31 October 2016 at 09:52:55 UTC, Dicebot wrote:
> On 10/30/2016 06:35 PM, Laeeth Isharc wrote:
>> But what I meant was LLVM will have a wasm backend.
>
> Yes, but it is developed so slowly and conservatively, that coming up with own proof-of-concept backend may be a chance to win early interest. They may speed up greatly though when WebAssembly design gets closer to MVP stage, but I am checking that regularly.

I was disappointed that after early hype it all went quiet for now.

I guess there is a window to grab attention,  but language like nim already has a JS backend (so they say - I haven't used), and I think D is in a different space from languages where how it plays on hacker news is most important.   Because if you have a wasm backend today for dmd,  I guess it will be some time before it's fast,  stable,  and has the basic stuff already in emscripten (though maybe with Remedy work it gets easier to wrap that).  So given limited manpower maybe the easier job (presumably most work needs to be done on phobos and runtime?) makes sense because in this case it's also likely the long term sensible way.   It would be great if we had a dmd back end early of course,  and I would certainly use it as soon as it was stable enough.

> But right now it is mostly irrelevant because runtime requirements have not been defined in WebAssembly at all, only low level byte code stuff. It is all in very early stages really.

You have looked into it more than me at a low level, but how is it possible then to run an app today in nightly browser in wasm?   Is it like saying you don't need glibc,  but it's probably a better idea to use one written for your platform rather than have some combination of assembly and hacked up library designed for another architecture and platform (which is what I guess emscripten do)?

Taking a step back,  it's quite amusing how much ingenuity goes into having to avoid writing Javascript...

On Tuesday, 1 November 2016 at 06:04:41 UTC, Laeeth Isharc wrote:
> On Monday, 31 October 2016 at 09:52:55 UTC, Dicebot wrote:
>> On 10/30/2016 06:35 PM, Laeeth Isharc wrote:
>>> But what I meant was LLVM will have a wasm backend.
>>
>> Yes, but it is developed so slowly and conservatively, that coming up with own proof-of-concept backend may be a chance to win early interest. They may speed up greatly though when WebAssembly design gets closer to MVP stage, but I am checking that regularly.
>
> I was disappointed that after early hype it all went quiet for now.

Actually, they have moved one with browser previews and dedicated web site jsut as we were talking: http://webassembly.org

I am curious how much attention it will gather on i.e. reddit

>> But right now it is mostly irrelevant because runtime requirements have not been defined in WebAssembly at all, only low level byte code stuff. It is all in very early stages really.
>
> You have looked into it more than me at a low level, but how is it possible then to run an app today in nightly browser in wasm?

How it works right now is that you can use WebAssembly byte-code to write a JavaScript-exposed function to be called from plain JavaScript. See http://webassembly.org/docs/js . Thus most of runtime level stuff is actually done by JS.

There are further plans to expose browser GC inside WebAssembly, allow direct usage of browser API like DOM and generally make possible to use it with no JavaScript at all - but those are all out of scope of MVP milestone.

> Taking a step back,  it's quite amusing how much ingenuity goes into having to avoid writing Javascript...

Judging by focus points in public statements one can reason that actually main driving goal of WebAssembly developers is not to throw away JavaScript but to make existing JavaScript/asm.js code more efficient (by pre-compiling it on server and distributing in binary form).

At the same time such initiative is of great value to company like Google who has lost "better JS" competition (remember Dart language?) to Microsoft TypeScript. Having common ground in form of byte code supported by all browsers will in some way reset the competition again.

On Sunday, 30 October 2016 at 10:04:02 UTC, Patrick Schluter wrote:
> On Sunday, 30 October 2016 at 06:39:42 UTC, Joakim wrote:
>>
>> It is not worth it, the web is dying.  I was stunned to see this chart of mobile web usage in the US:
>>
>> https://mobile.twitter.com/asymco/status/777915894659964928
>>
>> This isn't some third-world country with mostly 2G usage, the web numbers in those places are much worse. Combined with mobile passing even TV for time spent, there is no point in wasting time porting D to a dying platform.
>
> Yes, because outside of web on mobile nothing else exists... bwahahahah

Pretty soon it won't:

https://mobile.twitter.com/asymco/status/793401867053195264

On Sunday, 30 October 2016 at 16:35:54 UTC, Laeeth Isharc wrote:
> And wouldn't the changes to runtime and phobos be quite similar for both dmd and ldc? I don't see how the work flow would be any different as a language user whether you used an LDC with wasm back end,  or dmd with similar.

The changes to druntime and phobos wouldn't depend on the compiler used, but it is difficult to test unless you have a compiler with working codegen, so that usually comes first.  You can go ahead and make changes to druntime- not much has to be done for phobos, as the idea is to encapsulate platform-specific code in druntime, though a minority of phobos does call platform-specific APIs- based on the spec or available headers, but you won't know if it will work well till you can run it.

> Joakim - native on mobile is so much better (setting aside having to deal with Apple or Google)   but I guess the browser isn't going away on the desktop for a while yet.

I'm actually a heavy web user, have been for almost a quarter-century (though I don't use webapps, mostly reading), which is why that chart was so surprising to me.  While native mobile apps are usually more responsive, they are not ideal for reading, as I'm not going to install and load up The Verge's app, or an app for every other news site, every time.

The problem for the desktop browser is that the desktop is going away, as the linked tweet above shows.  I went from using a FreeBSD desktop and a dumbphone five years ago to an Android smartphone and two Android tablets today, ie no desktop or laptop since my ultrabook died late last year.  In my household, we went from using two smartphones, two PC laptops, and a Mac laptop four years ago to three smartphones, three Android tablets, and a Mac laptop today.

This is a shift that is happening in most households, as a PC overserves most and a mobile device will do.  Many D users are power users who cling to old tech like the desktop and the web, so they are missing this massive wave going on right now.  I myself missed the death of the mobile web, as I'm such a heavy user.