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

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

Applications are open for YC Summer 2018

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