Experiments with emscripten and D

[John Colvin]

On Saturday, 17 August 2013 at 20:42:33 UTC, H. S. Teoh wrote:
> On Sat, Aug 17, 2013 at 09:07:20PM +0200, John Colvin wrote:
>> On Saturday, 17 August 2013 at 18:51:23 UTC, H. S. Teoh wrote:
>> >On Sat, Aug 17, 2013 at 08:41:39PM +0200, John Colvin wrote:
>> >>On Saturday, 17 August 2013 at 16:35:46 UTC, H. S. Teoh 
>> >>wrote:
> [...]
>> >>>It's just like Nick Sabalausky always likes to rant about. 
>> >>>In 1975,
>> >>>we had slow 8-bit computers with 8kHz CPUs and 64kB of RAM, 
>> >>>and our
>> >>>applications ran rather slowly.  Then processor speed 
>> >>>increased
>> >>>exponentially, RAM increased exponentially, and today we 
>> >>>have
>> >>>64-bit computers with 4GHz CPUs (and multicore!) and who 
>> >>>knows how
>> >>>many GBs of RAM, and our (web) applications run at about 
>> >>>the same
>> >>>speed as in 1975.  Clearly, *something* is very, very wrong 
>> >>>with
>> >>>this picture.
> [...]
>> >>How do we fix it? We have a great language here, let's 
>> >>revolutionise
>> >>the web :p
>> >
>> >Yeah! vibe.d FTW! :) And the client-side version thereof. :)
> [...]
>> Yeah the server-side is relatively easy to pull off, seeing as
>> you're completely in control there.
>> 
>> The client side is an eensy little bit harder haha. It would
>> probably require heavily modifying/creating a new web-browser 
>> and
>> then convincing people to use it.
>> 
>> I wonder how powerful browser extensions can be these days...
>
> Hmm. That's an idea, write an extension that can run code 
> through rdmd.
> (You have to deliver the source rather than the object code, 
> since you
> don't know what OS your client is running on.)

not necessarily. The extension would know and could tell the 
server which version to send (with an optional fallback to code 
for systems that you don't have a binary ready for). It could 
also query shared library / dll versions.
Also, you could just send llvm IR...

> Requiring an extension puts it in the same boat as Flash, 
> though. :-(

An extension today, built-in to the browser tomorrow?

> And you'd have to sandbox the code since arbitrary D code 
> running wild
> on the user's computer is a Bad Thing(tm). Which runs into 
> GC-related
> issues when your client is a low-memory handheld device. Though 
> arguably
> this would still be an improvement over JS, since an interpreted
> language necessarily uses more resources.
>
>
> T

most, if not all operating systems have good sandboxing, don't 
they? iOS sandboxes the hell out of everything and I presume 
android does something similar. on linux you can use selinux 
utility sandbox or similar.