Hacker News new | comments | ask | show | jobs | submit login
"Hello World" in Dart, compiled to JavaScript (gist.github.com)
272 points by brodd on Oct 11, 2011 | hide | past | web | favorite | 148 comments

As me1000 (Randy Luecke) says Dart is not meant for hello world. If you run this through closure-compiler it's reduced to 2000 lines which is nothing next to Underscore, jQuery, Dojo, etc.

We all know the benefits of offloading code to a well known and well tested library or framework, especially if you're writing an app that is thousands of lines anyway. How is this contentious at the end of 2011 unless you're just hating Dart for the sake of it?

I haven't looked into the language yet and unless you haven't either let's all refrain from judgements based on this silly metric alone. Circle jerks and knee-jerk reactions are for Reddit, not HN.

Don't get me started on the whining about math performance. Reminds me of dinosaurs whining about how assembly is better than C is better than Java is better than.... There is more to software development than math. Crazy, new fangled, inefficient languages eat the lunch of older languages every single time. You have to be insane to pull out that gem. If math is your bottleneck then don't use Dart, if you know that math is your bottleneck then you shouldn't have to be told this! Sorry for the rant but half of the complaints I've read about Dart are utterly ridiculous, and speculative to boot.

> If you run this through closure-compiler it's reduced to 2000 lines > which is nothing next to Underscore, jQuery, Dojo, etc.

jQuery is 9000 lines, uncompressed with all the comments.

I call that about the same order of magnitude as the things you mention, hardly "next to nothing".

Additionally, just about every line in jQuery is actually useful for something, even the optimized code seems to mostly consist of a whole load of getters and setters and definitions of what addition and multiplication does.

> I haven't looked into the language yet and unless you haven't either let's all refrain from judgements based on this silly metric alone.

Lines of code stops being a "silly metric" when the numbers get really big, as they do here.

> Don't get me started on the whining about math performance. Reminds me of dinosaurs whining about how assembly is better than C is better than Java is better than.... There is more to software development than math.

Surely you didn't mean "There is more to software development than performance." :-)

Easy to pick off "math". But is this stuff not supposed to run in a browser? I'll reconsider when I see a simple application running smoothly on a cheap 3 year old desktop PC.

No, a Hello World program that compiles to 170kloc is what is ridiculous. That you can optimize it to 2kloc is nice, but it's still just a Hello World program.

And a more serious program, how big would that be?

  > "There is more to software development than performance." 
On the other hand, development is all about performance.

It's just a matter of what we mean by "performance". Time to run? Time to develop? Adoption rate? Income generated? Fame?

Software is always about doing something better. The controversy comes when we try to evaluate "better."

> If you run this through closure-compiler it's reduced to 2000 lines which is nothing next to Underscore [...]

Underscore is under 1000 lines unminified and with all comments.

> Circle jerks and knee-jerk reactions are for Reddit, not HN.

> Don't get me started on the whining

What is it with all the hostility from the people defending Dart? How about you display some of this expected HN behaviour yourself?

In general I do agree with you, but there's also some truth to the argument that statically linking only the required dependencies is better than embedding a VM. In a way, this is the difference between CoffeeScript and Dart for client side programming. Sure when your app is really large you'll probably end up with the same thing, but for smaller apps "compiling" should mean "including only the necessary stuff" which CoffeeScript successfully does.

I do have an issue with this trend of building VMs on top of VMs, abstracting further and further away to the point where we're using 1000 times more CPU cycles than in the 80s to run the same Pacman in the web browser. I'm for translation rather than virtualization I guess.

..and here's the jsperf for the --optimize'd hello world vs. vanilla JS - http://jsperf.com/dart-hello-world-test-with-optimize/2. 17k vs. 4M for me

Got any useful benchmarks? Nobody is wondering which language to write their next "hello world" app in.

Just for the record I'm not saying Dart is amazing and everyone should use it, all I'm saying is that we should evaluate it objectively. If raw speed is your bottleneck then why are you wasting time evaluating Dart? Nobody is forcing anyone to use it, you can ignore it and move on with your day.

Dart won't be supported ubiquitously any time soon (if ever) which is why there'll always be a Dart->JS compiler. Why not just stick with vanilla JS or Harmony/ES6? I'd benchmark some bigger apps but they don't exist yet

...and your benchmark makes no sense. You're creating the entire Dart environment every time.


Which is a one time cost - and roughly the same you pay for including any other framework out there.

Name one framework as heavyweight as this.

Underscore.js and Backbone.js put together are 1/8th the size of HelloDartTest.dart.app.js.

jQuery plus dozens of jquery.ui plugins can come close in size, but that actually does a lot. This boilerplate doesn't seem to have much functionality in it.

Let's be realistic with ourselves here: is all that overhead ever going to compete with ten lines of "low level" (ha..) JavaScript? No.

The problem here, and what is making us chuckle so much, is that the project as presented to us is not magical. For whatever reason, some of the brightest minds in our industry have not presented us (at this time) with a cross-compiler that is both robust enough to support large apps, and intelligent enough to self-optimize its output.

Were we expecting a JavaScript killer from Google? Some of us were, with cynical apprehension. Did this release of the project live up to that expectation? Nope. Could others have done a better job? Maybe, maybe not. Could this project improve over time? Certainly. Will Dart become a JavaScript killer without more magic in its cross-compiler? Personally, I doubt it. Tooling may matter for developing large web apps, but performance matters in those large web apps too; running this test in my iPhone's browser leaves me feeling meh.

It makes me think that dart would be a perfect language in which to re-implement OpenDoc.

It is improbably in my mind that we've reached an age where javascript is considered low level -- even tongue in cheek.

I wonder where this is on the path to the singularity?


I moved things around so that what code does is roughly equivalent. As you can see Dart is slower, but the Dart runtime does not differ by a margin that matters for many applications - and note the size of the gap differs significantly between JS engines.

In all fairness, you removed the actual print function from the code. Inspection of the non-compiled source suggests that the entire function execution as shown in /2 is called for every call to Dart's print.

print$getter()(1, $noargs, 'Hello, Dart!'); print$getter()(1, $noargs, 'foo'); print$getter()(1, $noargs, 'bar');

I did not remove print. Google Closure Compiler does inlining as well.

This is called "a runtime". A bunch of things that have to be loaded on the target machine for use by a compiled program. Just about every compiler works this way, whether the output is machine code or JavaScript. It is possible to not emit or load the parts of the runtime which will not be used by a given program, but that's difficult and in many cases even impossible.

I am not a web programmer, and I don't use JS and don't plan to use Dart, but I am flabbergasted that a bunch of techies are going wild and posting facepalm pictures over a perfectly normal technical situation. Maybe Google will pare down the runtime in the future, maybe they will figure out a way to exclude parts of it which are not needed, but right now they are just making the default technical choice that just about all compilers make. This is a non-story. Compile "Hello world" into an executable, and see how many kilobytes it takes on most architectures, despite the object file being a few bytes. Geez.

In general it's true that you can't avoid the runtime, but in this case I think people's expectations are colored by CoffeeScript, which offers (for many) a more productive environment than vanilla JavaScript, with no runtime at all. Since Dart is a CoffeeScript competitor in the "languages that compile to JS" space, this is a legitimate disadvantage. Dart may well have so many advantages over CS that this becomes a non-issue in practice, but we shouldn't pretend this isn't a story at all.

I agree that it's perfectly legitimate to discuss the runtime needed for Dart, and point out that it's a disadvantage that it is needed at all, or to criticize the runtime, or whatever.

What shocks me is that people who are supposed to be techies are pointing their fingers at the runtime and making monkey noises, because they apparently have never seen a language runtime or heard of the concept. Dart did not compile "Hello, world" to 17000 lines of code; most of that code has nothing to do with the specific program. And that's the usual situation for compilers, although some specific compilers can avoid that (e.g. CoffeeScript, which is a close mapping of its target architecture).

The reason we are making monkey noises and pointing fingers is because we expected a better JavaScript, not a Java that compiles to JavaScript. We already have that. It's called GWT and this is just GWT 2.0 with a pretty name.

There's already a GWT 2.0; this is more like GWT 9.0. And as someone who has done a lot of work in GWT (and JS, and CS), I can see a lot of potential in Dart. GWT is superior to javascript/coffeescript for a certain set of problems (mostly fat-client-type webapps); a major upgrade to the language and tooling would be welcome.

> This is called "a runtime". > I am not a web programmer

You see, it's not a spherical runtime in vacuum. In practical terms it's more like a whole lot of stuff to download, parse and execute each time your browser hits a new page.


I bet most of the people including JQuery on their pages only use a fraction of its functionality even though it all must be parsed. So what?

jQuery can be cached.

> I am flabbergasted that a bunch of techies are going wild and posting facepalm pictures over a perfectly normal technical situation

Have you actually met any techies lately?

> maybe they will figure out a way to exclude parts of it which are not needed

This is called "tree-shaking", is fairly standard, and is on the to-do list. I believe it does some now, but I think more is coming.

This thread answers how long a Hellow World executable is: http://news.ycombinator.com/item?id=3098672

So the joke is that a prototype of a whole separate language has to include its runtime in its cross-compiled output? Did people... think this wouldn't be the case? Do they think that Javascript is not thousands of lines of C/C++ lurking in your browser?

Good joke guys, but I don't think you realize which way the punchline is pointing...

It sort of amazes me that people are being so hard on Dart, given that they should be grasping for any chance to leave the warty and dated pile of compromises that is Javascript behind. Even the javascript community seems to tacitly admit that Javascript is a bit of diamond amongst a whole lot of dross; hence CoffeeScript and books like "Javascript: The Good Parts".

"...given that they should be grasping for any chance to leave the warty and dated pile of compromises that is Javascript behind..."

I would not characterize the JavaScript community as desperate graspers, but even so, I don't see the virtue in grasping for the chance to replace a dated pile of compromises with a contemporary pile of compromises. All the hate is totally overblown - this project is young and will likely improve a lot over time - but that doesn't change the fact that what we've seen of this project so far places it squarely in the category of 'novelty.'

Not desperate graspers? Try and count the number of libraries and frameworks that have come out in the last 5 years for JavaScript. Think of how many "to JS" solutions there are. Seriously, google that. Like 20? 25? How much "to C" solutions do you see getting on the front page of Hacker News these days?

It's staggering how much 'grasping' has been happening compared to other ecosystems. It's ironic that people would scoff at a well-designed replacement like Dart in its early stages. The only reason it's fashionable to do so is because it's Google. If this was some independent developer everyone would be falling over themselves to dig in.

"Oh, notch of Minecraft fame played a role? Count me in."

The mob mentality of the programming community at-large is worthy of being called despicable if only for creating precisely these sorts of regularly-scheduled circle-jerk bash sessions. The sessions I'm referring to involve "smarter than you" ass hats who walk around dumping on anything that doesn't "feel" right to them. If you want to "feel" good, go elsewhere. This is about moving the web forward.

Dear Internet, kindly get your head out of your ass.

I'll take the alleged mob mentality over Google elitism any day of the week. Google can try to move the web any direction it feels is appropriate - it's Google's time, it's Google's money - but let's be clear: JavaScript is not as deficient as you might think it is, and the JavaScript community is not dumb to expect more than what Dart has offered so far (in an admittedly short span of time).

"There are just two kinds of languages: the ones everybody complains about and the ones nobody uses."

Probably over-quoted these days, but I think we all know where JavaScript falls.

"Probably over-quoted these days, but I think we all know where JavaScript falls."

Well, if the distinction is between the ones nobody uses and the one "everybody complains about", then we also know where Dart falls...

It's off to an auspicious start ;)

Wow. What I'm seeing so far is the people critical being entirely reasonable (if perhaps misinformed), and the people defending Dart being positively hostile about it, calling "circle-jerk" left and right.

This post takes the cake in hostility, so far, though.

And what's it need defending for? Some people try to discuss the merits and flaws in a reasoned manner. The childish behaviour you speak of is entirely yours.

I'm seeing some pretty spurious arguments. The idea that semicolons would be a point of contention is mind-blowing to me.

"well-designed" is actually the point of contention, is it not? You're blithely asserting facts not in evidence.

Smart, experienced people "taking a dump" on things that "don't feel right" to them are in fact valuable and worth paying attention to (even if you ultimately ignore them).

There are many, many cases of teams of brilliant people producing deeply flawed stuff that turns out to be useless. Apple's ATG produced many useless products on top of Lisp back in the day (SK8, Dylan,...). Dylan in particular was "well-designed" for certain values of "well-designed" that turned out to be insufficient — time will tell, but don't assume talent + money -> useful.

Google right now "feels" a lot like Apple ca. 1993.

> Think of how many "to JS" solutions there are. Seriously, google that. Like 20? 25?

What do you expect? The most important platform to write software for only accepts a single language. It doesn't matter how good the language is, people will be writing things that get converted to that language.

> How much "to C" solutions do you see getting on the front page of Hacker News these days?

Well, there's ShedSkin, and HipHop. But that's not the point. Anything that can run C can run [arbitrary other language]. Because, often enough, that arbitrary other language was written in C. Surely, by your terms, everyone who programs in Python is a desperate grasper hoping to escape C?

    The only reason it's fashionable to do so is 
    because it's Google. If this was some independent
    developer everyone would be falling over themselves 
    to dig in.
Except that there's nothing released to "dig in" and if this came from an independent developer I would barely open the link.

Amen. The "me too" culture that's going on w/r/t Dart is really disappointing.

Google: "Hey everyone, let's make the browser better by switching to something that smells less like garbage than javascript."

Community: "You forgot a semi-colon!"


Sorry but it's been more like

Google: Hey everyone, we have decided the future, here it is, get used to it.

Community: Maybe you should get behind Harmony instead of secretly building replacements to the building blocks of the web and issuing them by imperial decree.

There was an internal memo. They're going to push it. Why do you have to "buck the man" in order to feel like you're in control of your tools? Why does it need to be repeated that everyone has a choice?

If Dart grows and solves some of the junk I have to deal with in the JS ecosystem, I will use it. We'd all be fools not to.

Wouldn't happen to be a Flash dev would you?

I do not want the core technologies on which the web is built owned or controlled by any one company. No matter how you look at it Dart is not a standard, it's not controlled or directed by any open body and its development is not public.

It took a goddamn decade to break Microsoft's endless attempts to own core web technology, if you're happy with another company doing it just because you think they're a 'nice' company you're the fool.

There is a large, public and active effort to solve many of the issues JS has, it's called Harmony. Maybe you should get involved with that instead of jumping on a proprietary bandwagon.

"Dart is not a standard, it's not controlled or directed by any open body"

You say that like it is a bad thing. I don't think it is.

Standardizing technologies is great once they are mature and are already accepted as the obvious de-facto standard, but trying to push real change through standards bodies results in exactly the sort of morass that JavaScript has been stuck in and which makes Dart a refreshing attempt at change.

Yeah, yeah, the great new version of JavaScript will be here next year, same as it has been going to be here next year for the past 10 years.

When it comes to making real progress you almost always need to buck the standards and drag the world kicking and screaming into a better future and then let the standards bodies figure out how to fit things in to their world later on. I'm continually shocked there are so many people in this industry that don't see this even though the proof for it is everywhere.

I'm not sure Dart really is the better future we need in a client-side language as there is still a ton more work to be done (the technology is far less baked than I expected it would be, even though it is only a preview release), but I applaud Google for trying and I'd suggest other players trying to sabotage their efforts should redirect their own efforts into something even better than Dart. Win on the merits of the technology, not on slavish devotion to existing standards. With increased competition everybody wins, especially if everyone uses an OSS model as permissive as Google is with Dart, and maintains JavaScript as a legacy lingua franca.

> exactly the sort of morass that JavaScript has been > stuck in

You mean the one where some large corporations are doing what they can to keep it from improving?

Seriously, Google has been sabotaging all sorts of JavaScript improvements by flat-out refusing to implement them.

So in fact the "other players" _are_ directing their effort to something they perceive as better than Dart: Harmony.

As for the rest, what will "win" is not necessarily going to be based on the merits of the technology but on the strength of single-vendor tie-ins, in the usual way....

JavaScript was stuck in the mud before Chrome or V8 even existed. Before Google, Microsoft and Yahoo got the blame.

Regardless of who the actors are that are most currently gumming up the works, all of this just proves the point that standard bodies are not an effective tool for actually creating useful technology.

There was all sort of innovation in JavaScript going on at the time; still is.

As you note, getting the innovation into a standard is the hard part, when some of the parties to the standards process don't actually want the language to improve...

But Google claiming this is a problem for JavaScript while it is one of those exact parties is just hypocritical.

Mozilla has been implementing new ES Harmony features for a while. Proxies work now. Strict mode works now. Let, const, destructuring assignment, generators, they all work now. V8 hasn't gotten around to implementing a lot of that stuff, but that's its problem.

This was explicitly announced as "work in progress", "please give us feedback", "this is the first impression" and so forth. If you read the language spec, it has "we don't know how to do this yet" and "we're requesting feedback on this" all over the place.

I really fail to see the imperial decree part here. In any case, JavaScript is there, it's supported by Google (and really only has been made viable by the speed improvements triggered by V8's development), it's not like anyone is taking anything away.

I think you overestimate the impact of V8 on JavaScript speed improvements. Both Apple and Mozilla were working on JITs well before V8 was announced...

> Community: "You forgot a semi-colon!"

The user is king. If Google doesn't give a shit about dart's users - ie programmers - then why should we care?

mate, it's not all that bad. people's reactions here will have pretty close to zero impact on the long term success or otherwise of Dart; programming languages are still much of a meritocracy

that said, wading in and telling people the things they like smell like garbage isn't the most effective way of getting them onside. If you're going to do that, then what you're selling better darn well blow their socks off, and Dart isn't doing that.

personally, I really enjoy writing js (and I have a growing love for coffeescript as well) and I don't feel Dart offers anything I need yet. I'll wait and see what happens

Yes, but I don't have to download the umpteenth thousands of C/C++ code that comprise the javascript engine and compile that each time I download jQuery.js.

Now, to be fair, I did a check of Lua, and it's 16,370 lines of C code (version 5.1.4, with all the current patches), so yes, 17,000+ lines of code for a VM doesn't appear quite that bad. I think what most people are complaining about is downloading that each time they hit a dart script.

Funny. But to be fair, a Hello World in C compiles to a 27k binary. Yeah yeah, optimize this, leave out that and you can get it smaller. Still doesn't change the fact that Hello World is not the target use-case for either C or Dart. Dart is intended for very large applications (compared to JS), so the additional weight for includes isn't that big of a deal.

It also doesn't change the fact that Dart sucks. For other reasons though.

On 32-bit Linux GCC, C hello world comes out to only 7 KB. Without optimization.

Just as a datapoint (I did this test before seeing the comment), in 32-bit cygwin a hello world written in C compiled to 12KB. In C++, it compiled to 497KB.


I'll repeat what I said in the GitHub thread:

There's this interesting tool called Google Closure Compiler. It does dead code elimination. https://gist.github.com/1277285

Notice that this source is now 2000 lines of pretty printed JS. Given that anything interesting these days uses jQuery or Underscore.js clientside, and similar things serverside, this amount of JS for even Hello World is standard fare.

EDIT: To be clear, I don't really give two hoots about Dart ... yet. I use ClojureScript and since ClojureScript ships with a similarly rich API / data structure set, Google Closure Compiler is essential to keeping code size down.

I'm sorry, but 2,300 lines of code is in no way acceptable as a "dead code"-eliminated Hello World program. Not by a longshot.

If all you use javascript for is console.log("Hello World"); then v8 will seem unnecessarily large too.

If all you do is one DOM transformation then jquery will seem huge compared to just doing it by hand (probably hundreds or thousands of lines of code vs 3).

I guess at this point I'm just repeating the OP, but this is simply in no way demonstrative of Dart. It can at best serve as a learning tool of the internals (and perhaps there are valid criticisms once you look at those), but any conclusion on code size is very flawed from this one example.

jQuery is huge compared to doing it by hand, and I actually chose against jQuery for a web service targeted at mobile phones.

However, in the case of jQuery the productivity / KB ratio is freakishly huge.

I fail to see how that will be the case for a new programming language. Javascript is already fast and still improving in bounds and leaps. It is also finally possible to write correct cross-browser code with the help of jQuery and CoffeeScript. It is a true standard.

What can Dart really provide that Javascript cannot?

Refactoring tools? Some people would like that, but it still won't be bullet proof (as I understand the static types in Dart are optional), and there's nothing worse that a tool on which you can't rely on (personally I hate the Intellisense attempts being made in IDEs for Ruby or Python).

What about speed? Well, Java/Quake2 was compiled to Javascript using GWT and it worked just fine -- what more could you want from a sandboxed environment? To me, these days big page load times either on my desktop or on my mobile are almost always related to bandwidth.

v8 actually runs the code, though, so it's not an accurate comparison.

(That said, this thread is just silly. I don't like Dart because it looks like it's built for obsolescense, but the hello world extrapolation is nonsense, as has been pointed out.)

What language do you program in where the dependencies are not as heavy as they are here? The only difference I can tell is that it's hidden from you.

The other difference is that they are not transferred over wire (once if developers were careful or on every request if they were not).

  $ cat hello.c 
  int main() { printf("Hello, world!\n"); }
  $ gcc hello.c
  $ ls -l a.out 
  -rwxr-xr-x  1 brian  staff   8.5K Oct 11 02:23 a.out*
And that's compiled code! And it also links to libc! But then again, any JS program requires tons of compiled C/C++ code to run.

See here for an effort to create the smallest possible hello world x86 ELF binary: http://timelessname.com/elfbin/

His original C app was about 6k, and 3k when stripped of debug symbols. Not content, he switched to assembly, which got him down to ... nah, I won't spoil the rest. ;)

That's dynamically loaded, try it with the runtime

    $ gcc hello.c
    $ ls -l a.out
    -rwxr-xr-x 1 maht maht 4511 Oct 11 16:38 a.out
    $ gcc --static hello.c
    $ ls -l a.out
    -rwxr-xr-x 1 maht maht 574106 Oct 11 16:38 a.out

Do you even understand programming? It includes the runtime, dammnit.

A C hello world (#include "stdio.h", int main(void){printf("Hello World\n"); return 0; }) produces an 8K executable on my Mac.

8K --you know, they used to write whole games in 8K.

If it's 2kloc for dead code eliminated "Hello World", how much would be left of that to eliminate when you actually write a program that does something?

Because I'm assuming once your program starts doing more complex things it'll actually need the rest of those 170kloc and be able to eliminate a lot less, right?

While if you make a complex program that uses basic jQuery, jQuery stays the same size.

Oh yeah, 2300 lines of gibberish JS and FSM only knows how many global variables and functions is a real improvement.

the original example should "compile" to nothing more than the following:

(function () { window.HelloDartTest = { testMain: function testMain() { console.log("Hello, Darter!"); } };

HelloDartTest.testMain(); })();

This is false. It is like claiming that it "should" really compile to just console.log("Hello,Darter!"); They're functionally equivalent so why not right?

Dart was designed for big apps. Google is not aiming at optimizing all the Hello World pages. Every single framework in existence has terrible size characteristics for Hello, World. Loading all of Foundation and UIKit for showing Hello World on the screen in iOS? It SHOULD just magically know to compile to the few commands that show the one text string right? No, that would be a waste of time optimization.

Now, if we start writing big apps in this thing and they are also bloated compared to their JavaScript equivalents then I will agree 100% that there is a problem. But there are just no worthwhile conclusions from the HelloWorld app regarding size. The only worthwhile conclusions are from the high level perspective, aka "how easy is it to write a hello world app".

Well, Dart is designed to replace JavaScript as the client side Web scripting language of choice. Given that goal, they need to do well at small projects as well as large ones.

If Dart ever replaced JavaScript then most code would probably be running under the native implementation and this issue would be moot. I think its acceptable for them to be focusing on the actual problems on the web (writing large maintainable applications), and not focusing too much on image swaps and console logs.

compilers are supposed to optimise what they spit out, so why is this spitting out either a) terribly inefficient code or b) a whole heap of un-used code?

1. Not necessarily, as shown here, Google has a separate optimization step. If you look at the other posts you will see that using other google products, such as closure compiler/etc will make this all significantly smaller. This makes sense. Have the guys who know how to make JS small work on that problem, thus benefiting BOTH hand rolled JS code and Dart-compiled JS code. If not you are eternally having to do merges of the product, the possibility of being on a stale copy, etc.

2. The reason for spitting out "inefficient" code is already described in my post. This is inefficient for Hello, World. That's fine, it may be the proper tradeoff for efficiency in more complex code. Take CocoaTouch for example. If you write a HelloWorld app for iOS and profile it, you could say "why on earth is this app reading in preferences, sending out didLaunch delegate messages, etc etc etc. Doesn't the code KNOW I don't need that and all I want is to show one string". This is an acceptable tradeoff, because all those things its doing are useful for more complex apps. No one is shipping HelloWorld, so who cares if its slower than the best possible HelloWorld? Is it possible to write a compiler so smart that it would even make HelloWorld super small and fast. Sure, maybe, but those engineering resources are much better spent working on problems real applications face. I'd much prefer Apple focus on scrolling performance than HelloWorld. And similarly, I much prefer Google focus on the problem of writing huge web apps that still perform really well, since thats the remaining unsolved problem for the web.

The "other tool" you mention reduces this to 2300 lines, and that's with the "remove unused code" option enabled.

Still fails.

Damn... all the hello world programs I've written in dart just feel like such a waste now :[


Already a solved problem thanks to HQ9+: http://www.esolangs.org/wiki/HQ9

I compiled that code with the google closure compiler. I used advanced optimisations for dead code removal.

The result is 94% smaller - 32k, or 9k gzipped. A 32k overhead could be absorbed by most large web applications without being noticed.


same code in coffeescript (@ preceding testMain makes it a static method and it looks like print in Dart converts to console.log)

    class HelloCoffeeTest
      @testMain: -> 
        console.log "Hello, Coffee!"
resulting js

    var HelloCoffeeTest;
    HelloCoffeeTest = (function() {
      function HelloCoffeeTest() {}
      HelloCoffeeTest.testMain = function() {
        return console.log("Hello, Coffee!");
      return HelloCoffeeTest;


CoffeeScript is meant to be synaptic sugar on top of JS. Dart is a language with different semantics that happens to compile to JS. As such it includes a lot of runtime code. More appropriate examples would be Emscripten, Parenscript, or ClojureScript.

There is a legitimate point here though. If I'm a developer working on a new project, and I'm dissatisfied with JavaScript, I have a couple of options. I could try Dart, which will cost me a significant amount of performance in all browsers that aren't Chrome, or I could go with CoffeeScript, which will have good performance in all browsers (including Chrome, since Chrome will be forced by the other browser manufacturers to keep its engine up-to-date). For me that'd be an easy choice, unless one of three things happens:

(1) Dart's performance is so much better than that of JavaScript that it's worth sacrificing performance in every other browser to get hugely better performance in Chrome. That seems unlikely to me, but maybe it's possible.

(2) Chrome ends up with 90%+ market share, so it doesn't matter that I'm bad in all the other browsers. But I can't see this happening as long as e.g. iOS is around and relevant.

(3) I have the resources to write both a Dart version for Chrome and a CoffeeScript version for older browsers. At this point, Google has strictly made my life harder than it would have been otherwise.

I do want to give Dart a fair shake, but I'm having a hard time seeing how it could realistically succeed.

> I could try Dart, which will cost me a significant amount of performance in all browsers that aren't Chrome

But will it, though? Sure, "Hello, World" transpiles to 17,000 lines of code, but I'd want to see some actual benchmarks of actual code to see what kind of performance hit that implies, before deciding against Dart on that basis.

And then there's the whole python argument about developer time being more valuable, and most applications these days not being performance constrained, etc, that could possibly apply here, as well.

Anything happening in a client browser will involve a significant amount of IO - querying / modifying DOM and remote requests. I don't think that choosing Dart over CoffeeScript is going to make much of a difference for most applications.

See Objective-J / Cappuccino which chose to eat the very real overhead messaging in order to gain expressiveness. How many JS apps are as responsive / elegant as 280 North Slides?

I'm referring mainly to the page load time increase, which is important, especially on mobile. (Given what I've seen of the generated code, I suspect runtime performance will be affected too, but I haven't tested, so I can't say for sure.) This is why people create microframeworks—the page load time improvement with e.g. zepto over jQuery is not insignificant.

> synaptic sugar

Is this a typo, tongue-in-cheek, or a technical term I don't know? I've only heard of "syntactic sugar" myself.

Dopamine is synaptic sugar.

Dopamine isn't a sugar - it contains Nitrogen.

I think he means sugar in the metaphorical sense

I know - couldn't resist though :)

> CoffeeScript is meant to be synaptic sugar on top of JS. Dart is a language with different semantics that happens to compile to JS. As such it includes a lot of runtime code. More appropriate examples would be Emscripten, Parenscript, or ClojureScript.

I think you are correct here. But there is still something very worrying about what Dart compiles into. It isn't just the amount of code, which is what most people are discussing. It's the content too.

The content of the code makes it look like much of that code will be run all the time. In other words, it isn't just some library functions that are called rarely, it is stuff that will end up being called from your inner loops. I might be wrong here, but that's what the code suggests to me.

In that respect, the Dart compiler looks different from both CoffeeScript and Emscripten. CoffeeScript by design compiles into straightforward JS, and Emscripten manages to compile into mostly-straightforward JS as well, which is why it has decent performance. But what Dart compiles into looks like it would not run very fast on most JS engines. It might run fast on Chrome, if they tune its inlining and other capabilities for Dart-like code, but I doubt that would hold anywhere else.

Again, though, I have not profiled the generated code, I just took a look at it, so I might be wrong.

Does CoffeeScript have all these data structures, http://www.dartlang.org/docs/api/index.html?

That's a long list, so probably not. Does Dart have an existential operator?[0]

    zip = lottery.drawWinner?().address?.zipcode
Hey look, I know they're not really comparable. They're solving different problems, are at different stages in maturity and have a different philosophy on how to do things. I also think that Hello World is probably the worst way to compare any two languages, but it's a fun exercise anyway

[0] example code from http://jashkenas.github.com/coffee-script

You can always import JS.Class: http://jsclass.jcoglan.com/

Which is > 300K before minification.

I don't understand why Dart is supposed to be good, someone please explain it to me like I'm an eight-year-old

It's not right now. It's a lousy CoffeeScript. The thing that makes dart good is that it could, some day, have it's own runtime. Also, the language is being designed by the team that did v8. So I'd imagine they plan to build support into chrome at some point.

I agree CoffeeScript has nicer syntax, but it retains all of Javascript's semantic warts. Whatever quibbles you might have about Dart's syntax (it's young yet!) it's semantics are much nicer than Javascript.

Well, except for the unsound covariant generics, the lack of an arguments object, and the implicit downcasts, and so on...

Hint: Dart is a dynamically typed language. The covariant generics and the implicit downcasts are there on purpose.

The lack of an arguments object is a feature not a bug. A rest argument like in Lisp is much better for optimization. The design isn't done yet given that Dart has optional arguments a rest argument would fit in.

I agree CoffeeScript has nicer syntax, but it retains all of Javascript's semantic warts

that comes across as both patronising and ignorant (although it could be me who's the latter). any examples of "all Javascript's semantic warts" coffeescript retains?

> I don't understand why Dart is supposed to be good

It's like Go: "It's from google, so awesome by default".

Go is awesome by default because of Ken Thompson, not because of Google.

And Dart is awesome by default because of Gilad Bracha :P

This reminds me of the very early days of C++ were people would use the size of a compiled "Hello World" to argue their point. C++ targets a completely different domain from JS where the size of the runtime etc. is somewhat important and it makes sense to think about this.

I always thought that JS had this culture of "it works and is fast enough for most users" attached to it, so I'm curious what is so different here? Every JS application nowadays comes with tons of framework code already. Does it make a big difference if you carry around a (non-minified) 17000 lines runtime?

Of course, if you argue about elegance, none of this matters.

While this is hilarious, it's exactly fair. Dart is still in a very early tech preview, and they clearly haven't optimised code generation yet.

Right now, it's probably designed to be run through something like Closure Compiler, which removes dead code and minimizes the output.

Oooooooo. So it's Javascript except with a highly constraining layer of blub on top of it. I'll go back to learning coffeescript then...

I'd say the gist demonstrates that it's not Javascript. What you see is the entire runtime, compiled to naive js.

If anything, Coffeescript is "just" js with syntactic sugar. Not that there is anything wrong with that.

that's a really interesting comment. where exactly is the line drawn between "just syntactic sugar" and "a different language"?

Here we have two ways of expressing code, coffeescript and dart. Both are syntactically quite different from js, both offer features not found in js, both encourage you to write code differently to how you would in js and both compile to plain js.

> where exactly is the line

Not that I have an aswer to that, but I have the impression Coffeescript was designed specifically to compile 1:1 to matching js.

A lot of the distinction seems to depend on the local culture of the language. I've seen a lot of lispers talking about their new "language", where they add some minor feature to scheme.

...Coffeescript was designed specifically to compile 1:1 to matching js

possibly initially, but there's a lot of constructs in coffeescript that aren't in js eg existential operator

    solipsism = true if mind? and not world?
compiles to

    var solipsism;
    if ((typeof mind !== "undefined" && mind !== null) && !(typeof world !== "undefined" && world !== null)) {
      solipsism = true;
see also splats http://jashkenas.github.com/coffee-script/#splats, function binding and comprehensions over collections eg

    eat food for food in ['toast', 'cheese', 'wine']

So this includes the full Dart runtime library compiled to JS, and people make a big deal out of it being a long listing.

It's official now: Dart is meant as a practical joke to show why Javascript needs to be replaced by something sane like a bytecode VM.

Either that, or I don't want to surf this internet anymore.

"Javascript needs to be replaced by something sane" really? You should read what the goals are for Dart.

I think the problem of Dart and Google's many strategies in web application developer tool area is the belief that the current state of web app development is in a very serious terminal illness that requires chemotherapy, with a complete change of how we do things, while many others - notably the CoffeeScript camp - have shown that we are still essentially in good shape and all we need is some herbal tea to help the immune system. I am not discounting the value of the bold move of Google, but I am very disappointed to see a big negligence of the good parts of JavaScript and other dynamic languages and a blind copy of Java (mis)features. I have not seen Google contributing to the common and popular JavaScript frameworks like jQuery (and Microsoft did... what a strange world). Maybe it's NIH syndrome at play.

They obviously embed into the emitted javascript the whole Dart runtime. Whether it is needed or not.

Wait, is this an indictment of Dart? Or of Javascript?

I thought it was an indictment of ridiculous comparisons...

As you gaze into this thread, it gazes into you.

This comparison is asinine at best. The runtime is bound to be bigger. And remember DART eventually will have the runtime included in Chrome and hopefully other browsers. The way things are going in the browser world, all people might actually care about is Chrome and if there is a wonderful IDE support which comes with strongly typed languages, there is a real shot at this becoming a standard.

I wonder if the only speed benefits that the Dart VM gives would be able to be beaten out by a smart compiler. I know this is early for the cross-compilation code (it doesn't trim out anything it doesn't need here), but I hope this isn't what is ultimately used in that comparison.

As I understand it, dart isn't trying to be a faster javascript. Its trying to be a better GWT.

Many googlers I've spoken to firmly believe that you need a strongly typed, OO language with good tooling to be able to develop any large application. They believe web apps are no exception.

Google has worked hard adding types to javascript with the closure compiler. But, there are limits to what you can achieve using javascript.

Comfortable programming in the large is the main value proposition of Dart. Expect to see good developer tools, debuggers, profilers and server-side runtime environments for Dart appearing over the next few years.

(Disclaimer: I don't share this view)

dart isn't trying to be a faster javascript.

It isn't trying to be a javascript, but it's certainly trying to be faster. Performance features prominently in every statement of their design goals. Not only that, but performance in all modern browsers - i.e. including the ones they don't control and won't ship with a Dart VM. I don't see how they can possibly pull that off. Can anybody?

> Many googlers I've spoken to firmly believe that you need a strongly typed

Dart might be many things, none of them come remotely close to _strongly typed_.

Also, I never understood why Google ever started GWT, the idea itself is like a bad Apr 1st joke that got out of hand. I guess that the legions of Java programmers google has been hiring have started to take over sigh

The Dart VM buys you sane numeric semantics (integers and floats and bignums). Dart is also quite a bit less dynamic and introspective than JS, which should make it easier to optimize.


V8 does not use static type inference, as you seem to suggest. It uses dynamic type specialization based on observed types. Only recent builds of SpiderMonkey (not those that are shipping in current Firefoxes) do static type inference.

v8 is not crazy fast. It is a fast dynamic language VM -- beats php, ruby, python and other javascript VMs. In absolute terms, it executes code slowly compared to, for instance, the Java, Scala, C, C++, C# and others.

The comments on this thread are a disgrace. Read more.

I'm noticing all those functions being defined with ever increasing argument counts. I'm sure Google will optimise the output one day, as soon as they learn about arguments.length.

Google Dart was designed to build large scale web applications, yet all their demos and example code only includes small applications. That still require quite a lot of code to build.

I don't see any profit of building a application in dart, if you have to create more code your self than you would with a regular HTML5 based application.

As this "Hello World" demo shows, the only thing It's good at is creating bloat and this will probably stay this way until native parsers are implemented.

Wow. Reminds me of GWT...

you say that like GWT is somehow bad!

I think GWT is a great piece of tech. To be honest, google has way too much NiH syndrome, even internally...

I still have trouble understanding how anyone can take something like GWT seriously.

Whole books could be written about everything that is wrong with GWT, but here is one post that barely scratches the surface: http://ryandoherty.net/2007/04/29/why-google-web-toolkit-rot...

I prefer coffescript https://gist.github.com/1277567

If Microsoft had suggested this, they would be persecuted and beat into submission.

Today yes. In 1995 it would get 95% market share.

Heh, true that.

So, something that lets people who don't understand JavaScript "compile" some other language into JavaScript, is horribly inefficient. Wow, what a surprise.

Do you mean to imply that the point of Dart is to be an easier to understand Javascript?

Not at all. I'm saying if you want to make web apps that use JavaScript, write JavaScript.

People got just as pissed off as this over the amount of code Fructose (my Ruby-PHP compiler) outputted for Hello World.

Looks like most here don't know how compilers work.

I haven't seen such a neatly formatted piece of JavaScript code in a long time.

so fuckin what

I can't believe that a gist somehow turned into a 4chan thread. I found that infinitely more horrifying than the fact that a hello-world program nearly crashed my browser through sheer size.

This is not going to be your century :-D


Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact