Dart language - <AUTHOR> http://www.dartlang.org/ <comment><USER5> 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>

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

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

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

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

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

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

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

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

<comment><USER7> 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!

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

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> 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.

<comment><USER10> 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 - <USER2> more re-packaging.

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

<comment><USER11> Small correction: Go was announced in November 2009.

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

</comment></comment></comment></comment></comment><comment><USER13> 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.

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

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

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

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

</comment></comment></comment></comment></comment><comment><USER17> 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.

        Collection<E>
        HashMap<K,V>
        HashSet<E>
        LinkedHashMap<K,V>
        List<E>
        Map<K,V>
        Set<E>

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

        int
        bool
        String
        Object

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

<comment><USER18> _> 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.

<comment><USER17> 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._

<comment><USER19> That's actually kind of like Haskell.

</comment></comment></comment></comment><comment><USER20> 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.

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

<comment><USER22> 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

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

<comment><USER22> 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 - <USER3> 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...

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

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

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

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> 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)"

<http://www.dartlang.org/docs/spec/dartLangSpec.pdf>

I wonder how they compile this down to Javascript?

<comment><USER26> 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>

<comment><USER25> The model seems slightly different - don't WebWorkers share state?

<comment><USER27> No, just message passing (notionally via JSON).

</comment></comment></comment></comment><comment><USER28> 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.

<comment><USER29> 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();

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

</comment></comment></comment><comment><USER31> 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!

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

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

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

</comment></comment></comment></comment><comment><USER34> 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?

<comment><USER24> Definitely.

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.

</comment></comment><comment><USER35> 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...](https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/client/samples#samples%2Ftotal)) I find this code a lot cleaner than JS versions I've seen.

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

</comment></comment><comment><USER37> 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?

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

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

</comment></comment></comment><comment><USER38> 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?

<comment><AUTHOR> 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...](https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/client/samples/hi/hi.dart) is a more DOM-oriented version of the same program.

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

<comment><USER40> Dart currently compiles to JS that runs on Firefox 4+.

[http://www.dartlang.org/docs/technical- overview/index.html#h...](http://www.dartlang.org/docs/technical- overview/index.html#howtouse)

</comment></comment></comment></comment><comment><USER41> I was hoping for something like the Dylan language.

<http://en.wikipedia.org/wiki/Dylan_programming_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.

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

</comment></comment><comment><USER43> Creating an object:

        Greeter greeter = new Greeter()

or

        var greeter = new Greeter()

Defining a constant:

        static final myConst = 1

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

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

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

        var greeter = Greeter()

there, no need for `new`.

Alternatively,

        var greeter = Greeter.new()

or

        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.

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

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

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

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

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

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER45> 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...

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

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

</comment></comment></comment><comment><USER47> 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...

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

</comment></comment><comment><USER49> 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.

</comment><comment><USER50> 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.

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

</comment></comment><comment><USER52> 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.

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

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

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

<comment><USER34>
        > 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: ->
            ...

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

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

</comment></comment></comment></comment></comment></comment><comment><USER56> 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.

<comment><USER57> "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'.

</comment></comment><comment><USER58> 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.

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

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

</comment></comment></comment><comment><USER60> 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.

<comment><USER61> 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

<comment><USER60> 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]."

</comment></comment></comment><comment><USER62> Hmm. A little underwhelmed so far.

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

<comment><USER64> best comment ;D

</comment></comment></comment><comment><USER65> 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.

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

<comment><USER66> 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. :)

<comment><USER7> 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 ;)

</comment></comment></comment></comment><comment><USER67> 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.

</comment><comment><USER68> Can anyone explain why I should use this instead of other web programming languages?

<comment><USER23> 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...](http://dartinside.com/2011/live-from-dart- launch/#liveblog-entry-102)

</comment></comment><comment><USER69> To me this looks a lot like Java but with optional types.

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

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

<comment><USER71> You really need to make a list of these types of response on your webpage.

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

</comment></comment></comment></comment></comment><comment><USER34> 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.

</comment><comment><USER72> 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.

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

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

<comment><USER75> From the menu example:

        document.query("#menu").nodes.add(sliderMenu.node);

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

<comment><USER21> Not perfect, but I prefer that over:

        document.querySelector('#menu').appendChild(sliderMenu.node);

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

<comment><USER76> 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:

      $('#menu').append(sliderMenu);

<comment><USER21> 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:

        document.query('#menu').nodes.add(sliderMenu.node);

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.

<comment><USER73> how about literal DOM elements?

        #menu.add(.sliderMenu)

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

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

Or a surprise.

<comment><USER78> 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/>

<comment><USER79> > eclipse

Oh. :-(

</comment></comment></comment><comment><USER80> 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?

</comment><comment><USER81> 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.

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

</comment></comment><comment><USER83> 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.

</comment><comment><USER84> 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?

<comment><USER6> 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:

<https://code.google.com/p/dart/>

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

</comment></comment><comment><USER85> 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.

<comment><USER51> Even better, a Google supported node.js _with actors_.

<comment><USER86> Hook.io seems to be a reasonably nice actors implementation for Node.js

</comment></comment></comment><comment><USER87> 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?

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

</comment><comment><USER89> 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).

</comment><comment><USER82> 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.

</comment><comment><USER90> 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.

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

</comment></comment><comment><USER92> [http://googlecode.blogspot.com/2011/10/dart-language-for- str...](http://googlecode.blogspot.com/2011/10/dart-language-for-structured- web.html)

</comment><comment><USER93> You guys need to check out ActionScript, your re-creating it.

</comment><comment><USER94> 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.

</comment><comment><USER95>
         class Sunflower {

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

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

<comment><USER51> Not sure exactly what your problem is since that code won't even compile

<comment><USER95> It's from the documentation <http://www.dartlang.org/samples/sunflower/index.html> ...

</comment></comment></comment><comment><USER96> Hmm.

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.

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

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

</comment></comment></comment><comment><USER97> 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.

</comment><comment><USER98> Here's a little valid Ascii art program with Dart

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

<http://try-dart-lang.appspot.com/s/y8YO>

</comment><comment><USER99> It seems that the "hello world" dart example compiled into Javascript takes up 538KB (though after closure advanced compilation, this drops to 30KB - <USER4> 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.

</comment><comment><USER100> 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.

</comment><comment><USER101> 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.

</comment><comment><USER102> Looks like an extended javascript with strong typing and more OO support, is it designed to replace javascript?

</comment><comment><USER103> 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.

</comment><comment><USER104> 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.

</comment><comment><USER105> Wow, indistinguishable from java. Statically typed and uses generics. Are you kidding me.

Dear Google: seriously? :(

</comment><comment><USER27> 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.

</comment><comment><USER106> Erlang style actor model and OO? I can just say awesome! The possibilities are endless.

</comment><comment><USER107> 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 :-)

</comment><comment><USER108> 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.

</comment><comment><USER109> Isn't this what coffeescript is, just that cs does it 100 times better

</comment><comment><USER110> 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.

<comment><USER110> but +1 to noSuchMethod()

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

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

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

</comment><comment><USER112> And this website is not written in Dart.

</comment><comment><USER113> There is something magical about programming languages, and I just felt motivated to continue studying PLP.

</comment><comment><USER114> I see a lot of comments on : braces, semicolons ? Do they really matter for serious programmers ?

</comment><comment><USER115> Will this language gain more traction than Go? What do you think?

</comment><comment><USER116> Why do languages still require semicolons in this day and age?

</comment><comment><USER117> curly braces and semi-colons: welcome back to 1985 again! _yawn_ I return to the snake.

</comment><comment><USER118> YAPB Yet another programming bla-nguage

</comment><comment><USER119> 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.

[http://gbracha.blogspot.com/2011/06/types-are-anti- modular.h...](http://gbracha.blogspot.com/2011/06/types-are-anti-modular.html)

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.

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

Misses:

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

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

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

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

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

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

</comment></comment></comment></comment></comment></comment></comment><comment><USER123> 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?

</comment><comment><USER118> I want node.dart. NOW!

</comment><comment><USER124> Is there a reason they didn't just call this ScalaScript?

<comment><USER125> Because it's nothing like Scala?

<comment><USER126> That didn't stop them calling JavaScript JavaScript...

<comment><USER127> A mistake that should not be made again.

</comment></comment></comment></comment><comment><USER128> 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.

<comment><USER35> This is not a product launch.

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

<comment><USER35> 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.</comment></comment></comment></comment>


Mathematicians Discuss the Snowden Revelations [pdf] - <AUTHOR> http://www.ams.org/notices/201406/rnoti-p623.pdf

<comment><USER2> Always a pleasure to read a piece by Keith Devlin.

Very interesting to read about his experience of working in the intelligence community and the conclusion that "narrow-and-deep" and HUMINT is the only effective way to counter terrorism without becoming an Orwellian society.</comment>


Everything I Know About Startup Marketing I Learned From Punk Rock - <AUTHOR> http://blog.francoismathieu.ca/punk-rock-marketing?hn

<comment><USER2> sounds very logical - many thanks for sharing this article</comment>


Esports has a diversity problem but these pro gamers are inspiring real change: - <AUTHOR> https://www.huckmag.com/?p=423738 <comment><USER2> I think native trans americans are underrepresented in the gaming community.

</comment><comment><USER3> Aren't these competitions _literally_ open to everyone?</comment>


Richard Branson's top 10 tips for success - <AUTHOR> http://www.bbc.co.uk/news/entertainment-arts-26575792

<comment><USER2> If you see no tips by those who failed then you fail to see the difference between success and failure :)</comment>