"Hello World" in Dart, compiled to JavaScript
gist.github.com
gist.github.com
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.
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."
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."
Underscore is under 1000 lines unminified and with all comments.
> 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?
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.
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.
Deleted comment
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.
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.
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.
print$getter()(1, $noargs, 'Hello, Dart!'); print$getter()(1, $noargs, 'foo'); print$getter()(1, $noargs, 'bar');
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".
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.'
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.
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.
"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.
Well, if the distinction is between the ones nobody uses and the one "everybody complains about", then we also know where Dart falls...
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.
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.
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!"
Shameful.
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.
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.
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.
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.
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....
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.
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.
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.
The user is king. If Google doesn't give a shit about dart's users - ie programmers - then why should we care?
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
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.
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.
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).
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?
Have you actually met any techies lately?
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.
It also doesn't change the fact that Dart sucks. For other reasons though.
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.
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.
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.
(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.)
$ 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*
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. ;)
$ 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.outA 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.
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.
the original example should "compile" to nothing more than the following:
(function () { window.HelloDartTest = { testMain: function testMain() { console.log("Hello, Darter!"); } };
HelloDartTest.testMain(); })();
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".
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.
Still fails.
SOMEBODY PLEASE RECOMMEND A GOOD HELLO WORLD LANGUAGE!!
The result is 94% smaller - 32k, or 9k gzipped. A 32k overhead could be absorbed by most large web applications without being noticed.
http://closure-compiler.appspot.com/code/jscd4ddca10c0a518fc...
class HelloCoffeeTest
@testMain: ->
console.log "Hello, Coffee!"
HelloCoffeeTest.testMain()
var HelloCoffeeTest;
HelloCoffeeTest = (function() {
function HelloCoffeeTest() {}
HelloCoffeeTest.testMain = function() {
return console.log("Hello, Coffee!");
};
return HelloCoffeeTest;
})();
HelloCoffeeTest.testMain();(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.
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.
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?
Is this a typo, tongue-in-cheek, or a technical term I don't know? I've only heard of "syntactic sugar" myself.
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.
zip = lottery.drawWinner?().address?.zipcode
[0] example code from http://jashkenas.github.com/coffee-script
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.
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?
It's like Go: "It's from google, so awesome by default".
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.
Right now, it's probably designed to be run through something like Closure Compiler, which removes dead code and minimizes the output.
If anything, Coffeescript is "just" js with syntactic sugar. Not that there is anything wrong with that.
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.
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.
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?
var solipsism;
if ((typeof mind !== "undefined" && mind !== null) && !(typeof world !== "undefined" && world !== null)) {
solipsism = true;
}
eat food for food in ['toast', 'cheese', 'wine']Either that, or I don't want to surf this internet anymore.
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)
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?
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
Deleted comment
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.
I think GWT is a great piece of tech. To be honest, google has way too much NiH syndrome, even internally...
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...
Looks like most here don't know how compilers work.