May 15, 2014
On Thursday, 15 May 2014 at 22:16:06 UTC, Etienne wrote:
> This same team (the V8 team) decided that a VM based on dynamic typing in a type-safe language would be better than pure bytecode because of adaptive and profile-guided optimizations. To me that's truly groundbreaking, and based on these charts - I'd trust them!

Yes, but not faster than a C-like IR. Still, you do get a non-intrusive GC, so in that sense it is a better option than PNaCl.

May 16, 2014
On 5/15/2014 6:16 PM, Etienne wrote:
>
> This same team (the V8 team) decided that a VM based on dynamic typing
> in a type-safe language would be better than pure bytecode because of
> adaptive and profile-guided optimizations. To me that's truly
> groundbreaking, and based on these charts - I'd trust them!

Using bytecode doesn't prevent any of that.

May 16, 2014
On Thursday, 15 May 2014 at 22:16:06 UTC, Etienne wrote:
> On 2014-05-15 6:04 PM, "Ola Fosheim Grøstad"
>> It can do some tree shaking if you turn off metainfo. But D templates is
>> bound to lead to bloat. Dart is a dynamic language and does not benefit
>> much from templates. The power of Dart is in closures, but are you sure
>> that D closures are compatible?
>
> Templates are compile-time, a D compiler always takes care of all its compile-time duties =)
>
>> Dart2js produce large files, acceptable performance, but big.
>
> That's a temporary issue, I'm looking at years from now when/if Dart is more mature and implemented in more browsers as an alternative to javascript
>
> Also, I talked about caching in the VM
>
> http://1.bp.blogspot.com/-W1p7BELpIDE/UH42kXZeFsI/AAAAAAAANLA/kZGulTfNjQg/s1600/Screen+Shot+2012-10-16+at+9.39.29+PM.png
>
>
>> Never. PNaCl will stay faster, it is IR based and multi threaded. Dart
>> is a dynamic language designed to be JS compatible. The advantage with
>> dart source distribution is in download size and future proof
>> compatibility, not speed.
>
> There's a lot of advantages to a source-code VM vs a bytecode VM.
>
> Javascript is compiled into a source-code VM, sure it'll never exceed the power of a byte-code VM because without more type information the optimization opportunities are limited
>

Only if you are speaking about V8, as the other VMs (Nashorn, Webkit, Gecko) do use bytecodes, multiple levels actually.

--
Paulo
May 16, 2014
On 16/05/14 00:16, Etienne wrote:

> Templates are compile-time, a D compiler always takes care of all its
> compile-time duties =)

Unfortunately it does not. It causes unnecessary bloat. Take this for example:

void foo (T) (T t);

foo(new Foo);
foo(new Bar);

This will generate two functions, even though the machine code is exactly the same for both.

-- 
/Jacob Carlborg
May 16, 2014
On Thursday, 15 May 2014 at 20:34:31 UTC, Etienne wrote:
>
> My position has changed, and I now think D would be in a better position if it ran in the Dart VM.

Even if I _were_ a Chrome user, I'd have precisely zero interest in a browser monoculture.  To wit, [P]NaCl and Dart effectively don't exist in my world.  ASM.js is only slightly better in this regard because it at least _runs_ on other browsers.

-Wyatt
May 16, 2014
On Friday, 16 May 2014 at 12:55:30 UTC, Wyatt wrote:
> On Thursday, 15 May 2014 at 20:34:31 UTC, Etienne wrote:
>>
>> My position has changed, and I now think D would be in a better position if it ran in the Dart VM.
>
> Even if I _were_ a Chrome user, I'd have precisely zero interest in a browser monoculture.  To wit, [P]NaCl and Dart effectively don't exist in my world.  ASM.js is only slightly better in this regard because it at least _runs_ on other browsers.
>
> -Wyatt

See my post:

http://forum.dlang.org/thread/lktk12$15u1$3@digitalmars.com?page=3#post-qjxnftlafeeaskifcefd:40forum.dlang.org

I don't trust product / company centric software. It will lock you in or lock you out.
May 16, 2014
On 2014-05-16 9:12 AM, Chris wrote:
>
> I don't trust product / company centric software. It will lock you in or
> lock you out.

Google doesn't have a reputation of creating company centric software. SPDY was adopted by other browsers as well. If steam picks up on Dart, it could very well be adopted even by IE14 if that browser doesn't go the Netscape way ;)
May 16, 2014
On 2014-05-16 2:14 AM, Paulo Pinto wrote:
>
> Only if you are speaking about V8, as the other VMs (Nashorn, Webkit,
> Gecko) do use bytecodes, multiple levels actually.
>
> --
> Paulo

Well it does need to be converted to bytecode at some point but my point is that there can be changes in the code's typing - Javascript is not typed so the dynamic typing is taken for granted but in a typed language it's an important decision to just switch over an 64 bit -> 8 bit dynamically depending on profiling, it has the potential to adjust instructions for branch prediction to succeed more and even carry more into the CPU registers for tight algorithms which (theoretically) would beat plain C with -O3 on intel compilers with an intel cpu =)
May 16, 2014
16-May-2014 17:21, Etienne пишет:
> On 2014-05-16 9:12 AM, Chris wrote:
>>
>> I don't trust product / company centric software. It will lock you in or
>> lock you out.
>
> Google doesn't have a reputation of creating company centric software.
> SPDY was adopted by other browsers as well. If steam picks up on Dart,
> it could very well be adopted even by IE14 if that browser doesn't go
> the Netscape way ;)

MS have TypeScript. Seems like everybody has their own favorite idea of better JavaScript.

-- 
Dmitry Olshansky
May 16, 2014
On 2014-05-16 9:36 AM, Dmitry Olshansky wrote:
> 16-May-2014 17:21, Etienne пишет:
>> On 2014-05-16 9:12 AM, Chris wrote:
>>>
>>> I don't trust product / company centric software. It will lock you in or
>>> lock you out.
>>
>> Google doesn't have a reputation of creating company centric software.
>> SPDY was adopted by other browsers as well. If steam picks up on Dart,
>> it could very well be adopted even by IE14 if that browser doesn't go
>> the Netscape way ;)
>
> MS have TypeScript. Seems like everybody has their own favorite idea of
> better JavaScript.
>

I'm guessing they'll have to make some browser plugins for each of those "better javascript"s just like we need to install perl/python/ruby to run them. Though I assume at that point there's going to be a "winning browser"