Hacker News new | comments | show | ask | jobs | submit login

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.


[deleted]


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?


http://jsperf.com/dart-hello-world-test-with-optimize/5

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.




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

Search: