WebAssembly and Dart

[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

[Günter Zöchbauer]

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ß]

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]

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.

[Bob Nystrom]

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

--
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 email to misc+uns...@dartlang.org.

[Don Olmstead]

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

[Warren]

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

[Filipe Morgado]

On Thursday, 18 June 2015 17:28:44 UTC+1, Bob wrote:

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

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.

On Thursday, 18 June 2015 18:28:11 UTC+1, Don Olmstead wrote:

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.

[Don Olmstead]

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/

--

[Günter Zöchbauer]

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]

On Thu, Jun 18, 2015 at 11:35 AM, Günter Zöchbauer <gzo...@gmail.com> wrote:

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. 

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]

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

[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

--

[Cristian Garcia]

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? 

[Bob Nystrom]

On Thu, Jun 18, 2015 at 1:16 PM, Cogman <cog...@gmail.com> wrote:

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

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

[Bob Nystrom]

On Thu, Jun 18, 2015 at 2:49 PM, Cristian Garcia <cgarc...@gmail.com> wrote:

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]

Great discussion. Thank you.

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

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

--

[Joris Hermans]

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

Op 19-jun.-2015 01:25 schreef "Cogman" <cog...@gmail.com>:

[Brendan Eich]

On Thursday, June 18, 2015 at 6:57:10 AM UTC-7, Filipe Morgado wrote:

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

[Brendan Eich]

On Thursday, June 18, 2015 at 4:25:42 PM UTC-7, Thomas May wrote:

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 

[Brendan Eich]

On Thursday, June 18, 2015 at 4:37:27 PM UTC-7, Joris Hermans wrote:

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]

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

--

[Brendan Eich]

On Thursday, June 18, 2015 at 5:51:41 PM UTC-7, Cristian Garcia wrote:

@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

[DoHyung Kim]

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. 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 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년 6월 18일 목요일 오후 5시 11분 52초 UTC+9, tomaszkubacki 님의 말:

[Danny Tuppeny]

On Thursday, 18 June 2015 18:28:11 UTC+1, Don Olmstead wrote:

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

 

On Thursday, 18 June 2015 19:35:20 UTC+1, Günter Zöchbauer wrote:

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]

1. Specify and implement incrementally:
   • a Minimum Viable Product (MVP) for the standard with roughly the same functionality as asm.js, primarily aimed at C/C++;
   • an effective and efficient polyfill 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 which adds several more essential features; and
   • additional features, 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.

--

[Cristian Garcia]

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

[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

[Daniel Joyce]

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

Daniel Joyce

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

[Danny Tuppeny]

On 20 June 2015 at 05:51, Daniel Joyce <daniel....@gmail.com> wrote:

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, so clearly the goal is to build something that can ultimately support it.

[Danny Tuppeny]

On 19 June 2015 at 18:33, Don Olmstead <don.j.o...@gmail.com> wrote:

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.

 

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.

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

[kc]

On Saturday, June 20, 2015 at 10:13:56 AM UTC+1, Danny Tuppeny wrote:

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]

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.

[kc]

On Saturday, June 20, 2015 at 1:23:22 PM UTC+1, Günter Zöchbauer wrote:

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]

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?

--

[kc]

On Saturday, June 20, 2015 at 3:20:18 PM UTC+1, Cristian Garcia wrote:

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]

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

--

[Lex Berezhny]

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.

[Justin Fagnani]

On Sat, Jun 20, 2015 at 4:31 AM, kc <kevin...@gmail.com> wrote:

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.

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.

 

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.

 

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.

K.

On Thursday, June 18, 2015 at 9:11:52 AM UTC+1, tomaszkubacki wrote:

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

--

[Brendan Eich]

On Sat, Jun 20, 2015 at 7:59 AM, kc <kevin...@gmail.com> wrote:

On Saturday, June 20, 2015 at 3:20:18 PM UTC+1, Cristian Garcia wrote:

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. 

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

[Daniel Joyce]

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.

[Brendan Eich]

On Mon, Jun 22, 2015 at 10:41 AM, Daniel Joyce <daniel....@gmail.com> wrote:

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

[Filipe Morgado]

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)

[Justin Fagnani]

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

/be

[kc]

On Monday, June 22, 2015 at 6:01:40 PM UTC+1, Justin Fagnani wrote:

On Sat, Jun 20, 2015 at 4:31 AM, kc <kevin...@gmail.com> wrote:

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

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 type annotations with rhs annotations. Also works well for tooling.  Dart's syntax is dense but not succinct. And my old favourite:

final Point p = new Point(1,1); // abomination

 

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.

 

 

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

[Brendan Eich]

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

[Brendan Eich]

On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc <mi...@dartlang.org> wrote:

On Mon, Jun 22, 2015 at 10:47 AM, Brendan Eich <brenda...@gmail.com> wrote:

On Mon, Jun 22, 2015 at 10:41 AM, Daniel Joyce <daniel....@gmail.com> wrote:

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.

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

[kc]

On Monday, June 22, 2015 at 6:39:31 PM UTC+1, Brendan Eich wrote:

On Sat, Jun 20, 2015 at 7:59 AM, kc <kevin...@gmail.com> wrote:

On Saturday, June 20, 2015 at 3:20:18 PM UTC+1, Cristian Garcia wrote:

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. 

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.

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

 

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]

On Mon, Jun 22, 2015 at 5:08 PM, kc <kevin...@gmail.com> wrote:

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.

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

 

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

[kc]

On Tuesday, June 23, 2015 at 1:12:57 AM UTC+1, Brendan Eich wrote:

On Mon, Jun 22, 2015 at 5:08 PM, kc <kevin...@gmail.com> wrote:

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.

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.

 

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.

 

/be

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

[Filipe Morgado]

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.

[Filipe Morgado]

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]

Not to worry, all the C++-implemented browsers cannot allow vtbls changing out under a given object identity's feet either. That's what is known as a pwn2own loss or 0day security bug :-|. WebAssembly doesn't change anything for the worse here.

However, JS is far from alone among dynamic languages in supporting both kinds of objects: those like the DOM and other built-in ones that are bounded by OO types which enable vptr/vtbl optimizations; and those whose methods can be monkey-patched willy nilly. All such languages should have common support in the future-features wasm design doc.

/be

[Daniel Joyce]

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.

[Daniel Joyce]

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.

--
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 email to misc+uns...@dartlang.org.

[Justin Fagnani]

On Mon, Jun 22, 2015 at 4:37 PM, Brendan Eich <brenda...@gmail.com> wrote:

On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc <mi...@dartlang.org> wrote:

On Mon, Jun 22, 2015 at 10:47 AM, Brendan Eich <brenda...@gmail.com> wrote:

On Mon, Jun 22, 2015 at 10:41 AM, Daniel Joyce <daniel....@gmail.com> wrote:

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.

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.

 

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]

On Tue, Jun 23, 2015 at 9:00 AM, Daniel Joyce <daniel....@gmail.com> wrote:

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

 

[Brendan Eich]

On Tue, Jun 23, 2015 at 9:43 AM, 'Justin Fagnani' via Dart Misc <mi...@dartlang.org> wrote:

On Mon, Jun 22, 2015 at 4:37 PM, Brendan Eich <brenda...@gmail.com> wrote:

On Mon, Jun 22, 2015 at 2:17 PM, 'Justin Fagnani' via Dart Misc <mi...@dartlang.org> wrote:

On Mon, Jun 22, 2015 at 10:47 AM, Brendan Eich <brenda...@gmail.com> wrote:

On Mon, Jun 22, 2015 at 10:41 AM, Daniel Joyce <daniel....@gmail.com> wrote:

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.

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.

 

 

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!

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

/be

[Danny Tuppeny]

On 23 June 2015 at 20:46, Brendan Eich <brenda...@gmail.com> wrote:

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]

+100

--

[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

[Danny Tuppeny]

On 23 June 2015 at 21:44, Kasper Peulen <kasper...@gmail.com> wrote:

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

[Kasper Peulen]

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.

--

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 email to misc+uns...@dartlang.org.

--

Kasper

[Brendan Eich]

On Tue, Jun 23, 2015 at 1:21 PM, Danny Tuppeny <da...@tuppeny.com> wrote:

On 23 June 2015 at 20:46, Brendan Eich <brenda...@gmail.com> wrote:

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.

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

[Justin Fagnani]

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. It'll get worse with decorators that mutate property descriptors.

However, modern autocomplete tooling (the subject up-thread) does 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.

[Don Olmstead]

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]

On Jun 23, 2015, at 2:48 PM, 'Justin Fagnani' via Dart Misc <mi...@dartlang.org> wrote:

JS with junk like `with` is hard to impossible to analyze, period. No 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 "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]

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

[kc]

On Tuesday, June 23, 2015 at 11:48:01 PM UTC+1, Brendan Eich wrote:

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.

[Daniel Joyce]

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.

--

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 email to misc+uns...@dartlang.org.

[kc]

On Tuesday, June 23, 2015 at 2:43:53 AM UTC+1, Cristian Garcia wrote:

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]

On Jun 23, 2015, at 4:14 PM, Cogman <cog...@gmail.com> wrote:
>
> @Brandon

(Brendan.)

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

> 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

[Brendan Eich]

On Tue, Jun 23, 2015 at 3:07 PM, Don Olmstead <don.j.o...@gmail.com> wrote: 

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

 

[Brendan Eich]

On Tue, Jun 23, 2015 at 4:17 PM, kc <kevin...@gmail.com> wrote:

On Tuesday, June 23, 2015 at 11:48:01 PM UTC+1, Brendan Eich wrote:

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.

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

 

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

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

[kc]

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.

 

/be

[Brendan Eich]

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]

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

 

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

[Brendan Eich]

On Wed, Jun 24, 2015 at 2:36 PM, Alex Tatumizer <tatu...@gmail.com> wrote:

> 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

[Justin Fagnani]

On Wed, Jun 24, 2015 at 3:14 PM, Gen <gp78...@gmail.com> wrote:

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

[Daniel Joyce]

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

[Alex Tatumizer]

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

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.

2015년 6월 25일 목요일 오전 11시 38분 54초 UTC+9, Alex Tatumizer 님의 말:

[Lasse R.H. Nielsen]

On Thu, Jun 25, 2015 at 4:38 AM, Alex Tatumizer <tatu...@gmail.com> wrote:

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

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

 

You can't say 

any x="foo" - because the type says "int".

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

 

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.

 

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

 

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

[kc]

On Wednesday, June 24, 2015 at 11:45:59 PM UTC+1, Justin Fagnani wrote:

 

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.

[kc]

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

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.

[Daniel Joyce]

On Wed, Jun 24, 2015 at 7:38 PM Alex Tatumizer <tatu...@gmail.com> wrote:

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

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.

[Danny Tuppeny]

On 23 June 2015 at 22:02, Kasper Peulen <kasper...@gmail.com> wrote:

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

[Justin Fagnani]

On Thu, Jun 25, 2015 at 4:24 AM, kc <kevin...@gmail.com> wrote:

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.

On Wednesday, June 24, 2015 at 11:45:59 PM UTC+1, Justin Fagnani wrote:

[kc]

On Thursday, June 25, 2015 at 6:14:18 PM UTC+1, Justin Fagnani wrote:

On Thu, Jun 25, 2015 at 4:24 AM, kc <kevin...@gmail.com> wrote:

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.

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.

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

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

 

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. 

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.

[Don Olmstead]

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

[kc]

On Thursday, June 25, 2015 at 7:21:00 PM UTC+1, Don Olmstead wrote:

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

What are you a tabloid reporter @kc?

Lol. Not a fanboy.

 

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.

[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???????????

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

[Don Olmstead]

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? 

[Gen]

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)