Hacker News new | comments | show | ask | jobs | submit login
Dart language (dartlang.org)
527 points by haasted on Oct 10, 2011 | hide | past | web | favorite | 489 comments

Mozilla's Brendan Eich, inventor of JavaScript, on the Dart memo leaked a few weeks ago:

A Dart to JS compiler will never be "decent" compared to having the Dart VM in the browser. Yet I guarantee you that Apple and Microsoft (and Opera and Mozilla, but the first two are enough) will never embed the Dart VM. So "Works best in Chrome" and even "Works only in Chrome" are new norms promulgated intentionally by Google. We see more of this fragmentation every day. As a user of Chrome and Firefox (and Safari), I find it painful to experience, never mind the political bad taste

From here: https://news.ycombinator.com/item?id=2982949

I disagree with his premise.

The Dart to JS compiler doesn't have to be "decent" compared to having the Dart VM in the browser to be useful in a world where other browsers don't use the Dart VM, it merely has to be "decent" compared to handcrafted JavaScript performing the same task in another browser.

If direct Dart code runs faster than JavaScript on Chrome, that's a nice bonus, but if it runs as well as similar code that was originally written in JavaScript on the other browsers (when the Dart code is compiled to JS) that's good enough. Dart on the other browsers isn't competing with Dart on Chrome, it is competing with JavaScript on the other browsers and that's how it should be measured.

And if it turns out apps in Dart on Chrome really blow away apps in JavaScript on other browsers to the point where both devs and users start embracing Chrome even more for these gains then hopefully that will light a fire under everyone else to either adopt Dart or do something to fix what would then be an undeniable problem of JavaScript.

I think you have missed the context of his remarks; perhaps I should have pasted more from the original post. You seem to be talking about "what is necessary for Dart to be a viable Web content language", while (I believe) Brendan is talking about "what are the consequences if Dart becomes a viable Web content language".

If the Dart → JS compiler produces "good enough" results, and web authors wind up adopting it en masse, then suddenly a chunk of the web "works best in Google Chrome", and every other browser manufacturer is put into a very, very awkward position. They can do nothing, in which case their continued relevance depends on Google continuing to ship the Dart → JS compiler (and diminishes as users switch to Chrome). They can license the Dart VM from Google, in which case their continued relevance depends on Google continuing to license the VM and we have another large chunk of the Web based on a single binary monoculture (which worked so well for Flash!). Or, they can try to develop their own Dart VM, in which case they'll be eternally chasing the tail-lights of Google's VM, kept behind by Google's head-start and Google's engineering power. None of those options is very pleasant, in the long run, for anybody who doesn't own Google stock.

As Brendan's original comment points out, this choice is not unique to Dart. Currently browser makers have picked option 3 ("write our own") to deal with V8, option 2 ("licence Google's implementation") to deal with WebM, and so far option 1 ("ignore it") to deal with SPDY.

Under the carefully-managed tension of ECMA, the ECMAScript standard has become a much more practical language to develop in directly, and to target from higher-level languages — and with the agreement of all the major browser vendors including Google. It's not immediately obvious that a project like Dart is even needed; even if it is a major technical advance, it's a political regression.

I understand the context and still disagree. If Dart is so much better than JavaScript on Chrome and if its Dart->JS engine does a good enough job of creating usable JS on other browsers that developers are willing to commit to using it to write apps then, well, that's too bad for everyone else, isn't it?

Why should Google put the brakes on improving client side development just because it puts other browsers in the uncomfortable position of having to license Dart (for free, since it is OSS and has a liberal patent grant)?

The same would be true if Microsoft created some sort of .NET->JS compiler with their own VM for IE, or if Mozilla did the same with some new language. As long as they bridge to JavaScript, more power to them. Client side web development could certainly use some of the tools that these different language environments could offer and if it kicks off another performance race to get browser-side languages even faster (especially on mobile devices), so much the better for everyone.

I really don't see how there is any downside (to anyone but maybe Brendan Eich) to widespread usage of Dart unless the Dart->JS code proves to be suboptimal, but in that case devs won't use it.

When I first got onto the Internet, nearly every page I came across had a little image at the bottom saying "Best Viewed in Netscape Navigator". Since I was using Netscape, everything worked fine and I didn't care. Some time later, I began to see images saying "Best viewed in Internet Explorer". Everything still worked fine, so I still didn't care... but as time went on, more of those images popped up, and the pages they appeared on began to look much, much scrappier in Netscape than they did in Explorer. While most of them still worked, more or less, Explorer made a noticeable improvement.

So, three cheers to Explorer for defeating Netscape and improving client-side development for everybody, right? Find a web-developer who still has to work with IE6 and ask them what they think.

Right now, Dart is freely-licensed and available to everybody, but who can contribute to it? Who will be allowed to veto compatibility-breaking changes? What happens if Apple announces some new hardware platform, and then Google coincidentally decides that supporting that platform in the Dart VM is no longer a priority, refuses to accept patches for it, and later refactorings happen to make it very difficult to maintain outside the official tree? What if the Dart VM becomes strategically important like Android, and current releases are only available to approved partners?

Sure, it's very unlikely that all those things would happen, and fairly unlikely that even one of them would: up until now, Google has stuck pretty close to the "do no evil" thing. But if we stick with openly, collaboratively created technologies, those things are impossible, and "impossible" is better than "unlikely" in my book.

If Dart were some kind of server-side thing Google wanted to use to increase the responsiveness of their sites, or something else internal to their systems, I wouldn't care — they're allowed to do whatever they want in the privacy of their own servers. It's only because the value proposition of Dart is "give Google an inherent advantage of control over the Web, and in exchange you will get shiny things" that I'm concerned. There'll always be more shiny things, but (so far) there's only one Web.

"So, three cheers to Explorer for defeating Netscape and improving client-side development for everybody, right"

Abso-friggin-lutely! You should be thanking Microsoft and Internet Explorer for upping everyone's game. They're the ones who introduced XmlHttpRequest. You knoww, "ajax"?

It's their browser and they can do what they want with it. If you don't like it, don't use it. If everyone else likes it though, tough luck for you. Go build your own browser and language and drum up your own support for it. All of this political correctness is a bunch of bull.

Must some historical fact or pattern of facts be "all good" or "all bad"? Grow up!

Microsoft added XHR to IE when they gave Java the boot in a spat with Sun, in order to keep Outlook Web Express in working order in IE. Was that "all good"? Clearly not for Sun or Java!

The browser wars phase I had no winners. Yes, IE's DHTML innovations such as innerHTML were a win, and Netscape should have agreed to implement and standardize them. No, the long IE6 stagnation and legacy were Not Good.

Wow, really? Grow up? Nobody said it was all good for everyone. I made a counter-point that was clearly as balanced as the original point.

Anyway, it really depends on your point of view. Personally I love the IE6 stagnation and other failures that affect the web such as the epic lameness of Javascript. Why? I think the whole platform sucks and I'm glad to see it fail and push people to build better solutions.

"Abso-friggen-lutely" on top of "three cheers" lacks qualification about the thing you cheered being less than good for anyone. You were abso-friggen-lutist.

Anyway, the open web standards are not failing. Dart is not a clearly better solution. I get your point about XHR, but do try to take mine about the whole history being a mixed bag, including what IE did. We can do better.

georgemcbay basically said [why shouldn't Google do what they want with their browser?], to which thristian replies [because...Microsoft]. I think that's a bullshit argument, especially since there's nothing about Dart that threatens to take away anyone's freedom to continue using Javascript or whatever else comes along.

I gave a bullshit reply to make a point; let's call it hyperbole. Of course I know that it was a mixed bag for everyone. Some good things did come out of it though, IE6 is almost gone and those good things are still here (and they've evolved). Evolution is slow and life itself IS indeed a mixed bag. Business is WAR!!

Anyway, I love, love, LOVE the fact that people are working on giving us lowly blub programmers a choice. :)

EDIT: Didn't realize who I was talking to, so let me be really clear that I have a LOVE/HATE relationship with all things in tech, including Javascript!

I have mixed feelings about JS and most software, but moreso JS than, e.g., Unix (BSD kernel code in the late '80s, not to date myself too much).

People seem to think I have some big ego investment in JS, but it's this thing I did in a hurry, but with a purpose that caught on when the web was young and growing fast. JS is not done, yet it will be hard to replace.

JS is easier to extend than some here claim (and as my recent comments have noted, not all the parties on the record asserting that it's hard to "fix" are truly giving it their best effort). As with most web standards, you can't remove stuff predictably, but new and more winning extensions can help retire worse old forms.

Business may be WAR but the modern browser era is marked by claims of peace and openness and standards conformance. So while Dart, and (I joke; I hope this doesn't happen) matching novelties from Apple ("Flechette") and Microsoft ("Javelin"), will take some attention off the standards, the forces operating in favor of standards will probably manage to keep JS evolving.

I actually miss some of the Googlers who have worked in TC39, or around the edges, but who are now full time on Dart or other projects. It seems like a lost opportunity to me, but it's Google's call.

The alternative to google developing Dart isn't doing nothing, but throwing more resources behind javascript.

I think you are missing some of the context of Eich's comments. The very same leaked memo declared that Dart was developed b/c js could not be evolved into a suitable language. Obviously Eich thinks it can, but more to the point he's working on the committee that is responsible for guiding such evolution -- the same committee that google plays a major role in.

So the particular claim he's laying out is this: Google throwing resources behind Dart is worse for the web than Google truly committing to an evolved javascript.

You might agree or disagree with this claim, but your arguments so far have been tangential to it.

If JS can be evolved, why has it taken over a decade, and still nothing much of substance? I think Javascript is much like Java, it is too hampered by concerns of remaining compatible with existing legacy semantics. Whenever you see a language where the only thing they can add is "syntactic sugar" it means they are unwilling to consider functionality that would break the underlying legacy VM assumptions, and that means, ultimately, their evolution is "boxed in" by these concerns.

Java basically is at a dead end because changing the JVM is hard.

Such ignorance. Willful? You seem new around here, and you are not using your real name. If only we were on Google+ :-/.

The long stagnation from ES3 (1999) to ES5 (2009) had everything to do with Microsoft abusing its browser-tying OS monopoly to stagnate the web by disbanding the IE team after IE6. This was prosecuted in U.S. v. Microsoft. How old are you, to never learn or else to forget this?

When I brought Mozilla back to Ecma in 2004 as we were launching Firefox 1.0, the JS standards group within TC39 was fooling around with E4X. Only one MSFT and one ex-BEA (ex-MSFT before that by way of Crossgain) guy were doing the spec work, and IE was not ever going to implement E4X.

We had to restart browser competition to get the various parties (Apple and Opera too) back in the room and working productively on the core language.

Now, we have ES5 done and ES6 under way. ES5 had new semantics, ES6 has more along with syntax, chiefly the module system (a second class system to facilitate prefetching, along with a loader API for when you need to be dynamic).

This is all documented on http://wiki.ecmascript.org/.

So your trollish commentary notwithstanding, ES5 is done and shipping in the latest browsers (finally complete in IE10 previews), and ES6 is being drafted and pieces are being prototyped in SpiderMonkey and V8.

I'm the last person to defend Java, but the JVM deserves a word here: it has finally evolved a bit, and it is fairly thriving on the server side with Scala, Clojure, and other languages.

Java's stagnation was due to Sun's miscalculations and mismanagement over the years.

You accuse me of trollish behavior, yet resort to personal slights, asking how old I am? Irony. Did I ever question your age or intent? I am fully aware of Microsoft's behavior, but that still doesn't address the fundamental issue that language evolution within spec committees is painfully slow and the competing interests waterdown proposals. It happened to C++ and to Java too. It happens in our government as well, we often don't get what's best or right, only what you've got the votes for.

The issue is whether or not any large changes can be pushed through in a timely manner, if the need arises. I've seen, over several threads, you seem to simultaneously stress the idea that Javascript performance is good enough (vs native), a Dart VM performing better than JS is a problem, and that whatever performance problems there are, they'll be resolved by better JS VMs. Not only are those hard to reconcile, but it requires a great leap of faith to believe that they will, because we've heard it all before. We've heard the same arguments about Smalltalk performance, about Self performance, and of course, the JVM, that the performance differentials will be tackled.

As for the language ecosystem on the server, yes, it's wonderful, but happened in spite of the JVM, not because of any evolution in it. The fact remains, Java changes were often evaluated towards remaining binary compatible with existing bytecode (e.g. erasure vs reification) and that caused the vote down of language proposals. (the same problem did not occur in C#/CLR)

My question is, when can I write a mobile web app using Javascript, that performs as delightful, in startup time, in runtime performance, in lack of janky-ness, for a mobile device, that doesn't burn battery or memory? Are you promising that evolved JS is going to fix this issue?

We agree on Java the language being mismanaged. Especially in comparison to C# (see a recent InfoQ interview with Neil Gafter). But the JVM is in better shape.

I despair of your reading comprehension, though, when it comes to what I have written about the leaked memo's Dash strategy. I never wrote that JS can be as fast at Dart-to-JS code as a native Dart VM could be. Not ever -- quite the reverse.

Now if we on TC39 had the benefit of Google's Dart expert input any time in the last year, we could have possibly worked harder on guards (optional type annotations), branding (aka trademarking, nominal types for use with guards), bignums, classes, or other proposals that have suffered in comparison to those that clearly made it into ES6. FYI, these were all strawman-status on http://wiki.ecmascript.org over the last year or so.

Some Googlers on TC39 did work on a few of these, in most cases too late for our agreed-upon ES6 proposal cut-off date. We did hear a dire warning from one Google rep in May 2010 that if two of these proposals were not promoted to Harmony status, JS "would be replaced!"

So your complaints about the ECMA standard not progressing fast enough come with ill grace from a google employee. Google has a lot of power and it has not discharged it responsibly, in my view. ES6 would be a better Dart-to-JS target language, including draft specs and prototypes in V8, if it had made a concerted effort.

Contrast this with Mark Miller (Google) and Tom Van Cutsem working in the open, and very effectively, on ES6 proxies, already prototyped in SpiderMonkey and V8. Or the module system designed by Dave Herman and Sam Tobin-Hochstadt in the open, which you overlooked.

Talk about self-fulfilling prophecy! In this case, you are not even predicting the future, you're misstating the past.

I think if it wants to be taken seriously as a good force in advancement of the web, google does have to be aboveboard with its involvement in TC39 and put in significant effort there. Maybe they really should have put in more effort to pushing strawmen through (I wasn't paying enough attention a year ago to comment on that).

But are you suggesting that particular people at google should have been (forced to be?) more involved in TC39 efforts? I don't think you can force that (and someone like Lars Bak would probably just leave if he didn't want to do it). There are lots of language experts out there that are working on their pet compiler instead of helping with the next coffeescript variant. That's not an evil, it's just a missed opportunity (and the reality of trying to get good people involved with a standards process).

I think that your better argument is that an open Dart repository from the start could have fed ideas back into TC39 process, but the problems you mention didn't suffer from lack of knowledge about them, just champions for strawman solutions. That is, again, not a job that most relish.

> We did hear a dire warning from one Google rep in May 2010 that if two of these proposals were not promoted to Harmony status, JS "would be replaced!"

"Unnamed sources at Google suggest gmail actually runs on the blood of orphans, kittens." What are you, a Techcrunch guest columnist? Give a name or don't bring it up.

Does it matter who said that? I don't think so.

You seem scandalized by the idea that an employer might force employees to work on standards (or anything else per typical work-for-hire contracts).

That is not unusual. It's dog-bites-man.

What's going on is unusual, in my experience.

Google is forcing people it employs off of tc39 work. I will not say whom, since I was told in confidence. Three people at least. This casts a different light on the Dash memo's serve-two-masters glibness, and on Alex Russell's recent blog post.

Am I promising you a pony? No, but then you are not a three-year old. I am simply working every day to advance the open web, including JS, including on mobile devices. What are you doing, besides asserting falsehoods about the JS standard and its leading implementations?

This is what this conversation is starting to sound like: http://www.youtube.com/watch?v=tOrI6uqS-vk

More than syntactic sugar is being added, for instance:


I'm super familiar with type arrays (I helped port GwtQuake which was one of the first apps to ever use them in large measure), but type arrays are an add-on API that doesn't change language semantics. Something that would change language semantics would be to offer early-bound namespaces. Early-binding would increase performance while simplifying VM implementation and make tooling easier.

Modules, which are statically bound, are part of ES Harmony [1]. Please stop spreading falsehoods.

[1]: http://wiki.ecmascript.org/doku.php?id=harmony:modules

Sorry, I'm out of date, when ES4 was terminated, John Resig said this: "Some ECMAScript 4 proposals have been deemed unsound for the Web, and are off the table for good: packages, namespaces and early binding. This conclusion is key to Harmony."

Is static scoping the same as early binding? For example, it is guaranteed that any class layouts within the module are statically frozen and cannot be altered at runtime? If you can add or remove methods from a class within a module, it's not really early binding, and this inhibits it's usefulness in a refactor or an IDE trying to do accurate usage search or code assist.

Exports from Harmony modules are frozen and cannot be changed at runtime. Classes are too if you use Object.freeze().

The points you're using to substantiate your argument are not really in line with the facts. Many browsers broadly share a single implementation for huge chunks of the web. Examples off the top of my head include NSS, WebGL, LibPNG, LibJPEG, and WebM. And it's inaccurate to claim WebM is "licensed" from Google; that's no more true than claiming that NSS is "licensed" from Mozilla. Both are open source projects accepting third-party contributions. People can happily use the code as is, contribute to changing it, or simply fork it off.

Finally, you seem to have missed the fact that Mozilla is already working on an experimentatl implementation of SPDY in Firefox: http://bitsup.blogspot.com/2011/09/spdy-what-i-like-about-yo...

Dart is OSS, so I geuss if it really got mass adoption, Firefox and IE could adopt it. Yes, this would lead to a single implementation, I'm not sure how I feel about this. On the one hand, it limits innovation from multiple implementations, on the other hand, incompatibilities between implementations, have been a big source of programmer headache in the first place. Flash was not bad in that respect and is one reason for it's success, despite its shortcomings. I mean, with Unix, most people are running a single implementation: Linux Kernel, and no one really cares about Open Solaris, or Darwin anymore.

Really though, Brendan has made the argument that Javascript is fixable and that it is a good target for higher level languages, and I don't really agree with either of them.

The changes I see being planned for ES.next don't really address some of the fundamental problems with JS, like network transport, or startup costs because of legacy constraints of not wanting to break existing JS. On mobile devices, loading a lot of Javascript is expensive, and I don't see anything in ES.next to bring it anywhere near competitive with native. If mobile is the future and the predominant way we consume the web, then we are at big risk of being dominated by native. Can we afford to wait years more for a promised fix that isn't even in sight?

For a mobile device, ideally you'd want a dynamic language that could be atleast partially statically optimized for a particular device platform, and transmitted in a highly compact format that is cheap to parse and execute on a mobile VM to not make the device waste bandwidth or precious battery performing tasks that could be done on the server for it (like executing a parse and eval)

Likewise, I don't agree that JS is an ideal intermediate format for higher level languages to compile to. I'm not saying LLVM or JVM bytecode are either, but if your HLL contains numerics like 64-bit ints or longs, for example, it's pretty crappy to translate. There's also double costs here: You're running a HLL compiler to parse, compile, and optimize one language, which then must be parsed, evaled, and optimized a second time on your target CPU.

Something like DVM, or a bytecode specifically designed for JS would be better I think.

There's a difference between open-source software and an open-source project. For example, compare the PostgreSQL and MySQL databases. Both are released under an open licence, but PostgreSQL is developed openly on a mailing-list and anyone can step up and contribute, while MySQL is developed privately by an organisation, with occasional source releases. No single entity has a majority control of PostgreSQL, but Oracle has a pretty firm grasp of MySQL.

Likewise, even though Dart is supplied under an open licence, it remains to be seen whether it's operated more like PostgreSQL or more like MySQL. As I understand it, the V8 project is somewhere between the two, and Android is way up the MySQL end of the spectrum. Based on what Brendan has said, I doubt Mozilla would want such a large part of their platform based on a black box they can't control, and I can't really imagine Microsoft doing it.

I don't think your Unix example is quite fair; the number of Unix systems on the planet is orders of magnitude smaller than the number of web-connected system. Even so, there's still a lot of people working with Darwin in the guise of iOS and OS X, and there's a decent number of computers running non-Unix-based operating systems too.

I'll confess I'm not too familiar with the exact changes planned for ES.next, I just recall Brendan saying that improving JS as a primary language and as a compilation target were major goals in the ECMAScript committee. Maybe it's not there yet, but it can get there faster than it will take to add performant Dart VMs to every browser.

Brendan talks about the specific issue of a standardised bytecode here: http://news.ycombinator.com/item?id=1905291 (as part of an entire thread on the topic)

"I mean, with Unix, most people are running a single implementation: Linux Kernel, and no one really cares about Open Solaris, or Darwin anymore."

Nobody cares about Darwin? Really? I mean, in terms of hacking the kernel, sure, but tons of people are running Darwin. The POSIX standard is more important than ever.

"On mobile devices, loading a lot of Javascript is expensive"

I keep seeing this assertion that bytecode would be smaller than gzipped, minified JavaScript source. I'm actually somewhat skeptical. Has anyone actually tested this?

"could be atleast partially statically optimized for a particular device platform"

I don't want this at all. That's too close to ActiveX for comfort.

"wasting precious battery performing tasks that could be done on the server for it (like executing a parse and eval)"

You realize that Java requires a nontrivial bytecode verifier too, right? IIRC the bytecode verifier, and certainly the compiler, require abstract interpretation to convert the stack-oriented bytecode to a virtual register-based one.

Who said anything about Java bytecode? Java bytecode != bytecode.

"I don't want this at all. That's too close to ActiveX for comfort."

It has nothing to do with ActiveX. It has everything to do with dead-stripping code and targeting particular browsers the way GWT and Closure Compiler do today.

In particular, Javascript VMs today always parse JS even if it's already been cached, hasn't changed, and is loaded from the cache. They must also retain the original source as well as the parsed AST representations due to other semantics (toString()), which wastes gobs of memory on memory constrained devices.

As for size, I believe there's a Microsoft paper floating around somewhere where they use a custom tokenized AST byte code format to achieve significant wire savings.

The reality is, Java on Android already starts up faster than Android and runs faster than JS, so there is ample evidence that JS is underperforming other environments, meanwhile, Android APKs are not any bigger than comparable JS apps from my anecdotal observations.

"They must also retain the original source as well as the parsed AST representations due to other semantics (toString()), which wastes gobs of memory on memory constrained devices."

Wrong. SpiderMonkey doesn't. It retains the bytecode only, throws away the original source, and uses a decompiler when toString() is used. V8 saves the original source, but that's its problem :)

I don't know about GWT, but in my experience closure compiler does not produce different output for different browsers (though it does strip dead code).

It has the ability, but doesn't not part of the default IIRC unlike GWT which is built around permutations. GMail I think varies permutations. However, there are sound reasons for wanting to do so besides differing DOM capabilities, namely, that different JS VMs have different performance characteristics and what may be an optimal pattern for one, isn't for another.

"You realize that Java requires a nontrivial bytecode verifier too, right? IIRC the bytecode verifier, and certainly the compiler, require abstract interpretation to convert the stack-oriented bytecode to a virtual register-based one."

It seems like you are talking about Dalvik VM (Android). Java class files (stack bytecode) are actually converted to Dakvik's register bytecode ahead of time. (Before installation on the mobile device.) I'm unsure if Dalvik bytecode is verified or not.

No, I'm talking about the verifier [1]. In particular: "There are no operand stack overflows or underflows." That requires abstract interpretation.

And every performant Java interpreter is required to convert the stack machine to vregs in order to perform register allocation. That requires abstract interpretation too.

[1]: http://java.sun.com/docs/white/langenv/Security.doc3.html

Sure, but I'd be willing to bet that performance impact of the the verifier is insignificant for all but the most trivial of programs.

That statement came with no benchmarks or numbers, no knowledge of the Dart VM and it's relative performance to V8, and no knowledge of the Dart to JS compiler and what kinds of optimizations it does.

If you run Google's closure compiler on JS, for example, in some cases, it produces a very significant speedup than hand-tuned hand-written JS, so saying "never be decent" is a pretty strong claim to make.

The key part is (...) compared to having the Dart VM in the browser.

It seems pretty obvious to me that unless Google fucks up the VM implementation, it'll always be much faster than compiling to JS, which doesn't even implement the same concepts - let alone semantics - of Dart. In fact, if VM is not much faster, why would they have it at all?

Being faster than handwritten JS is irrelevant, because the VM will be faster still, and that's the difference he's talking about.

Browsers already have a wide performance differential. What's the ratio between V8 and IE6? Or between desktop and mobile? As long as the performance isn't pathologically bad, it won't matter. Dart apps will start up quicker and run a percentage faster. Maybe perform much better on mobile. A decent win, but doesn't really change the fragmentation equation much from what it already is.

The keyword Brendan used was "decent", and frankly, I'll take a stab and say performance of Dart to JS will be beyond decent.

I specifically referred to new number types. Dart has bignums (int). See https://twitter.com/#!/maccman/status/123400799756881920 for a clue.

Dart-to-JS can't be faster than hand-coded JS if it does not use bignums. If it does use bignums that do not fit in 32-bit ints, then Dart-to-JS will be slower than a native VM with built-in bignum support.

IE6 is irrelevant. The topic is modern browser with native Dart VM vs. without.

What do you mean Dart-to-JS can't be faster than hand-code JS? That's like saying C can't be faster than hand-coded assembly. Unless you write unmaintainable code or spend efforts counting cycles and scheduling and pipeline harzards, this usually isn't the case, and is not the way most people write large application (all in asm). If you take your average hand-written Javascript and run it through closure compiler, in many cases, it ends up executing faster (at least in V8). If you haven't already, I would recommend investigating the behavior of JS VMs with and without Closure Compiler, you might be surprised.

We're talking averages here, not pathological edge cases. Java has a 64-bit long type which JS doesn't support. GWT supports longs. In theory, GWT code should run slower, in practice, because GWT contains an optimizer, it runs as well, or faster, than hand written JS, simply because very few code bases have hot paths dependent on long arithmetic. For example, I've actually ported popular JS benchmarks to Java, ran them through GWT, and the result was faster.

Sure, would you be able to concoct applications for which Dart and Dart-to-JS have a large divergence? Yes. Will they be the common case? Probably not. I can concoct normal JS applications today which show high divergence between Chrome, Firefox, and IE, because of all of the JS VMs have different weaknesses, different optimizers, different garbage collectors. If you're writing applications that are so CPU bound and performance critical (e.g. games), chances are you're going to run into other portability problems too.

Most of this worry over runtime performance I think is a red herring. The real difference will probably be in startup time.

"That's like saying C can't be faster than hand-coded assembly"

Don't change the subject. The topic is not productivity as you seem to imply here. Also, JS engines are not hard to track super-scalar CPUs. A compiler can target one JS VM (e.g., V8) but then you're locked in. All the current JS VMs have peculiar optimization faults, some worse than others, many completely disjoint across VMs. No one has a compiler targeting each to best effect.

Hand-coders can do well in general against current JS trans-compilers, but that wasn't my point.

The point is that if you actually need bignums, a JS emulation will be slower than a native Dart VM built-in bignum implementation.

"Most of this worry over runtime performance I think is a red herring."

The "worry" (such as it is, or was) was over Google's politics, not its Dart-to-JS compiler's generated code performance in isolation. Pushing a native Dart VM into Chrome, rewriting major Google apps to use Dart, then seeing if that creates market pressure for native Dart support in other browsers, was all suggested or even explicitly called out in the leaked memo. That was the "worry".

But it sounds like a native Dart VM in Chrome won't be immediately released, and the Google web apps written in JS or Closure won't be rewritten quickly. I don't know. Maybe you do -- do you work for Google?

What percentage of apps do you think bignum performance will matter? Even in cases where it might matter (cryptography), you would be better suited using GPGPU code, or adding cryptographic APIs to the browser itself rather than insisting it be done in JS. Indeed, you could always fallback to that for browsers with poor bignum performance.

GWT has supported Java's BigInteger/BigDecember, and it's never been an issue.

(For the record, since it is no secret by searching my handle, I work for Google, but I do not work on Dart. I specifically work on the GWT compiler, and do not speak for the Dart team nor represent their views, nor am I really representing anything, but my own biases here given my experience with trying to develop high performance Javascript games both in the browser and mobile)

If bignum performance doesn't matter, then Dart-to-JS code is generally no faster than other JS code. Duh!

If, as the leaked memo asserted, JS's lack of more than one number type is "unfixable", and we now see that Dart's fix is to add bignum as well as double, then bignum must matter. Else why do bignums in Dart?

This ignores the live bignum strawman on the ecmascript.org wiki, which Googlers on tc39 failed to champion.

If your argument is that bignum literal and operator syntax, not bignum performance, are what matters, I am with you -- but then why did no Google rep on tc39 work to advance the bignum strawman?

You can't have it both ways. It looks like some Google heavy hitters focused only on Dart as if it has a native VM, and not on Dart as a source language for JS, which implies certain obvious extensions to the ES standard.

And in any case I seem to recall being assured by Mozilla that we don't need no Native Client because Javascript is going to be fast enough for everything. Even pre-existing non-JS code could just be compiled to mighty JavaScript, the Assembler of The Web™ and all would be well. But now Dart is unacceptable because Dart-to-JS won't be close enough to the performance of native Dart?

Go back to the other thread and re-read the argument there (or go back to school and learn how to argue). No one said Dart-to-JS by itself was bad for anything.

The leaked memo spoke of a native Dart VM in Chrome and Chrome-first Dart as primary source web app authoring by Google. The clear intent was to pressure other browsers to adopt the native VM.

Google can act like Microsoft (but with less market share) if it so chooses. Just spare us the open-washing hypocrisy, and don't expect productive multi-vendor standardization. Instead, expect a new browser cold war -- no one wins.

You appear to have misunderstood.

On one occasion Mozilla has argued that the speed difference between a) non-JS code running natively and b) the same code rewritten in, or even compiled to, JS is (or soon will be) too small to be important. Now on this occasion Mozilla is arguing that the speed difference between a) native-VM Dart and b) Dart-to-JS is (and will remain) large enough to be important. I pointed out that these two claims are hard to reconcile. About the only way they can both be mostly-true is if the performance gap only happens to be large and important enough on exactly those occasions when that gap happens to bite Mozilla in its platform strategy. Not very likely, unless one assumes that the performance needs of the poor sods who just want to use the web (as publishers or consumers) are never all that important.

So the fact that Mozilla's problems with the relatively poor performance of Dart-to-JS would be solved if native-VM Dart went away has little relevance, because most other people's problems with the speed of JS are not helped by making there be no alternative to JS.

> or go back to school and learn how to argue


so let me get this right: you are arguing that a problem with Dart is that other browser makers won't get on board, and you happen to be CTO of one of those browser makers?

That seems a rather circular reason for dismissing it.

No browser vendor will give a free lunch to a competitor, at high opportunity cost, by locking themselves into a brand-new and 2nd scripting engine. No one. Steve Jobs' ghost will haunt anyone who tries.

It doesn't matter how "good" Dart is.

re: brand new: fine, wait until it isn't brand new

re: lock in: I'd think Mozilla isn't really locked in as long as there is a cross-compiler. If you decide the the code bloat isn't worth the speed improvement (for the sites that run dart code), yank the VM and no harm done

re: opportunity cost: well the code from Google can be dropped in, unless you really feel the need to rewrite your own version.

re: "free lunch to a competitor": it sounds like if there is is potential for another "browser war", it's coming from that sort of attitude. In fact, that sounds counter to the whole concept of open source.

re: "It doesn't matter how good Dart is.": well, that's a shame. I'd like to think merit counted for something.

Overall, maybe I don't know your world and the politics etc, but it just sounds like a lot of "not invented here" syndrome to me. And I say this as someone who genuinely admires your work and really likes Javascript (and am especially pleased that Dart looks enough like Javascript to be comfortable to me).

You seem new to software. Every addition costs. The 2nd scripting engine in particular. Mozilla went through this to no avail with CPython several years ago. I paid Mark Hammond to do the integration work. It was a constant source of bugs and overhead, and without CPython distribution on Windows, and sane versioning on Mac and Linux, no one used the non-JS code paths save ActiveState in Komodo.

WebKit is supporting Python bindings but that language is 3rd after Objective-C and Apple pays the big Obj-C costs.

My comment about Dart's merits was purely a businessman's evaluation, not NIH. Before you throw that accusation my way, consider Mozilla using Google WebM code, and lately implementing SPDY.

You expect other competing browsers to give Google a strategic free lunch, and to give up their share of influence in standards bodies? No way, not from us, or from Apple or Microsoft or Opera.

But it turns out Dart does not have obvious merit, such that I am moved to implement it (see SPDY for a counter-example). Dart is jejune, knee-jerk, and conservative in its design, from what I have now seen.

I have no doubt that there would be a cost associated with hooking in Google's code. And I'll take you at your word that it's not NIH, even though a casual reader might guess that you might be a bit more personally invested in Javascript than you'd be in the various things that, say, WebM seeks to replace.

Regardless, I'll leave your words to speak for themselves without further debating. I'll admit I'm a tad disappointed at the level of defensiveness and name calling (of both your competition and of those you debate with), though.

You had better put up or shut up. I did not call anyone names. Cite my words if you can.

As for defensiveness, that looks like your department.

Well, uh, I guess if you put it that way, I sure better....

Whether you want to debate whether the term "name calling" is accurate or not, I would suggest that the following fall astray of Hacker New's guidelines of "the principle here is not to say anything you wouldn't say face to face". Then again, I don't know.....maybe you are that way in person too.

"Grow up!"

"Such ignorance. Willful? You seem new around here, and you are not using your real name"

"How old are you, to never learn or else to forget this?"

"So your trollish commentary notwithstanding"

"I despair of your reading comprehension"

"Am I promising you a pony? No, but then you are not a three-year old."

"(or go back to school and learn how to argue)"

"Dart is jejune, knee-jerk, "

and of course:

"You had better put up or shut up"

Really? It seems you're quite a prominent figure to need to resort to that sort of schoolyard talk, but do as you wish. I'm not going to be baited anymore.

Thanks for javascript, though.

Name-calling means calling a person a name. If I say "Joe is an idiot", I have called Joe a name.

If, on the other hand, I call someone's behavior or rhetoric out, then that person has room to back up. We all make mistakes -- definitely me included.

Your previous comment accused me of NIH without evidence. I talk back to that kind of crap. I'm not baiting you. Let us take each other at our word.

For what its worth, I felt really awkward reading many of your replies in this thread. You are our spokesperson for JavaScript and the CTO of Mozilla. It would be nice if you could talk to people without making disparaging and downright condescending remarks.

I look up to you to speak for the community and to use judgement and character. Anyways, maybe I'm just being too sensitive, but I figured I'd say something.

I take your comment to heart. Sometimes I bite back too hard.

To all those here to whom I've made "grow up!" and similar remarks, my sincere apologies.

Much appreciated. =)

I've played with it today and the joy I admittedly feel was quite similar to what I felt when coding LISP. However, I only coded LISP in academia and would not feel comfortable at all using it in a live environment.

For now, I see DART as a proof of concept kind of thing and it definitely should /not/ gain widespread support any time soon. No matter how much money Google will throw at it.

I don't think any browser manufacturer would have an issue with Dart if it were only a Dart-to-JS compiler. Nobody had issues with GWT or CoffeeScript, after all.

> In fact, if VM is not much faster, why would they have it at all?

Google hasn't made dart so we can make our web apps faster. They made dart because there's a lot of java developers at google who believe that its easier to write monolithic javascript applications (GMail, G+, etc) using a language like java.

They believe it enough that they will try to convince others to follow suit.

No, I was asking "why would they have [the VM] at all?"

If the VM wasn't (much) faster than the Dart-to-JS compiler, there would make no sense to have both.

What Brendan is missing is that the contest is not closed between JavaScript and Dart. The elephant in the room is the huge and growing mobile space where ObjectiveC and Java rule. It's not about "Works only in Chrome", it's about "Works only on iOS/Android".

What you are missing is the bleeding obvious: the topic of that other thread where I commented was Google's leaked memo about Dart as "replacement" for JS -- that memo created "the contest".

Obj-C and Java are not browser-supported. Sure, there's a native apps vs. web apps contest. Native is winning? Not according to Fred Wilson (AVC) and other observers.

Who knows, really. We're speculating, but let's find out by doing. Mozilla is working on both Open Web Apps that run in modern browsers, and Boot To Gecko.

With all due respect to the awesome work Mozilla is doing, I'm not seeing in your response anything about mobile-native-jshtml5 platform. Funny enough, Microsoft is currently promoting jshtml5 as a platform harder than Mozilla is, and given their platform unification message, that ought to include the mobile/tablet space as well.

Edit. I'll have to retract the above. BootToGecko is the mobile platform from Mozilla. It would be awesome to market it harder as such.

Thanks for the retraction, and you're right: we are not going head-on against "mobile-native-jshtml5" (new one on me, but I know what you mean). I'm talking about B2G at Web 2.0 Expo New York this week. We will work up our marketing as we get closer to first hardware product launch with our partners.

Edit: we are, however, trying not to make special sauce on top of the web standards. Instead we're working with W3C and WAC to standardize device APIs progressively as we go.

I don't speak for the team but I believe I can add some perspective.

Think of it this way: what is GWT? GWT os compiling Java, a statically typed language, into Javascript. If you've used GWT you'll know that particularly early on there was a lot of friction. What's simple in Javascript with anonymous objects and duck typing doesn't quite gel with Java so you've had to do things like use JSNI for edge cases.

Google has some incredibly large and ocmplex JS apps (eg GMail). While GMail isn't written in GWT, GWT is aimed at that kind of application with deferred binding and the benefits of static type analysis.

What if you took that expertise (of GWT and static type analysis in producing Javascript) to produce a language that could run on the server, run in the browser (for browsers that support that) and compile to Javascript (for browsers that don't)?

The last point is particular is key to driving adoption as no one is going to develop only for Chrome.

I see it as no surprise the syntax is Java-like. I fully expect sometime soon to see a JVM implementation that will then leverage all the existing Java libraries.

In that context (IMHO) it makes a lot more sense. It might not be solving the problems you're interested in but it is definitely solving a particular set of problems.

If Google produced an innovative replacement for JavaScript, the world would listen. Instead, based on what they have released so far and your comments, they have released a language that is primarily designed to enhance their own tool-chain, which the rest of the world doesn't use and isn't interested in. We don't use GWT. Apparently, we won't use Dart either.

they have released a language that is primarily designed to enhance their own tool-chain

You make this sound like its a bad thing, but that's open-source always and forever. Scratch your own itch.

This was advertised as a replacement for JavaScript. It turned out to be a replacement for GWT. False advertising. I'm wasting time reading specs and code samples and comments just to figure that out. I don't like being misled or wasting time.

I'm curious what you thought a JavaScript replacement would look like. Apparently you thought it /wouldn't/ look like GWT.

Python has a great, clean, compact and expressive syntax and a lot of syntactic sugar. Erlang does concurrency and error handling well. A mix of the two would be a great language to work with.

JavaScript - the ugly + OO + update to the standard library. That's it. Essentially what frameworks like MooTools try to make it into.

Ah. I think I was getting caught up in the idea that a "replacement" was something completely different and not an evolution change in JavaScript. But it's all just a matter of terminology at that point.

He's not saying it's immoral of Google or anything, just that it doesn't help the rest of the programming world.

A lot of people use GWT for large web applications instead of JS, precisely for the reasons Dart was created, we just don't go brag about it. The biggest problem with GWT was how slow the toolchain was, and this is adressed with Dart by having a native VM in Chrome.

Out of curiosity, do you know of any notable non-Google sites using GWT? I see a few here, though none seem to be particularly large web apps - that I can tell, at least.





Given that its supported by Sencha (ExtGWT), and Spring, and IntelliJ, you can probably guess that the vast majority of GWT users are in enterprise environments. :) AngryBirds uses GWT. You actually don't see many people writing very large Web apps outside of Google precisely because most organizations didn't have the resources to produce something like Closure or GWT. Duplicating GMail with no tooling using basic JS is quite a tall order.

Many new Google services these days use GWT, like Google Flights, Hotels, the new YouTube editor, Google Offers, etc. AdWords is written in GWT too and is quite large (millions of lines)

One of the problems Dart hopes to solve is to have a large codebase(apps easily into the millions of lines of code) that is toolable, and statically optimizable. Javascript is particularly poor at this.

The Closure Compiler was actually invented by the Google Mail and Calendar teams as a way to wrangle Javascript and tame it's suckier bits to enable sane development of large apps.

I've used GWT. It's no cure all, but it has its place and time. It's too early to judge Dart.

There's already a language that runs on the server, runs in the browser and compiles to Javascript. It's Javascript!

Actually there are many of these languages[1], including Coffeescript and Clojurescript.

You now even have options!

[1] https://github.com/jashkenas/coffee-script/wiki/List-of-lang...

IMHO, this is not a "break away" approach as originally indicated in the leaked memo.

One of the biggest pain point in web dev is the inconsistent DOM implementations. I was imagining some sort of DOM-less, HTML5 Canvas-based UI controls. And something about the "Web", Semantic Web/URIs or a new approach to programming on Web. This is NOT a break away language in any sense - its more re-packaging.

The original leaked memo that everyone was freaking out about was incredibly overblown as it was entirely decontextualized.

The engineer that wrote the memo needed people for his team. To get people to join a team from any of the others at Google, you need to convince them that your team is awesome to work with. At Google, you can't offer more money/benefits, so it has to be a "join us and you'll change the world!" message. That's going to lead to a lot of overblown statements that may or may not end up being true, and may or may not even be believed by the author.

Google is not in the business of doing things that are bad for the web (and when they have done, there's been an about-face, see: Google Video shutdown), even if internal machinations might make it seem that way.

I'll stress that it's early days for Dart. Go was announced in 2007 and only this year is going to a version 1.0.

I don't know what the timeline is for Dart but I will say this:

1. If anyone is capable of the long sort of time frame that something like this can benefit from--event requires--it's Google;

2. If there is anyone who's qualified as a domain expert in Javascript generation it is, by virtue of GWT, Google; and

3. If there is anyone who's qualified to speak to the limits of what you can do with Javascript it is, by virtue of Chrome and V8, Google.

If anything, I believe the error here (if you can call it that) is failing to properly set expectations and communicate the goals of the language (as witnessed by all the comments on this thread from people who were expecting something more and/or different).

Small correction: Go was announced in November 2009.

Thank god. I was starting to think I'm getting old if 4 years goes by that quick.

We are definitely trying to improve the DOM API with Dart, but, for performance reasons, ditching the DOM and starting over from scratch in Canvas doesn't really fly, at least not in the short term.

This is completely the wrong thing to do.

Google should be proposing a standard, open, byte-code compatible, Intermediate Language standard that can run Javascript and in the interim run on Javascript.

That is something I could see Mozilla and Apple getting behind.

Only once they have actively campaigned for this should they be adding new languages to the browser which fracture the web.

I had hoped that Dart would surprise us and turn out to be a 'machine-code for the web' implementation. This would have been a much smarter move, I believe.

+1000. Give us a platform that people can grow languages on! Maybe the DartVM could become something like what you describe in the same sense as the JVM/CLR is a platform for many languages now? But since their pushing the language it doesn't seem to be the stated goal... sad ;(

Oddly enough, if in-browser Java had "won", we'd already have such a thing.

True. But in return we would have had to endure 10 years of in-browser Java.

We would have just built something else on the JVM. You could be writing Ruby in the browser with JRuby, or Python in the browser with Jython, or Scala. This would be a much better world (tooling and performance-wise) than the current compile to high level JS strategy.

As opposed to 10 years of stagnant JavaScript, and a conversion en-masse of all all video, audio, game content to Flash??

It was really sad to see everybody moving to Flash JavaScript could've done video/audio and games a long time ago.

Not necessarily - in that case, we might still be stuck with the Sun-versus-MS and Sun-versus-the-world games over control of the JVM, and with the JVM's startup-time problem. Though the startup-time problem was so bad that it's hard to imagine in-browser Java winning with the problem still there.

> Google should be proposing a standard, open, byte-code compatible, Intermediate Language standard that can run Javascript and in the interim run on Javascript.

> That is something I could see Mozilla and Apple getting behind.

Why would you expect either Mozilla or Apple to get behind such a proposal? Apple has a powerful self-interest in making sure the Web remains a second-best app platform behind iOS and desktop OS X. Mozilla wants the Web to be the premier app platform - but it's no bloody good to Mozilla if the web is the world's #1 web platform but Mozilla has no control over it anymore. The last thing Mozilla wants to see is the Web browser become some fairly-easily-implemented, highly-interchangeable runtime platform adhering to a stable, open spec somewhere. This would, I think, be very good for the world at large, but it would undoubtedly be very bad for Mozilla - it's what is known as the commoditization of the platform. Mozilla's self-interest is served by keeping as much of the Web as possible controlled, in the minutest detail possible, by the hard-to-join club of major browser vendors. Right down to things like the lexical syntax of JavaScript. So in reality, as soon as Google proposed such an IL, Mozilla's advocates would start blowing smoke about "oh no, another Java".

"Mozilla" consists in part of a bunch of people working to write down standards precisely so new browser implementors can enter the market and interoperate. I've spent years at this for the JS standard. It's part of the inevitable commoditization you cite.

Also, going back to 2006 or so when I invited pre-Google Alex Russell and other JS hackers to Ecma TC39 meetings, Mozillans including yours truly have tried to open up the standards process. Mozilla, Opera, and Apple co-founded the WHATWG and set up an open membership structure for it in 2004, to create HTML5. W3C finally relented and internalized much of that structure.

So alleging that "Mozilla" is trying to keep the old boy's club closed is simply false.

I've cited hard, in some cases physical (as in physics) reasons for why there won't be a lower-level bytecode standard for browser-based VMs any time soon. I'm not blowing smoke.


A high level bytecode sounds a lot like minified JS source, with a relatively-few extensions to the standard language. Extending is easier than replacing or setting up a new, parallel cross-browser standard.

Your inflamed sense of grievance at "Mozilla" is misplaced. Mozilla has no control other than what users of our software delegate to us by trusting us enough to download and run our stuff. We do not have hundreds of millions in our browser advertising budgets. We do not have billions of revenue with which to influence people or pay for attention and distribution.

If we are really in the way of Web standards, I'll personally pull the plug.

At a technical level, virtual machines are not the panacea many folks seem to think.

Certainly, VM byte code languages are often simpler than silicon processors' machine languages; perhaps they offer safety guarantees; and perhaps they provide garbage collection. These are all big wins for language implementers targeting such VMs.

But what no virtual machine will ever do is make modules written in different source languages work together transparently. Any time one module calls another module written in a different language, at least one side of that boundary needs to be written with a detailed understanding of both languages' semantics.

Tiny details of the semantics influence the idioms people settle on in that language --- and interfaces are designed around those idioms. For example, JavaScript conditionals treat the empty array and the empty object as true, while Python conditionals treat them as false. Each of these facts shapes what people expect of a "natural" API in that language --- and that ensures that modules written in other languages will always "speak with an accent", or seem unnatural, at best.

You can define a common data world, as the .NET CLR does, and extend each source language to cover that world, but the effect is to change each participant language into a gloss on the common data world. This is why CoffeeScript fits seamlessly into the JavaScript world: JavaScript's and CoffeeScript's data worlds are exactly the same. CoffeeScript cannot deviate from JavaScript's types and objects.

Each programming language is like a city occupying an island: commerce within the city is much less expensive than commerce between islands. Although it's sometimes worth it, dealing with "foreigners" is confusing and risky. No VM will change that.

It seems to allow for more variation in languages. The only time you really need to worry about those other languages is when you're trying to load modules written in other languages. At least that's how it works in .net. You can have pretty significant semantics from language to language and as long as you don't care about other languages actually loading your modules then it doesn't matter. If you concede that the problems of the lang->il developer are essentially the same as the lang->lang developer, then shouldn't we evaluate the il option strictly on it's merits? Such as reduced compilation at runtime and smaller payloads over the wire? As well as, optimally, less quirks than a language like JS. Not to mention existing lang->il compilers would have much less effort to retarget their output to the new platform. It just seems like a huge win to add the vm layer as the base instead of a general purpose language in every way.

Oh, targeting a good VM is a huge win over a typical machine language for an implementer. My prediction is specifically that the inter-language paradise some expect will never come.

But even within the points you bring up, I'm not sure that VMs are as winning as they're made out to be. Size and compilation time aren't somehow intrinsically better for VMs; JS does quite well on both fronts these days. And I'm not convinced JS's quirks are harder for implementers to cope with than a silicon machine language's.

If this were our (Mozilla's) strategy, it's hard to understand why we'd release our code under an open source license, and why we'd insist on every standard we implement being freely implementable by anyone with the requisite chops.

Mozilla "conspires" to do almost exactly the opposite of what you suggest. Having lots of decent browsers available was our old success condition. Now the mobile world is starting to look locked up, so breaking that open to competition and free choice is our new success condition.

The last thing Mozilla wants to see is the Web browser become some fairly-easily-implemented, highly-interchangeable runtime platform adhering to a stable, open spec somewhere.

Really? I thought that was the _mission_ of Mozilla. Except for the "stable" part perhaps, because that's quite at odds with innovation.

The track record easily shows that pretty much every single thing you have said is wrong.

My hopes were high, but the more read about it, the more it started to look like Java:

    class Foo implements Comparable Observable Deniable ...
Why not have interfaces like in Go, where you just define a set of methods and all classes having the methods will automatically implement the interface.

Why not just Array and Hash? And what's up with the whole generics thing - that's just plain old Java.

Why do some types start with lowercase and some with uppercase letter. Why not use a sensible naming convention?

    square(n) => n + n;
    square(5); // returns 25
    square2(n) { n + n; }
    square2(5); // returns null
Why not have an implicit return value everywhere?

I could go just on and on...

There's only one set of Rob Pikes and Ken Thompsons on this planet :-/

Good news, maybe they won't try creating an other crappy language.

>int bool String Object Why do some types start with lowercase and some with uppercase letter. Why not use a sensible naming convention?

Primitives and objects, it kind of makes sense but I do see your point.

But the thing is, they are not primitives:

> Although you might expect int and double to be primitive types, they're actually interfaces that extend the num interface. This means that int and double variables are also nums.

That's actually kind of like Haskell.

Aaaarghhh! It is full of semicolons.

Is it really necessary in the 21st century to create a language that terminates lines with semicolons? I am sure I have seen some other languages in the past that get by just fine without them.

The language isn't done yet. Now is the time to let us know if you want semicolons to go away. I know some of us on the team do too, but public interest will help a lot.

Please make the language a nice target for other languages to compile to. Better yet, make a lower level bytecode language that Dart can compile down to as well as other languages.

For example value types would be excellent. Even better would be explicit regions, but I'm sure that's not going to happen.

Also, please fix this:

The type system is unsound, due to the covariance of generic types. This is a deliberate choice (and undoubtedly controversial). Experience has shown that sound type rules for generics fly in the face of programmer intuition. It is easy for tools to provide a sound type analysis if they choose, which may be useful for tasks like refactoring.

And add proper generics. If sound type rules fly in the face of programmer intuition, that means that the programmer's intuition is wrong. The proper response is to inform the programmer of his mistake at compile time, and not to silently ignore it and add dynamic type checks on every contravariant use of generics including array access! That is worse on both programmer productivity because the programmer expects that his program is type safe when he is using static types and on runtime speed because the dynamic checks slow down all programs needlessly. Dart already has dynamic typing; use that when you want it, not something that looks like static typing but really is dynamic typing.

Another thing that would be awesome is if you provide a compact binary format for code.

I'll give you my votes then:

- no braces where avoidable, no semicolons where avoidable

- release early a free, open source reference development environment that really helps in developing with Dart. The biggest pain with Javascript, imho, is in the lack of development tools really thought out for it, and not just an adaptation of Java/C/whatever other editors

  - if you develop said IDE as a web-IDE, even better (why not writte in dart itself?)

  - give as many inobtrusive visual cues as possible to easily see tab alignment, syntax coloring, etc.

  - integrate unit testing facilities in the IDE

I like everything you propose here. Dart is earlier in development than I think most people realize, and I really hope we can get to something like what you're listing. Definitely self-hosting and a self-hosted IDE would be on my love-to-have list. As a testing nerd, integrating testing would definitely be on it too.

A good development environment is something where you could really differentiate yourselves, and I guess you could very easily integrate introspection and analysis features into chrome to help with it.

I've been thinking for years that if I ever were to develop a new language, I would start from developer usability first - I think there is much more to innovate there than in the core language features, nowadays. Developer usability is tightly coupled with the development tools the developer can use, not just with abstract language features. And especially for web development, you can't think only about top of class developers.

As I'm at it, I'll write here my dream feature of any language and IDE - not knowing if it is really feasible, but it doesn't look really impossible to me. Use case:

- You run your unit tests

- An assertion fails/there is an error

- A debugger brings you to where the problem is

- You can step back from where you are, make changes on the fly to your code and the tests, and step forward to the assertion/error again.

I guess that with a VM, and excluding some operations that depend from external status and which are destructive, this could be possible, and it could allow an incredible speedup in development...

Certainly feasible: Smalltalk debuggers do this. And Smalltalkers (allegedly) use a workflow just like you describe.

Yup. I often do something like this:

  - write a test for a method that isn't there yet
  - run it, get a red bar, as expected
  - run it in debug mode, and get a debugger
  - write the method implementation in the debugger
  - possibly write other methods that the new method calls, also in the debugger
  - resume the program, get a green bar
Writing code in the debugger is great, because you've got all the runtime state right in front of you, and you can step through the code you're working on. I'd love, love, love to see this in Dart.

But, is it possible to step backwards from the current state of the VM, to execute a changed code?

I read about this, and even tried downloading squeak once, but didn't find it very compelling. I admit that I might not have given it the time it needed, though...

A few weeks ago I whipped up this 3-minute video showcasing a Smalltalk class browser, method finder, and debugger: http://vimeo.com/27850933

You raise a good point. I'd like to see more about testing Dart.

We have a rudimentary unit test framework [1] that we've been using for the samples, though we're still playing with different styles. Personally, I'm fond of the Jasmine-inspired stuff I tried to slap together here [2]. This is of course different from the testing infrastructure for the language itself, which is its own thing.

    [1] https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/#dart%2Fclient%2Ftesting%2Funittest
    [2] https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/client/tests/client/view/ViewTests.dart

Thanks! I will take a look at these.

In terms of a language, it looks like a horrible step back into the 90s. What we need is the language to be terse, and clean with lots of built-in functional utilities for manipulating data structures and objects/modules/classes/etc. Ideally, take the best bits from ruby/coffeescript/coco/python and couple them with high quality tooling. Many of the most innovative minds are flocking to these languages for good reason.

Also +1 for ability to extend the language itself so we can code in DSLs. This is so powerful.

I love Python. I prefer working without semicolons.

But from a new language standpoint, it's not worth dropping them. The ridiculous arguments that come out of it, the programmers who refuse to use the language because of it, they're things that can and should be avoided by using semicolons like most languages.

I'll never understand why programmers care so much about this, but hey, that's life.

Programmers care about it because it adds extra noise to your program.

If you semantically, and naturally, communicate "end of statement" with a line break to human readers, why should you have to say it again with a semicolon to the compiler? Programming languages should focus on being DRY.

For human readers we use periods, not line breaks.

Code is more like poetry.

That was not a flippant remark.

Lines of code are clauses not sentences. This is also true of poetry.

A sentence is more akin to a stanza in poetry, and a function in code.

While I could entertain an argument for lines ending in commas and for functions to end with periods there is no reasonable argument for lines to end with periods (is there a language where a line is equal to a function?).

APL, and to some degree Perl, are examples of languages where to you might consider a period half-way through a line.

The context is programming, not writing.

Semicolon makes it possible to do jQuery-style chaining with the least noise. I think frequent-backslash is uglier than always-semicolon.

Semi-colons do not enable this feature. Multi-line chaining works just fine sans-semis.

I very often use and see "single" line of code flow onto more than one line for readability. So often a line break is definitely not enough.

I wasn't suggesting exclusive use of linebreak… Semicolon with no linebreak is fine, but semicolon + linebreak is 100% additional cruft. One or the other. Say it once.

Please make semicolons and braces optional. Unless they are explicitly required for marking blocks and endlines they are just wasted characters to people from prettier languages :-)

For those people who come from "ugly" languages like Java you could have a feature in the IDE which auto-inserted (and of course auto-removed) the braces/semicolons so that they felt at home too.

Are there really people that feel like the lack of adding semi-colons is bad? I understand why you want to be able to optionally terminate a line early for terseness but being required too is just more work. But then I also know people who wax on about the meditative aspects of dish washing instead of buying a machine to do it.

"Java" ugly ? Please name some beautiful languages.


Yes please. No semicolons. And please make it look a lot more like CoffeeScript than Java.

Am I in the minority? I madly in love with braces and semicolons. And, madly hate Pascal, Python & Ruby for the absence of them.

I have no particular affection for semicolons. But I do rather like braces - Python is ugly without them.

I've been convinced of "less typing means less bugs", so I prefer no brackets, no semicolons, short reserved words, etc.

> The language isn't done yet. Now is the time to let us know if you want semicolons to go away.

Seeing how Go, which "wasn't done yet" either, handled external feedback... I don't see why anyone would have hopes for dart.

I've been very pleasantly surprised at how open to feedback Lars, Kasper, and the gang have been with Dart. One of my big concerns joining the team was that it would be like Go which seems like a locked castle. So far, it's been much better than I expected.

Look at how C++ handled external feedback and what it became because of this.

There's kind-of a gap between accepting all external feedback (C++) and dismissing all of it (Go) don't you think?

The Go team has actually reacted to a lot of feedback. They just haven't made sweeping changes to the language willy nilly at request.

Personally I don't even have the tolerance for braces. You're already indicating blocks via indentation.

- Requiring a redundant mechanism to mark blocks

- Possible introducing situations where code looks differently than how it executes

is all very mid-90s. python was the first to fix this, but yaml and coffescript do to. In particular, Dart will have to compete with mindshare from .coffee, so at least should be better than that.

Yeah, but with significant whitespace you create problems like "spaces vs tabs". I like semi-colons for the same reason that I prefer statically typed languages - exactness.

Sure but when I hack python (which is a lot, as it's my day job), I rarely encounter this (YMMV of course). It seems everyone knows not to use tabs in most languages, python is no exception.

I want the semicolons to go away. Braces too.

Where's the best place to lodge our complaints?

I'm fine with the semicolons, but I'm not too keen on using underscore-starting identifiers to determine what is public and what is private.

The misc mailing list is the (strangely named) main one: https://groups.google.com/a/dartlang.org/group/misc/topics. Join and fire away.

> I'm not too keen on using underscore-starting identifiers to determine what is public and what is private.

That's also been discussed. It has more going for it than may be at first apparent, but it has detractors too.

_ for enforcing encapsulation is great, probably the one thing I've seen in dart that's exciting. simple way of giving an existing naming convention significance and cutting down on character overhead. i could see a whole line of languages expand on this idea.

The homepage links to this: http://www.dartlang.org/support/index.html.

Please allow type inference wherever possible:

I shouldn't need to write 'Point p = new Point(2, 3);'

var p = new Point(2,3); should be inferred as a Point

I prefer languages without semicolons, but, for me, semicolons aren't a dealbreaker.

they should not be mandatory

If they're not mandatory, they should be out altogether unless required. Making them just optional is a path straight to js-land weird edge cases.

That's not true. Go, Python, Ruby and Scala all have optional semicolons without insanity. It's just that JavaScript's specific semantics for semicolon insertion (instead of newline elision!) are batshit crazy.

> That's not true. Go, Python, Ruby and Scala all have optional semicolons without insanity.

Python (and Haskell) solve that issue by not using semicolons unless required. The Dart code in the examples is full of semicolons, that makes it an "optional semicolons language" akin to javascript more than a "possible semicolons language" akin to Python or Ruby.

> The Dart code in the examples is full of semicolons, that makes it an "optional semicolons language"

Well of course they do because semicolons are currently required, but that says nothing about its relationship to JavaScript's inane semicolon insertion semantics, and I'm pretty sure you're smart enough to know that. All Dart needs to do is:

1. Treat both newlines and semicolons as the same kind of token (call it whichever you like). 2. Pick an elision strategy. Go's or Python's work fine. 3. Remove all of the ";" from your source files.

No crazy JavaScript "rewind the parse and try again" insanity.

And pretty much all functional languages get by just fine without semicolons (Lisp, ML, Haskell, etc).

ML uses semicolons.

I use semicolons pretty heavily in Lisp. ;)

Haskell has curly braces and semicolons.

To be honest though, small syntactical differences like that are something that is meaningful only for novice-to-intermediate level programmers. Semicolons, braces, tabs-vs-spaces - classical examples of bikeshed bickering.

No, they're not – nor is tabs-vs-spaces (convention) in the same category as semicolons (syntax). It's ergonomics; less superfluous entities and boilerplate makes it easier to express ideas.

I have actually been noticing that I seem to prefer semicolons and braces in my code. I wonder if something about them makes it easier for my eyes/brain to delimit the content on the screen. Perhaps the "easy context-free-grammar parseable" code is easier on the brain than "hard context-free-grammar parseable" code. Having written a CFG for a Python dialect for one of the classes I took, it was a little tricky the first time doing it. Sure, it's not rocket science, but the fact that the semicolon is easier to implement may have some connection with easier identification of delimition on the screen.

Awesome, your comment is a perfect epitome of the point I was making :) Convention/syntax is completely orthogonal to that point - that point being that experienced programmers don't notice the semicolons, or braces vs 'End If' (OK I realize I'm threading on thin ice with that one...) - once one reaches a certain fluency in programming and reading code, one transcends minute details like that.

It's like learning how to read, or learning how to read a new script. At first, you focus on the letters, composing words or sentences. When you get more experience, you read ever-larger blocks of text at once and you no longer need to read aloud or read aloud in your head, you can read whole lines or several lines at once and immediately transfer the concepts embodied in them into your mind (this is effectively how people read - chunks of text at a time, it's also why it's easy to read text where the letters of all words are mingled except the first and last one, a feat that is impossible when reading letter by letter or even word by word).

Anyway, in reading/writing code it's the same - at some point you no longer see a line with statements, you see a block with initializations, or no longer a set of if/then or switch statement, you see a jump table. Once you get to that level, dollar signs to denote variables disappear from the mental model you have, because you no longer see tokens - you see variables (same with semicolons, braces, most indentation, etc.). That's where the comparison came from.

(I also think that that's where eloquent code comes from - it's from programmers who make an efficient and recognizable translation from high-level concepts into the mechanics of the programming language, even if there is no explicit support for such concepts in the language).

I am such an expert at reading English that I no longer think in terms of individual letters. Instead I think in words, phrases, concepts, and lines of argument.

But a crappy typeface or color scheme can still give me a headache.

Bullshit elitist crap.

No one can argue with you because you just claim knowledge superiority that can't be confirmed or denied.

People care about this stuff, I don't care if you don't, if other people do, then it's an issue.

i prefer semi colons too. i know its annoying when you write a piece of code, then you go test it. then an error occurs, then you go look for it, and finds out that theres missing an ;

besides that, its really easier to read the code with semi colon, when you get used to it.

also.. flash got optional ;

Which languages? javascript and go are both counter examples. In Go the lexer (sic) determines where a line ends, so if you write

    if (a == b)
        && (c == d) 
it will guess a line end after the first closing paren. WTF?

Python is a totally different beast, and I wouldn't include it in the discussion, because it also uses whitespace for block grouping.

There's no guesswork involved. The carriage return implies a semicolon. The rule is very simple and obvious in use (to me, the code you posted looks wrong - and it is).


This was my first thought, as well. Looks like I will still go with another layer on top like CoffeeScript to actually write my scripts. Curly braces for blocks are something I don't see the need for anymore, either.

Does having semicolons help with minification (which is common practice for sending JavaScript over the web)? Although, thinking about it, replacing ";" with "\n" would be the same number of bytes.

The only (contrived) advantage of using semicolons that I can think of is to avoid potential problems with line wrapping. For example, some mail clients add new lines after 80 characters, which would be more likely to break Dart code than JavaScript.

I am most excited about the concurrency model!

"Concurrency is supported via actor-like entities called isolates. An isolate is a unit of concurrency. It has its own memory and its own thread of control. Isolates communicate by message passing (10.14.4). No state is ever shared between isolates. Isolates are created by spawning (10.11)"


I wonder how they compile this down to Javascript?

That doesn't sound so different from WebWorkers, which you can already use from javascript in newer browsers. https://developer.mozilla.org/en/Using_web_workers

The model seems slightly different - don't WebWorkers share state?

No, just message passing (notionally via JSON).

Agree, it would be more interesting to know if it has some kind of built-in parallel support.

Well, you can implement pretty much everything you just described as a library. The only thing missing is preventing memory sharing, but that you can sort out at compile time.

An interesting question is if this means V8 is gaining threads.

V8 with threading? interesting.

V8 has isolates already. They are intended to be used for implementing WebWorkers.

The one thing I don't understand is why people work on new languages for the browser instead of giving us a platform (virtual machine / intermediate representation, whatever) to implement languages against.

I mean here in this thread we are already seeing it. Some people like semicolons, some people don't. Some people like a prototype based object system, some people like a class based system. And on and on.

I think what would really benefit us is a platform (like a JVM for the browser with a great API replacing the dom) where people could implement languages against. we would get

1) A lot of competition of languages (see what is happening on the JVM right now... Clojure, Scala, Groovy ... you name it), hopefully giving us better languages. Javascript has its strenghts but could you imagine that in such an environment a language that doesn't allow you to test whether or not something is a string would make it very long?

2) People could make their choice and be happy. Then you can program the server and the client in the same language, which is pretty much the main argument for server-side javascript.

Let the languages compete instead of giving us one and now another language for the platform!

I think the Dart VM will be a nice target for compilation from other languages. In general it's easier to put a typed language on an untyped runtime than it is to put an untyped language on a typed runtime.

Before Google I worked on an academic project that built a small Smalltalk-like VM that was also a compilation target for something that was very close to unthreaded Java. Worked pretty well.

> I think the Dart VM will be a nice target for compilation from other languages.

This would indeed be nice but it seems that google wants to push the language more than the VM. I quite get this because saying "you can now run your favorite language for the browser" seems much much more attractive than saying "look we made programming language 1001 and this is what you people should be using now!".

> In general it's easier to put a typed language on an untyped runtime than it is to put an untyped language on a typed runtime.

I have no knowledge of how one would do this but a lot of dynamically typed languages exist for the (I am assuming) statically typed platforms such as the JVM and CLR now.

They do, but it's a heck of a lot of work. The CLR has the DLR (Dynamic Language Runtime) that does a lot of the work for you now, but it's still a pain.

This is what JavaScript is trying to be, with the latest revision. They're explicitly trying to make it a better target language for things like ClojureScript and CoffeeScript.

Well yes, but I think the motivation here is more 'since javascript is the only game in town, we'll have to compile to that'. I am not aware of any changes made to Javascript to make it easier to compile to it. And I don't think anyone would choose Javascript as their runtime environment if they had a choice.

I like Clojure and have dabbled with clojurescript but the workflow feels pretty hacky and it is clear that this is not what javascript was made for.

Do you mind elaborating on the hackish parts of the ClojureScript workflow? It's alpha software at the moment, but we can always use some feedback.

Hello Fogus. What an honor! I loved your book ;)

Well, I am certainly not complaining, I think it is mostly just that it needs to be compiled to javascript and that you need to have the right dependencies in place. If you are compiling from the command line it takes a long time (I know this is caused by the jvm startup time, but it still is a little annoying). I know there are workarounds such as cljs-watch but setting everything up right definitely takes some time. The browser-based Repl is awesome but sometimes breaks, I don't always understand why. I do think there could be some improvements in terms of tutorials but those will surely come (I might write one...)

So if you are using it on a daily basis then all of this probably doesn't matter but it does take a bit to get started. And I think to some part this reflects the fact that, well, Javascript was not really intended to be a platform to be compiled against, it is just used that way because it is the only platform in the browser.

>>> I think to some part this reflects the fact that, well, Javascript was not really intended to be a platform to be compiled against, it is just used that way because it is the only platform in the browser.

I'm not so sure this is the case as it is VERY easy to get started with CoffeeScript and have it watch files for changes (at least on a mac with homebrew).

I've experienced general difficulty getting started with Clojure compared to something like Python or CoffeeScript. I suppose I haven't spent considerable time on it (Clojure is just a hobby for now) but the problems I've run into so far are an out of date version on homebrew (1.2 rather than 1.3) and difficulty just getting a usable REPL going (where I can edit lines and use the up-arrow). I'm very attracted to the aesthetics of Clojure but there is so much friction just to get started that I've only been using 4clojure (try-clojure has been non-functional every time I've tried it). I think this is an area that definitely needs to be addressed for Clojure/ClojureScript to get the mainstream traction that node.js/JS/CS enjoy.

If you're going to go to the trouble of creating a JavaScript replacement, making something more like Java is the wrong way to go IMO. CoffeeScript is a lot more palatable.

CoffeeScript basically simplifies (and does a pretty good job, imo) existing JavaScript language features. Whereas, Dart adds classes and interfaces and a few other neat things.

Admittedly, however, I do cringe whenever I see things like x.compareTo(y) or X x = new X();

Classes, types, better syntax - it's all available in JavaScript today, in it's various 'forms' (CoffeeScript, Mootools, Closure, etc.). Dart isn't a bad language, it just doesn't bring anything exciting to the table (or I fail to see it). Seems like it's ECMAScript 5 but early-bound and with Java syntax. And it runs only on browsers that already support ES5 - this one is really underwhelming.

as a sidenote, it does seem they have user defined operators, just not the starship <=> for compareTo

A question to ask yourself: If this had been Microsoft creating an IE10-only language to replace JavaScript, instead of Google, would you feel any differently about Dart?


But if they released an open-source version of IE, started shipping IE frequently for Windows, Macintosh and Linux and released the Dart language spec and implementation under an open-source license... well, then I'd like it a lot better.

There's probably still a few managers left at Microsoft that can recall VBScript vs. Javascript.

Probably the biggest difference between JS and whatever revision to it you like, and Dart, is that dart is early-bound. That means, you can't change the list of methods or fields present on an object at runtime.

It doesn't really make sense to ask "Why should I switch from a language I already love?" If you're already productive and love what you're using, then you should probably keep using it.

There are people who want a language that is more modular, scales better than JS for programming in the large, for IDE tooling, or ahead of time compilation, etc. Take a look at the Dart spreadsheet Total for example (https://code.google.com/p/dart/source/browse/branches/bleedi...) I find this code a lot cleaner than JS versions I've seen.

I was liking Dart's syntax but the early static binding is a deal breaker for me. Javascript would've been stuck in neutral if it didn't support mutable objects.

Is this effectively GWT 3.0?

The project page is very unclear, so I ended up on Wikipedia instead. Wikipedia actually has a leaked memo that seems to do a really good job describing the purpose of the language.

Specifically, the language is meant for three environments: server-side, compiled to JavaScript client-side, and fast native client-side once there is browser support. (The main goal is better performance on the client-side, which is deemed to be very difficult with JavaScript.)

However, the language looks so Java-like, one wonders why they didn't just use Java and extend GWT with a native Java client in Chrome. Did it just not make sense to bet the farm on Java when Oracle controls it?

Also, what does the "structured" in "structured web programming" mean?

Dart doesn't really share much with GWT. The basic language semantics are dynamic, not static. The types are more or assertions and documentation that generate runtime warnings, but do not produce compile time errors that refuse to let the app run at all.

Dart's a lot more like CoffeeScript than Java.

Only, it looks worse than CoffeeScript from a readability point of view... just a first impression.

> Also, what does the "structured" in "structured web programming" mean?

I would guess it's a reference to the optional static typing. There's a growing movement behind static typing and functional programming that resembles the movements behind dynamic typing and OOP of a decade ago...

I'd guess it's also a lot about class-based vs. prototype-based. The latter often leads to messy architectures. It might be an intrinsic characteristic of prototype-based design, or because 99% of people learn OOP with a class-based language, I don't know.

The "hello world" example is incredibly uninformative. What does that have to do with "structured web programming"? Where is this printed out on a web page? Does the console output there correspond to the html output? Or some other console?

It's actually runnable if you click the "play"-icon in the top-left of the code sample.

The "Hello, Dart!" is written to a console emerging from underneath the code sample.

https://code.google.com/p/dart/source/browse/branches/bleedi... is a more DOM-oriented version of the same program.

I realize it's runnable -- that's what I mean by it's not clear what the console that appears underneath refers to. Is that "echoed" out to the page? Or something different?

Yeah, there are more links to code samples here: http://www.dartlang.org/samples/index.html

Hmm strange, I can't see the "play"-icon using FFX 3.6.23

Dart currently compiles to JS that runs on Firefox 4+.


Yeah, exactly. This "hello world" uses a "print" function. What would such a print function do in a normal web app? Write to the console or something?

I was hoping for something like the Dylan language.


It was created in the 1990s and it still looks innovative, even compared to a lot of the new 'hot commodity' languages like python and ruby. I knew it wouldn't happen.

If a big corporation like Google put money into something like that, I think it would dominate the market.

But what they have delivered here isn't even interesting.

(The other option for something I would want would be standardized 'web byte-code', so that you just re-target a compiler back-end to emit it, and your language can be used as if it were javascript.

This is neither of those thing and I am sorely disappointed.

Yes, man. Dylan ftw. The best language that does not have s-exp syntax. There are still some guys tring to get a good implmentation out.

Dylan could have been what Objectiv-C is now. It was an awesome project it just had bad timing.

> But what they have delivered here isn't even interesting.

Not a big surprise. PL specialists (let alone theorists) have no place at google. Just look at the previous language coming from outside Google... Go.

I like it... It's kind of like schemey-ruby.

Creating an object:

    Greeter greeter = new Greeter()

    var greeter = new Greeter()
Defining a constant:

    static final myConst = 1

Plus there are classes, interfaces... It's just Java?

> var greeter = new Greeter()

Well, it's hard to get that much better than that.

> Plus there are classes, interfaces... It's just Java?

Java didn't invent classes. It certainly looks a lot like Java, but it's more Smalltalk under the hood.

> Well, it's hard to get that much better than that.

    var greeter = Greeter()
there, no need for `new`.


    var greeter = Greeter.new()

    var greeter = greeter new
if it's not acceptable to have arbitrary callable objects.

> it's more Smalltalk under the hood.

The speed and wide-spread use of Smalltalk with the regularity, flexibility and terseness of Java's syntax? That sounds like a recipe for success.

> there, no need for `new`.

Agreed. I didn't say you couldn't get better at all, just not much better. I'd personally be in favor of ditching new (or conversely making it a method on the class).

> The speed and wide-spread use of Smalltalk with the regularity, flexibility and terseness of Java's syntax?

Oh, you. You may be right. Making a new language is crazy, especially if you're aiming for widespread adoption. Still, you have to try, right?

Dart is definitely more terse and more flexible than Java. Maybe not perfect, but it's heading in the right direction. Dart is no DSL-friendly beauty like Ruby, but I think:

    var odds = [1, 2, 3, 4, 5].filter((i) => i % 2 == 1);
is pretty tolerable without being novel enough to scare people that have never programmed outside of a curly brace language.

> Agreed. I didn't say you couldn't get better at all, just not much better.

I strongly disagree, it makes away with a keyword and magical syntax, that is much better.

> Making a new language is crazy, especially if you're aiming for widespread adoption.

That's not what I'm saying, I like new languages, and I like interesting new languages, but it pains me to see you defend (or even work on?) Dart, which so far looks even worse on the programming-language-progress continuum than Go does. It barely makes any progress on the very language it's supposed to replace.

Well to be fair, the language it is replacing for the most part works, it's mostly just patching up problems: ability to optimize for startup performance, ability to program in the large, and ability to write tools easily (IDEs, etc)

Most new programming languages are really just variations on those that came before them. You've got you're LISP derived, your Forth/Stack derived, your APL derived, your ML derived, etc.

IMHO, it's hard to consider a programming language in isolation. As far as 'feel' or 'productivity', it really comes down to the ecosystem, the runtime and tools available. Here I think is where Dart hopes to excel -- make a JS-like replacement that supports a better runtime and tools story.

> Well to be fair, the language it is replacing for the most part works

They clearly disagree, since instead of taking part of cleanup/improvement efforts (e.g. Harmony) they decided to build a brand new language from scratch.

> Here I think is where Dart hopes to excel -- make a JS-like replacement that supports a better runtime and tools story.

I fail to see why that would happen, from what I've seen so far there's little in Dart which is a significant improvement for runtimes. And as far as tooling goes... well Google's history means they're unlikely to be those handling that, who's going to build tooling for Dart, and why would they have any reason to make that investment instead of improving their JS support further, or adding CoffeeScript support?

Google's build the Android Development Environment for Eclipse, the Google Plugin for Eclipse (AppEngine and GWT integration) and Dart already released an Eclipse environment, and a compiler. So the history seems to be that Google supports tools.

Google is taking part is JS cleanup efforts, but it's a large company with 20,000+ employees, so it has the reasons to pursue many different paths: Closure, GWT, Dart, Go, etc.

As for runtime improvement, if the team who has built the one of the best/fastest JS VMs (V8 team) says the language semantics allow them to do better, I think we should listen.

The early binding alone allows for substantial improvement. If all classes are early bound, then you can significantly optimize dead code, you can know object layouts immediately on load, you can detect effectively non-virtual methods immediately, and so on. You can pretty much snapshot important information that you normally have to discover each and every time you load the application.

greeter := Greeter()

> Well, it's hard to get that much better than that.

Ok, fine, but why have both forms?

Sometimes you care about the types, sometimes you don't.

Looks a lot more like James Gosling, actually ....

I had a comment above saying something to the effect of "not everyone can be Ken Thompsons" and then edited it out, sorry.

It is. Google is betting heavy on android. Expect more Java style languages.

The thing I was really hoping for from the dart site was an "about" section, or a "why" section, explaining about the language and their goals, instead of just jumping to code examples...

http://www.dartlang.org/docs/technical-overview/index.html has some information on the design goals.

That's a fair point, but it's pretty annoying when you read about some cool new language but you can't find any good sample code anywhere. anic and newspeak come to mind.

For the record, anic was and still is pure vaporware. Sample code exists but there is no working compiler or interpreter to run it...

Wow guys. Google is not aiming at a next gen Haskell or ML. They are trying to create a less cluttered Java and a stricter, more performant Javascript. Judge a solution in context of the problem it is trying to solve. If they got Simon Peyton Jones to design this it would be somewhat intimidating for your average webdev[no disrespect].

I'm somewhat disappointed that they insist on a 90's C syntax. It's like Python/Ruby/Coffeescript never existed.

C'mon Google, you can do way better...

I think this comment gets to the heart of the matter. People want something different. They want a Haskell. How many blog posts about Perlis languages have we seen in the past several months?

Reading these comments I've come across the words: boring, uninspired, underwhelmed...

I couldn't agree more.

JavaScript's prototypal object model can at least keep my attention.

Pretty disappointed with the lack of risk with this. Conceptually seemed like something with a ton of potential, but the minute I saw the tutorial shoehorning the worst of Java and JavaScript into something new, it was a non starter for me...better being insulated writing CoffeeScript a layer up and waiting for a compiler.

Things I've noticed so far that I don't like: get/set proliferation, semicolons, braces, positional args, var for instance vars, int/num dinostyle pseudo-primitives.

It seems like they tried to do some cool things, but failed in execution. Like "Greeter.withPrefix(this.prefix);" one-line constructor definition .. where this.prefix is a "shortcut that assigns the parameter's value to the instance variable prefix". Eliminate needless code.. but instead of using a dedicated symbol to call attention to the sugar, they used "this." WTF.. did they specifically want to kill scanability.

Things I've noticed so far that I like: using "_" as a prefix to enforce encapsulation.

Enforcing naming conventions as syntax seems at least somewhat python inspired in the sense of bringing the whitespace is significant design to naming is significant.. wish there had been more of that.

If someone other than Google were doing this it would be dead in the water already.

Funny to read all these comments just a few minutes after the announcement. I bet nobody had enough time to explore the language in any significant way. Yet very strong opinions already.

On the contrary, I was able to go through all of the tutorials, follow 2 separate live-tweetings, and start looking into the source before the keynote was over; I'd imagine many here did the same.

Two things I don't like about Dart, just from reading the tutorial:

1. Consuctor syntax requires repeating the name of the class when yor define the constructor. So if you change a class name, you have to carefully find all your constructors and rename them.

2. Instance variables in classes seem to be defined at the same level as class methods. Yet one is an instance attribute, and the other a class attribute. So you have irregular scoping rules based on type (data vs. function). This scares me as it indicates functions are "special" and not first-class types in the language.

A face-washed JavaScript with classes, interfaces and such stuff. I was expecting something more syntactically close to Go, or at least to Python.

Meanwhile, I've been slowly eliminating my usage of `class` from all of my CoffeeScript code. I've found that my code is much more reusable, far less prone to `this` bugs, easier to reason about, etc. I used to be a huuuge OOP guy, but now I rarely find a use for classes...

Prototypes are fine for a language like JavaScript. They keep things simple. I'd prefer that CoffeeScript (and Dart, of course) implemented a decent syntax for prototyping, replacing the JS mess, rather than trying to disguise them as leaky and half-featured classes.

    > leaky and half-featured classes.
This is a common willful misconception. CoffeeScript classes are isomorphic to JavaScript prototypes -- the do precisely the same thing. In addition, there is a shorthand syntax for prototyping objects, if that's more your style:

    Dog = -> 
    Dog::bark = -> 

    Dog::run = ->
Note that the above will produce the same result as:

    class Dog
      bark: ->
      run: ->

I didn't mean that CoffeeScript classes don't cover prototypes —but the other way around: prototypes can't implement the whole typical class abstraction (encapsulation, etc.). So I think CoffeeScript would do better implementing a completely new syntactic abstraction over prototyping that fix all the JavaScript awkward ambiguities than adapting classes to prototypes. But it's still OK, I like and use CS classes.

there are performance reasons for that choice, the prototypal inheritance + constructors are way faster than anything else at the moment

There was a recent article on HN about Self and its prototype patterns. Looked far superior to Javascript's. But even still, prototypes only seem primarily useful if you want member-access as dot-notation or polymorphism by type. When preferring composition over inheritance, most polymorphic-by-type situations either go away or can be trivially replaced with maps.

That said, CoffeeScript provides another interesting use for them: Simulating dynamic binding. Basically, the trick is that `this` becomes the dynamic binding context and `@` represents a dynamically bound variable. You use `fn.call @, x, y, etc...` if you want to pass the dynamic binding to callees. Nested bindings can be established with `Object.create`

I use classes in Coffeescript, but avoid 'this' bugs by knowing that:

- JQuery examples like to abuse 'this'.

- I should always, explictly provide the event as a parameter in the callback.

So '@' is always the object, and 'event' is whatever started the method.

I have used `class` less and less in my Python code, and when I still use it, it is as little more than a struct.

I never use inheritance.

Since I started to do this, my code has become much simpler and cleaner.

A language that has type hints class keyword, and interfaces, I really think Google should have been better off implementing ES.next stuff... This is one of the most pointless projects Google has ever done, it doesn't solve any web developer problems, it's just the 999999th language.

They should have just embraced Coffee script.

"This is one of the most pointless projects Google has ever done, it doesn't solve any web developer problems, it's just the 999999th language."

I would say this is a bit too early to take on the 'maximist' attitude, no?

Like munificent said, someone has gota try. At least he put the flag post down somewhere, and I'm sure he's having fun. Where the maximist point of view doesn't help at the moment is that most of the time It is projects like this one where out of the 1000 features, one or two are genuinely super super awesome new.

Eventually in time, after many projects like this, you end up merging all the 'cool' things you've learned you come up with something super awesome. Somewhat like learned progress. Already the project has grouped many minds together, and that has got to be beneficial.

In fact I don't remember the last time anyone has offered up so many voices in such short time to any language actively being developed nor even in the infantile stages such as this one.

Btw, from a philosophical point of view, today's 'web developer problem' might not be tomorrow's 'web developer problem'.

I'm really surprised to see all the hate here. It's early yet guys...give them time to hone it a bit.

I'm perfectly willing to live with the Java-like syntax and feel, so long as:

- I can write in the same language on both the client and server side - Solid libraries exist on the server side for interaction with RDBMSes, web services, etc - Good tooling support

Those of you complaining about the syntax...do you honestly think regular javascript is any better? Personally, I loathe javascript's syntax and inconsistencies...if Dart can solve that and give me good server side programming support, I'll sign up. That's the problem with things like Node today...the server side libraries are loosely documented and implemented IMO...it's very much a Wild West environment.

> That's the problem with things like Node today...the server side libraries are loosely documented and implemented

Why would different syntax or explicit types change that?

I don't think you have to replace JS to get better server-side libraries, and better language doesn't automatically give you better libraries and documentation.

I don't disagree with you. I'm simply saying that's what I'm looking for. Same language on the server and client...better libraries...better tools. If Google gets there with Dart, great! If javascript gets there, great! I'm not as hung up on language syntax, prettiness, etc (though it'd be nice). I'd rather focus on pragmatism and consistency across tiers.

New MIME type "application/dart"... I suspect that Google Chrome will embed a Dart Runtime when it gets stable, that will be very interesting; I'm not sure if it's a good or a bad thing though.

OTOH it's not that uncommon these days, especially when these transpiled-to-js languages want to run without being translated ahead of time (though usually in production you would want to do that offline)...text/coffeescript, text/traceur, text/es-harmony, etc etc

Yeah, but I don't think any of these mime-types represent any threat for today's Javascript. OTOH Dart(or Dash)'s sponsor already gave us some clues of that their intentions are. I quote https://gist.github.com/1208618 "Push for Dash to become an open standard and be adopted by other browsers. Developers using Dash tooling will be able to use a cross-compiler to target Javascript for browsers that do not support Dash natively." again, it says "target Javascript for browsers that do not support Dash natively [for now]."

on the other other hand, the live tweeting is saying "not yet in chrome" is listed on the "still not done" list, so maybe you're right :)

Well... http://blog.chromium.org/2011/10/dart-language-for-structure... "The Dart VM is not currently integrated in Chrome but we plan to explore this option."

Hmm. A little underwhelmed so far.

Yeppp... its like getting a birthday present. You get a moment of excitement and intrigue. You unwrap it, and .. socks.

You know I'll probably use those socks someday, but its not what I was really hoping for.

best comment ;D

I guess that was the intention, they bet on familiarity as well. Most changes are subtle, not necessarily a bad thing.

The only problem I have with this sort of development effort is that it fails to recognize that Javascript is an awesome language unto itself and has no need of "fixing" by introducing a completely new language that is completely different.

Sure, it needs a few refinements here and there, but by and large Javascript is an incredible, flexible, and battle tested language. As a web developer with 11 years of experience, who has worked professionally with RoR, Java, PHP, MySQL, Oracle, and PostgreSQL, my feedback is just stop.

The world doesn't need another tool that obviates the need for engineers to learn Javascript to program on the web. Seriously, Javascript isn't that difficult. Just learn it, buckle down and spend a couple months writing Javascript and you'll be just fine.

If half the time spent writing Dart had been spent learning Javascript instead, then you would think in prototypes instead of classes, anonymous functions instead of one off objects, callbacks instead of um... not having callbacks, and dynamic variables instead of casting, casting, casting.

I'm not claiming Javascript is better then your language of choice, I'm just saying that as a language, it's awesome. It's not broke, and as a web developer I'm not looking for something to replace it.

You don't need to cast in Dart. Dart is not Java. It has concise closures as well. It has dynamic types.

Javascript has problems. If it didn't, no one would be trying to evolve it and address it's weaknesses. The language had serious weaknesses, some of which were addressed recently (TypedArrays, strict mode, etc) and some of which there is no current fix (consistent, standardized, namespacing and modules), and some of which cause big performance holes ("with" statement).

Prototype based inheritance is extremely verbose to use. That's one reason why CoffeeScript is well liked, and why Classes are coming to JS. Prototypes and eval() also make it hard to develop language analysis tools and IDEs which can provide correct code assistence, which can refactor large code bases, etc

Javascript isn't broken if you're just writing a few lines of JS in jQuery to enhance a web page. But it doesn't really scale well if you're got 500klocs of code and a decent sized distributed team.

Sure, jQuery is bad at scale. And by "scale" I'm not talking pageviews, I'm talking features, development team, etc... For that, modular libraries like YUI and Dojo are the answer. You can create some of the most advanced web applications perfectly fine in JS as long as you approach it correctly.

P.S. Don't ever use the term "klocks" unless you want to sound like a enterprise middle manager who hasn't touched code in 20 years. Just a friendly tip. :)

Where are all the great JS tools and IDEs then? You simply cannot compare JS tooling to what can be had for a popular statically typed, inheritance based language. It's a whole different league.

P.S. Snide remarks such as that make you sound like a junior programmer who thinks he knows everything. Just a friendly tip ;)

I read a bit more into Dart, its optional typing is very interesting. I might even like that if it were a change to Javascript itself.

Of course Javascript has problems, every language has problems associated with it. They all have strengths and they all have weaknesses.

From what I've seen, projects like GWT, Dart, and Coffeescript come out of communities of developers other then the web development community. GWT and comes from Java engineers as an attempt to not have to write javascript, Coffeescript comes from Ruby developers attempting to accomplish the same thing. Now Dart is another attempt by the Java community to not write Javascript.

The thing is, I never hear from the web development community that Javascript is broken, missing major features, and needs to be replaced. These are the people using Javascript every day. The people that say Javascript needs these features are people who don't use it that much.

People also used to program computers with punch-cards. Everyday. Of course they can use Javascript.

You didn't address any of his points though. Where are the great Javascript tools and IDEs? There are tons of them for languages with static typing and classical inheritance.

Here's just one tiny example: Compare how you go about refactoring code (renaming classes, functions, etc) in Javascript with the many ways that it may be done in Java or C#.

He made many points, Javascript not having great tools and IDE's is only one of them.

It's a valid one though, the Javascript IDE's out there aren't very good. However, that's a function of community support, not language quality. Personally, I don't use an IDE for javascript or RoR programming, I just use Textmate.

I use Eclipse for Java programming, and I don't think I would want to program in Java without it. Maybe it says something about the languages themselves that they require an IDE to develop in.

Actually, many people have tried to build refactoring and editing tools for JS and they always hit the same limitations. The language is just not conducive to tooling. Without a great refactoring tool, big projects become difficult.

After seeing so many negative comments primarily focusing on the syntax and verbosity of the language, I felt compelled to create an account to try and get some understanding of why this is.

The way I understand it, a terse syntax is useful in getting something working quickly. However, this is not necessarily the best code when it comes to performance or maintenance. Adding "boilerplate" code not only makes the compiler/interpreter more efficient, it also makes the job of the maintainer much easier. Personally, it takes me less time to figure out what a particular piece of code is doing if the datatypes of variables and return values of functions are obvious.

Dart seems to understand this well and so makes typing optional which is useful for prototyping but then also allows you to refactor and explicitly include types to gain performance and improve maintenance for production code. Am I missing something? If not this sounds pretty exciting to me.

Can anyone explain why I should use this instead of other web programming languages?

From their "technical overview" page http://www.dartlang.org/docs/technical-overview/ :

"Dart will include a rich set of execution environments, libraries, and development tools built to support the language. These tools will enable productive and dynamic development, including edit-and-continue debugging and beyond—up to a style where you program an application outline, run it, and fill in the blanks as you run."

Sounds like a Smalltalk-style debugger running in the browser.

Though it seems these tools aren't actually ready yet: "This is a technology preview, not a product launch" -- http://dartinside.com/2011/live-from-dart-launch/#liveblog-e...

You shouldn't. This has no practical use right now. Google's basically just showing us what they think JavaScript should look like.

To me this looks a lot like Java but with optional types.

Why didn't they go a bit further and have type inference? They proved already with Go that you can have type inference in a language and still have a fairly light/dynamic feel.

Type inference is a tooling feature, not a language feature for Dart. The tools can do some type inference now, and more may be added later. At the very least, I personally really hope we get fully inferred local variables.

You really need to make a list of these types of response on your webpage.

Good idea. At some point, we'll probably harvest a bunch of this and put together a FAQ.

The language could require that inferred types are consistent.

   a = 1
   a = "1"; // error

It's actually very reminiscent of ActionScript-3.

If anyone has a good example of what a medium-size Dart script looks like when compiled into JavaScript -- I for one would love to see it.

I am really disappointed seeing the "yet familiar" argument behind the C-like syntax.

It takes a day to get used to Python syntax, and another day to make it subconscious, that is to stop forgetting it.

The arrow in CoffeeScript is a pain to type, but overall CS saves you a lot of time.

How come Google that can dictate rules to some extent, doesn't have the balls to fix the long lasting issue with syntax? Why voluntarily subject oneself to, probably, years of pain?! Did they just start following letter-by-letter the success stories, like the one of Javascript? (scheme+smalltalk+java/c syntax)

I can't find an explanation to this.

I don't understand this. The only thing different here is the async handling. Why would anyone want to switch?

Switch from where?

If this were as commonly supported (and as performant) as JavaScript, and if, as I expect, this allows DOM manipulation, I would prefer it over it, if only for the strong typing.

Also, I haven't read the spec yet, but I would expect the 'VM' to run Dalvik code. If so, this will make it easier to port your web app to Android.

From the menu example:

So, yes, DOM manipulation is there albeit kind of ugly.

Not perfect, but I prefer that over:

If you have suggestions for improvement, please do pass them along.

Bake in a jQuery-like thing, or make it easy to build jQuery-like things, since I would much rather write something like the following in any language:


We had a separate jQuery-like lib that we wrote in Dart for a while before we figured, "why not just make the main DOM API better"? So this stuff:

Is a reflection of that. The ".node" part after sliderMenu will go away at some point. Our DOM lib doesn't currently work like jQuery's "collection-that-acts-like-an-object" style because we're worried about performance.

Keep in mind that you can always ditch jQuery and go straight to the DOM if jQuery is too slow. If jQuery was the only way, you'd lose your fast path.

So we've tried to come up with a DOM API that's easier to use, but still performant. If you've got ideas for how we can improve it, we'd definitely like to hear them.

how about literal DOM elements?

e.g. #,., maybe % or _ before elements, and you have a much more fluent syntax.

I was expecting dynamically typed Scala, with ready to go IDE from Google and truck full of apis and tools.

Or a surprise.

Re: IDE:

09.50: Now they are demoing a full eclipse based IDE for dart, very cool too, wow

From http://dartinside.com/2011/live-from-dart-launch/

> eclipse

Oh. :-(

This looks it's just Java flavored Javascript. Why would we use this over languages that already work such as CoffeeScript, ClojureScript, or even plain Javascript?

I am also disappointed, but in a different way that most commenters. I don't mind java syntax, and I prefer strongly-typed languages. My concern is that Dart seems to give up a lot vs. gwt, and not add much.

That is, with gwt you get

- strongly typed java syntax

- it abstracts away browser differences, and supports many browsers

- it lets you run mostly the same code on client and server, and gives you access to lots of java libraries on the server

With dart, it seems you get a weaker java syntax, and you lose access to all the existing java libraries on the server. You also seem to get a new interpreted server side environment. Maybe that will be better/faster than the JVM, but that is not obvious to me.

Overall, I agree with a commenter above who said that they should have defined a general VM for web browsers, similar to the JVM, but simpler/faster/more appropriate. Then, all kinds of languages could be cross compiled into it, while you could use the language natively on the server.

I think their original memo got many of the problems right - javascript has become a limiting factor in advancing web development - but I think the solution lies in a more general VM approach.

"I think their original memo got many of the problems right - but I think the solution lies in a more general VM approach".

I think Dart is the preferred way to target that VM. Staying at the language level eliminates binary format headaches!

Besides, the web should not be binary.

Either give me a brand new browser VM with a brand new modern language that is supported by all browsers or don't bother. If my code will be translated to Javascript I rather write it in Javascript and control it myself.

I'll happily adopt a new browser language if it offers me benefits that I don't get from Javascript, but I really don't get the new trend of compile to Javascript languages.

I don't get it. What's the runtime for this? The interpreter seems to be running on App Engine, so it's probably JVM based, right?

Though I saw no direct mention of this in any of the writeups thus far (they are just announcing it now at GOTO), it appears you can download code for the the VM, compiler, etc from here:


(Look in the bleeding_edge branch)

Currently doing a repo pull here so I haven't had much time to look around at it yet. I'm cautiously optimistic though, it looks quite a bit like I was hoping Dart would look (a bit of the ECMA4/ActionScript feel on top of JavaScript).

See http://blog.chromium.org/

There's a compiler that translates to JavaScript, and a standalone VM.

I like it. And if they make it work great on the server as well, that's a big plus. A google supported node.js would be great.

Even better, a Google supported node.js with actors.

Hook.io seems to be a reasonably nice actors implementation for Node.js

I'm mainly curious why Google isn't going after some sort of bytecode for browsers, and then building a language on top of that. That would let developers use the language that works best for them, and would really open things up for new languages in the browser.

Does anyone on the Dash team have any feedback on why you guys decided not to go that route?

Who wants to begin work on CoffeeScript-for-Dart? Possibly call it Arrow or Bolt, although I'd find Dash endlessly amusing.

I feel like at this point in the development of technology, we should be moving towards less programming languages (and ultimately less programming), not more. I haven't spent hours studying Dart, but what does Google hope to accomplish with this, besides getting their skin in the programming language game (see Microsoft). It doesn't really do much else that other languages can't, at least not that I can see. I mean, YOU CONVERT IT TO JAVASCRIPT just to get it to work! Come on! Programming languages are a lot like web browsers. There are some that are more suited for certain things than others, but having so many creates more problems than it solves (especially because they try to do little, insignificant things differently, just for the sake of being different).

The language could satisfy the trolls at both sides of the semicolons/braces fence: your favorite editor/IDE could support your style (with two-way tools).

As for the preferred format, I suspect code with ; and {..} may remove some ambiguity, so it should execute faster. That's the decisive argument in my book.

Besides being useful by itself, I understand Dart as an intermediate language: other languages should compile into Dart. Its syntax should be extremely consistent, so code can be reasoned about.

For one day we'll need 99% accurate machine translation, like from chinese to english and back, but from Perl to Python or Javascript. In some respects that should be easier: translated functions can be tested to work identically.

The current Dart buzz shows merely two things: (1) There is a need for better languages to program web apps. (2) Google marketing power is impressing.

But, technically what Dart introduces is nowhere new. Have a look for instance at Opa (http://opalang.org) which is open source and already does more than Dart. If you take out the marketing bulls... that it is going to replace JavaScript, when it now just compiles into JS as many other do.

It looks like the website dartlang.org is down. I hope it will be up again soon so that we can compare the two languages in details.

You guys need to check out ActionScript, your re-creating it.

It's interesting that dart provides the translator at the html level, which allows dart to support direct inclusion of dart scripts in an html page, and for one dart script to require another.

However, it seems like this would actually make it harder to package up dart script files efficiently to minimize multiple http requests; it would be nice if dart had some way of emitting a single packaged up dart file as part of the html translation process.

     class Sunflower {
       static void main() {
         new Sunflower();

No thank you! I would rather stay with prototype objects.

Not sure exactly what your problem is since that code won't even compile


print('${(1<<31)}'); -2147483648 (correct value is 2147483648)

print('${(1<<30)+(1<<30)}'); 2147483648 (correct)

print('${(1<<30)+(1<<30)+(1<<30)+(1<<30)}'); 4294967296 (correct)

print('${(1<<30)x(1<<30)x4}'); 4611686018427388000 (correct value is 4611686018427387904)

(I've used x instead of star here as the latter does not display on HN.)

This is completely nonsensical.

It has the same numeric semantics as Javascript. Javascript does not have a 64-bit integer.

This is not about the lack of 64 bit integers. Dart can have 32 bit or 31 bit or 30 bit integers or whatever it wants.

But mathematically it doesn't make sense to have an int type which does not represent integers consistently. Clearly Javascript can represent 2^31 as a positive integer. In fact it can represent 2^53 as a positive integer (of course in reality it uses a double precision float) as can be verified by typing (1<<20)x(1<<20)x(1<<13) into a Javascript console.

So why is (1<<31) not positive? This is surely something which needs to be fixed in Dart. If they want to make (1<<31) negative, then (1<<30) + (1<<30) should equal (1<<31) and so it should also be negative. Otherwise doing arithmetic is difficult and error prone, which makes it unsuitable as a target for other languages which want to compile down to Dart.

In fact, not having at least 32 bit unsigned integers would be a major drawback. For efficiency reasons you want these to be handled directly by your VM using integer assembly instructions. This is the only way that you'll ever implement efficient bignum libraries for example which require FFT's which necessarily use integers that are an exact multiple of 32 bits in length (Z/pZ for p = 2^(2^L) + 1 usually, where 2^L is a multiple of 64 at least, usually).

From the Dart documentation:

"Integers are not restricted to a fi xed range. Dart integers are true integers, not 32 bit or 64 bit or any other fi xed range representation. Their size is limited only by the memory available to the implementation"

So they obviously haven't got this right. Not only does their implementation not implement this, but it is completely broken anyway because you certainly won't be more efficient than Javascript if your integers are implemented as bignums instead of floats.

Has programming language creation maniacs took over Google or what? What happened to Go. Why Google thinks that they can steal our precious time with these stuff. Why don't they eat their own dog food first and benefit from the nutrition and then develop sense of urgency to share it with world! I even regret to take time to write this comment.

Here's a little valid Ascii art program with Dart

  main() { var _ = 1;
  ;;             ;;
  ;; ( (){ }() ) ;;
  ;; (_  ^_^  _) ;;
  ;; {;  _|_  ;} ;;
  ;;             ;;

It seems that the "hello world" dart example compiled into Javascript takes up 538KB (though after closure advanced compilation, this drops to 30KB - still much larger than the 20 bytes of JS).

Unless the compiler is improved a lot, dart->js' runtime overhead probably makes it impractical for any app less than gmail-size.

It seems to me that Dart is to JavaScript as Vala is to C. Both Dart and Vala compile to their target languages, have syntax similar to their target languages, are additionally influenced by relatives of their target languages (Java for Dart, C# for Vala), and add an object system onto their target languages.

I was honestly hoping for an Open Intermediate Representation of web languages to be part of the announcement. One that both Javascript and Dart could target so developers could ship binaries to the browser. I am disappointed in the language and I am disappointed in the lack of imagination from Google.

Looks like an extended javascript with strong typing and more OO support, is it designed to replace javascript?

It seems to be very misguiding when designers of some new programming language are heavily biased with some business needs or platform selection.

Programming language is not just a technology. It's a way of communicating my thoughts. I don't want to think and write (and read!) in just an _efficient_ language.

The incorporation of bignums is interesting - i'm curious how does that works when compiling to javascript (where double is the only numeric type)

does that mean all integer math is emulated? Long emulation is slow enough in GWT, but you have the choice of using int if you don't need a long.

Wow, indistinguishable from java. Statically typed and uses generics. Are you kidding me.

Dear Google: seriously? :(

VM snapshots for fast startup are potentially nice. But what's the format going to be like? Any realistic chance this will work with multiple browsers? Would need to be something closer to Java serialization than LISP-ish VM imaging.

Erlang style actor model and OO? I can just say awesome! The possibilities are endless.

I know many HN readers subscribe to my JavaScript, Ruby, and HTML5 newsletters so a public service announcement.. http://dartweekly.com/ is up and will be publishing soon :-)

I fail to see what Dart accomplishes that other languages don't already accomplish. Not just syntactically, but all things considered -- runtimes, compilers, etc.

Sorry to be critical, but this looks like technology for technology's sake.

Isn't this what coffeescript is, just that cs does it 100 times better

static methods, inability to add behaviour to base objects, no metaclasses

It's early days, and they haven't presented yet, but son I am disappoint.

I guess I'm not super-excited about it because I was expecting something revolutionary, but when you think about where they're coming from, it was to be expected. Lars and co are simply building on V8, so it makes more sense that Dart is some sort of improvement on javascript, rather than something entirely new.

but +1 to noSuchMethod()

It doesn't look like to support JSON anymore: http://try-dart-lang.appspot.com/s/86QN

This works though: http://try-dart-lang.appspot.com/s/M1wN

It just doesn't have the syntax for maps that javascript has for objects.

It appears to work without dot-notation: http://try-dart-lang.appspot.com/s/kJ4N

I was expecting first class language support for asynchrony, to get away from nesting and error handling JS hell

And this website is not written in Dart.

There is something magical about programming languages, and I just felt motivated to continue studying PLP.

I see a lot of comments on : braces, semicolons ? Do they really matter for serious programmers ?

Will this language gain more traction than Go? What do you think?

Why do languages still require semicolons in this day and age?

YAPB Yet another programming bla-nguage

From whatever little I see, I am already hating it :-) This looks like Java for Javascript, if that makes any kind of sense. We are in the year 2011, PL design has progressed so much since 1990 that such an anachronism is unpardonable. I sincerely wish that companies like Google focus on hiring the right kind of person for designing programming languages.

What is frustrating is that there are so many people who can do this job right, yet we are stuck with amateurish programming languages designed by companies like Google. Please try and hire people like Oleg Kiselyov, Simon Marlow, Erik Meijer or some one from the possible hundreds who have worked deep in PL theory for literally decades. On the face of it Gilad Bracha has great credentials, credentials that would make the HR folk happy but one look at some of the stuff he writes and we know things are not going to be good.


I think Phil Wadler gave him more respect than was due in the comments :-) Microsoft hired Anders Hejlsberg for .Net which I don't think was a good idea, he is a great engineer but not a PL theory expert. They however "rectified" the situation by hiring Erik Meijer later and his impact via LINQ and F# and improvements in C# is obvious. Not to say that Hejlsberg is not good, but Meijer is better. Getting back on track, I may be wrong but Dart makes me groan. It is one thing to design such a language in 1990, but quite another thing to do it in 2011.

Agree with parent comment. My opinion, so far:

Overall: uninspired. Below what I was expecting. Probably good for Google goals (tooling, migrating developers, etc)

The language is somewhat interesting, but unfortunately saddened by an incredibly boring syntax. At this point, I am thinking that they would have been better off just going with the Go language for this. Looks like something good to migrate fleets of java engineers to, but not something that would inspire "hackers".

Now I feel like it is not worth to create any "brigthly" IDE whatsoever. Just go with eclipse.

I was planning to immediately rush to the language. But changed to wait and see now.


  - Incredibly uninspired, boring Java-like syntax.
  - Not everything is an expression.
  - Java-like classes, instead of anything more interesting.
  - Lacks simplicity, symmetry and beauty.
  - Semicolons.
Some notes:

  In Dart, you can often create objects directly from an interface, 
  instead of having to find a class that implements that interface
What?? Why to blur the concepts of classes with interfaces and introduce a quirk? Beauty comes from simplicity and symmetry.

  named constructors:
  var greeter = new Greeter.withPrefix('Howdy,');
Mildly interesting.

  Every type in Dart is public unless its name starts 
  with an underscore ("_")
I laughed at this. I always have hated the practice to start with "_" for supposed private variables, in languages without true private. I like it this way in Dart. My little favorite syntax feature until now.

Can someone explain to me what's the point of having syntax like:

`var foo = new Bar()`?

Why can't a constructor just be a regular method that happens to return a new instance? What's with this new nonsense?

I agree, this syntax makes little sense in dynamic languages where classes/types are first-class values that share the namespace with functions and ordinary values... Even in JavaScript, where it sort-of-kind-of makes sense, it introduces more problems than it solves.

Nitpick: you can make a constructor look like a regular method that happens to return a new instance, but you cannot make it one. How would that constructor make the instance that it returns?

I think the overhead of adding that 'new' is worth it. Without it: in var foo = Bar(), is Bar a type or a function? If you decide it should be colored like a type, your syntax colorer needs deeper information about the code, making it harder to write, slower, etc.

Not true, look at Objective-C for an example of how it's done. Broken up into two methods, the first of which is a static method which creates an uninitialized instance, and the second which is a plain method which initializes the instance and returns self (or rarely, nil):

    + alloc // reserves memory and creates an instance
    - init // initializes the instance
    - initWithSomething: // can have multiple inits

I go back and forth on whether I like this. On the one hand, the clean split makes it conceptually simple what's going on. On the other hand, you can have allocated, uninitialized code, which makes me uneasy.

You always chain together `alloc` / `init` calls, and so you're hardwired never to have a situation where you don't initialize something you've allocated. I think the compiler even knows to warn you about it, now.

>but you cannot make it one

Why not? It makes no difference whatsoever. Make it so that the only constructor in the system is Object.new(), and so everything else that inherits behaves just like a method.

>Without it: in var foo = Bar(), is Bar a type or a function?

That's easy. Make it so that only classes and consts can be capitalized.


I agree with you about the syntax - I was hoping for something more like Python.

Perhaps this is by design, though? Presumably the syntax doesn't look too bad to people who spend all day writing JavaScript (i.e. the target demographic for this language).

Presumably some bright spark will eventually write a Python-to-Dart compiler and then we'll all be happy :-)

When you're trying to change things, it's best to appeal to the early adopters and to do give them a real reason to switch. Making it look the same and appealing to the same "user base" won't work, because then they might find little reason to switch in the first place.

Staying with the norm worked out quite well for both Java and C#.

When I learned Java in 1996 I did not already know Haskel, Lisp and Python. Now I do.

I learned LISP and Python before Java and C#. The latter two are just as useful nevertheless.

The world's experience outside of HN makes me think Dart will not be at all inhibited by its Java like syntax. If it doesn't catch on, it will be for other reasons.

> I was hoping for something more like Python.

Me too! We already have a very readable, simple and elegant language, let's use that. Anyone know why that wouldn't have worked? (Not using the current CPython implementation but maybe the same syntax but with a different (web-only) set of libraries, that is...)

That's almost exactly what coffeescript is.

With Source Mapping in browsers, it also means you'll be able to get a .coffee line in your tracebacks too.

I agree. Yes, I would have liked to just have coffeescript as their new language. Maybe they could have just supported direct native execution on Chrome. Maybe Firefox would have followed.

CoffeeScript solves most of the problems with JavaScript's syntax, but the problem they're trying to solve here isn't the syntax, it's the structure and semantics.

Because Python's semantics are fucktarded.

I interpreted (no pun intended) this all to mean is that Dart is aimed at people who spend all day writing Java.

  In Dart, you can often create objects directly from an interface, 
  instead of having to find a class that implements that interface
What?? Why to blur the concepts of classes with interfaces and introduce a quirk? Beauty comes from simplicity and symmetry

Sounds like Java's anonymous classes. Quite a useful feature, actually.

Sounds like Java's anonymous classes. Quite a useful feature, actually.

It's only useful because Java lacks first class functions and syntax for lambdas. This is the single most irritating thing about Java to me. When this is fixed with the release of 8, the only thing Java will be missing is a really good implementation of persistent data structures a la Clojure.

I agree that the syntax and semantics are uninspiring (you could say the same about Scala).

Where it shines IMHO is in the core library (http://www.dartlang.org/docs/api/index.html). Look there and you will find some interesting classes that deal with concurrency and asynchronous operations (Isolate, ReceivePort, Promise<T>). Also, unlike standard Javascript, there are collection classes for specific use cases (like Queue, Set, LinkedHashMap). This is where it is superior to both Javascript and mainstream static typed languages like Java.

  - Incredibly uninspired, boring Java-like syntax.
Syntax should be boring. It should not deviate from one's expectations. One should not spend any mental resource thinking about it.

What does "boring Java-like syntax" mean? Can anyone show some quick examples of a boring and a not boring syntax?


    some_string += "\n"

Edit: Someone's in disagreement with me, so I'll try and clarify. I'd classify boring code as code where the intent gets lost in the syntax/language or other constructs the maintainer of the code doesn't care about but are required anyway.

Trying to open and read a file in Java is probably a better example as the intent (open this file and read the contents) is buried in about 6 lines of boilerplate code

I use Java as an example because in a previous life I used to write it and see this as perfectly acceptable

Well, for one you can probably make your own "+=" for strings, if not available, since Dart has operator overloading.

Also, System.getProperty("line.separator") does not translate to n"\n".

The first makes your program more portable. Of course it could be made accesible easier, eg as a constant System.NEWLINE or something.

[UPDATE] Downvote? Really? Because someone thinks "\n" is the same as "line.separator"?

Indeed they do not translate into the same thing. But neither makes your program more or less portable in itself. It all depends on what you want to use it for. Some files and protocols should always have \n some always \r\n while in some cases it should be the system line separator. I think Python, Perl, C, and Ruby have fixed that quite well by making the IO library do the conversions. I do not remember if it is the same in Java.

I didn't downvote, but see universal newline support in Python http://www.python.org/dev/peps/pep-0278/

Of course they could have taken perl's tact and defined "\n" to mean System.NEWLINE not 0x0A.

That would have been an improvement right there.

    Circle my_circle = new Circle();
I have to type the word circle 3 times to define a circle. It gets boring. This gets worse if you are trying to do any kind of user input.

    BufferedReader my_reader = new BufferedReader(new InputStreamReader(System.in));
Had to type reader 4 times. :(

People can argue with "boring", call it redundant instead and you'll get less harsh feedback.

Dart doesn't require the type.

var c = new Circle();

But then it appears to just turn off type checking. This would be the cakiest cake ever for even a shoddy type inference engine.

But is it something people actually type? I haven't played with Java for almost ten years now but I do C# for a living which is pretty similar and I can't remember the last time I had to type something that long, Visual Studio does it for me. I can see the point if you say it's longer to read but it's also much clearer, isn't it?

Redundancy is noise.. How is it any clearer to read?

How's that redundant? In C# you would just "var something = new object()", so there wouldn't be any redundancy at all.

I was replying to:

"Visual Studio does it for me. I can see the point if you say it's longer to read but it's also much clearer,"

So he's saying that: Circle circle = new Circle() is typed by Visual Studio for you, and clearer to read. I don't think it's clearer to read.

It's kind of a misnomer too, because only the second circle is typed for you so you had to type Circle at least once... which is the same as if you were typing var. So it's not only not saving you much effort it's uglier. And with more complex types it's downright evil (to not use var).

Requiring a function for a simple print statement, perhaps? The demo breaks when you remove the surrounding main() loop.

Default interface implementations are nothing new. In Scala for example, if you create a Map, you can get it to automatically construct a MapImpl, without having to know it. A really common case in many code bases is 1 implementing class, and 1 mock/testing class, and this fits the common case really well.

I think "beauty" is really a subjective consideration when it comes to programming languages.

Also, string interpolation using only double quotes has bothered me in Rails. That was the one feature I saw that they supported, although now that I think about it, Rails probably adopted it as a convention to prevent excessive escaping.

That's Ruby, not Rails. It allows you to influence how your content should be escaped, so you write '\n' instead of "\\n" and '"' instead of "\"", it's actually pretty handy in practice.

I believe this interpolation difference in Ruby originates from Perl which in turn got it from bash and other UNIX shells. I actually like the fact that Ruby and Perl have so many way to quote a string a lot since I have always hated excessive escaping.

> This looks like Java for Javascript, if that makes any kind of sense.

It completely does. And I love that it manages to be completely incoherent with Go, the other "Google Language". That's so symptomatic of what google does on that front.

Weird that a systems language and a web language are different, huh?

I said "coherent" not "identical". They could be coherent on shared features, such as type specifications or variable declarations, which have little to do with the "class" of the language. They're not.

I don't see any reason why the syntax of a systems language couldn't be the same as the syntax of a web language. They can have different libraries available to them for example but syntax doesn't have to be different.

One of the design goals: "Ensure that Dart delivers high performance on all modern web browsers and environments ranging from small handheld devices to server-side execution."

Server-side execution...

One has pointers and no security model and produces binary processor-dependent artifacts, the other has to support untrusted code, mobile code that runs on any device.

Go doesn't really have pointers in the same manner as C, though, does it?

As was as I was aware, you can only have a pointer to an actual object.

Go allows you to take the address of any value. You just can't do pointer arithmetic like you can in C. That is, you can't address uninitialized memory.

I assume you mean "any lvalue"? You can't take the address of rvalues, can you?

Go doesn't define "lvalues," in the spec, but it does define "addressability." My comment would be more accurate if I had said "Go lets you take the address of any value in memory." (stack or heap)

I don't think Go lets you take stack addresses. If you try to do that, it will copy the data structure onto the heap.

The compiler is free to optimize this how it sees fit. Taking the address of a value doesn't necessarily move it to the heap.

I imagine this optimization can only happen once escape analysis is performed. In the general case, address-of moves the data to the heap, or causes it to be stored on the heap in the first place. Correct?


If they had taken Javascript (or if you prefer a more coffee-script like syntax) and added Go's best features: interfaces-as-duck-typing, channels as fundamental types, string iteration over runes rather than bytes then they would have had a nice little language.

The only thing I like is underscore for private variables. Go does the opposite (which I think is a safer approach): anything you want public has to start with a capital. It really works—it is both easy to do and easy to read.

Systems language: move data from point A to point B.

Web language: move data from point A to point B.

Airplane: move people from point A to point B.

Boat: move people from point A to point B.

Voiture: transport des personnes du point A au point B

Car : move people from point A to point B

Yeah, you didn't really get the point. Again.

Systems language and web language are not just a different name for the same thing --like Voiture and Car.

And, no, that their function defined in abstract and in totally generic terms is the same, doesn't make them the same thing.

"move data from point A to point B" can be said for any programming language. As such, it's not particularly enlightening when comparing a language's suitability to a specific task.

Turing-completeness aside, your argument misses the point that a particular language's design, compiler, library, toolset, (heck, even a particular language's community) can make it better suited for system programming or for web programming or for some other field.

Avion: transport des personnes du point A au point B

Boot: Menschen bewegen von Punkt A nach Punkt B

We are talking past each other :) Here is your first comment interpreted through your second one. There is no reason to have different languages, but it's OK to have different jargon.

I might not get the joke. Do you mean this ironically?

There sure is reason to have different programming languages, and it's called specialization (see: necessary engineering compromises).

My first comment says: two objects having the same generic functionality, does not mean that one and the same object can implement their specific (non generic) functionalities.

My second comment says: the same thing, basically.

I mean that (programming) language is a special kind of object that has enough versatility to express any idea in a reasonable form. Historically, our programming languages weren't that good in versatility and made various utterances an universally agreed on pain. But we are getting better and there is no law in the universe saying that we'll be forever stuck in Babel.

To some extent, your point is that Shakespeare is better in English than in its German translation for style reasons. My point is that it doesn't really matter and that an universal language is better than Babel because of network effects. Life is too short to erect artificial communication barriers.

"Historically, our programming languages weren't that good in versatility"

Well, we're not yet to the point that barrier between systems and web programming languages to be eliminated. You seem to imply that the problem is the inflexibility of the languages, but to me it's not a problem, it's a feature: I want different abstractions to work in different problem domains (e.g. systems vs web). So it's not that the languages are not flexible enough, but rather that we, as language designers and users, have MORE flexibility, to use a different tool for a different job.

Also: yes, Shakespeare is better in English than in its German translation. And it's not just the language, it's also the cultural universe that Shakespeare presupposes. For business use, maybe, but for culture I don't like universal languages, network effects be damned. Life is too short to reduce world languages and communication to a lowest common denominator [and that is inevitable, because any wannabe universal language will lack the historical and cultural ties and shared substructure of any particular population).

> Well, we're not yet to the point that barrier between systems and web programming languages to be eliminated.

We are one or two iterations away. Look at this thread. A lot of people were expecting something looking closer to Go. Go itself is an example: statically typed, garbage collected "systems" language. If you ignore the differences in the type system and the slice syntactic sugar, that sounds conspicuously close to Java. And Dart itself sounds closer to Java than Javascript as well. Not that I believe we'll converge on Java, given the glacial pace of evolution in that community.

But the edges of the state-of-the-art are getting closer in this generation. Next generation (5-10 years from now) will be even closer, if not identical.

On a technical note: what exactly do you have in mind when making a distinction between "web" and "systems"? Backends qualify as "systems" in my book and I'd be a fool if I'd want to develop in two distinct languages when there is just one app. Thanks to GWT and now Dart, I don't have to.

Well, by "web programming" in the context of the original comment, I was talking mostly about web backends. If you mean that, then yeah, we'd develop those in one language, in fact we already do in some case (node.js et al).

But I don't qualify that as "systems programming", to quote Wikipedia:

"System programming (or systems programming) is the activity of programming system software".


"System software is computer software designed to operate the computer hardware and to provide a platform for running application software".

Go is a systems programming language, not a web programming language. It's like saying Javascript is incoherent with C.

Yes, science forbid they be coherent on the exact same feature such as a type specification.

Do you even read what you write?

Why should they resemble each other? They are unrelated languages produced by unrelated teams for unrelated purposes.

The language does look less cumbersome than Java though. In terms of how interesting I find it, I would place it between Java and Haxe. While I cannot see what it buys you that CoffeeScript or even JavaScript do not, I do not have Google's vantage point to be able to adequately judge. I am only at the foot of the mountain they already scaled. And then tunnelled.

Not only did they create V8, they write many boat loads of JavaScript so they are well placed to address both the technical and human pain points of scaling JavaScript. And in introducing a new language they can't stray too far from the mainstream if they wish large adoption. All that said, I am not moved.

Also, F# is Don Syme's work not Erik Meijer's. Although F# probably gained from some Haskell people in Cambridge (the original one).

I'm in two minds about it. Firstly I was hoping for something like a simplified Scala or a slightly extended Go. Its not either. On the other hand the surprise of seeing it coming out looking so mainstream (i.e. its a mix of javascript and java) is a reminder that really the language doesn't matter that much. The blub paradox is not half as important as one intuitively gives it credit for. See Peter Norvig's comments about how C++ programmers can be as productive as Lispers. Look at something like the iphone. The implementation behind the shiny interface is boringly mainstream, C, objective-C with standard OO GUI framework. Like it or not Google and Apple are about engineering and getting things done. From that point of view something like Haskell might improve things slightly but not half enough to make a significant difference to the end product. i.e. it just doesn't matter.

In summary when I saw the language this morning my first thought was: "Nothing to see here". But as a result my second was: "Get back to work". Maybe that's not so bad.

It sounds like there's a lot of PL innovators† here on HN, who value new technology for its intrinsic value, rather than for its benefits.

I would expect PL theory to deliver great benefits at about the same rate as for other fields, e.g. that pure mathematics does for physics - some of it does; though it's common for it to be reinvented independently by people trying to solve specific problems.

BTW: Notwithstanding the over-general flame-bait title, I think his "types are anti-modular" is really just making the point that, while interfaces reduce your dependence on implementation, now you depend on interfaces. i.e. The problem with using types to hide decisions that you think will change is if your prediction about what will change is wrong. "On the Criteria to Be Used in Decomposing Systems Into Modules" http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/crite...

Perhaps one solution is to specify all the types you use in a module, internally; and provide a mechanism for converting between equivalent types at the boundary, to remove the dependency while facilitating interoperation. This mechanism acts as a buffer or glue (or middleware) - a kind of interface between interfaces if you will.

Although the technology adoption lifecycle gives the impression that a new technology with interesting properties is just the beginning of great things, the vast majority of new things do not become massively successful - it's just that the lifecycle is based on those that were. http://en.wikipedia.org/wiki/Technology_adoption_lifecycle

It is easy to agree that there MUST be essential dependencies between modules in a system designed separated in a certain way. (Ignoring some philo arguments on identity, separation and reference point...)

The issue is whether the interfacing technique adds in non-essential coupling. A technique that has at least the constraints of another technique will also have trivially have at least the non-essential coupling of the other technique.

Types add constraints, thus increasing coupling (and decreasing modularity).

Although types have benefits. And direct modularity is seldom the only concern. I.e. Correctness and reliability also enhances modularity in an indirect way - an erroneous module definitely decreases modularity.

> The issue is whether the interfacing technique adds in non-essential coupling. A technique that has at least the constraints of another technique will also have trivially have at least the non-essential coupling of the other technique.

I'm not sure exactly what you mean. Could you elaborate please?

I'll clarify my view with an analogous example: you can think of a database as having a set of types - its schema. Think of each of the applications that use that database as also having its own set of types - its classes or data structures in general. Now, an example of the "mechanism" I mean is that SQL provides a way for each app to translate data in the database's schema into its own data structures. If its data structures change, the SQL can change to adapt to that; similarly, if the DB's schema changes, it can also adapt by changing SQL (or even creating a virtual schema with another layer of SQL - a view). Of course, this only works if these are only changes of the representation of the information, and the information content itself is the same. If the information changes, in a way that the DB or an app depends on, then there's no avoiding that dependency.

A similar example are JSON/XML API's, where the JSON/XML is like the DB, and the data binding code is like SQL. The "type" of XML is often explicitly defined with an "XML Schema" document; JSON doesn't usually have that, but it is of an implicit expected form - which is still a type, just informally defined. There are also tools for converting between XML types - XSLT, and may GUI "XML mappers" that display two xml schema and let you draw lines between them.

tl;dr These enable "modules" with different types to interoperate without dependency. Each defines its own types at its own boundary, and so can be compiled independently. The middleware glue (SQL/databinder/XSLT/datamapper) facilitates interoperation by converting between types at the respective boundaries of two modules - provided those types are equivalent, i.e. contain the same information, just in a different schema/type.

Does your concept of "non-essential coupling" include the requirement of precisely identical types at the boundary? If so, by loosening that to only require the same information, this mechanism avoids that particular kind of non-essential coupling.

Typing adds constraints - the type must be represented by and implemented in a particular type system. A trivial anti-modular constraint is that interacting modules must all use the same type system. The type system matters too - in Java, choosing from easily implementable types can easily add a lot to the complexity of the data structure, leading to a complex interface (in a more expressive type system, less of this happens).

More trivially, adding types IS adding constraints that are verifiable at compile time.

If compile-time verification of that sort is not essential (or not desired, which is the more general form of not essential), then the constraints are non-essential (or not desired).


Whether you choose to

1. Choose a particular data-structure and implement both modules to pass and receive that data-structure.

2. Specify an interface: The interface requires the data-structure to have certain properties (e.g. some methods work on them). The modules then build to the interface.

3. Specify that an adaptor exist to convert the data-structure to whatever the module requires.

is a somewhat different issue, although the kind of type system used does affect the implementation complexity and effort required.

I've got to say, I'm looking at it and thinking "That's it?". It looks embarrassingly like C# to me.

Other than that: it's got coffeescript's fast initializer syntax, but it's not as concise. It's got types but AFAICT no type inference. No destructuring either.

Only thing I can see it's really got going for it is some basic types which could have been provided as a standard Javascript library (and probably will become one...)

> AFAICT no type inference.

Not yet.

> No destructuring either.

There's a proposal floating around for pattern-matching that would address that too.

This is still early days for the language, so there's a lot left to be done.

I've thought about this, and I don't really think the "early days" defence is really acceptable in this case. If Dart isn't better in some appreciable way than Javascript, it has no reason to exist whatsoever. Equally, why not just adopt C# wholesale (it's even registered with the same standards body as Javascript) and give it a new library suitable for web programming?

Sorry man, accidental downvote. It was actually a +1.

I agree with you, the first impact with the language is terrible, the syntax is too reminiscent of Java. It seems that at Google Java is popular for web apps (GWT, Closure, ...). This must have had an influence.

I still fail to see what are the improvements over Javascript (while they managed to get the syntax worse). I guess a concurrency model, optional static typing, interfaces. Did I miss anything?

As I'm reading through the tutorial, it seems to me that it doesn't even have optional static typing. The tutorial claims:

> Types can help you write and maintain your code, but they don't change how Dart programs behave.

That, in my opinion, is not a type system, it's a documentation system. Writing

  String a = 1;
should crash the program/produce a runtime error in a language with (optional) static type system. In Dart, in only produces a compile time warning.

    void doSomething(String a) {
        // Do something 1

    void doSomething(Integer a) {
        // Do something 2

That's the sort of thing they mean by types don't change how programs behave. You can't easily change or remove the type system because it's tightly coupled with method resolution. If you have an optional type system, the evaluation semantics of the language cannot depend on the type system because you don't want the program to do something different if you are/are not using the type system.

The fact that type errors are only manifested as warnings is a (perhaps odd) design decision, but it doesn't stop them being type errors. They could just as easily made them errors, and String a = 1 would give a compile time error.

Hopefully they'll be a 'warnings as errors' flag for those of us more used to type errors being compile errors.

I like it. It still gives dynamic types like Javascript, but catches a huge class of errors immediately upon compilation. It's exactly what I wish Javascript had.

Yeah, those aren't types, they're merely annotations.

Have you seen ES.next? It's worse. I want to see T39 just start over and aim for the same elegant JS-style solutions that Dart has shown for things like class declarations and a separate int type. Instead they're adding things nobody gives a damn about, like debuilderstructors and shit.

> Have you seen ES.next? [...] I want to see [...] class declarations

Uh... like this? http://brendaneich.com/brendaneich_content/uploads/CapitolJS...

On Anders - you're not giving him enough credit.

C# had a hard constraint to start with - it was supposed to be an easy replacement for Java, it actually started from Microsoft's own Java implementation and it had to ship as fast as possible.

Even so, the language evolved nicely as they left room for improvement in a forward-thinking manner.

Also, C# 1.1 did have 5 things which I terribly miss from Java - delegates, P/Invoke, stack-allocated types without "special" exceptions, object properties and the GAC. From a theory-standpoint, none of them are groundbreaking, but we are talking about a language that's supposed to be grounded in real-world constraints.

word. Anders is awesome.

In my opinion, Go is an anomaly in a company dominated by Java developers. I mean, this is a company that has gone so far as to write what is essentially a Java to Javascript compiler. http://code.google.com/webtoolkit/

I wouldn't be surprised if "performance" of the language meant "able to get our vast fleets of mediocre Java developers to write web apps faster" rather than "able to execute faster".

"I wouldn't be surprised if "performance" of the language meant "able to get our vast fleets of mediocre Java developers to write web apps faster" rather than "able to execute faster"."

Yes, because Google is notorious for hiring "mediocre developers".

Or are Java developers especially considered "mediocre" by definition?

Or does dabbling in Ruby/Python/Lisp/Closure/Scala/Haskell make you "non mediocre" by definition?

It's the skills, it's not the language.

I would like to see something with the scope, ecosystem and functionality of, say, Eclipse, written in one of the non-mediocre languages (no, Emacs doesn't come close).

Again this is my opinion, and I say this as a very mediocre developer in a past life and having managed many developers, both mediocre and ninja awesome.

I agree that there are some amazing Java devs out there.

Most Java devs are not amazing (and heck most devs aren't amazing). But Java devs are not amazing with a frequency and depth that both boggles the mind and is entirely expected as that's the point of the language -- accommodate mediocre developers in a large shop producing boring enterprise code.

If you look where it's publicly known that Google uses Java, it's pretty much in Ads. The most boring, enterprisy kind of dev job Google has, but it's the money maker so it has to work despite having unmotivated "I'm just here for the paycheck" developers hacking on it.

Yeah, I know, it was used on the backend of Wave, and via GWT for the Wave web client (which was dog slow btw, I loved Wave, but have yet to encounter a web app as slow). And look where that got us.

As an aside, here's an interesting little writeup about why GWT is bad (with bonus example by pg of all people)


And, at least publicly that's about it. If a dev can't be bothered to just learn the syntax of another language in a couple of weeks in order to properly support their target platform, they are a mediocre developer almost by definition.

Oleg Kiselyov works for the U.S Navy. Don't think he was available. His essays on programming and computation are examples of an astounding mind - http://okmij.org/ftp/Computation/

> Please try and hire people like Oleg Kiselyov, Simon Marlow, Erik Meijer

All brilliant people, but you have to remember that not everyone thinks types are all that matters. I like type systems, but the majority of the world's shipped code was written in languages with unsound type systems.

Then what about "hire people like the creators of PLT Scheme / Racket" - they have extraordinary strong scientific background too.

I have little knowledge of the latest trends in programming languages, but if your example of a good PL theorist is someone who designed LINQ, then I am going to have to take your opinion with a grain.OfType(Salt).Where(m => m.Value.Contains(nothing)).ToList<Salt>().OrderBy(m => m.irrelevance).FirstOrDefault<Salt>();

Actually, you would write that query as:

    var q = from m in grains.OfType<Salt>()
            where m.Value.Contains(null)
            orderby m.irrelevance
            select m;

    return q.FirstOrDefault();
which fits in 80 characters on one screen. From this post and your reply, it seems like the your complaint is that LINQ is hard to understand if you write it poorly. But that's true of most programming.

Yes if you write it like that, it removes one of my complaints, but it leaves the other. You now have inconsistency in the language because LINQ is basically being used as a new type of language added to an existing language. You are working with two languages at once. Why stop there? Why not add python to c#? And every other language. The super language that has everything from everywhere. It is a total mess.

LINQ solves a real business need -- how to access sets of data, regardless of the source, in a uniform teachable way. If you can teach people how to query data structures using a one syntax that is integrated into the language, then you don't have to teach them a different API for every different data source. By encouraging the few API designers to target a standard, the many API consumers can build more reliable code faster.

If you approach it as what it is, yes, a language-integrated query syntax, and avoid the fluent-chaining style most of the time, then you'll see an information-dense productivity booster instead of a "total mess".

The LINQ syntax fits on 1 sheet of paper:

Personally, I look at the two-tier language and library support as a case of "the easy things should be simple, and the hard things possible." That's just my own take, but I find that it guides thought process a little better. I look for a syntax solution first, then rewrite it using a chaining style if I need to (e.g. SelectMany), or possibly split into multiple queries. I don't think I've ever written one longer than 10 lines, properly formatted.

Now, as far as python and other languages are concerned, LINQ is less "python in C#" and more "PEP 202 in C#".

Do you have a specific criticism of Linq, or suggestions to how it could have been designed better?

Yes, it requires a wide-screen monitor. I don't think I can answer the other question as I don't see any value in it. Turning loops and so on into a giant, inflexible (unless you want two wide-screen monitors) daisy-chain of methods does not improve the readability or maintainability of code. It also encourages programmers to perform actions that should otherwise be in "repository" classes, in inappropriate places.

The from item in blah syntax is just SQL rearranged, and SQL isn't as expressive as programming language constructs, so why try to emulate it?

It encourages you to write the grain of salt statement I mentioned earlier, which requires programmers to read through and understand the implementation of what you are doing, instead of it being embodied in a meaningful method and called. Of course you could just wrap that in a method, and slowly grow the line to 2-3 wide-screen monitors as you add more conditions.

The more tools you add to the core of a language, the more of a monstrosity of a kitchen sink it becomes (c#/.NET). Now you can loop over a list in 6 different ways! Hooray! That is why Dart looks good - a few basic concepts that can be used to build things suited to a particular problem.

Well, if your example were meant seriously, it is needlessly verbose. ToList is not necessary in this context, and the type arguments to ToList and FirstOrDefault are not necessary since they can be inferred. And anyway, you can just insert line breaks if you think the chain is too long. So:

          .Where(m => m.Value.Contains(nothing))
          .OrderBy(m => m.irrelevance)
I don't really get your verbosity criticism, sine any alternative I can think of (eg. using for loops) is much more verbose.

I'm not familiar with LINQ, but is that roughly equivalent to

      g.is_a?(Salt) && g.value.blank?
      a.irrelevance <=> b.irrelevance

Ruby tip: Instead of .sort you can use .sort_by.

      g.is_a?(Salt) && g.value.nil?
Edit: Changed from blank? to nil? since that is probably closer to nothing in C#.

thanks. I've been writing Ruby for a few years now and I never knew about sort_by. Looks like is works in 1.8 too, but without the &: syntax

source: http://www.ruby-doc.org/core-1.9.2/Enumerable.html#method-i-...

I actually believe the &:symbol syntax was added in 1.8.7 since I am 100% positive we use that in our codebase which still has not been ported to 1.9.

  $ ruby -e 'puts VERSION; p ["10", "2", "3"].sort_by(&:to_i)'
  ["2", "3", "10"]

Rails adds it too, even if your version of Ruby does not support it. Yay monkeypatching!

EDIT: said duck typing first. It's too early for thinking.

var saltGrains = new List<Salt>();

foreach (var g in grains) {

    if (g.TypeOf() == "Salt" && g.Value == nothing)


saltGrains.sort(m => m.Value.irellevance);

return saltGrains.First();

or something.

Could you enumerate what actually made you hate it? Familiarity is not necessarily a bad thing, and it seems it was one of the main goals of the language.

This http://www.dartlang.org/docs/technical-overview/index.html

A delightfully blank page :-) Yes it mentions classes, interfaces, optional types, libraries, tools, structured yet flexible language. But all of these are a given. Is there nothing else?

What about Generics, Covariance/Contravariance ? Type inference? Odersky thinks type inference in the presence of subtyping is untenable. Is it the same here? Are interfaces linearized as in Scala? What about immutability? It might be too much to ask for rank-2 polymorphism and Haskellish Type Classes but what about support for delimited continuations? Let me guess, these aren't "design goals". All I am saying is this isn't 1990 either.

I guess you should have a look at the language spec, there are answers to some of your questions and concerns. (http://www.dartlang.org/docs/spec/dartLangSpec.pdf)

For example: " Dart supports optional typing based on interface types. The type system is unsound, due to the covariance of generic types. This is a deliberate choice (and undoubtedly controversial). Experience has shown that sound type rules for generics fly in the face of programmer intuition. It is easy for tools to provide a sound type analysis if they choose, which may be useful for tasks like refactoring."

Almost none of those things are relevant to a dynamically-typed language. If you want a statically-typed language use a statically-typed language.

What Dart brings to the table is a dynamic web language that's somewhat more structured than Javascript by using a class mechanism and optional typing. This is a great region of the design space, inhabited by languages like Common Lisp and Dylan.

I know that you were not trying to praise Gilad, but I found that article really insightful and it gelled with my experience with CoffeeScript.

In CoffeeScript compilation is entirely local and highly modular.

AFAICT, Google is a lost cause when it comes to PLs.

Type are indeed anti-modular - types create huge amounts of coupling across multiple module boundaries in ways that are not easy to wrap up, to componentize, if you will. If you create a module A, but the interface of that module (functions, classes, whatever you might have put in it) uses types from modules B and C, is it not anti-modular?

Designs are anti-modular. Types are descriptions of the design. They document the (anti-)modularity. Take the types away and you have the exact same anti-modular design as before.

In so far as (a) the language has a static nominative type system and (b) these types describe values that pass between modules, all modules that work with types defined outside the module will require other modules that use the module to also include (implicitly if not explicitly) the module dependencies.

You can get away from this by having a structural type system, or by being dynamically typed (duck typing ultimately being another form of structural typing). But within the constraints of the type system, you can't get away from this by merely changing the design - unless you put everything into a single module, which is the ultimate in anti-modularity.

"Microsoft hired Anders Hejlsberg for .Net which I don't think was a good idea, he is a great engineer but not a PL theory expert."

Wow. And I thought nobody in their right minds would question Hejlsberg's chops or the work he did for .Net.

He is "not a PL theory expert"? Great. We need less of them in mainstream language design and more pragmatism.

> And I thought nobody in their right minds would question Hejlsberg's chops or the work he did for .Net.

Why not? C# 1.0 was terrible and most of the version since have been exercises in trying to fix it by piling more stuff on, in order to replace previous tentative fixes which did not work for any value of "work" worth using because they lacked generality.

> We need less of them in mainstream language design and more pragmatism.

I hope that's a joke, PL theory experts are nowhere to be seen in mainstream language designs (some have managed to get a claw or two into C# to add actually useful features like... lambdas...), and the "pragmatists" have a field days reinventing problems (not solutions) instead (hello, Go)

C# 1.0 was "terrible" for the reasons of being practical. You can design the most beautiful language in the world, but if all of the features you designed into it add exponential degrees of complexity to the rest of the system (parser, compiler, runtime, base framework, etc) then you're never going to release.

What language do you think was perfect at it's first release?

> C# 1.0 was "terrible" for the reasons of being practical.

No, C# 1.0 was terrible for the reasons of being a slightly improved Java, without some of the baggage (before it created its own, because you can't be a good java descendent without building a pile of legacy garbage) and nothing more.

Fucking hell, I loathe this bullshit about "pratical", it's the most meaningless term since "strongly typed". You know what else is practical? Computed gotos, FORTRAN IV, Superzap, front-panel switches, punch-cards, tape decks and magnetic-core memory.

Releasing C# without generics and half-deprecating all of the collection hierarchy (but leaving it in an undead state by not actually migrating users of old collections) a version and 2 years later was not "practical", it was a lack of foresight. Not having iterables was not "practical" it was "a pain", taking 2 releases to get properties (in the first place, and not so verbose you wanted to stab your eyes out) was not "practical" it was "whelp let's get this shit out now, who cares", having nullable references still isn't practical to this day.

> What language do you think was perfect at it's first release?

None, I've yet to see a perfect language at all. But there's a gap between a terrible language and a good language, or even an interesting language. C# 1.0 was nowhere near a good language. It wasn't even interesting.

And it's not like this shit's new, most of it is multiple decades old at this point (the only language aiming at mainstream I've seen do anything even remotely novel as of late is Rust and its typestates). We're talking about making mistakes which have been solved for 20 years.

> What language do you think was perfect at it's first release?

Algol 60.

I agree with that.

From the very first comment: "We are in the year 2011, PL design has progressed so much since 1990 that such an anachronism is unpardonable."

It's meant to be a language for web development. Catering to the HUGE, EXISTING javascript dev crowd and meant to work with javascript (compile to, reuse staff) etc.

Can we please remove our blinders for a little while and stop whining that it's not like Haskell or any other flavor du jour?

curly braces and semi-colons: welcome back to 1985 again! yawn I return to the snake.

I want node.dart. NOW!

Is there a reason they didn't just call this ScalaScript?

Because it's nothing like Scala?

That didn't stop them calling JavaScript JavaScript...

A mistake that should not be made again.

I don't see a similarity either

A language that compiles to JavaScript really needs better browser support. Decent web apps use feature detection to provide graceful degradation for browsers from the stone age. Dart breaks this by making it impossible to run any code at all.

I mean, "IE9 support coming soon!", what the hell? What about IE6? This isn't a CSS style or an animation library we're talking about.

This is not a product launch.

The lack of browser support implies architectural choices that will always make old browsers lag behind. It means that the generated JS uses modern JS features. If it would be easy to support older browsers, they would've done so already - at least to some extent. The fact that it compiles only to JS for the very latest versions of a small number of browsers gives me the impression that a lot of language/compilation choices are closely tied to these new JS features. This, in turn, implies that supporting older JS versions is non-trivial.

Maybe I'm wrong, that'd be nice.

Or maybe they've only been working on this thing for a few months and were slavishly fixing bugs right up to the announcement, and IE6 support wasn't really a priority?

Except for Isolates -> WebWorkers, there's not really anything that can't be emulated in IE6. GWT has to handle a significantly more complex set of semantics and still works on IE6.

But personally, I prefer if there wasn't IE6 support, or any non-HTML5 browser support for that matter. If you're going to do a new VM, do a clean-break, because legacy support is another factor which makes web development a pain.

> It means that the generated JS uses modern JS features.

I believe it compiles to ES 3, which is isn't exactly "modern JS features". IE6 is ten years old. At some point, you've gotta cut the cord!

Google officially started phasing out support for IE6 in January 2010. It's reasonable to assume that new languages (etc.) released by Google would be aligned with their general policy on which browsers are to be supported and which are not.

Fuck IE6 and all its users.

Wait, I get downvoted and you don't?

Are you defending people (or perhaps friends or family of people) who use IE6? You have absolutely no case there.

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact