[dart-misc] WebAssembly and Dart

I guess for quite some time it will not be much more than asm.js is to Dart
currently.
I think I saw GC and access to JS objects mentioned as planned for later.
When they reach this state it might be worth reconsidering.

Benjamin Strauß

2015-06-18 12:25:30 UTC

If this gets implemented in all browser some day, i guess this would be the
new compilation target. The good thing is you won't have to change your
dart code then. :)

Filipe Morgado

2015-06-18 13:57:10 UTC

Dart may have to change in subtle (and not so subtle) ways, to run
efficiently in a "WebVM" and interoperate with modules written in other
languages.
I don't think WebAssembly (wasm) will ever support big integers, and the
lack of fixed-size arithmetic in Dart seems problematic.

I see a bright future for wasm, if done right.
Runs any languages.
Various VM implementations.
May be compiled AoT, no more problems targeting iOS apps.
May run as sandboxed plugins in any software.
Great tooling, including stuff like observatory.
Could even target Linux Kernel modules someday.

I see a lot of overlap with Dart, regarding tooling and VM.
IMO, it would be wise to rethink Dart overall strategy.
Wasm and Dart would benefit a lot from each other.
(Imagine Sky running .wasm files :D )

I just wish the wasm committee would get in touch with Khronos, regarding
Vulkan and SPIR-V.
These seem different strategies to answer the same fundamental problem.
And it would awesome to have wasm support for OpenCL and shaders.

Post by Benjamin StrauÃ
If this gets implemented in all browser some day, i guess this would be
the new compilation target. The good thing is you won't have to change your
dart code then. :)

'Bob Nystrom' via Dart Misc

2015-06-18 16:28:08 UTC

In the immediate future, wasm is just a smaller binary encoding of asm.js.
It still has the same constraints as asm.js which make it a worse
compilation target for high level languages than JS itself is. Primarily,
that's:

1. No GC.
2. No DOM access. (Specifically, no references to DOM objects.)

If you want to compile a *garbage-collected web application language* to
something that runs on a browser, you need those. JS has them and
asm.js/wasm don't.

Cheers!

- bob

Post by Filipe Morgado
Dart may have to change in subtle (and not so subtle) ways, to run
efficiently in a "WebVM" and interoperate with modules written in other
languages.
I don't think WebAssembly (wasm) will ever support big integers, and the
lack of fixed-size arithmetic in Dart seems problematic.
I see a bright future for wasm, if done right.
Runs any languages.
Various VM implementations.
May be compiled AoT, no more problems targeting iOS apps.
May run as sandboxed plugins in any software.
Great tooling, including stuff like observatory.
Could even target Linux Kernel modules someday.
I see a lot of overlap with Dart, regarding tooling and VM.
IMO, it would be wise to rethink Dart overall strategy.
Wasm and Dart would benefit a lot from each other.
(Imagine Sky running .wasm files :D )
I just wish the wasm committee would get in touch with Khronos, regarding
Vulkan and SPIR-V.
These seem different strategies to answer the same fundamental problem.
And it would awesome to have wasm support for OpenCL and shaders.

Post by Benjamin StrauÃ
If this gets implemented in all browser some day, i guess this would be
the new compilation target. The good thing is you won't have to change your
dart code then. :)

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

Don Olmstead

2015-06-18 17:28:08 UTC

To add to Bob's assessment it also is targeting C/C++ not every language
under the sun.

On Thu, Jun 18, 2015 at 9:28 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
In the immediate future, wasm is just a smaller binary encoding of asm.js.
It still has the same constraints as asm.js which make it a worse
compilation target for high level languages than JS itself is. Primarily,
1. No GC.
2. No DOM access. (Specifically, no references to DOM objects.)
If you want to compile a *garbage-collected web application language* to
something that runs on a browser, you need those. JS has them and
asm.js/wasm don't.
Cheers!
- bob

Post by Benjamin StrauÃ
If this gets implemented in all browser some day, i guess this would be
the new compilation target. The good thing is you won't have to change your
dart code then. :)

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

Warren

2015-06-18 18:01:10 UTC

They do mention possible future work to add GC - so perhaps a glimmer of
hope.

Post by Don Olmstead
To add to Bob's assessment it also is targeting C/C++ not every language
under the sun.
On Thu, Jun 18, 2015 at 9:28 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
In the immediate future, wasm is just a smaller binary encoding of
asm.js. It still has the same constraints as asm.js which make it a worse
compilation target for high level languages than JS itself is. Primarily,
1. No GC.
2. No DOM access. (Specifically, no references to DOM objects.)
If you want to compile a *garbage-collected web application language* to
something that runs on a browser, you need those. JS has them and
asm.js/wasm don't.
Cheers!
- bob

Post by Filipe Morgado
Dart may have to change in subtle (and not so subtle) ways, to run
efficiently in a "WebVM" and interoperate with modules written in other
languages.
I don't think WebAssembly (wasm) will ever support big integers, and the
lack of fixed-size arithmetic in Dart seems problematic.
I see a bright future for wasm, if done right.
Runs any languages.
Various VM implementations.
May be compiled AoT, no more problems targeting iOS apps.
May run as sandboxed plugins in any software.
Great tooling, including stuff like observatory.
Could even target Linux Kernel modules someday.
I see a lot of overlap with Dart, regarding tooling and VM.
IMO, it would be wise to rethink Dart overall strategy.
Wasm and Dart would benefit a lot from each other.
(Imagine Sky running .wasm files :D )
I just wish the wasm committee would get in touch with Khronos,
regarding Vulkan and SPIR-V.
These seem different strategies to answer the same fundamental problem.
And it would awesome to have wasm support for OpenCL and shaders.

Post by Benjamin StrauÃ
If this gets implemented in all browser some day, i guess this would be
the new compilation target. The good thing is you won't have to change your
dart code then. :)

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

Filipe Morgado

2015-06-18 18:01:47 UTC

Yes, "immediate future". That might change in a "near future".
I'd hate to see Dart miss the boat on this one. Especially considering how
much expertise regarding VMs and tooling there is in the Dart team.

WebAssembly is what everybody has been waiting for, since long ago. It
tries to solve the same problem as Dart, except its language is lower
level, more suitable and flexible as a compilation target, and apparently
agreed upon by all major browser vendors.

Dart could be a part of it, even if only with experimental features on top
of current wasm spec and a Dart front-end.

Post by 'Bob Nystrom' via Dart Misc
To add to Bob's assessment it also is targeting C/C++ not every language
under the sun.

Don Olmstead

2015-06-18 18:08:14 UTC

This has been discussed I don't know how many times see
https://groups.google.com/a/dartlang.org/forum/#!searchin/misc/asm.js and
of course https://www.dartlang.org/articles/why-not-bytecode/

Post by Filipe Morgado

Post by 'Bob Nystrom' via Dart Misc
In the immediate future, wasm is just a smaller binary encoding of
asm.js. It still has the same constraints as asm.js which make it a worse
compilation target for high level languages than JS itself is. Primarily,
1. No GC.
2. No DOM access. (Specifically, no references to DOM objects.)
If you want to compile a *garbage-collected web application language* to
something that runs on a browser, you need those. JS has them and
asm.js/wasm don't.
Cheers!
- bob

Yes, "immediate future". That might change in a "near future".
I'd hate to see Dart miss the boat on this one. Especially considering how
much expertise regarding VMs and tooling there is in the Dart team.
WebAssembly is what everybody has been waiting for, since long ago. It
tries to solve the same problem as Dart, except its language is lower
level, more suitable and flexible as a compilation target, and apparently
agreed upon by all major browser vendors.
Dart could be a part of it, even if only with experimental features on top
of current wasm spec and a Dart front-end.

Post by 'Bob Nystrom' via Dart Misc
To add to Bob's assessment it also is targeting C/C++ not every language
under the sun.

Rust and swift could probably already be used (any LLVM-targeted languages
actually).
Once it gets GC and dynamic linking, it will compete with the JVM, CLR and
any other VM, including DartVM.
That means a lot more languages will be supported.
I recognize it's probably too soon and/or too disruptive, but wasm seems
very serious and could (will?) revolutionize not only the web, but maybe
all computing.
Dart cannot play alone in its corner.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

Günter Zöchbauer

2015-06-18 18:35:19 UTC

Post by Filipe Morgado
WebAssembly is what everybody has been waiting for, since long ago. It
tries to solve the same problem as Dart, except its language is lower
level, more suitable and flexible as a compilation target, and apparently
agreed upon by all major browser vendors.

Somehow I have the impression people just desire WebAssembly to be what
they are waiting for without caring much what it actually is.

'Bob Nystrom' via Dart Misc

2015-06-18 19:38:00 UTC

Post by Filipe Morgado
WebAssembly is what everybody has been waiting for, since long ago. It

Post by Filipe Morgado
tries to solve the same problem as Dart, except its language is lower
level, more suitable and flexible as a compilation target, and apparently
agreed upon by all major browser vendors.

Somehow I have the impression people just desire WebAssembly to be what
they are waiting for without caring much what it actually is.

I believe that's correct.

*Lots* of people want a compilation target language in the browser that's a
good fit for high level languages. asm.js is not that. WebAssembly is not
that. Maybe it will be in the future. But, *today*, JS is actually a pretty
good compilation target for a high level language that has GC, dynamic
dispatch, and interacts with the DOM.

That describes Dart well, so compiling to JS is still by a large margin,
the best fit for us.

Now, if WebAssembly eventually morphed into something closer to JVM or CLR
bytecode, sure, we may jump on it. But today it is clearly a target for
compiling *unmanaged* languages.

Cheers!

- bob

Cogman

2015-06-18 20:16:10 UTC

@Bob. From Brandon's blog post it sounded like the first step was to
polyfil with a asm.js parser and the second step was getting the GC in
place.

I'm guessing it will be sooner rather than later that WebAssembly allows
for GCed memory management.

Either way, the exciting thing is that unlike asm.js and PNaCL, this has
cross vendor support. I think it stands a good chance of getting much
wider adoption than its predecessors.

But yeah, I agree it doesn't sound like some of the higher level languages
can target it until it gets more higher level vm features implemented.

On Thu, Jun 18, 2015 at 1:38 PM, 'Bob Nystrom' via Dart Misc <

Post by Filipe Morgado
WebAssembly is what everybody has been waiting for, since long ago. It

Somehow I have the impression people just desire WebAssembly to be what
they are waiting for without caring much what it actually is.

I believe that's correct.
*Lots* of people want a compilation target language in the browser that's
a good fit for high level languages. asm.js is not that. WebAssembly is not
that. Maybe it will be in the future. But, *today*, JS is actually a
pretty good compilation target for a high level language that has GC,
dynamic dispatch, and interacts with the DOM.
That describes Dart well, so compiling to JS is still by a large margin,
the best fit for us.
Now, if WebAssembly eventually morphed into something closer to JVM or CLR
bytecode, sure, we may jump on it. But today it is clearly a target for
compiling *unmanaged* languages.
Cheers!
- bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

'Bob Nystrom' via Dart Misc

2015-06-18 22:25:03 UTC

Post by Cogman
@Bob. From Brandon's blog post it sounded like the first step was to
polyfil with a asm.js parser and the second step was getting the GC in
place.
I'm guessing it will be sooner rather than later that WebAssembly allows
for GCed memory management.

Cogman

2015-06-18 23:25:39 UTC

@Bob, I'm hoping that having multiple parties (google, microsoft, mozilla)
pushing on this will help move it towards a universal vm sort of spot.
Microsoft has interest in getting .Net stuff to run on the web, Google has
Dart, go, and others that it might want to push in this direction. I'm not
sure what mozilla is getting out of this, but I'm glad they are a part of
it as they have generally been the biggest proponents of "Only javascript
here!" for a while now. The change of tune is refreshing.

On Thu, Jun 18, 2015 at 4:25 PM, 'Bob Nystrom' via Dart Misc <

If they do, that would be great, but asm.js has been out for two years and
still doesn't have anything like GC. They are very focused on compiling
C/C++ with LLVM so I wouldn't hold my breath for WebAssembly becoming a
target for higher-level languages.
- bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

Joris Hermans

2015-06-18 23:37:21 UTC

asm.js is an experiment of Mozilla ;) :) and rustlang is alsof from them
right?

Post by Cogman
@Bob, I'm hoping that having multiple parties (google, microsoft, mozilla)
pushing on this will help move it towards a universal vm sort of spot.
Microsoft has interest in getting .Net stuff to run on the web, Google has
Dart, go, and others that it might want to push in this direction. I'm not
sure what mozilla is getting out of this, but I'm glad they are a part of
it as they have generally been the biggest proponents of "Only javascript
here!" for a while now. The change of tune is refreshing.
On Thu, Jun 18, 2015 at 4:25 PM, 'Bob Nystrom' via Dart Misc <

If they do, that would be great, but asm.js has been out for two years
and still doesn't have anything like GC. They are very focused on compiling
C/C++ with LLVM so I wouldn't hold my breath for WebAssembly becoming a
target for higher-level languages.
- bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

Brendan Eich

2015-06-18 23:49:17 UTC

Post by Joris Hermans
asm.js is an experiment of Mozilla ;) :) and rustlang is alsof from them
right?

No, asm.js (http://asmjs.org/) is a type system for a subset of JS, which
can be ahead-of-time (AOT) optimized when loading a module or program,
beyond how full JS can be optimized. Microsoft in addition to Mozilla does
this full type-check (linear complexity with source size, and done while
parsing) and to-the-metal optimization. Other engines are looking into it.

The same approach works with wasm, which indeed starts life as alternative
syntax to asm.js's syntax for the same underlying semantics. One VM, one GC
-- this is critical, and lack of it felled DartVM in any browser including
Chrome -- and must continue even as wasm, asm.js, and JS all evolve to
absorb 64-bit ints, SIMD, shared memory threads (shared ArrayBuffer), and
value types (including bignums as library code if not built-in). At some
point (depending on installed base upgrading to wasm-decoding VMs in
sufficient >95% share) wasm diverges and can support GC and
JIT-to-wasm-to-native.

HTH,

/be

Cristian Garcia

2015-06-19 00:51:26 UTC

@Brendan why is there an emphasis in no GC? According to @Bob this is a
mayor limitation on many for languajes that might want to target wasm.

Post by Joris Hermans
asm.js is an experiment of Mozilla ;) :) and rustlang is alsof from them
right?

No, asm.js (http://asmjs.org/) is a type system for a subset of JS, which
can be ahead-of-time (AOT) optimized when loading a module or program,
beyond how full JS can be optimized. Microsoft in addition to Mozilla does
this full type-check (linear complexity with source size, and done while
parsing) and to-the-metal optimization. Other engines are looking into it.
The same approach works with wasm, which indeed starts life as alternative
syntax to asm.js's syntax for the same underlying semantics. One VM, one GC
-- this is critical, and lack of it felled DartVM in any browser including
Chrome -- and must continue even as wasm, asm.js, and JS all evolve to
absorb 64-bit ints, SIMD, shared memory threads (shared ArrayBuffer), and
value types (including bignums as library code if not built-in). At some
point (depending on installed base upgrading to wasm-decoding VMs in
sufficient >95% share) wasm diverges and can support GC and
JIT-to-wasm-to-native.
HTH,
/be
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

Brendan Eich

2015-06-19 01:19:24 UTC

Post by Cristian Garcia
@Brendan why is there an emphasis in no GC? According to @Bob this is a
mayor limitation on many for languajes that might want to target wasm.

It's just what I wrote: start from minimum viable product that can be
polyfilled (for asm.js or best-JS emulation-by-translation of wasm to JS)
and evolve from there. You are in effect asking "why can't I have
everything at once?" On the web, you cannot. Don't break the web --
backward compat matters. But over N browser releases (which are fast these
days), you can indeed have it all.

So GC and JIT-to-wasm are post-MVP features, per
https://github.com/WebAssembly/design/blob/master/FutureFeatures.md.

/be

Brendan Eich

2015-06-18 23:33:43 UTC

I'm not sure what mozilla is getting out of this, but I'm glad they are a
part of it as they have generally been the biggest proponents of "Only
javascript here!" for a while now. The change of tune is refreshing.

I'm not at Mozilla, don't speak for them, but co-founded and had a lot of
say in the past. There was never any "Only JS here" message. Rather, "PNaCl
requires Pepper, too big a pill for other browsers to swallow" and "DartVM
requires 2nd VM + OilPan or equivalent" (also too big a pill). Realism
requires accuracy about statements of what is, what can be reached from
what is, and what might be reached from a number of such is/can-be-reached
steps. Idealism (especially bankrolled for years by a big company) doesn't
really matter. That's all.

It's not as if I have no ideals (I do). It's not as if we all don't want
better languages (plural) for web programming. We (most browser vendors,
perhaps all in light of DartVM not going into Chrome) do *not* want
multiple VMs and expensive write barriers in each to support cross-heap
cycle collection. Most or all browsers do not want to C++ code as
specification (being addressed by Dart's Ecma TC now, but not a done deal
as 20-year-old JS is). Most if not all browsers cannot afford multi-year
experiments that end in a good but incompatible outcome.

I hope this help!

/be

Danny Tuppeny

2015-06-19 17:07:04 UTC

Post by Don Olmstead
To add to Bob's assessment it also is targeting C/C++ not every language
under the sun.

Their pages specifically mention several other languages (like C#, Rust,
Go), so I don't believe this is the case (other than the immediate future).

Post by Don Olmstead
Somehow I have the impression people just desire WebAssembly to be what
they are waiting for without caring much what it actually is.

is, or will be?

Since the involved companies all have clear desires to provide something
"better" than JavaScript for web development and are now actually open to
working together on something; there is now a far bigger posibility of
"what we are waiting for" whereas previously it looked like it would never
happen. It doesn't seem crazy to be excited by this, especially if you work
on large client-heavy web apps. Once wasm is sufficiently mature, I just
can't see MS/Google/etc. passing up on making it a compile target for
things like Dart/TypeScript (even C#).

Even if it's years away, it looks like we're starting on the road to a good
solution. Compiling to JavaScript is not a *good* solution, it is the
*only/best* solution today. This needs to change, and maybe now it will.

Things like GC and DOM access are already listed as post-MVP desires:

https://github.com/WebAssembly/design/blob/master/FutureFeatures.md

Don Olmstead

2015-06-19 17:33:58 UTC

1. Specify and implement incrementally:
- a Minimum Viable Product (MVP)
<https://github.com/WebAssembly/design/blob/master/MVP.md> for the
standard with roughly the same functionality as asm.js
<http://asmjs.org/>, primarily aimed at C/C++
<https://github.com/WebAssembly/design/blob/master/CAndC++.md>;
- an effective and efficient polyfill
<https://github.com/WebAssembly/design/blob/master/Polyfill.md> library
for the MVP that translates WebAssembly code into JavaScript in
the client
so that WebAssembly MVP can run on existing browsers;
- a follow-up to the MVP
<https://github.com/WebAssembly/design/blob/master/PostMVP.md> which
adds several more essential features; and
- additional features
<https://github.com/WebAssembly/design/blob/master/FutureFeatures.md>,
specified iteratively and prioritized by feedback and
experience, including
support for languages other than C/C++.

from https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md.
Notice how languages other than C/C++ are a later feature.

Here's another blog post about what this is
http://bytecrafter.blogspot.com/2015/06/a-quick-overview-of-what-webassembly-is.html

You should probably curb your enthusiasm. Its a good start but its nothing
to get excited about yet.

Post by Don Olmstead
To add to Bob's assessment it also is targeting C/C++ not every language
under the sun.

Their pages specifically mention several other languages (like C#, Rust,
Go), so I don't believe this is the case (other than the immediate future).

Post by Don Olmstead
Somehow I have the impression people just desire WebAssembly to be what
they are waiting for without caring much what it actually is.

is, or will be?
Since the involved companies all have clear desires to provide something
"better" than JavaScript for web development and are now actually open to
working together on something; there is now a far bigger posibility of
"what we are waiting for" whereas previously it looked like it would never
happen. It doesn't seem crazy to be excited by this, especially if you work
on large client-heavy web apps. Once wasm is sufficiently mature, I just
can't see MS/Google/etc. passing up on making it a compile target for
things like Dart/TypeScript (even C#).
Even if it's years away, it looks like we're starting on the road to a
good solution. Compiling to JavaScript is not a *good* solution, it is
the *only/best* solution today. This needs to change, and maybe now it
will.
https://github.com/WebAssembly/design/blob/master/FutureFeatures.md
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

Cristian Garcia

2015-06-19 19:19:27 UTC

The exiting part is that now there is the possibility of a better solution
in the future.

Post by Don Olmstead
- a Minimum Viable Product (MVP)
<https://github.com/WebAssembly/design/blob/master/MVP.md> for the
standard with roughly the same functionality as asm.js
<http://asmjs.org/>, primarily aimed at C/C++
<https://github.com/WebAssembly/design/blob/master/CAndC++.md>;
- an effective and efficient polyfill
<https://github.com/WebAssembly/design/blob/master/Polyfill.md> library
for the MVP that translates WebAssembly code into JavaScript in the client
so that WebAssembly MVP can run on existing browsers;
- a follow-up to the MVP
<https://github.com/WebAssembly/design/blob/master/PostMVP.md> which
adds several more essential features; and
- additional features
<https://github.com/WebAssembly/design/blob/master/FutureFeatures.md>,
specified iteratively and prioritized by feedback and experience, including
support for languages other than C/C++.
from https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md.
Notice how languages other than C/C++ are a later feature.
Here's another blog post about what this is
http://bytecrafter.blogspot.com/2015/06/a-quick-overview-of-what-webassembly-is.html
You should probably curb your enthusiasm. Its a good start but its nothing
to get excited about yet.

Post by Don Olmstead
To add to Bob's assessment it also is targeting C/C++ not every language
under the sun.

Their pages specifically mention several other languages (like C#, Rust,
Go), so I don't believe this is the case (other than the immediate future).

Post by Don Olmstead
Somehow I have the impression people just desire WebAssembly to be what
they are waiting for without caring much what it actually is.

is, or will be?
Since the involved companies all have clear desires to provide something
"better" than JavaScript for web development and are now actually open to
working together on something; there is now a far bigger posibility of
"what we are waiting for" whereas previously it looked like it would never
happen. It doesn't seem crazy to be excited by this, especially if you work
on large client-heavy web apps. Once wasm is sufficiently mature, I just
can't see MS/Google/etc. passing up on making it a compile target for
things like Dart/TypeScript (even C#).
Even if it's years away, it looks like we're starting on the road to a
good solution. Compiling to JavaScript is not a *good* solution, it is
the *only/best* solution today. This needs to change, and maybe now it
will.
https://github.com/WebAssembly/design/blob/master/FutureFeatures.md
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

Brendan Eich

2015-06-20 03:38:44 UTC

We need all types, the alpha mighty-hunter types, the cheerleaders for
same, the disthymic types at the end of the campfire, scanning the
nighttime horizon for glowing eyes of sabertooths. I take Dan to be the
last ;-).

The glass is definitely 50.1% full. :-D

/be

Post by Cristian Garcia
The exiting part is that now there is the possibility of a better solution
in the future.

Post by Don Olmstead
To add to Bob's assessment it also is targeting C/C++ not every
language under the sun.

Their pages specifically mention several other languages (like C#, Rust,
Go), so I don't believe this is the case (other than the immediate future).

Post by Don Olmstead
Somehow I have the impression people just desire WebAssembly to be what
they are waiting for without caring much what it actually is.

is, or will be?
Since the involved companies all have clear desires to provide something
"better" than JavaScript for web development and are now actually open to
working together on something; there is now a far bigger posibility of
"what we are waiting for" whereas previously it looked like it would never
happen. It doesn't seem crazy to be excited by this, especially if you work
on large client-heavy web apps. Once wasm is sufficiently mature, I just
can't see MS/Google/etc. passing up on making it a compile target for
things like Dart/TypeScript (even C#).
Even if it's years away, it looks like we're starting on the road to a
good solution. Compiling to JavaScript is not a *good* solution, it is
the *only/best* solution today. This needs to change, and maybe now it
will.
https://github.com/WebAssembly/design/blob/master/FutureFeatures.md
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

Daniel Joyce

2015-06-20 04:51:15 UTC

Rust doesn't need a gc so it should be on the list....

Post by Brendan Eich
We need all types, the alpha mighty-hunter types, the cheerleaders for
same, the disthymic types at the end of the campfire, scanning the
nighttime horizon for glowing eyes of sabertooths. I take Dan to be the
last ;-).
The glass is definitely 50.1% full. :-D
/be

Post by Cristian Garcia
The exiting part is that now there is the possibility of a better
solution in the future.

Post by Don Olmstead
- a Minimum Viable Product (MVP)
<https://github.com/WebAssembly/design/blob/master/MVP.md> for
the standard with roughly the same functionality as asm.js
<http://asmjs.org/>, primarily aimed at C/C++
<https://github.com/WebAssembly/design/blob/master/CAndC++.md>;
- an effective and efficient polyfill
<https://github.com/WebAssembly/design/blob/master/Polyfill.md> library
for the MVP that translates WebAssembly code into JavaScript in the client
so that WebAssembly MVP can run on existing browsers;
- a follow-up to the MVP
<https://github.com/WebAssembly/design/blob/master/PostMVP.md> which
adds several more essential features; and
- additional features
<https://github.com/WebAssembly/design/blob/master/FutureFeatures.md>,
specified iteratively and prioritized by feedback and experience, including
support for languages other than C/C++.
from https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md.
Notice how languages other than C/C++ are a later feature.
Here's another blog post about what this is
http://bytecrafter.blogspot.com/2015/06/a-quick-overview-of-what-webassembly-is.html
You should probably curb your enthusiasm. Its a good start but its
nothing to get excited about yet.

Post by Don Olmstead
To add to Bob's assessment it also is targeting C/C++ not every
language under the sun.

Their pages specifically mention several other languages (like C#,
Rust, Go), so I don't believe this is the case (other than the immediate
future).

Post by Don Olmstead
Somehow I have the impression people just desire WebAssembly to be
what they are waiting for without caring much what it actually is.

is, or will be?
Since the involved companies all have clear desires to provide
something "better" than JavaScript for web development and are now actually
open to working together on something; there is now a far bigger posibility
of "what we are waiting for" whereas previously it looked like it would
never happen. It doesn't seem crazy to be excited by this, especially if
you work on large client-heavy web apps. Once wasm is sufficiently mature,
I just can't see MS/Google/etc. passing up on making it a compile target
for things like Dart/TypeScript (even C#).
Even if it's years away, it looks like we're starting on the road to a
good solution. Compiling to JavaScript is not a *good* solution, it is
the *only/best* solution today. This needs to change, and maybe now it
will.
https://github.com/WebAssembly/design/blob/master/FutureFeatures.md
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

Danny Tuppeny

2015-06-20 09:09:18 UTC

Post by Daniel Joyce
Rust doesn't need a gc so it should be on the list....

I'm not sure there's really "a list"... I don't think the job of the
WebAssembly group is to provide compilers for all the languages, but to
provide a format that is able to support these languages. I suspect
Mozilla/Google/MS (and others) will do the work of creating compilers to
compile their languages to wasm once it supports what is needed for each.

That said, Rust (along with many others) is mentioned on the tooling page
<https://github.com/WebAssembly/design/blob/master/Tooling.md>, so clearly
the goal is to build something that can ultimately support it.

Danny Tuppeny

2015-06-20 09:13:51 UTC

Post by Don Olmstead
from https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md.
Notice how languages other than C/C++ are a later feature.

I never suggested any timeline for support for other languages. But the
fact is, they're going to be a possibility long-term. This is a big change
from what we have today where every language gets compiled to JS and often
ends up with different behaviour/semantics to the native version or
performance penalties to correct it.

Post by Don Olmstead
You should probably curb your enthusiasm. Its a good start but its nothing
to get excited about yet.

I know it's very early days; but this could be the start of significant
change in web development. Any attempts to bring more language choice and
the ability to write more structured code to web development should be
applauded. This is the first time an attempt has been supported by all
major browser vendors, I really thing this is a big deal!

The more enthusiasm for projects like this, the faster and further they
will go. Enthusiasm should never be curbed.

2015-06-20 11:44:15 UTC

Post by Danny Tuppeny
The more enthusiasm for projects like this, the faster and further they
will go. Enthusiasm should never be curbed.

Well, Dart's very own Larry David certainly curbed Don's enthusiasm for
union types.

K.

Günter Zöchbauer

2015-06-20 12:23:22 UTC

Post by Danny Tuppeny
The more enthusiasm for projects like this, the faster and further they
will go. Enthusiasm should never be curbed.

Can't agree with this at all.
There are so many people claming everything they think might attract some
attention.
What's needed more than enthusiasm is critical thinking and investigating
if the right questions were asked.
Enthusiasm mostly causes bubbles and stupid useless hypes and a lot of
dissatisfaction when people learn they were following the wrong prophet,
while they could have done something useful with their time and energy.

2015-06-20 13:02:27 UTC

Post by GÃ¼nter ZÃ¶chbauer

Post by GÃ¼nter ZÃ¶chbauer
Can't agree with this at all.

There are so many people claming everything they think might attract some
attention.
What's needed more than enthusiasm is critical thinking and investigating
if the right questions were asked.
Given that Dart's main competitor is doing a victory dance in Dart's

endzone some critical thinking would be useful.

Developers can see the collegiate collaboration of Google/MS/Mozilla vs
Festung Aarhus.

K.

Cristian Garcia

2015-06-20 14:20:03 UTC

Lets imagine a say Python and Dart have compilers for wasm in a distant
future, would it be possible to call instantiated objects from Python in
Dart and vice-versa? Whats the story here?

Post by GÃ¼nter ZÃ¶chbauer

Post by GÃ¼nter ZÃ¶chbauer
Can't agree with this at all.

endzone some critical thinking would be useful.
Developers can see the collegiate collaboration of Google/MS/Mozilla vs
Festung Aarhus.
K.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

2015-06-20 14:59:45 UTC

Post by Cristian Garcia
Lets imagine a say Python and Dart have compilers for wasm in a distant
future, would it be possible to call instantiated objects from Python in
Dart and vice-versa? Whats the story here?

I think this is quite distant.

wasm is close to the metal low-level and static - truly 'C' for the web. As
you move up levels of abstraction to dynamic languages decisions need to be
made about core runtime semantics. The Python, dotnet, Java and JS VM's
all have their own runtime models. Attempts in the past to port Ruby and
Python to dotnet, Java and even JS VM's have never really panned out. There
was always friction and mismatches.

Also the JS engines (and Dart) have spent alot of effort on the JIT/gc
parts of their VM's. Why throw it away - better to subset/sunset the cruft
which causes complexity and deopts - which is the V8 teams approach with
Strong mode. Or start fresh - which is Darts.

What has worked are 'new' languages which take inspiration from other
programming languages/paradigms and applies them sympathetically to a
runtime. For instance Scheme/Lisp with Clojure and SML/Haskell/OCaml with
Scala on the JVM. Because of the shared object model interop is possible.

I honestly don't think ppl are looking for multiple languages and runtimes.
Rather they are looking for a runtime and libs with the the right
characteristics in terms of performance, resource usage, security,
toolability etc which is available in the client with a decent 'canonical'
syntax.

K.

Cristian Garcia

2015-06-20 15:52:09 UTC

@kc, thanks for the reply. I kind of get this for "normal" software, but I
have a hard time imagining how you would call e.g. the jQuery `$` object
through wasm. If this turns out to be impossible then there would be a huge
tradeoff: you get your nice language but loose all the UI goodies that the
JS community has been building for years.

I think this is quite distant.
wasm is close to the metal low-level and static - truly 'C' for the web.
As you move up levels of abstraction to dynamic languages decisions need to
be made about core runtime semantics. The Python, dotnet, Java and JS VM's
all have their own runtime models. Attempts in the past to port Ruby and
Python to dotnet, Java and even JS VM's have never really panned out. There
was always friction and mismatches.
Also the JS engines (and Dart) have spent alot of effort on the JIT/gc
parts of their VM's. Why throw it away - better to subset/sunset the cruft
which causes complexity and deopts - which is the V8 teams approach with
Strong mode. Or start fresh - which is Darts.
What has worked are 'new' languages which take inspiration from other
programming languages/paradigms and applies them sympathetically to a
runtime. For instance Scheme/Lisp with Clojure and SML/Haskell/OCaml with
Scala on the JVM. Because of the shared object model interop is possible.
I honestly don't think ppl are looking for multiple languages and
runtimes. Rather they are looking for a runtime and libs with the the
right characteristics in terms of performance, resource usage, security,
toolability etc which is available in the client with a decent 'canonical'
syntax.
K.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

Lex Berezhny

2015-06-20 16:05:44 UTC

Why would you want to use JavaScript crutches outside of JavaScript?

When doing Dart HTML development I've never found the need for $ because
you can use object oriented principles to solve the same problem in a much
better and more scalable way.

Post by Cristian Garcia
@kc, thanks for the reply. I kind of get this for "normal" software, but I
have a hard time imagining how you would call e.g. the jQuery `$` object
through wasm. If this turns out to be impossible then there would be a huge
tradeoff: you get your nice language but loose all the UI goodies that the
JS community has been building for years.

I think this is quite distant.
wasm is close to the metal low-level and static - truly 'C' for the web.
As you move up levels of abstraction to dynamic languages decisions need to
be made about core runtime semantics. The Python, dotnet, Java and JS VM's
all have their own runtime models. Attempts in the past to port Ruby and
Python to dotnet, Java and even JS VM's have never really panned out. There
was always friction and mismatches.
Also the JS engines (and Dart) have spent alot of effort on the JIT/gc
parts of their VM's. Why throw it away - better to subset/sunset the cruft
which causes complexity and deopts - which is the V8 teams approach with
Strong mode. Or start fresh - which is Darts.
What has worked are 'new' languages which take inspiration from other
programming languages/paradigms and applies them sympathetically to a
runtime. For instance Scheme/Lisp with Clojure and SML/Haskell/OCaml with
Scala on the JVM. Because of the shared object model interop is possible.
I honestly don't think ppl are looking for multiple languages and
runtimes. Rather they are looking for a runtime and libs with the the
right characteristics in terms of performance, resource usage, security,
toolability etc which is available in the client with a decent 'canonical'
syntax.
K.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

Brendan Eich

2015-06-22 17:39:28 UTC

I think this is quite distant.

Distant or not (we can wager, it's all speculation). I took kc's question
"what's the story here?" to be asking about the plan of record. The answer
(what, not when) is: one VM.

https://github.com/WebAssembly/design/blob/master/PostMVP.md
https://github.com/WebAssembly/design/blob/master/FutureFeatures.md

So yes, Python or Dart on future wasm with GC, JIT, and other support would
interop with the DOM and JS objects in one runtime, using one GC.

On "when", I agree this "one runtime to rule them all" is a ways out ;-).
Next year will be a stretch.

However, and this is why people are enthusiastic: getting onto the
evolutionary path toward this plan-of-record future right now is much
better than staying in a two-or-more-runtimes (three-or-more if you count
C++ and JS as first two, in today's browsers) planning stage. That stage
goes nowhere. (Sorry if I'm beating a dead horse!)

/be

Filipe Morgado

2015-06-22 19:30:14 UTC

I can imagine different languages sharing structures. But whole classes seems more difficult. They would need to share virtual tables (if not final) as well, with the respective overhead.

Should our APIs use structures for efficiency, or classes for ease-of-use?

Eitherway, it don't imagine it interoperating well with JS's mutating type system.
(not that I would use it)

Brendan Eich

2015-06-22 23:36:26 UTC

All browsers use C++ with vtbls to implement "host objects" including the
DOM. And all optimize JS => C++-vptr-at-front-object method calls. In other
words, sharing whole classes.

If you imagine otherwise, you're imaging either duplicative or incoherent
DOMs, which no one wants. The same ad-hoc properties on exandable DOM
objects, added by any language compiled to wasm or JS (or added by JS code
itself), must reflect to all.

"JS's mutating type system" does not parse. Please rephrase in standard
terms.

/be

Filipe Morgado

2015-06-23 03:24:32 UTC

A "mutating type system" is what JS has. It's not easy to optimize a given wasm module if the vtables keep changing/expanding under our feet from the JS side.

And by classes, I don't mean only DOM, but any class defined in any module. I wouldn't want JS to be able to override everything I statically declare.

2015-06-23 00:08:57 UTC

I think this is quite distant.

Looks very exciting. Especially given the collaboration between
MS/Mozilla/Google.

Post by Brendan Eich
However, and this is why people are enthusiastic: getting onto the
evolutionary path toward this plan-of-record future right now is much
better than staying in a two-or-more-runtimes (three-or-more if you count
C++ and JS as first two, in today's browsers) planning stage. That stage
goes nowhere. (Sorry if I'm beating a dead horse!)

Wither the DartVM given that it's not going into Chrome (or any other
browser)?

Well the reason I'm still interested in Dart are the Fletch and Sky
experiments for mobile apps. Save us from Java/XML.

https://github.com/dart-lang/fletch
https://github.com/domokit/sky_sdk/

Dart could give a developer the opportunity to create iOS and Android apps
with either 'native' or Sky UI's. And there's still dart2js for the web.
The Fletch concurrency story is especially interesting.
Sky has selected Dart as it's scripting language.

The DartVM proper - which was planned for Oilpan/Chrome and currently runs
in the server and Dartium - I'm not sure it pays for itself.

K.

Brendan Eich

2015-06-23 00:12:53 UTC

Post by Brendan Eich
However, and this is why people are enthusiastic: getting onto the

Post by Brendan Eich
evolutionary path toward this plan-of-record future right now is much
better than staying in a two-or-more-runtimes (three-or-more if you count
C++ and JS as first two, in today's browsers) planning stage. That stage
goes nowhere. (Sorry if I'm beating a dead horse!)

Wither the DartVM given that it's not going into Chrome (or any other
browser)?
Well the reason I'm still interested in Dart are the Fletch and Sky
experiments for mobile apps. Save us from Java/XML.
https://github.com/dart-lang/fletch
https://github.com/domokit/sky_sdk/
Dart could give a developer the opportunity to create iOS and Android apps
with either 'native' or Sky UI's. And there's still dart2js for the web.
The Fletch concurrency story is especially interesting.
Sky has selected Dart as it's scripting language.

This is all good and should help level the (proprietor-controlled) native
vs. web playing field.

Post by Brendan Eich
The DartVM proper - which was planned for Oilpan/Chrome and currently
runs in the server and Dartium - I'm not sure it pays for itself.

The dead horse. Enough beatings!

/be

2015-06-23 00:54:56 UTC

Post by Brendan Eich
However, and this is why people are enthusiastic: getting onto the

Wither the DartVM given that it's not going into Chrome (or any other
browser)?
Well the reason I'm still interested in Dart are the Fletch and Sky
experiments for mobile apps. Save us from Java/XML.
https://github.com/dart-lang/fletch
https://github.com/domokit/sky_sdk/
Dart could give a developer the opportunity to create iOS and Android
apps with either 'native' or Sky UI's. And there's still dart2js for the
web.
The Fletch concurrency story is especially interesting.
Sky has selected Dart as it's scripting language.

This is all good and should help level the (proprietor-controlled) native
vs. web playing field.

Sure. This is just my take on why Dart is still of interest in other than a
dart2js context. The DOM has always been the bottleneck and Sky is
definitely trying to tackle this - but not in a web context. And
concurrency > promises.

Post by Brendan Eich
The DartVM proper - which was planned for Oilpan/Chrome and currently
runs in the server and Dartium - I'm not sure it pays for itself.

The dead horse. Enough beatings!

Still fed and watered (for some reason).

K.

Post by Brendan Eich
/be

Cristian Garcia

2015-06-23 01:43:39 UTC

I really appreciate the DartVM, Dart by itself is an incredibly nice
language, flexible when you needed but with all the static goodies, and
very good support on webstorm. Makes coding asynchronous servers a very
nice experience, although I'll also give ASP .NET vNext a try now that you
can run it free on linux machines.

Post by Brendan Eich
However, and this is why people are enthusiastic: getting onto the

Wither the DartVM given that it's not going into Chrome (or any other
browser)?
Well the reason I'm still interested in Dart are the Fletch and Sky
experiments for mobile apps. Save us from Java/XML.
https://github.com/dart-lang/fletch
https://github.com/domokit/sky_sdk/
Dart could give a developer the opportunity to create iOS and Android
apps with either 'native' or Sky UI's. And there's still dart2js for the
web.
The Fletch concurrency story is especially interesting.
Sky has selected Dart as it's scripting language.

This is all good and should help level the (proprietor-controlled) native
vs. web playing field.

Sure. This is just my take on why Dart is still of interest in other than
a dart2js context. The DOM has always been the bottleneck and Sky is
definitely trying to tackle this - but not in a web context. And
concurrency > promises.

Post by Brendan Eich
The DartVM proper - which was planned for Oilpan/Chrome and currently
runs in the server and Dartium - I'm not sure it pays for itself.

The dead horse. Enough beatings!

Still fed and watered (for some reason).
K.

Post by Brendan Eich
/be
--

2015-06-23 23:33:01 UTC

Post by Cristian Garcia
I really appreciate the DartVM, Dart by itself is an incredibly nice
language, flexible when you needed but with all the static goodies, and
very good support on webstorm. Makes coding asynchronous servers a very
nice experience, although I'll also give ASP .NET vNext a try now that you
can run it free on linux machines.

On the server there's a lot of competition - Go, JVM, Node (reunited),
dotnet (open) and maybe even Swift and Rust.

Whereas Fletch imo is going after a niche with a lot of added value.

Maybe Fletch could think about targeting wasm - esp as wasm's
dynlang/Jit/GC story is fleshed out. Could be a way back to the browser.

And more broadly if Dart dev effort went towards things like value types in
ES7 it would help both JS and Dart.

K.

Brendan Eich

2015-06-18 23:28:54 UTC

Post by Filipe Morgado
I don't think WebAssembly (wasm) will ever support big integers, and the
lack of fixed-size arithmetic in Dart seems problematic.

Remember, wasm, asm.js and JS itself all evolve over rapid design/release
cycles. Bignums (Dart ints) are on the ES7/2016 roadmap, at least via value
types. It may take till ES2017, but your "ever" is a risky bet. JS wants
bignums for the same good reasons Dart int is what it is (in DartVM
-- https://github.com/dart-lang/sdk/issues/1533 is still open).

/be

Joao Pedrosa

2015-06-18 21:07:34 UTC

Hi,

I think they have hefty goals. By staying closer to the bare metal they
don't even need a lot of permission by Apple and Apple may even feel more
enticed to join the ranks since Apple likes the bare metal and their
languages can better fit that environment. And by their polyfill strategy
they also get support by those who want it to support some backward
compatibility.

The C++ revival is by itself a pain though. :-) Then there are the more
exciting alternatives like Rust and Swift.

Now that the web has apparently slowed down and the mobile has taken off,
more of them seem concerned with bringing the browser toolset to mobile and
take advantage of its sandbox there. So for all of the excitement around
this, beware of the sandbox monster hiding in the dark alley. :-)

Cheers,
Joao

Post by tomaszkubacki
Hello Dartisians,
I'm very curious what this new WebAssembly (
https://github.com/WebAssembly ) initiative means for Dart in general.
Will WebAssembly will be just another Dart's compilation target when it
matures ?
Thoughts ?
Cheers,
t.k
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

Cristian Garcia

2015-06-18 21:49:27 UTC

Bear with my low-level ignorance for a minute:

Dart is written in C++ and somehow WASM is aiming for C++ languages,
doesn't that help even a little? Now, totally assuming it doesn't, couldn't
the GC (and other language features) be included on an "import" before hand
or compiled into the byte-code itself?
Wouldn't this solve the code-size problem for Dart given a "dart2wasm"
compiler?

Leaving Dart aside, can I expect to develop client apps in e.g. Python in
the distant future?

Post by Joao Pedrosa
Hi,
I think they have hefty goals. By staying closer to the bare metal they
don't even need a lot of permission by Apple and Apple may even feel more
enticed to join the ranks since Apple likes the bare metal and their
languages can better fit that environment. And by their polyfill strategy
they also get support by those who want it to support some backward
compatibility.
The C++ revival is by itself a pain though. :-) Then there are the more
exciting alternatives like Rust and Swift.
Now that the web has apparently slowed down and the mobile has taken off,
more of them seem concerned with bringing the browser toolset to mobile and
take advantage of its sandbox there. So for all of the excitement around
this, beware of the sandbox monster hiding in the dark alley. :-)
Cheers,
Joao

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

'Bob Nystrom' via Dart Misc

2015-06-18 22:27:37 UTC

Post by Cristian Garcia
Dart is written in C++ and somehow WASM is aiming for C++ languages,
doesn't that help even a little? Now, totally assuming it doesn't, couldn't
the GC (and other language features) be included on an "import" before hand
or compiled into the byte-code itself?

It could be compiled into the bytecode (though you'd have to write another
JIT back-end since wasm is essentially a new "instruction set" that you
need to JIT to).

Let's say that bytecode is about as big as the native machine code that the
VM is normally compiled to. On my Mac, the Dart VM is about 12MB. I don't
think it's acceptable to add 12MB to a user's web app if they want to write
it in Dart, not to mention further problems from DOM interaction,
gross-heap GC issues, etc.

- bob

David Notik

2015-06-18 22:52:23 UTC

Great discussion. Thank you.

Some interaction I had w/ Brendan
Eich: https://twitter.com/davenotik/status/611636200277803008

It could be compiled into the bytecode (though you'd have to write another
JIT back-end since wasm is essentially a new "instruction set" that you
need to JIT to).
Let's say that bytecode is about as big as the native machine code that
the VM is normally compiled to. On my Mac, the Dart VM is about 12MB. I
don't think it's acceptable to add 12MB to a user's web app if they want to
write it in Dart, not to mention further problems from DOM interaction,
gross-heap GC issues, etc.
- bob

DoHyung Kim

2015-06-19 06:25:26 UTC

For browsers, I definitely agree with the approach taken by WASM guys.
There should be single VM for various practical reasons.

And as stated in this page
<https://github.com/WebAssembly/design/blob/master/Tooling.md>. I hope the
following statement is eventually realized: "Virtual machines which use a
just-in-time compiler (JavaScript VMs, luajit, pypy) should be able to
support a new just-in-time backend for WebAssembly." The statement surely
assumes when WASM has support for GC. Maybe we can add Dart VM to the list
of language VMs mentioned in the quote.

This is too early to think about the future of Dart VM, considering the
WASM effort is just announced and many details are still not determined.
Though, what I'm curious about is if Dart VM in other contexts such as
server is really competent in the future when WASM VMs (without any
privileged language implementations on them) are available. I know that the
language specific VM may do better in optimizing the generated codes, but
will its competitive edge be enough to justify the cost of maintaining a
separate VM? (see this page
<https://github.com/WebAssembly/design/blob/master/NonWeb.md> for
mentioning of WASM in non-browser contexts)

As for the possiblity of emitting bytecodes from a language VM running in
the very bytecode VM, dynamic languages running on JVM are already doing so.

2015-06-20 11:31:52 UTC

The idea of interfacing with a runtime via an AST is interesting.
Especially if the AST has both a readable text format and a dense binary
format and can round-trip between the two losslessly. Sidesteps issues with
trad byte code in Java/Flash/Dotnet.

I suggested something similar at core-dev - but for the higher level
dynamic side of things:

I've often thought that the best interface to a dynamic runtime would be a

truly abstract AST rather than source code. Agree on the modern semantics
- lexical bindings, closures/first class functions, classes with ref and
value semantics, good core primitives/collections with ideally built-in
concurrency /co-routines. End religious wars over syntax. Transformations
would be tree to tree.

The DartVM is basically a Smalltalk-like runtime, but the interface to this
*dynamic* VM is source code with an awful *static* Java-like syntax. So the
thing that makes this project interesting is lost.

If there was an AST interface it could be a target for language
innovation/experimentation. At the moment the source syntax and the DartVM
are so intertwined that any changes are tricky/expensive. There's nothing
wrong with syntax 'sugar' that transforms down to core semantics as long as
it's straightforward, non-magical and can be reasoned about.

K.

Hello Dartisians,
I'm very curious what this new WebAssembly (
https://github.com/WebAssembly ) initiative means for Dart in general.
Will WebAssembly will be just another Dart's compilation target when it
matures ?
Thoughts ?
Cheers,
t.k

'Justin Fagnani' via Dart Misc

2015-06-22 17:01:17 UTC

Post by kc
The idea of interfacing with a runtime via an AST is interesting.
Especially if the AST has both a readable text format and a dense binary
format and can round-trip between the two losslessly. Sidesteps issues with
trad byte code in Java/Flash/Dotnet.
I suggested something similar at core-dev - but for the higher level
I've often thought that the best interface to a dynamic runtime would be a

I think you're missing the very calculated reasons behind the static nature
of Dart (and I don't find the syntax awful at all): toolability. The static
features of Dart: the top-level of a Dart file is only declarations, not
statements. Imports, classes, functions and typedefs are all declarations.
No dynamic property access (without mirrors), is what makes Dart as
statically analyzable as it is - as toolable as it is. That analyzability
is a huge part of Dart's value proposition.

For example, it might be great fun for you to have your super class be an
expression, but it's not great for the analyzer, which suddenly can't tell
what class hierarchy you have and what the shape of your class is anymore.

Post by kc
If there was an AST interface it could be a target for language
innovation/experimentation.

An AST would only enable different expressions of essentially the same
syntax, basically by definition. You couldn't represent a construct that
isn't representable already in the AST. ASTs don't define semantics, and
having a standard AST wouldn't mean that you could do anything more dynamic
that you could now.

Post by kc
At the moment the source syntax and the DartVM are so intertwined that any
changes are tricky/expensive. There's nothing wrong with syntax 'sugar'
that transforms down to core semantics as long as it's straightforward,
non-magical and can be reasoned about.

If you're just talking about syntax transformations, you can already do
this with text formats... You can even go further than than syntax only
transformations if you so wish.

Post by kc
K.

Hello Dartisians,
I'm very curious what this new WebAssembly (
https://github.com/WebAssembly ) initiative means for Dart in general.
Will WebAssembly will be just another Dart's compilation target when it
matures ?
Thoughts ?
Cheers,
t.k

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

Daniel Joyce

2015-06-22 17:41:04 UTC

Javascript and perl render in depth tooling and code completiong/analysis
nearly impossible since they are so dynamic. Its difficult to write a tool
that can scan a javascript library and then provide code completion help
because there are about half a dozen ways to define
objects/libraries/modules in javascript, and every project uses their own
hack. Then not only that, the only way to suss out what properties on a
object may be available ( needed for completion ), you basically would need
to 'run' the program in some fashion, and then walk the live objects. But
of course in Javascript, even properties/methods/etc can change at run time
as well, over the life of the object! So writing any lexical analysis or
dynamic code completion support for Javascript or PERL borders on madness.

On Mon, Jun 22, 2015 at 10:01 AM 'Justin Fagnani' via Dart Misc <

a truly abstract AST rather than source code. Agree on the modern
semantics - lexical bindings, closures/first class functions, classes with
ref and value semantics, good core primitives/collections with ideally
built-in concurrency /co-routines. End religious wars over syntax.
Transformations would be tree to tree.

I think you're missing the very calculated reasons behind the static
nature of Dart (and I don't find the syntax awful at all): toolability. The
static features of Dart: the top-level of a Dart file is only declarations,
not statements. Imports, classes, functions and typedefs are all
declarations. No dynamic property access (without mirrors), is what makes
Dart as statically analyzable as it is - as toolable as it is. That
analyzability is a huge part of Dart's value proposition.
For example, it might be great fun for you to have your super class be an
expression, but it's not great for the analyzer, which suddenly can't tell
what class hierarchy you have and what the shape of your class is anymore.

Post by kc
If there was an AST interface it could be a target for language
innovation/experimentation.

Post by kc
At the moment the source syntax and the DartVM are so intertwined that
any changes are tricky/expensive. There's nothing wrong with syntax 'sugar'
that transforms down to core semantics as long as it's straightforward,
non-magical and can be reasoned about.

If you're just talking about syntax transformations, you can already do
this with text formats... You can even go further than than syntax only
transformations if you so wish.

Post by kc
K.

Hello Dartisians,
I'm very curious what this new WebAssembly (
https://github.com/WebAssembly ) initiative means for Dart in general.
Will WebAssembly will be just another Dart's compilation target when it
matures ?
Thoughts ?
Cheers,
t.k

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

Brendan Eich

2015-06-22 17:47:32 UTC

Post by Daniel Joyce
Javascript and perl render in depth tooling and code completiong/analysis
nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and many other such
products.

/be

'Justin Fagnani' via Dart Misc

2015-06-22 21:17:41 UTC

Post by Daniel Joyce
Javascript and perl render in depth tooling and code completiong/analysis
nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and many other
such products.

Oh, come on. JavaScript completers are usually very simple and dumb, based
on extracting what look like symbols in files. Even when they do analysis
(like Closure and Ternjs), they only work for a subset of the language and
often rely on extra type information like JSDocs or TypeScript.

It's trivial to terminally confuse even the best JavaScript analysis:

var Foo = Foo || (Foo() {
if (iHateStaticAnalysis) {
this.bar = 'JavaScript';
}
});

myFrameworksMixinApproximator(Foo, (function() {
var props = {};
if (iHateStaticAnalysis) {
props.baz = function() { return this.bar + ' is so awesome!'; }; //
error, warning, nothing?
}
return props;
})());

var foo = new Foo();
console.log(foo.baz().length); // Sorry Cloud9

Post by Brendan Eich
/be
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

Brendan Eich

2015-06-22 23:37:55 UTC

On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and many other
such products.

Daniel Joyce

2015-06-23 16:03:34 UTC

Dart is tolerable, its better than JS. But given how many times I've been
bitten by stupid bugs that a simple type system would catch in Javascript
or even python/Dart, I wish Dart had more typing, or at least more warnings.

We talk about writing secure software for the web and yet we still use
languages that can't even provide basic guarantees of soundness.

Post by Brendan Eich
On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and many other
such products.

And Dart's unsound type system differs only in degree, not kind. Useful
warning systems are useful.
I fear I've stumbled into the "tastes great! less filling!" section of
this list. Backing out slowly...
/be
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

'Justin Fagnani' via Dart Misc

2015-06-23 16:43:23 UTC

Post by Brendan Eich
On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and many other
such products.

And Dart's unsound type system differs only in degree, not kind. Useful
warning systems are useful.

And even a sound type system won't help know all available properties when
dealing in interfaces, so while technically the difference is "only" in
degree, it's still a massive difference.

Post by Brendan Eich
I fear I've stumbled into the "tastes great! less filling!" section of
this list. Backing out slowly...

I just have a problem with drawing an equivalence, or even near
equivalence, in static analyzability between languages like JavaScript and
languages like Dart. It borders on dishonesty. It's ok to say that
JavaScript is much more dynamic, and more malleable, with one tradeoff
being that it's harder to analyze.

Brendan Eich

2015-06-23 19:50:00 UTC

On Tue, Jun 23, 2015 at 9:43 AM, 'Justin Fagnani' via Dart Misc <

Post by Brendan Eich
On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc <

On Mon, Jun 22, 2015 at 10:41 AM, Daniel Joyce <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and many other
such products.

And Dart's unsound type system differs only in degree, not kind. Useful
warning systems are useful.

And even a sound type system won't help know all available properties when
dealing in interfaces, so while technically the difference is "only" in
degree, it's still a massive difference.

Yes, differences of degree matter. Agreed.

Post by Brendan Eich
I fear I've stumbled into the "tastes great! less filling!" section of
this list. Backing out slowly...

I just have a problem with drawing an equivalence, or even near
equivalence, in static analyzability between languages like JavaScript and
languages like Dart. It borders on dishonesty.

Sorry to Daniel, I misattributed "borders on dishonesty" to him.

It's ok to say that JavaScript is much more dynamic, and more malleable,

Post by 'Justin Fagnani' via Dart Misc
with one tradeoff being that it's harder to analyze.

"harder" == "difference of degree". It seems we agree.

JS with junk like `with` is hard to impossible to analyze, period. No
question. Dart's a lot easier!

However, modern autocomplete tooling (the subject up-thread) does not
"guess".

/be

'Justin Fagnani' via Dart Misc

2015-06-23 21:48:52 UTC

Post by Brendan Eich
On Tue, Jun 23, 2015 at 9:43 AM, 'Justin Fagnani' via Dart Misc <

Post by Brendan Eich
On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc <

On Mon, Jun 22, 2015 at 10:41 AM, Daniel Joyce <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and many other
such products.

And Dart's unsound type system differs only in degree, not kind. Useful
warning systems are useful.

And even a sound type system won't help know all available properties
when dealing in interfaces, so while technically the difference is "only"
in degree, it's still a massive difference.

Yes, differences of degree matter. Agreed.

Post by Brendan Eich
I fear I've stumbled into the "tastes great! less filling!" section of
this list. Backing out slowly...

I just have a problem with drawing an equivalence, or even near
equivalence, in static analyzability between languages like JavaScript and
languages like Dart. It borders on dishonesty.

Sorry to Daniel, I misattributed "borders on dishonesty" to him.
It's ok to say that JavaScript is much more dynamic, and more malleable,

Post by 'Justin Fagnani' via Dart Misc
with one tradeoff being that it's harder to analyze.

"harder" == "difference of degree". It seems we agree.
JS with junk like `with` is hard to impossible to analyze, period. No
question. Dart's a lot easier!

Post by Brendan Eich
"guess".

I never said it did (I mentioned Closure and Tern which go to great lengths
to do analysis and inference). Their capabilities simply pale in comparison
even to the Dart analyzer, to such a degree that the comparison is silly.

In personal experience, I write JavaScript full time now, and the pain is
very real. I've used almost every JS analyzer out there. They all suck (and
it's not their fault). It's not just auto-complete - knowing that the code
you wrote has a reasonable chance of running requires... running it. I have
to write a lot more mind-numbingly boring tests now to protect against
things that should be caught by tools. I'll probably start using Closure
compiler soon. I was trying to stay with as plain JS as possible, but
that's just a path to more bugs. I hope SoundScript and strong mode work
out, they seem to be the only hope for mainstream JS programmers.

Don Olmstead

2015-06-23 22:07:47 UTC

I totally agree with Justin here. JS is a poor language to attempt any sort
of analysis on. For anyone coming from a C/C++/C# language its horribly
lacking in terms of analysis.

There are things that help like closure compiler but even that has
problems. Basically you end up in a realm where you have to annotate
everything to make it moderately useful. It requires a discipline that is
hard to ask for from other developers who kinda cowboy code their way since
JS lets them do that. Even if you follow the conventions there are cases
where it still doesn't catch everything. As an example I had a typo where I
was removing something from an array and so nothing was ever being removed.
This was caught years later in this code base. Closure compiler never said
a word. The Dart analyzer would've freaked out over that. Instead you end
up writing tests on everything to double check something weird isnt
happening which honestly makes writing stuff in JS a huge chore.

Brendan Eich

2015-06-23 23:49:19 UTC

As an example I had a typo where I was removing something from an array
and so nothing was ever being removed. This was caught years later in this
code base. Closure compiler never said a word. The Dart analyzer would've
freaked out over that.

Hi Don, do you remember the typo? I'm still in touch with Dimitris
Vardoulakis, who works on Closure. Maybe there's something more to do. I'm
curious too what the equivalent Dart would have looked like, where the typo
would have led to a freak-out. Thanks.

/be

Don Olmstead

2015-06-23 23:58:07 UTC

Sure. It was really surprising it didn't get caught when it got found.

// Within a member function
// this.tasks_ was typed as an Array<function>
var tasks = this.tasks_,
index = tasks.indexOf(tasks);

It might already be fixed. The code base doesn't see a lot of movement
anymore so been sticking with an older version of Closure compiler.

Brendan Eich

2015-06-24 09:07:09 UTC

Post by Don Olmstead
Sure. It was really surprising it didn't get caught when it got found.
// Within a member function
// this.tasks_ was typed as an Array<function>
var tasks = this.tasks_,
index = tasks.indexOf(tasks);
It might already be fixed. The code base doesn't see a lot of movement
anymore so been sticking with an older version of Closure compiler.

Just to close this sub-thread out, Dimitris wrote back "The current
[Closure] type checker doesn't catch it, because it's quite loose when
instantiating generics. We're currently working on a new type checker,
which is more strict with things like that."

/be

Alex Tatumizer

2015-06-24 21:36:10 UTC

Post by Brendan Eich
At some later date, wasm should grow support needed to be a better target

for compilation of Dart than JS is today, as Bob noted. In that future wasm
iteration, the AST code will still be statically typed. Not redundantly or
abundantly, just enough to verify.

If wasm becomes a target of dart compilation, AND wasm is statically typed,
then dart has to become statically typed, too. Not redundantly or
abundantly, just enough to verify, but still - no more optional typing.

I wonder what was the benefit of optional typing to begin with.
It can save you some keystrokes, and initially I was enthusiastic about the
boldness of the decision, but when I started refactoring, turned out free
lunch comes at a price.
In retrospect, maybe optional typing was an attempt to appeal to
javascript programmers, who were assumed to love type-less coding?
(I'm speculating here, sorry).

Brendan Eich

2015-06-24 22:20:56 UTC

Post by Brendan Eich
At some later date, wasm should grow support needed to be a better

target for compilation of Dart than JS is today, as Bob noted. In that
future wasm iteration, the AST code will still be statically typed. Not
redundantly or abundantly, just enough to verify.
If wasm becomes a target of dart compilation, AND wasm is statically
typed, then dart has to become statically typed, too. Not redundantly or
abundantly, just enough to verify, but still - no more optional typing.

No, because future wasm will have dynamic language features including an
"Any" type and JIT support. That's all down the road, on the roadmap:

https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#platform-independent-just-in-time-compilation

I share Bob Nystrom's skepticism about JS being an inferior target to
future-wasm, because future-JS will still be another syntax reaching the
one VM per browser. But to be fair and remove my own speculations, the
stated roadmap includes dynamic language support.

Here's another way to think of wasm and its roadmap: benchmark against the
JVM. The JVM has grown dynamic language support (finally) and can host
languages including JS and Ruby pretty well now. We should be able to meet
or beat.

/be

Brendan Eich

2015-06-23 22:45:57 UTC

JS with junk like `with` is hard to impossible to analyze, period. No question. Dart's a lot easier!

Don't I know it! JS sucks, let me tell you :-P. But we're stuck with it.

Nevertheless, low-annotation and bare-JS analyzers such as DoctorJS and Flow can cope, till they call out errors. Some people find them useful.

It'll get worse with decorators that mutate property descriptors.

Decorators that do runtime meta programming are not a done deal, FYI. Ecma TC39 pushed back, the draft spec went back to the lab.

However, modern autocomplete tooling (the subject up-thread) does not "guess".

I never said it did

Right, Daniel J. wrote "guess" -- you wrote that most are "simple and dumb". Re-reading up the thread, I see kc criticized Dart syntax in context of wasm AST code, and you replied with a fine defense of Dart syntax and how it benefits analysis. No one was arguing against that except kc.

Yet from my last exchange with Danny T., it's clear many folks still assume JS and other dynamic languages cannot be analyzed usefully, e.g. for autocomplete. I say that's false. Nothing against Dart in saying so, and borderline honesty requires it. :-|

(I mentioned Closure and Tern which go to great lengths to do analysis and inference). Their capabilities simply pale in comparison even to the Dart analyzer, to such a degree that the comparison is silly.

Who said anything against Dart? That JS IDEs and other tools can autocomplete and do useful albeit "pale" static checks doesn't play a zero sum game vs. Dart. What's with the "comparison" strawman?

There is no either/or here, just people wondering about wasm and Dart. Maybe we should pop the stack to the Subject: topic, after agreeing Dart is easier to analyze by far than JS :-).

In personal experience, I write JavaScript full time now, and the pain is very real. I've used almost every JS analyzer out there. They all suck (and it's not their fault).

Have you used Flow?

I hope SoundScript and strong mode work out, they seem to be the only hope for mainstream JS programmers.

Opinions vary -- many people like JS with just linters. Mainstream JS is what it is.

SoundScript may work out, in part by collaboration with Flow and TS. Without collaboration and buy-in across the developer and vendor spaces, it will fail as ES4 did.

Strong mode, I have a harder time handicapping.

But if neither SoundScript nor strong mode works out, the tool-checked code culture of Flow, TS, and the linters will probably cope. I don't buy that "only hope" line (it was false in Star Wars Ep. IV too ;-).

/be

Cogman

2015-06-23 23:14:36 UTC

@Brandon

I think the thing most people are getting at here is that no matter what,
more statically typed languages will be able to have better tooling than
less/dynamically typed languages. Sure, there are a lot of neat things you
can do to make it better/smarter/faster, but ultimately you are striving to
get to an "on par" level of tooling compared to a statically typed language.

That isn't to say that these tools aren't useful and interesting. Just
that ultimately the nature of javascript means that it is really REALLY
easy to write code which will confuse the best static javascript analyser.
You ultimately have to either decide you will only write javascript in a
way that tools can digest, or live with the fact that the tools aren't
going to handle every situation you could devise.

Compare that with the tooling around Java. Tools don't generally get
lost. Auto complete and static analysis tools are really fantastic and
they actually provide a lot of useful information and checks basically at
the cost of a little extra developer time worrying about types.

It all comes down to information. Tools work best when there is an
abundance of it.

On Jun 23, 2015, at 2:48 PM, 'Justin Fagnani' via Dart Misc <
JS with junk like `with` is hard to impossible to analyze, period. No

Post by Brendan Eich
question. Dart's a lot easier!

It's not just 'with' it's open objects, open prototypes and building them
imperatively, mutable proto pointers, 'this' bindings, class expressions,
extends expressions. Reflective access (o[p]) being first class with
property screws with analysis.
Don't I know it! JS sucks, let me tell you :-P. But we're stuck with it.
Nevertheless, low-annotation and bare-JS analyzers such as DoctorJS and
Flow can cope, till they call out errors. Some people find them useful.
It'll get worse with decorators that mutate property descriptors.
Decorators that do runtime meta programming are not a done deal, FYI. Ecma
TC39 pushed back, the draft spec went back to the lab.
However, modern autocomplete tooling (the subject up-thread) does not

Post by Brendan Eich
"guess".

I never said it did
Right, Daniel J. wrote "guess" -- you wrote that most are "simple and
dumb". Re-reading up the thread, I see kc criticized Dart syntax in context
of wasm AST code, and you replied with a fine defense of Dart syntax and
how it benefits analysis. No one was arguing against that except kc.
Yet from my last exchange with Danny T., it's clear many folks still
assume JS and other dynamic languages cannot be analyzed usefully, e.g. for
autocomplete. I say that's false. Nothing against Dart in saying so, and
borderline honesty requires it. :-|
(I mentioned Closure and Tern which go to great lengths to do analysis and
inference). Their capabilities simply pale in comparison even to the Dart
analyzer, to such a degree that the comparison is silly.
Who said anything against Dart? That JS IDEs and other tools can
autocomplete and do useful albeit "pale" static checks doesn't play a zero
sum game vs. Dart. What's with the "comparison" strawman?
There is no either/or here, just people wondering about wasm and Dart.
Maybe we should pop the stack to the Subject: topic, after agreeing Dart is
easier to analyze by far than JS :-).
In personal experience, I write JavaScript full time now, and the pain is
very real. I've used almost every JS analyzer out there. They all suck (and
it's not their fault).
Have you used Flow?
I hope SoundScript and strong mode work out, they seem to be the only hope
for mainstream JS programmers.
Opinions vary -- many people like JS with just linters. Mainstream JS is what it is.
SoundScript may work out, in part by collaboration with Flow and TS.
Without collaboration and buy-in across the developer and vendor spaces, it
will fail as ES4 did.
Strong mode, I have a harder time handicapping.
But if neither SoundScript nor strong mode works out, the tool-checked
code culture of Flow, TS, and the linters will probably cope. I don't buy
that "only hope" line (it was false in Star Wars Ep. IV too ;-).
/be
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

Brendan Eich

2015-06-23 23:40:34 UTC

Post by Cogman
@Brandon

(Brendan.)

Post by Cogman
I think the thing most people are getting at here [...]

No need to demolish strawman arguments. No one recommended JS as an easy to analyze candidate language for any role before us on the Web. JS is not the topic in the subject, wasm and Dart are the topics.

I posted something against the false idea tha auto-complete in JS just "guesses", and something else on the higher order analyses for JS that seem unknown or misunderstood. But that was just in a few replies to digressions along the thread. Sorry to have added to the digressing.

Post by Cogman
It all comes down to information. Tools work best when there is an abundance of it.

To get back on topic, wasm is statically typed AST code that starts out equal to asm.js (a true static type system for an object-less subset of JS) but which can grow and diverge.

At some later date, wasm should grow support needed to be a better target for compilation of Dart than JS is today, as Bob noted. In that future wasm iteration, the AST code will still be statically typed. Not redundantly or abundantly, just enough to verify.

I'm glad you like Dart. I do too. It is nicely done.

/be

2015-06-23 23:17:16 UTC

Post by Brendan Eich
Right, Daniel J. wrote "guess" -- you wrote that most are "simple and
dumb". Re-reading up the thread, I see kc criticized Dart syntax in context
of wasm AST code, and you replied with a fine defense of Dart syntax and
how it benefits analysis. No one was arguing against that except kc.

I was arguing in favour of a sane core runtime object model with pluggable
types/analysis. Not against declarative structure or analysis. I have a
feeling that the Java-ish syntax of Dart locks dev's into some
misconceptions about Darts core semantics and it's
optional/gradual/pluggable type annotation concepts. Perversely the TS type
annotation syntax could have made these ideas an easier sell (I think).

K.

Brendan Eich

2015-06-23 23:56:23 UTC

I was arguing in favour of a sane core runtime object model with pluggable
types/analysis. Not against declarative structure or analysis.

Right, sorry if I seemed to suggest otherwise! Thanks for clarifying.

Post by kc
I have a feeling that the Java-ish syntax of Dart locks dev's into some
misconceptions about Darts core semantics and it's
optional/gradual/pluggable type annotation concepts. Perversely the TS type
annotation syntax could have made these ideas an easier sell (I think).

Interesting. For JS, the Algol/ML-style ":" annotation syntax is reserved
to future standards, not to be differently implemented as an allowed
extension by a particular implementation. Not that TC39 foresees making
types pluggable, but we've discussed that idea too.

/be

2015-06-24 01:08:04 UTC

I was arguing in favour of a sane core runtime object model with
pluggable types/analysis. Not against declarative structure or analysis.

Right, sorry if I seemed to suggest otherwise! Thanks for clarifying.

The rhs ":" type annotation syntax both for eye-balling and parsing/tooling
always seemed superior to the 'C'/Java style imo. When TS was announced I
thought there was a case for skinning Dart with this syntax. A lot of
tooling could have been co-opted.

Also, a structured critique (as opposed to abuse) of JS vs the benefits of
Dart's core runtime model was never made effectively imo. Potential early
adopter dev's of Dart were making their mind up within five minutes - an
instinctive 'Java - wft'. Periodically Seth Ladd goes onto
reddit/hackernews to disabuse folks of this - but it's an uphill battle.

K.

Post by Brendan Eich
/be

Gen

2015-06-24 22:14:35 UTC

Quote: "In personal experience, I write JavaScript full time now, and the
pain is very real."

What could possibly be the reason for writing JavaScript if you do not like
it ?
Seriously.
There is Typescript.
And you work even for Google, the company that tries promote Dart as
alternative.

Post by Brendan Eich
On Tue, Jun 23, 2015 at 9:43 AM, 'Justin Fagnani' via Dart Misc <

Post by Brendan Eich
On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and many
other such products.

And Dart's unsound type system differs only in degree, not kind. Useful
warning systems are useful.

And even a sound type system won't help know all available properties
when dealing in interfaces, so while technically the difference is "only"
in degree, it's still a massive difference.

Yes, differences of degree matter. Agreed.

Post by Brendan Eich
I fear I've stumbled into the "tastes great! less filling!" section of
this list. Backing out slowly...

I just have a problem with drawing an equivalence, or even near
equivalence, in static analyzability between languages like JavaScript and
languages like Dart. It borders on dishonesty.

Sorry to Daniel, I misattributed "borders on dishonesty" to him.
It's ok to say that JavaScript is much more dynamic, and more malleable,

Post by 'Justin Fagnani' via Dart Misc
with one tradeoff being that it's harder to analyze.

"harder" == "difference of degree". It seems we agree.
JS with junk like `with` is hard to impossible to analyze, period. No
question. Dart's a lot easier!

Post by Brendan Eich
"guess".

I never said it did (I mentioned Closure and Tern which go to great
lengths to do analysis and inference). Their capabilities simply pale in
comparison even to the Dart analyzer, to such a degree that the comparison
is silly.
In personal experience, I write JavaScript full time now, and the pain is
very real. I've used almost every JS analyzer out there. They all suck (and
it's not their fault). It's not just auto-complete - knowing that the code
you wrote has a reasonable chance of running requires... running it. I have
to write a lot more mind-numbingly boring tests now to protect against
things that should be caught by tools. I'll probably start using Closure
compiler soon. I was trying to stay with as plain JS as possible, but
that's just a path to more bugs. I hope SoundScript and strong mode work
out, they seem to be the only hope for mainstream JS programmers.

'Justin Fagnani' via Dart Misc

2015-06-24 22:45:35 UTC

Post by Gen
Quote: "In personal experience, I write JavaScript full time now, and the
pain is very real."
What could possibly be the reason for writing JavaScript if you do not
like it ?
Seriously.
There is Typescript.
And you work even for Google, the company that tries promote Dart as
alternative.

Not every project at Google uses Dart. Or GWT, TypeScript, Closure... or
plain JavaScript even.

Every project has their own priorities and makes their own decisions. I
joined the Polymer team which tries to stick to very plain JS (no required
build steps, no module systems, etc.) for many reasons. That was my
calculated tradeoff when I joined them, but it doesn't make it less painful
:)

Post by Brendan Eich
On Tue, Jun 23, 2015 at 9:43 AM, 'Justin Fagnani' via Dart Misc <

Post by Brendan Eich
On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and many
other such products.

And Dart's unsound type system differs only in degree, not kind.
Useful warning systems are useful.

And even a sound type system won't help know all available properties
when dealing in interfaces, so while technically the difference is "only"
in degree, it's still a massive difference.

Yes, differences of degree matter. Agreed.

Post by Brendan Eich
I fear I've stumbled into the "tastes great! less filling!" section of
this list. Backing out slowly...

I just have a problem with drawing an equivalence, or even near
equivalence, in static analyzability between languages like JavaScript and
languages like Dart. It borders on dishonesty.

Sorry to Daniel, I misattributed "borders on dishonesty" to him.
It's ok to say that JavaScript is much more dynamic, and more malleable,

Post by 'Justin Fagnani' via Dart Misc
with one tradeoff being that it's harder to analyze.

"harder" == "difference of degree". It seems we agree.
JS with junk like `with` is hard to impossible to analyze, period. No
question. Dart's a lot easier!

Post by Brendan Eich
"guess".

I never said it did (I mentioned Closure and Tern which go to great
lengths to do analysis and inference). Their capabilities simply pale in
comparison even to the Dart analyzer, to such a degree that the comparison
is silly.
In personal experience, I write JavaScript full time now, and the pain is
very real. I've used almost every JS analyzer out there. They all suck (and
it's not their fault). It's not just auto-complete - knowing that the code
you wrote has a reasonable chance of running requires... running it. I have
to write a lot more mind-numbingly boring tests now to protect against
things that should be caught by tools. I'll probably start using Closure
compiler soon. I was trying to stay with as plain JS as possible, but
that's just a path to more bugs. I hope SoundScript and strong mode work
out, they seem to be the only hope for mainstream JS programmers.

Post by Brendan Eich
/be
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

Daniel Joyce

2015-06-25 02:06:51 UTC

There is also type inferencing. I rarely have to sprinkle types in Scala...
Static typing and strong type inferencing give you the best of both
worlds...

On Wed, Jun 24, 2015, 15:45 'Justin Fagnani' via Dart Misc <

Not every project at Google uses Dart. Or GWT, TypeScript, Closure... or
plain JavaScript even.
Every project has their own priorities and makes their own decisions. I
joined the Polymer team which tries to stick to very plain JS (no required
build steps, no module systems, etc.) for many reasons. That was my
calculated tradeoff when I joined them, but it doesn't make it less painful
:)

Post by Brendan Eich
On Tue, Jun 23, 2015 at 9:43 AM, 'Justin Fagnani' via Dart Misc <

Post by Brendan Eich
On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc <

On Mon, Jun 22, 2015 at 10:41 AM, Daniel Joyce <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and many
other such products.

And Dart's unsound type system differs only in degree, not kind.
Useful warning systems are useful.

And even a sound type system won't help know all available properties
when dealing in interfaces, so while technically the difference is "only"
in degree, it's still a massive difference.

Yes, differences of degree matter. Agreed.

Post by Brendan Eich
I fear I've stumbled into the "tastes great! less filling!" section
of this list. Backing out slowly...

I just have a problem with drawing an equivalence, or even near
equivalence, in static analyzability between languages like JavaScript and
languages like Dart. It borders on dishonesty.

Sorry to Daniel, I misattributed "borders on dishonesty" to him.
It's ok to say that JavaScript is much more dynamic, and more

Post by 'Justin Fagnani' via Dart Misc
malleable, with one tradeoff being that it's harder to analyze.

"harder" == "difference of degree". It seems we agree.
JS with junk like `with` is hard to impossible to analyze, period. No
question. Dart's a lot easier!

Post by Brendan Eich
"guess".

I never said it did (I mentioned Closure and Tern which go to great
lengths to do analysis and inference). Their capabilities simply pale in
comparison even to the Dart analyzer, to such a degree that the comparison
is silly.
In personal experience, I write JavaScript full time now, and the pain
is very real. I've used almost every JS analyzer out there. They all suck
(and it's not their fault). It's not just auto-complete - knowing that the
code you wrote has a reasonable chance of running requires... running it. I
have to write a lot more mind-numbingly boring tests now to protect against
things that should be caught by tools. I'll probably start using Closure
compiler soon. I was trying to stay with as plain JS as possible, but
that's just a path to more bugs. I hope SoundScript and strong mode work
out, they seem to be the only hope for mainstream JS programmers.

Post by Brendan Eich
/be
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

Alex Tatumizer

2015-06-25 02:38:51 UTC

Post by Brendan Eich
No, because future wasm will have dynamic language features including an

"Any" type and JIT support.
@Brendan: "Any" won't help much. Type system in dart is a bit involved.
Consider this line:
int x="foo";
It produces a warning (not an error). How would you compile it to the
language with static typing?
You can't say
any x="foo" - because the type says "int".
And you can't compile it to
int x="foo" - because in the target language, this would be an error.

Type inference has its own quirks, too. E.g.
var x="foo";
x=0;
produces no errors and no warnings; though type inference exists, it's not
equivalent to explicit declaration.
(To play with small snippets of the code, you can use
https://dartpad.dartlang.org/)

This is just a tip of the iceberg. There are errors, warnings and hints,
checked mode, VM, dartium, javascript etc. - these notions come into play
when one starts wrapping their head around dart's type system.

Again, my guess is that properties of target language had major effect on
the design of dart's type system. If target languages changes (e.g becomes
statically typed) - the concept might be in need of some rethinking.

DoHyung Kim

2015-06-25 05:40:05 UTC

Alex,

Dart erases all the type annotation at runtime (though objects carry their
type information at runtime). So using any for all variables should work
for compling Dart down into WASM. Also even if a Dart implementation on
WASM requires to implement *checked mode*, it can generate additional
checks here and there.

Post by Brendan Eich
No, because future wasm will have dynamic language features including an

"Any" type and JIT support.
@Brendan: "Any" won't help much. Type system in dart is a bit involved.
int x="foo";
It produces a warning (not an error). How would you compile it to the
language with static typing?
You can't say
any x="foo" - because the type says "int".
And you can't compile it to
int x="foo" - because in the target language, this would be an error.
Type inference has its own quirks, too. E.g.
var x="foo";
x=0;
produces no errors and no warnings; though type inference exists, it's
not equivalent to explicit declaration.
(To play with small snippets of the code, you can use
https://dartpad.dartlang.org/)
This is just a tip of the iceberg. There are errors, warnings and hints,
checked mode, VM, dartium, javascript etc. - these notions come into play
when one starts wrapping their head around dart's type system.
Again, my guess is that properties of target language had major effect on
the design of dart's type system. If target languages changes (e.g becomes
statically typed) - the concept might be in need of some rethinking.

'Lasse R.H. Nielsen' via Dart Misc

2015-06-25 05:46:32 UTC

Post by Brendan Eich
No, because future wasm will have dynamic language features including an

If it only gives a warning, then you are in production mode. That means the
type is actually dynamic/Any at runtime.
In Dart production mode, type assertions are ignored. That corresponds to a
variable having a type that allows any value and any operation on it -
which is equivalent to the type "dynamic".

Post by Brendan Eich
You can't say
any x="foo" - because the type says "int".

Who can't say that? The compiler sure can.

Post by Brendan Eich
And you can't compile it to
int x="foo" - because in the target language, this would be an error.

In production mode you would compile it to "any". In checked mode you would
compile it to "int".
Seems fine to me.

Post by Brendan Eich
Type inference has its own quirks, too. E.g.
var x="foo";
x=0;
produces no errors and no warnings; though type inference exists, it's
not equivalent to explicit declaration.
(To play with small snippets of the code, you can use
https://dartpad.dartlang.org/)
This is just a tip of the iceberg. There are errors, warnings and hints,
checked mode, VM, dartium, javascript etc. - these notions come into play
when one starts wrapping their head around dart's type system.

Oh, I'm not saying that adapting one type system to another is going to be
easy. I'm quite a lot more worried about mixins, function types and
bi-variance of function parameters.
Type assertions are pretty simple compared to that (well, depending on how
wasm's types will behave wrt. being nullable/non-nullable).

Post by Brendan Eich
Again, my guess is that properties of target language had major effect on
the design of dart's type system. If target languages changes (e.g becomes
statically typed) - the concept might be in need of some rethinking.

I doubt that will be the problem - if you have "any", you can always use
that and move the Dart type checks into the compiled code. It might hurt
performance, but we're compiling the same thing to JS now!

If/when JS gets bignums, that'll be a big day for Dart-to-JS compilation.
It not being there didn't stop Dart from adding them to the language.

/L
--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÃžbenhavn K
- Denmark - CVR nr. 28 86 69 84

2015-06-25 12:20:32 UTC

On Thursday, June 25, 2015 at 6:46:56 AM UTC+1, Lasse Reichstein Holst

Post by 'Lasse R.H. Nielsen' via Dart Misc
If/when JS gets bignums, that'll be a big day for Dart-to-JS compilation.
It not being there didn't stop Dart from adding them to the language.

Dart did add bigints without a clear dart2js story.

On the SIMD front John McCutchan was able to communicate/collaborate with
BE/TC39 to make progress.

Why not for bignum/bigints? It would have benefited both Dart and JS.

K.

Post by 'Lasse R.H. Nielsen' via Dart Misc
/L
--
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÃžbenhavn K
- Denmark - CVR nr. 28 86 69 84

Daniel Joyce

2015-06-25 15:39:54 UTC

Post by Brendan Eich
No, because future wasm will have dynamic language features including an

In scala, that would be an error.

var x = "foo" <- Compiler goes "Ahh, x is a String, type assigned when
variable declared

x = 0 <- Compiler throws error, make up your mind!

The inferred type of 'x' is fixed by inference when it is declared and can
not be changed

If simple assignment ( not declaration ) can change the type, you don't
have type inference / static typing, you have a dynamically typed language.

To get what you are thinking of

var a = true;

var x = if(a){
"A"
}else{
0
}

x now has the type of Any at variable declaration time, since the inferred
type of the if statement evaluates to Any.
--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

2015-06-25 11:24:59 UTC

I joined the Polymer team which tries to stick to very plain JS (no
required build steps, no module systems, etc.) for many reasons.

Plain JS as in ES5? This makes your comments above more understandable.

But there has been a big shift to Babel/ES6/TS/Flow. Basically there is now
enough tooling/analysis available via a mainstream route. This wasn't true
when Dart kicked off but it's true now.

It's unlikely Dart will pick up any new users given the announcement that
the DartVM is not going into Chrome. And wasm is the icing on the cake. The
V8 engine will have ES6+/Strong mode/SoundScript + wasm. I'm sure the V8
team are thinking about how to leverage wasm in a SoundScript context with
a decent evolutionary path in 1VM.

Every project has their own priorities and makes their own decisions.

This is eventually going to hurt Google. Too many languages and runtimes.
Dev's need platforms/ecosystems. Fletch and Sky are interesting - but will
these experiments turn into products that dev's can rely on.

K.

Not every project at Google uses Dart. Or GWT, TypeScript, Closure... or
plain JavaScript even.
Every project has their own priorities and makes their own decisions. I
joined the Polymer team which tries to stick to very plain JS (no required
build steps, no module systems, etc.) for many reasons. That was my
calculated tradeoff when I joined them, but it doesn't make it less painful
:)

Post by Brendan Eich
On Tue, Jun 23, 2015 at 9:43 AM, 'Justin Fagnani' via Dart Misc <

Post by Brendan Eich
On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc <

On Mon, Jun 22, 2015 at 10:41 AM, Daniel Joyce <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and many
other such products.

And Dart's unsound type system differs only in degree, not kind.
Useful warning systems are useful.

And even a sound type system won't help know all available properties
when dealing in interfaces, so while technically the difference is "only"
in degree, it's still a massive difference.

Yes, differences of degree matter. Agreed.

Post by Brendan Eich
I fear I've stumbled into the "tastes great! less filling!" section
of this list. Backing out slowly...

I just have a problem with drawing an equivalence, or even near
equivalence, in static analyzability between languages like JavaScript and
languages like Dart. It borders on dishonesty.

Sorry to Daniel, I misattributed "borders on dishonesty" to him.
It's ok to say that JavaScript is much more dynamic, and more

Post by 'Justin Fagnani' via Dart Misc
malleable, with one tradeoff being that it's harder to analyze.

"harder" == "difference of degree". It seems we agree.
JS with junk like `with` is hard to impossible to analyze, period. No
question. Dart's a lot easier!

Post by Brendan Eich
"guess".

I never said it did (I mentioned Closure and Tern which go to great
lengths to do analysis and inference). Their capabilities simply pale in
comparison even to the Dart analyzer, to such a degree that the comparison
is silly.
In personal experience, I write JavaScript full time now, and the pain
is very real. I've used almost every JS analyzer out there. They all suck
(and it's not their fault). It's not just auto-complete - knowing that the
code you wrote has a reasonable chance of running requires... running it. I
have to write a lot more mind-numbingly boring tests now to protect against
things that should be caught by tools. I'll probably start using Closure
compiler soon. I was trying to stay with as plain JS as possible, but
that's just a path to more bugs. I hope SoundScript and strong mode work
out, they seem to be the only hope for mainstream JS programmers.

Post by Brendan Eich
/be
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

'Justin Fagnani' via Dart Misc

2015-06-25 17:13:53 UTC

I joined the Polymer team which tries to stick to very plain JS (no

required build steps, no module systems, etc.) for many reasons.

Plain JS as in ES5? This makes your comments above more understandable.

Actually, in my corner of the world I get to use a lot of ES6 (I get
totarget io.js and Chrome Canary atm). Growing the language as strict
supersets does not make it more analyzable.

But there has been a big shift to Babel/ES6/TS/Flow. Basically there is
now enough tooling/analysis available via a mainstream route. This wasn't
true when Dart kicked off but it's true now.

Nom not in general, maybe a little in practice. Closure compiler has been
around a long time doing the herculean work of trying to force JS into
analyzable patterns, it's not a new thing. ES6 doesn't help much either. I
mentioned several ES6 features that will throw any static analyzer for a
loop up thread. Classes in particular don't prevent you from imperatively
changing the shape of prototypes or instances, or the prototype chain.

It's unlikely Dart will pick up any new users given the announcement that
the DartVM is not going into Chrome.

That's provably false inside Google. Probably outside too.

And wasm is the icing on the cake.

WASM really doesn't have the effect on Dart that you think it does. It
really doesn't change anything at all yet. Asm.js is a JS encoding of a
bytecode. WASM is a binary encoding of that. The only way to get any
language to run on that is to either 1) not have a runtime, or 2) compile
the runtime to WASM. Python, Ruby, Dart, Java, C#, and on and on are not
going to magically become viable in WASM when they weren't in asm.js. The
to-JS compilers that are available for those languages will continue to
target normal JS, as that's the only reasonable solution.

Those compilers all take advantage of (and then work around to varying
degrees) the JavaScript object model, and they use much, much more of
JavaScript than the asm.js subset. WASM isn't the big breakthrough that's
needed, IMO.

To be a better compilation target JS needs things like: value types;
Proxies; more optimizations of getters, setters, bound functions, exception
handling, Symbol-based property access; much faster postMessage and
lighter-weight workers; something like strong mode: a way for a code to opt
out of implicit type conversions, boolean coercion, Arrays with holes,
shape-changing objects, and all the other things that make JS hard to
optimize. Then a compiler can generate an easy to optimize subset of JS,
that's still interoperable with the DOM and all the other JS in the wild.

The V8 engine will have ES6+/Strong mode/SoundScript + wasm. I'm sure the

V8 team are thinking about how to leverage wasm in a SoundScript context
with a decent evolutionary path in 1VM.

I don't think these things fit together like you imagine. asm.js already
doesn't support the things that strong mode limits. SoundScript is
concerned with optional typing of objects, asm.js only has numbers, arrays
and functions.

Every project has their own priorities and makes their own decisions.
This is eventually going to hurt Google. Too many languages and runtimes.
Dev's need platforms/ecosystems. Fletch and Sky are interesting - but will
these experiments turn into products that dev's can rely on.
K.

Post by Gen
Quote: "In personal experience, I write JavaScript full time now, and
the pain is very real."
What could possibly be the reason for writing JavaScript if you do not
like it ?
Seriously.
There is Typescript.
And you work even for Google, the company that tries promote Dart as
alternative.

Not every project at Google uses Dart. Or GWT, TypeScript, Closure... or
plain JavaScript even.
Every project has their own priorities and makes their own decisions. I
joined the Polymer team which tries to stick to very plain JS (no required
build steps, no module systems, etc.) for many reasons. That was my
calculated tradeoff when I joined them, but it doesn't make it less painful
:)

Post by Brendan Eich
On Tue, Jun 23, 2015 at 9:43 AM, 'Justin Fagnani' via Dart Misc <

Post by Brendan Eich
On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc <

On Mon, Jun 22, 2015 at 10:41 AM, Daniel Joyce <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and many
other such products.

And Dart's unsound type system differs only in degree, not kind.
Useful warning systems are useful.

And even a sound type system won't help know all available properties
when dealing in interfaces, so while technically the difference is "only"
in degree, it's still a massive difference.

Yes, differences of degree matter. Agreed.

Post by Brendan Eich
I fear I've stumbled into the "tastes great! less filling!" section
of this list. Backing out slowly...

I just have a problem with drawing an equivalence, or even near
equivalence, in static analyzability between languages like JavaScript and
languages like Dart. It borders on dishonesty.

Sorry to Daniel, I misattributed "borders on dishonesty" to him.
It's ok to say that JavaScript is much more dynamic, and more

Post by 'Justin Fagnani' via Dart Misc
malleable, with one tradeoff being that it's harder to analyze.

"harder" == "difference of degree". It seems we agree.
JS with junk like `with` is hard to impossible to analyze, period. No
question. Dart's a lot easier!

Post by Brendan Eich
"guess".

I never said it did (I mentioned Closure and Tern which go to great
lengths to do analysis and inference). Their capabilities simply pale in
comparison even to the Dart analyzer, to such a degree that the comparison
is silly.
In personal experience, I write JavaScript full time now, and the pain
is very real. I've used almost every JS analyzer out there. They all suck
(and it's not their fault). It's not just auto-complete - knowing that the
code you wrote has a reasonable chance of running requires... running it. I
have to write a lot more mind-numbingly boring tests now to protect against
things that should be caught by tools. I'll probably start using Closure
compiler soon. I was trying to stay with as plain JS as possible, but
that's just a path to more bugs. I hope SoundScript and strong mode work
out, they seem to be the only hope for mainstream JS programmers.

Post by Brendan Eich
/be
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

2015-06-25 18:10:50 UTC

I joined the Polymer team which tries to stick to very plain JS (no

required build steps, no module systems, etc.) for many reasons.

Plain JS as in ES5? This makes your comments above more understandable.

Actually, in my corner of the world I get to use a lot of ES6 (I get
totarget io.js and Chrome Canary atm). Growing the language as strict
supersets does not make it more analyzable.

Not supersets. The sane emerging subset is analyzable. Maybe not so much as
Dart - but it is.

But there has been a big shift to Babel/ES6/TS/Flow. Basically there is
now enough tooling/analysis available via a mainstream route. This wasn't
true when Dart kicked off but it's true now.

Stay within the sane subset. Don't imperatively muck around with prototypes.

It's unlikely Dart will pick up any new users given the announcement that
the DartVM is not going into Chrome.

That's provably false inside Google. Probably outside too.

Outside Google - unlikely. A couple of wins - sure - mass take up -
unlikely.

And wasm is the icing on the cake.

'yet' is right. wasm is icing on the cake in terms of developer mind-share.
It shows collaboration.

Post by 'Justin Fagnani' via Dart Misc
Those compilers all take advantage of (and then work around to varying
degrees) the JavaScript object model, and they use much, much more of
JavaScript than the asm.js subset. WASM isn't the big breakthrough that's
needed, IMO.

Initially ES modules will be able to call WASM modules for
computational/graphics work without paying the JS dynlang tax. That's
enough to start with. As I commented when asm.js first was announced:

"The point of asm.js is that it's there if the developer feels they need
it. The lower level part of an app - which may need to be closer to the
metal - can use this subset. And then expose an API to the higher level
more dynamic parts of the app."

Post by 'Justin Fagnani' via Dart Misc
To be a better compilation target JS needs things like: value types;
Proxies; more optimizations of getters, setters, bound functions, exception
handling, Symbol-based property access; much faster postMessage and
lighter-weight workers; something like strong mode: a way for a code to opt
out of implicit type conversions, boolean coercion, Arrays with holes,
shape-changing objects, and all the other things that make JS hard to
optimize. Then a compiler can generate an easy to optimize subset of JS,
that's still interoperable with the DOM and all the other JS in the wild.
The V8 engine will have ES6+/Strong mode/SoundScript + wasm. I'm sure the

V8 team are thinking about how to leverage wasm in a SoundScript context
with a decent evolutionary path in 1VM.

I said *evolutionary* path. I think these things will come together
eventually pretty well.

Is Dart's future dart2js. Or does the VM have an independent future - and
are Google going to back it long-term. Especially on the client - where
Fletch looks interesting.

ES6/TS/WASM have done enough to undermine Dart's story. Is there a response.

K.

Post by Gen
Quote: "In personal experience, I write JavaScript full time now, and
the pain is very real."
What could possibly be the reason for writing JavaScript if you do not
like it ?
Seriously.
There is Typescript.
And you work even for Google, the company that tries promote Dart as
alternative.

Not every project at Google uses Dart. Or GWT, TypeScript, Closure... or
plain JavaScript even.
Every project has their own priorities and makes their own decisions. I
joined the Polymer team which tries to stick to very plain JS (no required
build steps, no module systems, etc.) for many reasons. That was my
calculated tradeoff when I joined them, but it doesn't make it less painful
:)

Post by Brendan Eich
On Tue, Jun 23, 2015 at 9:43 AM, 'Justin Fagnani' via Dart Misc <

Post by Brendan Eich
On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc <

On Mon, Jun 22, 2015 at 10:47 AM, Brendan Eich <

On Mon, Jun 22, 2015 at 10:41 AM, Daniel Joyce <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and many
other such products.

And Dart's unsound type system differs only in degree, not kind.
Useful warning systems are useful.

And even a sound type system won't help know all available
properties when dealing in interfaces, so while technically the difference
is "only" in degree, it's still a massive difference.

Yes, differences of degree matter. Agreed.

Post by Brendan Eich
I fear I've stumbled into the "tastes great! less filling!" section
of this list. Backing out slowly...

I just have a problem with drawing an equivalence, or even near
equivalence, in static analyzability between languages like JavaScript and
languages like Dart. It borders on dishonesty.

Sorry to Daniel, I misattributed "borders on dishonesty" to him.
It's ok to say that JavaScript is much more dynamic, and more

Post by 'Justin Fagnani' via Dart Misc
malleable, with one tradeoff being that it's harder to analyze.

"harder" == "difference of degree". It seems we agree.
JS with junk like `with` is hard to impossible to analyze, period. No
question. Dart's a lot easier!

Post by Brendan Eich
"guess".

I never said it did (I mentioned Closure and Tern which go to great
lengths to do analysis and inference). Their capabilities simply pale in
comparison even to the Dart analyzer, to such a degree that the comparison
is silly.
In personal experience, I write JavaScript full time now, and the pain
is very real. I've used almost every JS analyzer out there. They all suck
(and it's not their fault). It's not just auto-complete - knowing that the
code you wrote has a reasonable chance of running requires... running it. I
have to write a lot more mind-numbingly boring tests now to protect against
things that should be caught by tools. I'll probably start using Closure
compiler soon. I was trying to stay with as plain JS as possible, but
that's just a path to more bugs. I hope SoundScript and strong mode work
out, they seem to be the only hope for mainstream JS programmers.

Post by Brendan Eich
/be
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it,

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

Don Olmstead

2015-06-25 18:20:56 UTC

"ES6/TS/WASM have done enough to undermine Dart's story. Is there a
response."

What are you a tabloid reporter @kc?

WASM isn't at a point where you can use a GCed language. Its probably not
going to happen for awhile. Until then we're stuck in a compile to JS world
not a byte-code world. How many times does this need to be reiterated.

I joined the Polymer team which tries to stick to very plain JS (no

required build steps, no module systems, etc.) for many reasons.

Plain JS as in ES5? This makes your comments above more understandable.

Actually, in my corner of the world I get to use a lot of ES6 (I get
totarget io.js and Chrome Canary atm). Growing the language as strict
supersets does not make it more analyzable.

Not supersets. The sane emerging subset is analyzable. Maybe not so much
as Dart - but it is.

But there has been a big shift to Babel/ES6/TS/Flow. Basically there is
now enough tooling/analysis available via a mainstream route. This wasn't
true when Dart kicked off but it's true now.

Stay within the sane subset. Don't imperatively muck around with prototypes.

It's unlikely Dart will pick up any new users given the announcement
that the DartVM is not going into Chrome.

That's provably false inside Google. Probably outside too.

Outside Google - unlikely. A couple of wins - sure - mass take up -
unlikely.

And wasm is the icing on the cake.

'yet' is right. wasm is icing on the cake in terms of developer
mind-share. It shows collaboration.

Initially ES modules will be able to call WASM modules for
computational/graphics work without paying the JS dynlang tax. That's
"The point of asm.js is that it's there if the developer feels they need
it. The lower level part of an app - which may need to be closer to the
metal - can use this subset. And then expose an API to the higher level
more dynamic parts of the app."

V8 team are thinking about how to leverage wasm in a SoundScript context
with a decent evolutionary path in 1VM.

I said *evolutionary* path. I think these things will come together
eventually pretty well.

Every project has their own priorities and makes their own decisions.
This is eventually going to hurt Google. Too many languages and
runtimes. Dev's need platforms/ecosystems. Fletch and Sky are interesting -
but will these experiments turn into products that dev's can rely on.

Is Dart's future dart2js. Or does the VM have an independent future - and
are Google going to back it long-term. Especially on the client - where
Fletch looks interesting.
ES6/TS/WASM have done enough to undermine Dart's story. Is there a response.
K.

Post by Gen
Quote: "In personal experience, I write JavaScript full time now, and
the pain is very real."
What could possibly be the reason for writing JavaScript if you do not
like it ?
Seriously.
There is Typescript.
And you work even for Google, the company that tries promote Dart as
alternative.

Not every project at Google uses Dart. Or GWT, TypeScript, Closure...
or plain JavaScript even.
Every project has their own priorities and makes their own decisions. I
joined the Polymer team which tries to stick to very plain JS (no required
build steps, no module systems, etc.) for many reasons. That was my
calculated tradeoff when I joined them, but it doesn't make it less painful
:)

Post by Brendan Eich
On Tue, Jun 23, 2015 at 9:43 AM, 'Justin Fagnani' via Dart Misc <

Post by Brendan Eich
On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc <

On Mon, Jun 22, 2015 at 10:47 AM, Brendan Eich <

On Mon, Jun 22, 2015 at 10:41 AM, Daniel Joyce <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and many
other such products.

And Dart's unsound type system differs only in degree, not kind.
Useful warning systems are useful.

And even a sound type system won't help know all available
properties when dealing in interfaces, so while technically the difference
is "only" in degree, it's still a massive difference.

Yes, differences of degree matter. Agreed.

Post by Brendan Eich
I fear I've stumbled into the "tastes great! less filling!"
section of this list. Backing out slowly...

I just have a problem with drawing an equivalence, or even near
equivalence, in static analyzability between languages like JavaScript and
languages like Dart. It borders on dishonesty.

Sorry to Daniel, I misattributed "borders on dishonesty" to him.
It's ok to say that JavaScript is much more dynamic, and more

Post by 'Justin Fagnani' via Dart Misc
malleable, with one tradeoff being that it's harder to analyze.

"harder" == "difference of degree". It seems we agree.
JS with junk like `with` is hard to impossible to analyze, period.
No question. Dart's a lot easier!

Post by Brendan Eich
"guess".

I never said it did (I mentioned Closure and Tern which go to great
lengths to do analysis and inference). Their capabilities simply pale in
comparison even to the Dart analyzer, to such a degree that the comparison
is silly.
In personal experience, I write JavaScript full time now, and the
pain is very real. I've used almost every JS analyzer out there. They all
suck (and it's not their fault). It's not just auto-complete - knowing that
the code you wrote has a reasonable chance of running requires... running
it. I have to write a lot more mind-numbingly boring tests now to protect
against things that should be caught by tools. I'll probably start using
Closure compiler soon. I was trying to stay with as plain JS as possible,
but that's just a path to more bugs. I hope SoundScript and strong mode
work out, they seem to be the only hope for mainstream JS programmers.

Post by Brendan Eich
/be
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it,

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

2015-06-26 00:19:30 UTC

Post by Don Olmstead
"ES6/TS/WASM have done enough to undermine Dart's story. Is there a
response."

Lol. Not a fanboy.

Post by Don Olmstead
WASM isn't at a point where you can use a GCed language. Its probably not
going to happen for awhile. Until then we're stuck in a compile to JS world
not a byte-code world. How many times does this need to be reiterated.

No need to reiterate anything. It's the collaboration, roadmap and
potential that looks promising for higher level langs. Not the MVP.

But initially ES6 will have easy interop with WASM (to call performant
low-level code) as WASM is packaged as ES6 modules. How about Dart? It's
struggling with JS interop as it is.

So a response would be useful (at some point).

But yeah - I'll leave you Dartisans waiting for your dev_compiler paddle
and check in 6 months if there's life in Fletch (and Sky). Or if CDE'ed.

K.

I joined the Polymer team which tries to stick to very plain JS (no

required build steps, no module systems, etc.) for many reasons.

Plain JS as in ES5? This makes your comments above more understandable.

Actually, in my corner of the world I get to use a lot of ES6 (I get
totarget io.js and Chrome Canary atm). Growing the language as strict
supersets does not make it more analyzable.

Not supersets. The sane emerging subset is analyzable. Maybe not so much
as Dart - but it is.

But there has been a big shift to Babel/ES6/TS/Flow. Basically there is
now enough tooling/analysis available via a mainstream route. This wasn't
true when Dart kicked off but it's true now.

Nom not in general, maybe a little in practice. Closure compiler has
been around a long time doing the herculean work of trying to force JS into
analyzable patterns, it's not a new thing. ES6 doesn't help much either. I
mentioned several ES6 features that will throw any static analyzer for a
loop up thread. Classes in particular don't prevent you from imperatively
changing the shape of prototypes or instances, or the prototype chain.

Stay within the sane subset. Don't imperatively muck around with prototypes.

It's unlikely Dart will pick up any new users given the announcement
that the DartVM is not going into Chrome.

That's provably false inside Google. Probably outside too.

Outside Google - unlikely. A couple of wins - sure - mass take up -
unlikely.

And wasm is the icing on the cake.

'yet' is right. wasm is icing on the cake in terms of developer
mind-share. It shows collaboration.

the V8 team are thinking about how to leverage wasm in a SoundScript
context with a decent evolutionary path in 1VM.

I said *evolutionary* path. I think these things will come together
eventually pretty well.

Every project has their own priorities and makes their own decisions.
This is eventually going to hurt Google. Too many languages and
runtimes. Dev's need platforms/ecosystems. Fletch and Sky are interesting -
but will these experiments turn into products that dev's can rely on.

Is Dart's future dart2js. Or does the VM have an independent future - and
are Google going to back it long-term. Especially on the client - where
Fletch looks interesting.
ES6/TS/WASM have done enough to undermine Dart's story. Is there a response.
K.

Post by Gen
Quote: "In personal experience, I write JavaScript full time now, and
the pain is very real."
What could possibly be the reason for writing JavaScript if you do
not like it ?
Seriously.
There is Typescript.
And you work even for Google, the company that tries promote Dart as
alternative.

Not every project at Google uses Dart. Or GWT, TypeScript, Closure...
or plain JavaScript even.
Every project has their own priorities and makes their own decisions.
I joined the Polymer team which tries to stick to very plain JS (no
required build steps, no module systems, etc.) for many reasons. That was
my calculated tradeoff when I joined them, but it doesn't make it less
painful :)

Post by Brendan Eich
On Tue, Jun 23, 2015 at 9:43 AM, 'Justin Fagnani' via Dart Misc <

Post by Brendan Eich
On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc <

On Mon, Jun 22, 2015 at 10:47 AM, Brendan Eich <

On Mon, Jun 22, 2015 at 10:41 AM, Daniel Joyce <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and
many other such products.

And Dart's unsound type system differs only in degree, not kind.
Useful warning systems are useful.

And even a sound type system won't help know all available
properties when dealing in interfaces, so while technically the difference
is "only" in degree, it's still a massive difference.

Yes, differences of degree matter. Agreed.

Post by Brendan Eich
I fear I've stumbled into the "tastes great! less filling!"
section of this list. Backing out slowly...

I just have a problem with drawing an equivalence, or even near
equivalence, in static analyzability between languages like JavaScript and
languages like Dart. It borders on dishonesty.

Sorry to Daniel, I misattributed "borders on dishonesty" to him.
It's ok to say that JavaScript is much more dynamic, and more

Post by 'Justin Fagnani' via Dart Misc
malleable, with one tradeoff being that it's harder to analyze.

"harder" == "difference of degree". It seems we agree.
JS with junk like `with` is hard to impossible to analyze, period.
No question. Dart's a lot easier!

Post by Brendan Eich
not "guess".

I never said it did (I mentioned Closure and Tern which go to great
lengths to do analysis and inference). Their capabilities simply pale in
comparison even to the Dart analyzer, to such a degree that the comparison
is silly.
In personal experience, I write JavaScript full time now, and the
pain is very real. I've used almost every JS analyzer out there. They all
suck (and it's not their fault). It's not just auto-complete - knowing that
the code you wrote has a reasonable chance of running requires... running
it. I have to write a lot more mind-numbingly boring tests now to protect
against things that should be caught by tools. I'll probably start using
Closure compiler soon. I was trying to stay with as plain JS as possible,
but that's just a path to more bugs. I hope SoundScript and strong mode
work out, they seem to be the only hope for mainstream JS programmers.

Post by Brendan Eich
/be
--
For other discussions, see
https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it,

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it,

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

Don Olmstead

2015-06-26 00:34:11 UTC

Its not about being a fanboy. You're basically asking is there a response
for this hypothetical thing that may or may not exist in the future.

Dart team I need to know what the latest evidence of Bigfoot means for Dart
on the web! Why aren't you answering me???????????

Post by Don Olmstead
"ES6/TS/WASM have done enough to undermine Dart's story. Is there a
response."

Lol. Not a fanboy.

No need to reiterate anything. It's the collaboration, roadmap and
potential that looks promising for higher level langs. Not the MVP.
But initially ES6 will have easy interop with WASM (to call performant
low-level code) as WASM is packaged as ES6 modules. How about Dart? It's
struggling with JS interop as it is.
So a response would be useful (at some point).
But yeah - I'll leave you Dartisans waiting for your dev_compiler paddle
and check in 6 months if there's life in Fletch (and Sky). Or if CDE'ed.
K.

I joined the Polymer team which tries to stick to very plain JS (no

required build steps, no module systems, etc.) for many reasons.

Plain JS as in ES5? This makes your comments above more understandable.

Actually, in my corner of the world I get to use a lot of ES6 (I get
totarget io.js and Chrome Canary atm). Growing the language as strict
supersets does not make it more analyzable.

Not supersets. The sane emerging subset is analyzable. Maybe not so much
as Dart - but it is.

But there has been a big shift to Babel/ES6/TS/Flow. Basically there
is now enough tooling/analysis available via a mainstream route. This
wasn't true when Dart kicked off but it's true now.

Nom not in general, maybe a little in practice. Closure compiler has
been around a long time doing the herculean work of trying to force JS into
analyzable patterns, it's not a new thing. ES6 doesn't help much either. I
mentioned several ES6 features that will throw any static analyzer for a
loop up thread. Classes in particular don't prevent you from imperatively
changing the shape of prototypes or instances, or the prototype chain.

Stay within the sane subset. Don't imperatively muck around with prototypes.

It's unlikely Dart will pick up any new users given the announcement
that the DartVM is not going into Chrome.

That's provably false inside Google. Probably outside too.

Outside Google - unlikely. A couple of wins - sure - mass take up -
unlikely.

And wasm is the icing on the cake.

'yet' is right. wasm is icing on the cake in terms of developer
mind-share. It shows collaboration.

the V8 team are thinking about how to leverage wasm in a SoundScript
context with a decent evolutionary path in 1VM.

I don't think these things fit together like you imagine. asm.js
already doesn't support the things that strong mode limits. SoundScript is
concerned with optional typing of objects, asm.js only has numbers, arrays
and functions.

I said *evolutionary* path. I think these things will come together
eventually pretty well.

Every project has their own priorities and makes their own decisions.
This is eventually going to hurt Google. Too many languages and
runtimes. Dev's need platforms/ecosystems. Fletch and Sky are interesting -
but will these experiments turn into products that dev's can rely on.

Is Dart's future dart2js. Or does the VM have an independent future -
and are Google going to back it long-term. Especially on the client - where
Fletch looks interesting.
ES6/TS/WASM have done enough to undermine Dart's story. Is there a response.
K.

Post by Gen
Quote: "In personal experience, I write JavaScript full time now,
and the pain is very real."
What could possibly be the reason for writing JavaScript if you do
not like it ?
Seriously.
There is Typescript.
And you work even for Google, the company that tries promote Dart as
alternative.

Not every project at Google uses Dart. Or GWT, TypeScript, Closure...
or plain JavaScript even.
Every project has their own priorities and makes their own decisions.
I joined the Polymer team which tries to stick to very plain JS (no
required build steps, no module systems, etc.) for many reasons. That was
my calculated tradeoff when I joined them, but it doesn't make it less
painful :)

Post by Brendan Eich
On Tue, Jun 23, 2015 at 9:43 AM, 'Justin Fagnani' via Dart Misc <

On Mon, Jun 22, 2015 at 4:37 PM, Brendan Eich <

Post by Brendan Eich
On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc

On Mon, Jun 22, 2015 at 10:47 AM, Brendan Eich <

On Mon, Jun 22, 2015 at 10:41 AM, Daniel Joyce <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and
many other such products.

And Dart's unsound type system differs only in degree, not kind.
Useful warning systems are useful.

And even a sound type system won't help know all available
properties when dealing in interfaces, so while technically the difference
is "only" in degree, it's still a massive difference.

Yes, differences of degree matter. Agreed.

Post by Brendan Eich
I fear I've stumbled into the "tastes great! less filling!"
section of this list. Backing out slowly...

I just have a problem with drawing an equivalence, or even near
equivalence, in static analyzability between languages like JavaScript and
languages like Dart. It borders on dishonesty.

Sorry to Daniel, I misattributed "borders on dishonesty" to him.
It's ok to say that JavaScript is much more dynamic, and more

malleable, with one tradeoff being that it's harder to analyze.

"harder" == "difference of degree". It seems we agree.
JS with junk like `with` is hard to impossible to analyze, period.
No question. Dart's a lot easier!

Post by Brendan Eich
not "guess".

I never said it did (I mentioned Closure and Tern which go to great
lengths to do analysis and inference). Their capabilities simply pale in
comparison even to the Dart analyzer, to such a degree that the comparison
is silly.
In personal experience, I write JavaScript full time now, and the
pain is very real. I've used almost every JS analyzer out there. They all
suck (and it's not their fault). It's not just auto-complete - knowing that
the code you wrote has a reasonable chance of running requires... running
it. I have to write a lot more mind-numbingly boring tests now to protect
against things that should be caught by tools. I'll probably start using
Closure compiler soon. I was trying to stay with as plain JS as possible,
but that's just a path to more bugs. I hope SoundScript and strong mode
work out, they seem to be the only hope for mainstream JS programmers.

Post by Brendan Eich
/be
--
For other discussions, see
https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it,

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it,

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

Filipe Morgado

2015-06-26 02:57:05 UTC

I'm with KC on this one.

When there's a new JS feature, everybody jump on it. A lot of people
mention ES7 as a reason not to use Dart, while ES6 has not even properly
rolled everywhere. Now comes a new standardized way to run code (in or off
the browser) which runs in the same VM as JS, and everyone is skeptical?
There's so much to win here.

Wasm if currently just a binary asm.js, but it will get to the point where
it can relate to JVM or CLR.
Everyone is affirmative. The resources are allocated.

There's a lot of pressure behind the project. The asm.js guys are on it,
Mozilla needs it to make Firefox OS run decently. The NaCl (and V8) guys
are on it, so there's a lot of interest from Google as well. Microsoft
needs a standard app format because very few people target Windows on
mobile. Unity has shown strong interest, and a lot of game developers are
wetting their pants (and app developers as well since there will finally be
a unified target).

Even if it takes 5 years to come to a point where it's usable (I would bet
3), it's not much in a language lifetime.
A heads-up from Dart would be nice, and any future collaboration with wasm
would strengthen both.
Sky would benefit a lot. A smooth transition from DartVM to Dart-on-wasm
would bring a lot more languages.

JS-interop has problems, Sky introduces an API that's not portable and
Fletch may come with a completely different mindset.
I would say Dart's motto to embrace the web and not break it is not true
anymore.

Post by Don Olmstead
Its not about being a fanboy. You're basically asking is there a response
for this hypothetical thing that may or may not exist in the future.
Dart team I need to know what the latest evidence of Bigfoot means for
Dart on the web! Why aren't you answering me???????????

Post by Don Olmstead
"ES6/TS/WASM have done enough to undermine Dart's story. Is there a
response."

Lol. Not a fanboy.

Post by Don Olmstead
WASM isn't at a point where you can use a GCed language. Its probably
not going to happen for awhile. Until then we're stuck in a compile to JS
world not a byte-code world. How many times does this need to be reiterated.

No need to reiterate anything. It's the collaboration, roadmap and
potential that looks promising for higher level langs. Not the MVP.
But initially ES6 will have easy interop with WASM (to call performant
low-level code) as WASM is packaged as ES6 modules. How about Dart? It's
struggling with JS interop as it is.
So a response would be useful (at some point).
But yeah - I'll leave you Dartisans waiting for your dev_compiler paddle
and check in 6 months if there's life in Fletch (and Sky). Or if CDE'ed.
K.

I joined the Polymer team which tries to stick to very plain JS (no

required build steps, no module systems, etc.) for many reasons.

Plain JS as in ES5? This makes your comments above more
understandable.

Actually, in my corner of the world I get to use a lot of ES6 (I get
totarget io.js and Chrome Canary atm). Growing the language as strict
supersets does not make it more analyzable.

Not supersets. The sane emerging subset is analyzable. Maybe not so
much as Dart - but it is.

But there has been a big shift to Babel/ES6/TS/Flow. Basically there
is now enough tooling/analysis available via a mainstream route. This
wasn't true when Dart kicked off but it's true now.

Nom not in general, maybe a little in practice. Closure compiler has
been around a long time doing the herculean work of trying to force JS into
analyzable patterns, it's not a new thing. ES6 doesn't help much either. I
mentioned several ES6 features that will throw any static analyzer for a
loop up thread. Classes in particular don't prevent you from imperatively
changing the shape of prototypes or instances, or the prototype chain.

Stay within the sane subset. Don't imperatively muck around with prototypes.

It's unlikely Dart will pick up any new users given the announcement
that the DartVM is not going into Chrome.

That's provably false inside Google. Probably outside too.

Outside Google - unlikely. A couple of wins - sure - mass take up -
unlikely.

And wasm is the icing on the cake.

'yet' is right. wasm is icing on the cake in terms of developer
mind-share. It shows collaboration.

Initially ES modules will be able to call WASM modules for
computational/graphics work without paying the JS dynlang tax. That's
"The point of asm.js is that it's there if the developer feels they
need it. The lower level part of an app - which may need to be closer to
the metal - can use this subset. And then expose an API to the higher level
more dynamic parts of the app."

the V8 team are thinking about how to leverage wasm in a SoundScript
context with a decent evolutionary path in 1VM.

I don't think these things fit together like you imagine. asm.js
already doesn't support the things that strong mode limits. SoundScript is
concerned with optional typing of objects, asm.js only has numbers, arrays
and functions.

I said *evolutionary* path. I think these things will come together
eventually pretty well.

Every project has their own priorities and makes their own decisions.
This is eventually going to hurt Google. Too many languages and
runtimes. Dev's need platforms/ecosystems. Fletch and Sky are interesting -
but will these experiments turn into products that dev's can rely on.

Is Dart's future dart2js. Or does the VM have an independent future -
and are Google going to back it long-term. Especially on the client - where
Fletch looks interesting.
ES6/TS/WASM have done enough to undermine Dart's story. Is there a response.
K.

Post by Gen
Quote: "In personal experience, I write JavaScript full time now,
and the pain is very real."
What could possibly be the reason for writing JavaScript if you do
not like it ?
Seriously.
There is Typescript.
And you work even for Google, the company that tries promote Dart
as alternative.

Not every project at Google uses Dart. Or GWT, TypeScript,
Closure... or plain JavaScript even.
Every project has their own priorities and makes their own
decisions. I joined the Polymer team which tries to stick to very plain JS
(no required build steps, no module systems, etc.) for many reasons. That
was my calculated tradeoff when I joined them, but it doesn't make it less
painful :)

On Tue, Jun 23, 2015 at 12:50 PM, Brendan Eich <

Post by Brendan Eich
On Tue, Jun 23, 2015 at 9:43 AM, 'Justin Fagnani' via Dart Misc <

On Mon, Jun 22, 2015 at 4:37 PM, Brendan Eich <

Post by Brendan Eich
On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc

On Mon, Jun 22, 2015 at 10:47 AM, Brendan Eich <

On Mon, Jun 22, 2015 at 10:41 AM, Daniel Joyce <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and
many other such products.

And Dart's unsound type system differs only in degree, not
kind. Useful warning systems are useful.

And even a sound type system won't help know all available
properties when dealing in interfaces, so while technically the difference
is "only" in degree, it's still a massive difference.

Yes, differences of degree matter. Agreed.

Post by Brendan Eich
I fear I've stumbled into the "tastes great! less filling!"
section of this list. Backing out slowly...

I just have a problem with drawing an equivalence, or even near
equivalence, in static analyzability between languages like JavaScript and
languages like Dart. It borders on dishonesty.

Sorry to Daniel, I misattributed "borders on dishonesty" to him.
It's ok to say that JavaScript is much more dynamic, and more

malleable, with one tradeoff being that it's harder to analyze.

"harder" == "difference of degree". It seems we agree.
JS with junk like `with` is hard to impossible to analyze,
period. No question. Dart's a lot easier!

Post by Brendan Eich
not "guess".

I never said it did (I mentioned Closure and Tern which go to
great lengths to do analysis and inference). Their capabilities simply pale
in comparison even to the Dart analyzer, to such a degree that the
comparison is silly.
In personal experience, I write JavaScript full time now, and the
pain is very real. I've used almost every JS analyzer out there. They all
suck (and it's not their fault). It's not just auto-complete - knowing that
the code you wrote has a reasonable chance of running requires... running
it. I have to write a lot more mind-numbingly boring tests now to protect
against things that should be caught by tools. I'll probably start using
Closure compiler soon. I was trying to stay with as plain JS as possible,
but that's just a path to more bugs. I hope SoundScript and strong mode
work out, they seem to be the only hope for mainstream JS programmers.

Post by Brendan Eich
/be
--
For other discussions, see
https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it,

For other discussions, see
https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it,

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it,

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

Don Olmstead

2015-06-26 03:34:55 UTC

Look I certainly agree with the sentiment. The idea of a world without
JavaScript is what drew me to Dart. I do think that wasm is a great idea. I
can see why it would be exciting.

This thread has had technical explanations on what web assembly is. It's
currently only managed languages. In the future they plan on adding gc and
access to the DOM. When this future is going to happen? No timeline though
I would certainly peg it at around 2020 at the earliest because it's a
group effort and because of the huge technological hurdles. This is why we
live in a compile to JS world. In this potential post JS world a VM would
need to target wasm. That would mean a dart VM would just target that as
its output. There's the tl;dr of this thread.

What other info do you need to make you happy?

Post by Filipe Morgado
I'm with KC on this one.
When there's a new JS feature, everybody jump on it. A lot of people
mention ES7 as a reason not to use Dart, while ES6 has not even properly
rolled everywhere. Now comes a new standardized way to run code (in or off
the browser) which runs in the same VM as JS, and everyone is skeptical?
There's so much to win here.
Wasm if currently just a binary asm.js, but it will get to the point where
it can relate to JVM or CLR.
Everyone is affirmative. The resources are allocated.
There's a lot of pressure behind the project. The asm.js guys are on it,
Mozilla needs it to make Firefox OS run decently. The NaCl (and V8) guys
are on it, so there's a lot of interest from Google as well. Microsoft
needs a standard app format because very few people target Windows on
mobile. Unity has shown strong interest, and a lot of game developers are
wetting their pants (and app developers as well since there will finally be
a unified target).
Even if it takes 5 years to come to a point where it's usable (I would bet
3), it's not much in a language lifetime.
A heads-up from Dart would be nice, and any future collaboration with wasm
would strengthen both.
Sky would benefit a lot. A smooth transition from DartVM to Dart-on-wasm
would bring a lot more languages.
JS-interop has problems, Sky introduces an API that's not portable and
Fletch may come with a completely different mindset.
I would say Dart's motto to embrace the web and not break it is not true
anymore.

Post by Don Olmstead
"ES6/TS/WASM have done enough to undermine Dart's story. Is there a
response."

Lol. Not a fanboy.

Post by Don Olmstead
WASM isn't at a point where you can use a GCed language. Its probably
not going to happen for awhile. Until then we're stuck in a compile to JS
world not a byte-code world. How many times does this need to be reiterated.

No need to reiterate anything. It's the collaboration, roadmap and
potential that looks promising for higher level langs. Not the MVP.
But initially ES6 will have easy interop with WASM (to call performant
low-level code) as WASM is packaged as ES6 modules. How about Dart? It's
struggling with JS interop as it is.
So a response would be useful (at some point).
But yeah - I'll leave you Dartisans waiting for your dev_compiler paddle
and check in 6 months if there's life in Fletch (and Sky). Or if CDE'ed.
K.

I joined the Polymer team which tries to stick to very plain JS (no

required build steps, no module systems, etc.) for many reasons.

Plain JS as in ES5? This makes your comments above more
understandable.

Actually, in my corner of the world I get to use a lot of ES6 (I get
totarget io.js and Chrome Canary atm). Growing the language as strict
supersets does not make it more analyzable.

Not supersets. The sane emerging subset is analyzable. Maybe not so
much as Dart - but it is.

But there has been a big shift to Babel/ES6/TS/Flow. Basically there
is now enough tooling/analysis available via a mainstream route. This
wasn't true when Dart kicked off but it's true now.

Nom not in general, maybe a little in practice. Closure compiler has
been around a long time doing the herculean work of trying to force JS into
analyzable patterns, it's not a new thing. ES6 doesn't help much either. I
mentioned several ES6 features that will throw any static analyzer for a
loop up thread. Classes in particular don't prevent you from imperatively
changing the shape of prototypes or instances, or the prototype chain.

Stay within the sane subset. Don't imperatively muck around with prototypes.

It's unlikely Dart will pick up any new users given the announcement
that the DartVM is not going into Chrome.

That's provably false inside Google. Probably outside too.

Outside Google - unlikely. A couple of wins - sure - mass take up -
unlikely.

And wasm is the icing on the cake.

'yet' is right. wasm is icing on the cake in terms of developer
mind-share. It shows collaboration.

Post by 'Justin Fagnani' via Dart Misc
Those compilers all take advantage of (and then work around to
varying degrees) the JavaScript object model, and they use much, much more
of JavaScript than the asm.js subset. WASM isn't the big breakthrough
that's needed, IMO.

Initially ES modules will be able to call WASM modules for
computational/graphics work without paying the JS dynlang tax. That's
"The point of asm.js is that it's there if the developer feels they
need it. The lower level part of an app - which may need to be closer to
the metal - can use this subset. And then expose an API to the higher level
more dynamic parts of the app."

the V8 team are thinking about how to leverage wasm in a SoundScript
context with a decent evolutionary path in 1VM.

I don't think these things fit together like you imagine. asm.js
already doesn't support the things that strong mode limits. SoundScript is
concerned with optional typing of objects, asm.js only has numbers, arrays
and functions.

I said *evolutionary* path. I think these things will come together
eventually pretty well.

Every project has their own priorities and makes their own

decisions.

This is eventually going to hurt Google. Too many languages and
runtimes. Dev's need platforms/ecosystems. Fletch and Sky are interesting -
but will these experiments turn into products that dev's can rely on.

Is Dart's future dart2js. Or does the VM have an independent future -
and are Google going to back it long-term. Especially on the client - where
Fletch looks interesting.
ES6/TS/WASM have done enough to undermine Dart's story. Is there a response.
K.

Post by Gen
Quote: "In personal experience, I write JavaScript full time now,
and the pain is very real."
What could possibly be the reason for writing JavaScript if you do
not like it ?
Seriously.
There is Typescript.
And you work even for Google, the company that tries promote Dart
as alternative.

Not every project at Google uses Dart. Or GWT, TypeScript,
Closure... or plain JavaScript even.
Every project has their own priorities and makes their own
decisions. I joined the Polymer team which tries to stick to very plain JS
(no required build steps, no module systems, etc.) for many reasons. That
was my calculated tradeoff when I joined them, but it doesn't make it less
painful :)

On Tue, Jun 23, 2015 at 12:50 PM, Brendan Eich <

Post by Brendan Eich
On Tue, Jun 23, 2015 at 9:43 AM, 'Justin Fagnani' via Dart Misc

On Mon, Jun 22, 2015 at 4:37 PM, Brendan Eich <

Post by Brendan Eich
On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart

On Mon, Jun 22, 2015 at 10:47 AM, Brendan Eich <

On Mon, Jun 22, 2015 at 10:41 AM, Daniel Joyce <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and
many other such products.

And Dart's unsound type system differs only in degree, not
kind. Useful warning systems are useful.

And even a sound type system won't help know all available
properties when dealing in interfaces, so while technically the difference
is "only" in degree, it's still a massive difference.

Yes, differences of degree matter. Agreed.

Post by Brendan Eich
I fear I've stumbled into the "tastes great! less filling!"
section of this list. Backing out slowly...

I just have a problem with drawing an equivalence, or even near
equivalence, in static analyzability between languages like JavaScript and
languages like Dart. It borders on dishonesty.

Sorry to Daniel, I misattributed "borders on dishonesty" to him.
It's ok to say that JavaScript is much more dynamic, and more

malleable, with one tradeoff being that it's harder to analyze.

"harder" == "difference of degree". It seems we agree.
JS with junk like `with` is hard to impossible to analyze,
period. No question. Dart's a lot easier!

Post by Brendan Eich
not "guess".

I never said it did (I mentioned Closure and Tern which go to
great lengths to do analysis and inference). Their capabilities simply pale
in comparison even to the Dart analyzer, to such a degree that the
comparison is silly.
In personal experience, I write JavaScript full time now, and the
pain is very real. I've used almost every JS analyzer out there. They all
suck (and it's not their fault). It's not just auto-complete - knowing that
the code you wrote has a reasonable chance of running requires... running
it. I have to write a lot more mind-numbingly boring tests now to protect
against things that should be caught by tools. I'll probably start using
Closure compiler soon. I was trying to stay with as plain JS as possible,
but that's just a path to more bugs. I hope SoundScript and strong mode
work out, they seem to be the only hope for mainstream JS programmers.

Post by Brendan Eich
/be
--
For other discussions, see
https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from

For other discussions, see
https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it,

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it,

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

Gen

2015-06-26 08:56:29 UTC

The lacking support of ES6 in browsers for months is nothing but boycott of
programmers.
Javascript is dead for me.
I only use it server side with iojs (nodejs) because I do not want to
infect my Typescript code with "require()".
Besides, Dart is dead for me as well because of weird design choices which
I do not remember well anymore by now.
Dart is not even suitable or good enough for the teams within Google
itself.

If one wants direct interoperation between languages then Javascript is
still the platform to use.
Javascript offers the required calling convention, garbage collector,
object layout,...
Maybe the industry will grow WASM to another JVM or .net VM and Javascript
competitor.
Maybe Mozilla and Apple will refuse that plan and want a lighter, simpler
and more native and device specific solution.

For me, the potential of WASM is to liberate language ecosystems from the
sickening "Javascript compatible" strait jacket.
I really hope that with WASM comes along a sane and secure but not
over-engineered universal operation system API (local, cloud, internet of
things).
So that programmers are no longer limited to what is dictated too late by
the HTTP and HTML committees and implemented even later by zero or more
browser makers.
Can we have filesystem access please ? Or some real sockets ? No ? Not yet ?
Computer scientists invented and discovered all the necessary basics and
approaches back in the 1970s and even before.
The only thing that remains to be invented and implemented is a simple and
working network security mechanism; maybe some genius knows how to protect
even against government spyware/malware like Duqu.
(http://www.kaspersky.com/about/news/virus/2015/Duqu-is-back)

Post by Don Olmstead
"ES6/TS/WASM have done enough to undermine Dart's story. Is there a
response."

Lol. Not a fanboy.

Post by Don Olmstead
WASM isn't at a point where you can use a GCed language. Its probably
not going to happen for awhile. Until then we're stuck in a compile to JS
world not a byte-code world. How many times does this need to be reiterated.

No need to reiterate anything. It's the collaboration, roadmap and
potential that looks promising for higher level langs. Not the MVP.
But initially ES6 will have easy interop with WASM (to call performant
low-level code) as WASM is packaged as ES6 modules. How about Dart? It's
struggling with JS interop as it is.
So a response would be useful (at some point).
But yeah - I'll leave you Dartisans waiting for your dev_compiler paddle
and check in 6 months if there's life in Fletch (and Sky). Or if CDE'ed.
K.

I joined the Polymer team which tries to stick to very plain JS (no

required build steps, no module systems, etc.) for many reasons.

Plain JS as in ES5? This makes your comments above more
understandable.

Actually, in my corner of the world I get to use a lot of ES6 (I get
totarget io.js and Chrome Canary atm). Growing the language as strict
supersets does not make it more analyzable.

Not supersets. The sane emerging subset is analyzable. Maybe not so
much as Dart - but it is.

But there has been a big shift to Babel/ES6/TS/Flow. Basically there
is now enough tooling/analysis available via a mainstream route. This
wasn't true when Dart kicked off but it's true now.

Nom not in general, maybe a little in practice. Closure compiler has
been around a long time doing the herculean work of trying to force JS into
analyzable patterns, it's not a new thing. ES6 doesn't help much either. I
mentioned several ES6 features that will throw any static analyzer for a
loop up thread. Classes in particular don't prevent you from imperatively
changing the shape of prototypes or instances, or the prototype chain.

Stay within the sane subset. Don't imperatively muck around with prototypes.

It's unlikely Dart will pick up any new users given the announcement
that the DartVM is not going into Chrome.

That's provably false inside Google. Probably outside too.

Outside Google - unlikely. A couple of wins - sure - mass take up -
unlikely.

And wasm is the icing on the cake.

'yet' is right. wasm is icing on the cake in terms of developer
mind-share. It shows collaboration.

Post by 'Justin Fagnani' via Dart Misc
Those compilers all take advantage of (and then work around to
varying degrees) the JavaScript object model, and they use much, much more
of JavaScript than the asm.js subset. WASM isn't the big breakthrough
that's needed, IMO.

Initially ES modules will be able to call WASM modules for
computational/graphics work without paying the JS dynlang tax. That's
"The point of asm.js is that it's there if the developer feels they
need it. The lower level part of an app - which may need to be closer to
the metal - can use this subset. And then expose an API to the higher level
more dynamic parts of the app."

the V8 team are thinking about how to leverage wasm in a SoundScript
context with a decent evolutionary path in 1VM.

I don't think these things fit together like you imagine. asm.js
already doesn't support the things that strong mode limits. SoundScript is
concerned with optional typing of objects, asm.js only has numbers, arrays
and functions.

I said *evolutionary* path. I think these things will come together
eventually pretty well.

Every project has their own priorities and makes their own

decisions.

Is Dart's future dart2js. Or does the VM have an independent future -
and are Google going to back it long-term. Especially on the client - where
Fletch looks interesting.
ES6/TS/WASM have done enough to undermine Dart's story. Is there a response.
K.

Post by Gen
Quote: "In personal experience, I write JavaScript full time now,
and the pain is very real."
What could possibly be the reason for writing JavaScript if you do
not like it ?
Seriously.
There is Typescript.
And you work even for Google, the company that tries promote Dart
as alternative.

Not every project at Google uses Dart. Or GWT, TypeScript,
Closure... or plain JavaScript even.
Every project has their own priorities and makes their own
decisions. I joined the Polymer team which tries to stick to very plain JS
(no required build steps, no module systems, etc.) for many reasons. That
was my calculated tradeoff when I joined them, but it doesn't make it less
painful :)

On Tue, Jun 23, 2015 at 12:50 PM, Brendan Eich <

Post by Brendan Eich
On Tue, Jun 23, 2015 at 9:43 AM, 'Justin Fagnani' via Dart Misc

On Mon, Jun 22, 2015 at 4:37 PM, Brendan Eich <

Post by Brendan Eich
On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart

On Mon, Jun 22, 2015 at 10:47 AM, Brendan Eich <

On Mon, Jun 22, 2015 at 10:41 AM, Daniel Joyce <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and
many other such products.

And Dart's unsound type system differs only in degree, not
kind. Useful warning systems are useful.

And even a sound type system won't help know all available
properties when dealing in interfaces, so while technically the difference
is "only" in degree, it's still a massive difference.

Yes, differences of degree matter. Agreed.

Post by Brendan Eich
I fear I've stumbled into the "tastes great! less filling!"
section of this list. Backing out slowly...

I just have a problem with drawing an equivalence, or even near
equivalence, in static analyzability between languages like JavaScript and
languages like Dart. It borders on dishonesty.

Sorry to Daniel, I misattributed "borders on dishonesty" to him.
It's ok to say that JavaScript is much more dynamic, and more

malleable, with one tradeoff being that it's harder to analyze.

"harder" == "difference of degree". It seems we agree.
JS with junk like `with` is hard to impossible to analyze,
period. No question. Dart's a lot easier!

Post by Brendan Eich
not "guess".

I never said it did (I mentioned Closure and Tern which go to
great lengths to do analysis and inference). Their capabilities simply pale
in comparison even to the Dart analyzer, to such a degree that the
comparison is silly.
In personal experience, I write JavaScript full time now, and the
pain is very real. I've used almost every JS analyzer out there. They all
suck (and it's not their fault). It's not just auto-complete - knowing that
the code you wrote has a reasonable chance of running requires... running
it. I have to write a lot more mind-numbingly boring tests now to protect
against things that should be caught by tools. I'll probably start using
Closure compiler soon. I was trying to stay with as plain JS as possible,
but that's just a path to more bugs. I hope SoundScript and strong mode
work out, they seem to be the only hope for mainstream JS programmers.

Post by Brendan Eich
/be
--
For other discussions, see
https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from

For other discussions, see
https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it,

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it,

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

Daniel Joyce

2015-06-23 16:00:57 UTC

Exactly this. Javascript completers just 'guess' based on symbol scanning,
unlike JAVA IDEs, which can make use of java compiler hooks to provide
immediate feedback on compilet errors and even with a compiled jar provide
IN DEPTH proposals because the public api can not be changed via simple
code execution.

PERL has the same problem. The only way a IDE can be 100% sure of the api
would be execute all possible paths of the code and analyze all possible
states of all objects, which is impossible, since
properties/methods/functions can be added/removed at any time.

On Mon, Jun 22, 2015 at 2:18 PM 'Justin Fagnani' via Dart Misc <

Post by Daniel Joyce
Javascript and perl render in depth tooling and code
completiong/analysis nearly impossible since they are so dynamic.

Please see https://docs.c9.io/v1.0/docs/autocompletion and many other
such products.

Oh, come on. JavaScript completers are usually very simple and dumb, based
on extracting what look like symbols in files. Even when they do analysis
(like Closure and Ternjs), they only work for a subset of the language and
often rely on extra type information like JSDocs or TypeScript.
var Foo = Foo || (Foo() {
if (iHateStaticAnalysis) {
this.bar = 'JavaScript';
}
});
myFrameworksMixinApproximator(Foo, (function() {
var props = {};
if (iHateStaticAnalysis) {
props.baz = function() { return this.bar + ' is so awesome!'; }; //
error, warning, nothing?
}
return props;
})());
var foo = new Foo();
console.log(foo.baz().length); // Sorry Cloud9

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

Brendan Eich

2015-06-23 19:46:57 UTC

Post by Daniel Joyce
Exactly this. Javascript completers just 'guess' based on symbol scanning,

This is a false statement. I'm going to assume that you didn't know of the
higher-order JavaScript control flow analysis done by projects like Cloud9,
so I'm not going to drop bombs like "borders on dishonesty" :-|. Modern JS
tools use static analysis, they do not "guess".

An early example of higher-order control flow analysis for JS was DoctorJS,
based on Dimitris Vardoulakis's work (Dimitris studied under Olin Shivers;
he works for Google on the Closure Compiler now). See
http://dimvar.github.io/ and https://github.com/mozilla/doctorjs. HTH,

/be

Danny Tuppeny

2015-06-23 20:21:45 UTC

Post by Brendan Eich
This is a false statement. I'm going to assume that you didn't know of the
higher-order JavaScript control flow analysis done by projects like Cloud9,
so I'm not going to drop bombs like "borders on dishonesty" :-|. Modern JS
tools use static analysis, they do not "guess".

I don't want to stoke any flames but I'm genuinely curious about this, as
I've always considered this a fairly unsolvable problem...

eg.:

var a = new Date().getYear == 2010 ? 0 : "";

I don't see how tools can provide anything useful information about "a"
here. Although this example is contrived, I'm sure production JavaScript is
littered with code that has similar issues (can't tell at analysis time).
If everything just ends up being dynamic (or huge union types), then we
don't get much help from tools. Though maybe I'm overestimating how much
code falls into this category?

I long for the day when we can write for the browser in a language with a
really strong sound type system. Apps are becoming too big and too complex
to not have good static analysis and tooling. Dart is a great attempt; but
the IDEs I've tried it in all kinda suck :(

tekz omnisoft

2015-06-23 20:24:24 UTC

+100

Post by Brendan Eich
This is a false statement. I'm going to assume that you didn't know of
the higher-order JavaScript control flow analysis done by projects like
Cloud9, so I'm not going to drop bombs like "borders on dishonesty" :-|.
Modern JS tools use static analysis, they do not "guess".

I don't want to stoke any flames but I'm genuinely curious about this, as
I've always considered this a fairly unsolvable problem...
var a = new Date().getYear == 2010 ? 0 : "";
I don't see how tools can provide anything useful information about "a"
here. Although this example is contrived, I'm sure production JavaScript is
littered with code that has similar issues (can't tell at analysis time).
If everything just ends up being dynamic (or huge union types), then we
don't get much help from tools. Though maybe I'm overestimating how much
code falls into this category?
I long for the day when we can write for the browser in a language with a
really strong sound type system. Apps are becoming too big and too complex
to not have good static analysis and tooling. Dart is a great attempt; but
the IDEs I've tried it in all kinda suck :(
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

Kasper Peulen

2015-06-23 20:44:41 UTC

Apps are becoming too big and too complex to not have good static

analysis and tooling. Dart is a great attempt; but the IDEs I've tried it
in all kinda suck :(

really? so you basicly mean the dart analyser sucks ? I find the
combination webstorm+ dart really god. But I've only tried
javascrip+webstorm and objective c+xcode before. Maybe my expectations are
just low...

+100

Post by Brendan Eich
This is a false statement. I'm going to assume that you didn't know of
the higher-order JavaScript control flow analysis done by projects like
Cloud9, so I'm not going to drop bombs like "borders on dishonesty" :-|.
Modern JS tools use static analysis, they do not "guess".

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Kasper

Danny Tuppeny

2015-06-23 20:47:33 UTC

Post by Kasper Peulen

Apps are becoming too big and too complex to not have good static

analysis and tooling. Dart is a great attempt; but the IDEs I've tried it
in all kinda suck :(
really? so you basicly mean the dart analyser sucks ? I find the
combination webstorm+ dart really god. But I've only tried
javascrip+webstorm and objective c+xcode before. Maybe my expectations are
just low...

Kasper Peulen

2015-06-23 21:02:24 UTC

So you mean not really the functionality, but more the looks/ UI etc ?

I guess you are using windows ? Webstorm at windows does feel unpolished
and sluggish to me. But on mac, it feels excellent. It is really quite a
difference.

But maybe Webstorm is also something you get used to. Every so much time, I
find out some new feature of webstorm, and many times, features blow my
mind. Things like emmett, live templates, automatic sass compiler, git GUI,
pressing alt+enter for quick fixes, debuggin options, ability to have live
refreshing docs and code side by side (like dartpad), well and much more.

I find it hard to complain about webstorm, except that the looks at windows
and especially at HDPI screens is really horrible.

Post by Kasper Peulen

Apps are becoming too big and too complex to not have good static

analysis and tooling. Dart is a great attempt; but the IDEs I've tried it
in all kinda suck :(
really? so you basicly mean the dart analyser sucks ? I find the
combination webstorm+ dart really god. But I've only tried
javascrip+webstorm and objective c+xcode before. Maybe my expectations are
just low...

No, I think the Analyser is good. It's the feel of the IDEs I dislike.
They all feel unpolished and sluggish/quirky. I'm mostly used to the C#
editor in VS which feels really polished compared to anything else I've
tried. I tried both DartEditor and WebStorm and I wasn't sold on either
(and CDE was never really finished).
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Kasper

Danny Tuppeny

2015-06-25 16:26:43 UTC

Post by Kasper Peulen
So you mean not really the functionality, but more the looks/ UI etc ?

Not really bothered by looks, just doesn't seem like it performs the same
and feels rather unpolished. Eg. delay in opening intellisense/completing.
C# editor feels *really* fast, but nothing I've used for Dart does. Doesn't
seem like something that can't theoretically be solved, but not sure how
(technically) feasible it is.

There are also weird things I just couldn't figure out; like when I created
a new Dart project, it had things set up for me to debug. When I opened up
an existing folder I had on disk, I spent ages trying to set it up the same
way; even diffing the folders on disk, and couldn't figure out why it
wasn't launching its web server when I pressed run. It was quite a
frustrating experience.

I guess you are using windows ? Webstorm at windows does feel unpolished

Post by Kasper Peulen
and sluggish to me. But on mac, it feels excellent. It is really quite a
difference.

I am indeed using Windows. And Visual Studio is probably going to keep me
there on its own for a long time :(

But maybe Webstorm is also something you get used to. Every so much time, I

Post by Kasper Peulen
find out some new feature of webstorm, and many times, features blow my
mind. Things like emmett, live templates, automatic sass compiler, git GUI,
pressing alt+enter for quick fixes, debuggin options, ability to have live
refreshing docs and code side by side (like dartpad), well and much more.

There are lots of editors with great features I'd like, but I just can't
see through the lack of polish (maybe I'm shallow!) ;( I spend enough time
waiting for my computer to start up, load the IDE, compile, etc. (and it's
a very fast machine), having to keep pausing for stuff while I'm spewing
out code from my fingers annoys me. My IDE needs to work far faster than
me, and lots of these other IDEs just don't feel that way :O(

Brendan Eich

2015-06-23 21:31:38 UTC

Post by Brendan Eich
This is a false statement. I'm going to assume that you didn't know of
the higher-order JavaScript control flow analysis done by projects like
Cloud9, so I'm not going to drop bombs like "borders on dishonesty" :-|.
Modern JS tools use static analysis, they do not "guess".

Tools like C9, Flow (flowtype.org), etc. have knowledge of built-ins, so
they can flag bugs in the above such as comparing a method to a number.
Fixing to avoid the Y2K-bugged Gosling getYear method, and to actually call
getFullYear, gives:

var a = new Date().getFullYear() == 2010 ? 0 : "";

The type of a is a union (number | string). For Flow, see
http://flowtype.org/docs/union-intersection-types.html. The big-picture
point is that JS can be checked by useful analyzers such as DoctorJS and
Flow. With JS in full you can indeed run into undecidable hard cases, and
the best checkers make these errors ;-).

/be

Daniel Joyce

2015-06-23 23:31:49 UTC

Biggest Gotcha:

http://flowtype.org/docs/third-party.html#_

So why bother then? They also don't reccomend running flow against third
party libraries, which makes no sense to me. Isn't that the whole purpose
of Flow?

Doctor JS does some weird type of pseudo interpretation.

Still seems to me that these may work for decent well-written Javascript,
but not help with older tricksey-hobbitses javascript.

Its better than nothing, I know this kind of thing is being done, but its
still not very comforting.

Post by Brendan Eich
This is a false statement. I'm going to assume that you didn't know of
the higher-order JavaScript control flow analysis done by projects like
Cloud9, so I'm not going to drop bombs like "borders on dishonesty" :-|.
Modern JS tools use static analysis, they do not "guess".

Tools like C9, Flow (flowtype.org), etc. have knowledge of built-ins, so
they can flag bugs in the above such as comparing a method to a number.
Fixing to avoid the Y2K-bugged Gosling getYear method, and to actually call
var a = new Date().getFullYear() == 2010 ? 0 : "";
The type of a is a union (number | string). For Flow, see
http://flowtype.org/docs/union-intersection-types.html. The big-picture
point is that JS can be checked by useful analyzers such as DoctorJS and
Flow. With JS in full you can indeed run into undecidable hard cases, and
the best checkers make these errors ;-).
/be
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

2015-06-22 23:27:49 UTC

Post by kc
The DartVM is basically a Smalltalk-like runtime, but the interface to
this *dynamic* VM is source code with an awful *static* Java-like syntax.
So the thing that makes this project interesting is lost.

I appreciate the nominal class based declarative nature of Dart. Much less
meta-programming then JS/Ruby/Lua etc - but more structure.

I mean dynamic in that all method calls are resolved at runtime and type
annotations are not used in method resolution:

a.msg(x:1, y:2); // a 'message' to the receiver 'a'

For some reason Dart's syntax and checked mode locks ppl into a very
'static must satisfy the analyzer' way of thinking. Rather than the
flexibility of reflection and a optional/pluggable type system with types
as documentation. With a live dev environment/playground maybe this story
would have been clearer.

Syntax - ES/TS/Flow finds it easy to express function and union annotations
with rhs type annotations which also works well for tooling. The syntax is
dense but not succinct. And my old favourite:

final Point p = new Point(1,1); // abomination

Post by 'Justin Fagnani' via Dart Misc
An AST would only enable different expressions of essentially the same
syntax, basically by definition. You couldn't represent a construct that
isn't representable already in the AST. ASTs don't define semantics, and
having a standard AST wouldn't mean that you could do anything more dynamic
that you could now.

By abstract I mean abstract not a Concrete Syntax Tree. Dart could have
been a Newspeak-ish VM with an AST interface and 2 skins - Newspeak and
something more familiar with curlies. As long as interop and round-tripping
worked could have been interesting.

Post by kc
At the moment the source syntax and the DartVM are so intertwined that
any changes are tricky/expensive. There's nothing wrong with syntax 'sugar'
that transforms down to core semantics as long as it's straightforward,
non-magical and can be reasoned about.

If you're just talking about syntax transformations, you can already do
this with text formats... You can even go further than than syntax only
transformations if you so wish.

Basically I feel the Dart syntax has been such an footgun that it's
tempting to skin the Dart runtime with syntax similar to ES5/TS/Swift and
deal with some of the egregious syntax elements - const/new, optional/pos
params etc. Given the way ES/TS/Swift/Kotlin/Scala have gone what does
'familiar' mean?

K.

Filipe Morgado

2015-06-23 03:43:46 UTC

I love the idea of a WebVM, as long as I'm able to use high-level languages, such as Dart or Ceylon, with STATIC type systems.

JS has grown like a cancer (no offense). I wouldn't want it to infect such an ambitious project
project.

Brendan Eich

2015-06-23 07:48:21 UTC