
Microsoft shoots down Google's Dart - taylorbuley
http://news.cnet.com/8301-30685_3-57330431-264/microsoft-shoots-down-googles-dart-language/
======
johnbender
> JavaScript has the classic benefits of an incumbent technology. Programmers
> are familiar with it...

This is only from my own experience but I'm consistently blown away by how
_little_ people actually know of JavaScript. Between interviews and looking at
samples attached to jQuery Mobile issues all day I get the impression that
most people don't know how to use the prototype system at all and generally
organize their code as a series of jQuery event bindings.

While this isn't necessarily and endorsement of Dart, I welcome anything that
can provide/encourage well-known and sane code reuse patterns.

~~~
ahi
Guilty. Any recommendations for learning?

edit: I have the rhino book. I meant, learning alternatives to organizing my
code as a series of jQuery event bindings.

~~~
johnbender
Yehuda Katz has a nice article on the prototype system that I generally point
people to.

[http://yehudakatz.com/2011/08/12/understanding-prototypes-
in...](http://yehudakatz.com/2011/08/12/understanding-prototypes-in-
javascript/)

And the JavaScript Patterns book is a good read to get an overview of what can
be done with just JavaScript. If your application is even remotely complex
you'll probably end up using something like backbone or sproutcore which
provide constructs for organizing your code anyway.

------
azakai
The most interesting part of the Microsoft blogpost that is the basis for this
story, IMO, is that

> The Office Web Applications, which consist of hundreds of thousands of lines
> of JavaScript, are written primarily in a variant of Script# that is then
> compiled into JavaScript that can be executed on today’s browsers.
> [http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-
> ecmas...](http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-
> ecmascript.aspx)

Apparently Script# is quite mature now, and is being used to compile very
large apps to JavaScript. This is a big vote of confidence from Microsoft
regarding JavaScript as a compilation target.

~~~
cskau
> Apparently Script# is quite mature now, and is being used to compile very
> large apps to JavaScript. This is a big vote of confidence from Microsoft
> regarding JavaScript as a compilation target.

I'd say the same thing about Google's own Closure, which they oddly enough
don't mention alongside CoffeeScript et al.

I see Dart as a rethinking of much of Closure so I don't quite get what
Microsoft thinks the difference between their Script# and Dart/Closure is.

~~~
azakai
Did you mean Google Web Toolkit? That compiles Java to JS, and is similar to
Script# (which compiles C# to JS). Whereas Closure Compiler is an optimizing
compiler for JS, it compiles JS to (better) JS. (The Microsoft article did
mention Google Web Toolkit, which was nice of them.)

GWT and Script# are both quite mature at this point, it looks like. Very
interesting stuff. (However, GWT is probably losing focus inside Google to
Dart, so I am not sure of its long-term prospects. It's open source though so
anyone can continue it if they want.)

~~~
munificent
Closure compiler doesn't just compile vanilla JS. It supports type annotations
in comments and will use those to generate code. It's type system supports
classes and interfaces. The Closure library has support for class-style
inheritance.

Programming in Closure-style JS feels like you're using an optionally-typed
class-based language, just one with really terrible syntax.

~~~
azakai
Thanks, I didn't know that. Perhaps those type annotations could help optimize
compiled code (like from Emscripten).

------
Yxven
I've never understood the point of special browser only languages.

Why don't browsers support a sand-boxed python (or insert favorite language x)
with some sort of standard dependency management? It already has JIT
compilation, is cross-platform, bytecode, a wealth of libraries, etc. Why are
we reinventing this wheel?

~~~
tikhonj
JavaScript isn't a special "browser-only" language. It's just a normal
interpreted, dynamically typed language (much like Python or Ruby) that just
happens to run in all browsers. Right now it also happens to be quite a bit
faster than Python or Ruby (as far as I know) and is also extremely expressive
and flexible.

The fact that Python has "a wealth of libraries" isn't particularly pertinent
--web apps mostly need web-specific libraries, which Python doesn't have
(because it isn't in the browser). Most people using JavaScript get by with
jQuery, maybe some web ui framework and perhaps something like Raphael. And,
with the advent of node and server-side JavaScript, JavaScript is getting more
and more libraries outside of the browser as well.

Of course, the browsers could support a bunch of different languages, but I
think the complexity outweighs the (limited) benefits. Google, obviously,
disagrees and thinks that Dart should also be an option, but I really think it
isn't worth the effort.

Ultimately, JavaScript is more than good enough as a browser language; while
it does have some annoying quirks, upcoming versions (and things like "use
strict") are getting rid of most of them. There really is no overwhelming
reason to switch away from JavaScript, and even just adding another language
is probably not worth it.

~~~
Yxven
Javascript was originally built for the browser and later expanded to other
areas.

I'm not claiming that python wouldn't need a new standard library to
manipulate a browser's dom tree or whatever. That's about all it would need
though, so it seems like it would have been far less work to embrace and
extend than to completely start over.

You seem to be arguing from the perspective (and please correct me if I'm
wrong) that javascript is a good solution and a fine programming language, and
I am not claiming otherwise. I just don't understand why so much effort has
been spent creating and polishing Javascript instead of making slight
improvements to a previously established quality language.

I suspect the answer is that your browser has an advantage if your javascript
engine is faster, but there can be no advantage if everyone uses the standard
python interpreter.

~~~
tikhonj
I'm not sure why Netscape decided to write their own language for the job.
Perhaps integrating a different language into their browser would have been
difficult back then. Now, however, JavaScript is a well-established language
so there is no need to replace it with anything else.

Also, unless I'm unaware of something, wasn't Perl the most popular scripting
language back then? So if they had included an already existing language, Perl
would probably have been the best bet.

~~~
chromatic
_So if they had included an already existing language, Perl would probably
have been the best bet._

Embedding Perl was (and is) painful. Tcl would have been easier.

Sandboxing would have been more difficult. Auditing all of Perl 5's operations
for the possibility of escaping that sandbox is a huge task.

------
CurtHagenlocher
It looks like it's really the alternate VM that's being "shot down". After
all, the piece goes to the trouble of pointing out that "...transforming
compiler libraries like Traceur and CoffeeScript show how syntax additions to
JavaScript and even completely alternative syntaxes can be supported in
today’s browsers, without changes to the runtime."

Disclaimer: I work at Microsoft.

~~~
kodablah
But those languages aren't a significant deviation and still require pre-
compilation as opposed to runtime cross-compilation to be useful. Dart is a
significant deviation and expected to support debugging directly in the
language. Similar to developing in GWT, I doubt the JS will really be looked
by the developers at once Dart's compiler is optimized more.

Also, the VM wouldn't be required, it would just provide performance
improvements.

~~~
azakai
> Also, the VM wouldn't be required, it would just provide performance
> improvements.

I'm curious, is this true? Last I heard, Dart-in-JS didn't enforce types, so
integer math could overflow into doubles for example, but the Dart VM did use
native types (so ints would not overflow). So the semantics of the language
differ in JS and in the native VM, which means the VM doesn't just provide
speed, it provides different behavior.

Is this no longer the case - are the semantics of Dart-in-JS and in the VM
exactly the same?

~~~
adgar
Disclaimer: I work for Google.

JavaScript doesn't have integers. I suspect that the Dart VM will support
integers with overflow. So yes, I suspect in that case they are different.

I also strongly suspect this will not be a significant edge case in practice:
if you use integer types in your dart code, then you clearly don't want
doubles to result from a calculation. So the only unexpected "surprise" you
would encounter there is if you _expect_ integer overflow but get doubles. If
you are writing code that expects integer overflow to happen a certain way,
you're doing it wrong. If you're writing code that doesn't expect integer
overflow, and you want integers, then you're going to be fucked either way.
Either you end up with doubles and type errors or an overflow and your result
is wrong.

Changing things as entrenched as JavaScript while maintaining backwards
compatibility is messy and hard. Especially given some of the horrible
characteristics of the language. I'm glad someone's at least trying.

~~~
azakai
> JavaScript doesn't have integers. I suspect that the Dart VM will support
> integers with overflow. So yes, I suspect in that case they are different.
> [..] I also strongly suspect this will not be a significant edge case in
> practice [..] If you are writing code that expects integer overflow to
> happen a certain way, you're doing it wrong.

It's a valid position to say that relying on integer overflow in one's Dart
code is "wrong". But you will need to carefully educate coders about that,
since relying on overflow is common in popular languages like C and C++. This
won't be easy.

Another big worry is that this could lead to very hard to diagnose bugs.
Having the native VM and the compiled code have different semantics in subtle
ways is risky - unintended overflows will lead to different bugs in different
cases.

Also, integer overflow is not the only case where this problem arises. It also
happens with say division of an integer. Will Dart compiled code in JS add
proper rounding correction to all divisions of integers? Or will this be
another case where the VM differs from compiled code?

Overall, it seems much simpler and safer to just correct overflows in the
compiled code.

> Especially given some of the horrible characteristics of the language
> [JavaScript]

It's fine if you don't like something of course, but I don't think calling
languages "horrible" is going to lead to a productive discussion.

~~~
munificent
> But you will need to carefully educate coders about that, since relying on
> overflow is common in popular languages like C and C++.

This is something we're aware of and we know we need to be extra clear and
loud about it.

> Also, integer overflow is not the only case where this problem arises.

As far as I know, bigints are the _only_ place where the VM and the generated
JS intentionally differ in behavior. We are trying very hard to keep the two
in sync.

> It also happens with say division of an integer. Will Dart compiled code in
> JS add proper rounding correction to all divisions of integers?

Dart has two division operators (~/ and /) to handle this. The former rounds
(truncates? I'm not sure) and the latter does floating point division. So it's
always the operation that determines the type of the result, and not the type
of the operands.

> Overall, it seems much simpler and safer to just correct overflows in the
> compiled code.

Simpler: yes. Safer: yes. Unfortunately, it's also _much_ slower.

Rolling your own numeric type in JS means slower behavior when you have
overflowed and slow behavior even when you haven't. If you're generating code
for "a + b", you can't compile that to "a + b" in JS because you need to check
for overflow and handle the fact that a or b could be bignums.

We really want the compiled JS to behave the same as native code, but if it's
significantly slower, people just won't use it at all. It's an unfortunate
trade-off.

~~~
azakai
> > Overall, it seems much simpler and safer to just correct overflows in the
> compiled code.

> Simpler: yes. Safer: yes. Unfortunately, it's also much slower.

In my experience with something similar - compiling LLVM to JavaScript in
Emscripten, which also needs to properly implement integer math in JavaScript
- it actually isn't a lot slower. On the Emscripten benchmark suite enabling
overflow correction everywhere makes it only 5% slower. We might be running
very different benchmarks I guess.

(However, overflow correction does increase code size a lot, which is why we
have tools that let you get rid of it where it isn't needed.)

------
jjcm
Microsoft has long since lost the ability to shape the face of the web. While
they do contribute to w3c here and there, at the end of the day the webkit and
firefox teams are going to control where it goes. The question isn't whether
or not it has Microsoft's support, the question is whether or not javascript
is flawed enough to put the effort needed into releasing a new scripting
language engine with browsers.

Disclaimer: I work for Microsoft.

~~~
gcp
_at the end of the day the webkit and firefox teams are going to control where
it goes._

I don't think this is entirely true. IE still has more than enough marketshare
to matter. Microsoft embracing some approach, be it a new language, or be it
evolving JavaScript, has influences in how likely the efforts of the other
teams are to succeed in the marketplace.

------
kodablah
Saying Dart needs Microsoft adoption is like saying CoffeeScript or GWT needs
Microsoft adoption. They all allow JS compilation and the ability to use JS
and be called from JS. Google will likely make an IE extension to run Dart
natively anyways.

~~~
viggity
If it requires my users on a public site to install an extension, I'm not
going to use it. case. closed.

~~~
eCa
What he said was that Dart will compile into JS.

Natively run Dart will (otherwise, what's the point) than the JS it can be
compiled into. What I forsee is some kind of conditional that will allow
Chrome to run the Dart code, and other browser get served the compiled-into-
JS.

Demanding an extension installation is a no-go.

------
rwj
I was surprised to hear about Dart. A closer look at Google's other new
language (Go), shows a statically typed, compiled language that can be safely
sand-boxed. For example, look at how Google has included Go in AppEngine.
Additionally, there has been work at compiling Go to another project of
theirs, Native Client (NaCl). It still seems like this might be a good match.

------
orthecreedence
It took long enough for people to agree on Javascript and and HTML standard.
It works well for most people, most of the time. Dart smells to me of another
.NET for web...a framework that works ok, but not spectacularly enough for me
to care.

Also, it seems there are a lot of people who don't like Javascript and try to
either replace it or compile down to it. I don't understand why. I love
Javascript. I think it's terse and powerful. It's a perfect fit for web
applications. Sure, there may be a few annoying flaws, but it works well for
its intended purposes. Also, add a few libraries, or a real framework like
Mootools, and most of the flaws vanish.

Also, if we're going to go around creating systems for creating web apps that
compile to javascript, can we PLEASE use languages that allow macros (ie a
lisp variant)? Does another C-like language really add anything? (I'm actually
asking, not judging)

------
jfoutz
It's been a looong time since i fooled around with it, but isn't IE the only
browser that lets you specify the scripting language in page? I vaguely recall
using perl and Windows Scripting Host to do perl in a web page... Perhaps my
memory is as fossilized as that tech though.

~~~
ajasmin
I think their goal was to support any language. Do they still even support
VBScript now?

------
scriptproof
I believe Dart may have lot of uses beyond scripting HTML pages, and does not
need for IE compatibility. And I have not found a single word about Dart in
the article. Just some small changes in JavaScript, very minor compared to
what is planed to JavaScript 5.

------
rbanffy
Interesting. This must be a new position within Microsoft - it deviated
significantly from the previous Silverlight idea of using C# within an
environment provided by a browser plug-in.

Now that they discontinued the plugin (was it a month ago?), they feel it's OK
to criticize Google's approach.

~~~
rbarooah
If they've decided to abandon plugins and proprietary languages in favor of
javascript, why shouldn't they feel that it is ok to criticize Google's
approach?

~~~
rbanffy
Usually, when you defend a flawed approach for years and spend millions of
dollars on it, it's surprising to see you attack a competitor for following a
very similar but slightly less flawed approach, weeks after you partially and
not very publicly acknowledge your mistake.

------
masklinn
Well, duh. They also seem to indicate (in the linked blog post) that they have
no interest in the language's syntax evolving (including destructuring
assignment or `let` block-scoped bindings)

------
mqqq
As much as I like google I really don't want to go to yet another language. I
rather focus on building content rather than have to maintain my page in dart
and in JavaScript because of fragmentation issues.

~~~
kreek
Dart compiles to JavaScript, and the language is pretty standard stuff, if you
know any C style language you can pick it up quickly.

~~~
bad_user
The compiled Javascript is an abomination.

~~~
interknot
That initial 17 KLOC Hello World was an abomination, but it isn't looking
anywhere near as bad these days.

<https://gist.github.com/1385015>

------
HnNoPassMailer
The article is laughable. Microsoft itself is an important reason to develop
Dart to begin with. MS has EEE'd html/js/css with IE 5.5 and up, and developed
.NET to offer a competitive (proprietary) platform. We can't use C# although
it's open, because MS is acting as a patent troll.

~~~
Delmania
Do you live in the 90s? If Microsoft attempted to EEE HTML, Javascript, and
CSS with IE5+, it's failed miserably, since the usage of both Chrome and
Firefox continues to rise while IE stagnates or declines. You only have to
follow the development of IE10 to realize the company knows it needs to play
nicely with these technologies, whether it wants to or not. Also, .NET was a
response to Java, and while Silverlight and WPF were attempts to develop
competing technologies to Flash and HTML/Javascript/CSS that also seems to
have failed, since HTML and JS are key elements of the Metro UI for Windows 8.
In addition, Microsoft's actions against Android, while despicable, are hardly
different than what most other tech companies are doing, so it's best to focus
on the broken patent system. Finally, C# (and CLI) is a standard owned by the
ECMA, so Microsoft can't sue you if you write a compiler and library from
scratch.

~~~
HnNoPassMailer
That previous attempts failed does not mean they quit trying. IE9/10 does show
some goodwill, but also shows the are still in the EEE game. Take for example
the hardware accelerated canvas: Several (non-MS) websites had "optimized for
IE" marketing campaigns. Such optimization is nonsense when using standards.
Also, MS publicly stated WebGL has security problems because of direct access
to the shaders. However, they forget to mention Silverlight has the exact same
problem.

> In addition, Microsoft's actions against Android, while despicable, are
> hardly different than what most other tech companies are doing,

Eh, no. It's true more patent trolls exist, but not many companies in the
industry try to enforce software patents.

About C#: Microsoft has stated several times that open is not the same as
patent-free. They did so in context of Linux/Android, but also in the context
of .net. Also, anaylis exist where C# tech is tied to patents.

~~~
Delmania
> That previous attempts failed does not mean they quit trying. IE9/10 does
> show some goodwill, but also shows the are still in the EEE game. Take for
> example the hardware accelerated canvas: Several (non-MS) websites had
> "optimized for IE" marketing campaigns. Such optimization is nonsense when
> using standards. Also, MS publicly stated WebGL has security problems
> because of direct access to the shaders. However, they forget to mention
> Silverlight has the exact same problem.

Cool story, bro. Most people these days either use the browser that comes with
the OS, or install the one they want.

> Eh, no. It's true more patent trolls exist, but not many companies in the
> industry try to enforce software patents.

Really? Did you forget that Oracle started a lawsuit against Google for the
usage of Java within Android? Or how about Apple's lawsuit against Samsung for
the look and feel of the Galaxy Tablet? How about i4i's lawsuit against
Microsoft?

> Eh, no. It's true more patent trolls exist, but not many companies in the
> industry try to enforce software patents.

[Citation needed]

From Wikipedia: The C# language definition and the CLI are standardized under
ISO and Ecma standards that provide reasonable and non-discriminatory
licensing protection from patent claims.

You seem to have a hard time differentiating the language, C# from the
library, .NET. It's similar to C++ and the STL.

~~~
HnNoPassMailer
> Cool story, bro. Most people these days either use the browser that comes
> with the OS, or install the one they want.

This does not refute in an way that MS quit the EEE game. Merely, you seem to
troll me ("Cool story, bro.").

> Really? Did you forget that Oracle started a lawsuit against Google for the
> usage of Java within Android? Or how about Apple's lawsuit against Samsung
> for the look and feel of the Galaxy Tablet? How about i4i's lawsuit against
> Microsoft?

Exactly, a few big fish and some smaller pure trolls. I am not aware of
industrywide patent enforcement. There are thousands, if not tens of thousands
of IT companies, who don't pursue software patents let alone enforce if they
have.

> [Citation needed]

I am not aware of industrywide patentfights regarding software patents.
Telecom companies do battle each other ferociously over patents, which are not
necessarily for software (from what I read, not relatively many software
patents are involved).

> From Wikipedia: The C# language definition and the CLI are standardized
> under ISO and Ecma standards that provide reasonable and non-discriminatory
> licensing protection from patent claims.

If MS decides to sue they decide to sue.

~~~
Delmania
> This does not refute in an way that MS quit the EEE game. Merely, you seem
> to troll me ("Cool story, bro.").

I'm trolling you because the claim that MS is trying to EEE HTML/JS/CSS by
implementing hardware support for rendnering in IE is inane. Both Chrome and
Firefox have the same capabilities, and I've seen more that one site (I
actually use IE9 for specific reasons) that usually point me towards the usual
bunch.

>Exactly, a few big fish and some smaller pure trolls. I am not aware of
industrywide patent enforcement. There are thousands, if not tens of thousands
of IT companies, who don't pursue software patents let alone enforce if they
have.

So what in your mind makes Apple and Oracle different from Microsoft? If not,
just concede the point: hating the players is pointless, the game is broken.

> If MS decides to sue they decide to sue. Your point here is? Sure, if I
> implemented C# according to the standard and my own set of libraries, the
> company could try to sue me. I am positive they wouldn't get very far. But
> continue on with your Stallman like conspiracy theories.

------
diamondhead
Some people working for Google pointed similar thoughts even before the launch
of Dart, too.

