Hacker News new | past | comments | ask | show | jobs | submit login
Dart is ready for the real world (arstechnica.com)
52 points by leephillips on Oct 16, 2012 | hide | past | web | favorite | 51 comments



Honestly I still don't see the point of Dart. It's made some strange choices (IMHO) like optional typing.

The idea that code can be shared between client and server is the panacea touted by GWT, which (IMHO) failed to eventuate (eg some classes weren't "GWT compatible" and this included protocol buffers generated classes). Dart seems like the next throw of the dice. I am not optimistic about its successes.

Go on the other hand, seems to have an incredibly bright future (IMHO) and it has lots of things in it that I like.

The only issue with Go, as a low-level (C++ replacement) language at least, is that it is a GC language. I used to think that you could implement some kind of ARC (automatic reference counting) system a la Obj-C/iOS 5+ as a middle ground between manual memory management and GC but I now have doubts about this, largely due to reference counting being an issue with locking on highly concurrent systems (something not an issue on phones with Obj-C/iOS).

More to the point, I think Javascript is like the email of programming languages: its ubiquitous and a whole bunch of people are convinced it needs fixing but I'm not exactly sure why. More to the point, those fixes seem to be incredibly complicated to the point of being a questionable value proposition.

I've been using AngularJS of late and to me it's a bit like the Lisp of Javascript frameworks in the sense that it is actually incredibly expressive but can have a steep learning curve. There is a lot that's simple about Angular but once you start delving into custom directives that support ngModel and the like you start requiring a deeper understanding of what's actually happening.

Anyway, back to Dart: I wish them the best but the complexity of language cross-compilation I think diminishes most if not all of the benefits of client and server language-sharing.


>It's made some strange choices (IMHO) like optional typing.

Yes, this may look a bit weird, but it actually makes perfect sense. Those types are annotations. If you use them at the "API boundaries" (parameters and return values), you already get most of the benefits you may know from Java or C#.

Compare the doc comments you usually have to write with those baked-in type annotations:

    /**
     * Foos the bar.
     * @param {int} x
     * @param {int} y
     * @returns {String}
     */
    function foo (x, y) {
        ...
    }
vs

    /// Foos the bar.
    String foo (int x, int y) {
        ...
    }
Much better, isn't it?

Additionally, adding those type annotations is useful right off the bat. The IDE will make use of them right away.

>Go on the other hand [...]

Well, Go is very different. It has a completely different focus. It's more like Rust, for example.


You made an example of how not to write documentation and then you shown that the code was better without. That is not the point.

Try to add content to the documentation, as "what is expected to be x?", then you can't remove it so easily anymore


The point is right now JS developers of big apps write this kind of comments because they are understood by tools like https://developers.google.com/closure/.


> You made an example of how not to write documentation and then you shown that the code was better without.

Both code snippets are equally documented. That triple slash thing is a doc comment and the type annotations will be also used by dart doc.

Furthermore, those type annotations will be used by the IDE right away. It will tell me if I pass something of the wrong type or if I do something silly with the return value. That type information will be also shown in call tips. I can also run my stuff in checked mode during development, which will make sure that everything is used correctly.

That's the advantage of having this kind of annotations baked into the language itself. It's a lot less annoying to write and, since it's standardized, every tool can use this information, too.

Since this stuff is optional, you can gradually add them as you go. You can quickly prototype something and if it worked as intended, you can add some types while you clean it up.


Um, I think that's a type annotation for closure compiler, not a documentation comment.


The closure compiler uses doc comments.

YUIDoc or JSDoc comments look pretty similar, for example. However, since this stuff isn't standardized, there are some differences between different flavors.


I agree. Even though I'm not a JS fanboy, can't really be against the language at this point. It has evolved a very good community around it, and libraries like Jquery make it very simple to pick up. That just makes adoption of Dart less likely.


Dart was actually created by the guys who created V8. They gave a great interview about it in episodes 8[1] and 8.1[2] of Javascript Jabber.

1: http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-ba...

2: http://javascriptjabber.com/008-1-v8-and-v8-and-dart-with-la...


There are middle grounds between unsafe manual memory management and full garbage collection other than atomic reference counting. Region systems (like in Cyclone and Rust), for example.


You can also integrate unsafe manual memory management with a full garbage collector in environments like .NET. Use the GC for 99% of your code, manually malloc/free/pin the other 1%.


One of the more elegant ways of handling this, .net does a great job of integrating with unmanaged (COM, i'm looking at you) resources.


From the editor-promoted comment:

Why are we bothering with developing new languages when what we should be doing is developing a web standard for a universal bytecode + VM? Hell, use the JVM or the CLR, just as long as it doesn't tie me to a specific language. Dart may be better than JavaScript (I would hope so) but that doesn't mean it's a silver bullet. If we create a standardized bytecode, it doesn't matter what language produced it.

I've been thinking about something like this for a long time. However, the question came up in an interview or presentation with either Brendan Eich or Douglas Crockford (I can't remember exactly where I read this) about why Javascript won out over a VM solution (supposedly this is what the JVM was made for). The most salient argument against a universal VM was that maintaining backwards compatibility between byte-code versions and the competing eco-system of languages would have been a nightmare. Instead the web targeted a single language (and all the trouble that has been along with it). I would rather like to see other languages on the web but I don't think a browser is good place to do it.

Instead what I'd rather see is http://www.cs.cornell.edu/home/ulfar/cuba/paper/ -- work could be done to improve that initial design, but the idea IMO is that the OS already handles processes and allocating memory well and the browser vendors are terrible at this task by comparison.

Either way, Dart is an interesting experiment and I'd give it a shot on some prototyping projects.


Brendan Eich talks about the VM solution (http://www.youtube.com/watch?v=Rj49rmc01Hs Slides: http://brendaneich.github.com/Strange-Loop-2012/#/).

I personally believe that HTML is fantastic for what it was designed for: Structured Documents. But the world has gone more interactive and I believe the ad-hoc solution of Javascript, HTML and CSS is not "rich" enough to provide for the users demand.

I like the language independent VM idea as long as it doesn't turn out like bloated Java bytecode.


#golang had Limbo in its ancestry, another CSP language, this time for the Inferno register-based VM from Bell Labs. Target Go at a browser VM?


It depends on your goals.

If the goal was to create a new language well Dart has done that.

If the goal was to give web dev some of tools of app dev (static typing, classical restricted OOP, better speed) I don't think Dart was the right answer specifically because I don't think it's got much chance of getting adopted by other browsers.

The practical solution IMO would be the CLR. Why? Because if Google had chosen the CLR they'd instantly have brought Microsoft and IE along with them at which point Mozilla would probably be pulled in if kicking and screaming.

That seems to me the most pragmatic solution but sadly Google is unwilling to do that for whatever reason.


I love what you're saying, but I don't think it would be mutually exclusive with dart. While a standard byte code solves a very similar problem, it's still a different problem, and a much harder and longer one to solve.


From what I've seen of both, TypeScript seems like the language that Google should have created in the first place. It has similar goals, but without the "let's create a whole new VM and replace the entire JacaScript runtime in all browsers" ambition (which is ridiculous).


Maybe you would be interested in watching a discussion between the leaders of these two projects. I think Dart shouldn't be dismissed as a "ridiculous" ambition. I would also like to point out that Dart compiles to JavaScript the same way as TypeScript, so your remark regarding replacing the JavaScript runtimes in all browsers is an exaggeration

http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-a...


(Disclaimer: I'm partly working on Dart)

- Every Javascript program is a valid typescript program so typescript doesn't fix JS semantics (like variable hoisting and the only numeric type being floats). I think typescript is a good fit when you already have some big JS project and you want to get some type errors by loading a predefined signature for jquery or whatever library you're using. You basically get a linter + code completion for free on a pre-existing project. But if I have the choice between Javascript and any other language with saner semantics to start a new project, then I will for sure not chose Javascript.

- I don't think that Dart aims to "replace the entire JacaScript runtime in all browsers", even though the Ars Technica article says so. It's an alternative to Javascript, exactly like Ruby is an alternative to Python. Of course there's a difference between Js vs Dart and Python vs Ruby: every browser runs Js and only Js. That's why the story with Dart is: develop with the VM and Dartium, so that you can reload you application with F5, use the debugger, etc. and then deploy by compiling to Javascript.


Function hoisting is a good thing.


Sorry, what do you mean by function hoisting? The fact that you can write mutually recursive functions at toplevel? Anyway, I was referring to variable hoisting.


I was excited about Dart, until I saw how many lines of code the JavaScript output was for one of its simple examples.

And then I completely lost interest when I started structuring my code well, and realised that I didn't need it as much as I thought.


The output is more optimized now. However, there is a one-time cost for some of the language features. So, it grows kinda quickly initially. There is some sort of bump, basically.

Thanks to "tree shaking" (=dead code removal), you'll reach the break-even point fairly quickly though. You can use massive libraries, buy only those pieces you actually use get included in the final output.

For example, the last JS app I wrote is about 80kB (minified and compressed). jQuery alone took about 33kB of that. How much of jQuery do I actually use? I'd guess it's less than 20%.

So, even with that initial overhead, a Dart version would be probably a bit smaller.


I'm not convinced. After Google killed numerous projects this year, I'm a little skittish about jumping into Dart. When it has the traction of Go, I'll be more willing.


Second time I've seen this today. An account created minutes after the submission apparently just for the purpose of spreading FUD.


I disagree that it's FUD. Not every concern expressed about a new technology is FUD. And it seems to me that Google's history of canceling projects that get only limited traction does provide a legitimate concern.


Why FUD? Javascript is well established, in fact it is the most popular programming language on the Earth. Are you sure that if Dart would not catch up for 2 years, it would not be cancelled by Google (or, as it is nicely said these days, "given to the communit", as Google Wave was.)


All new languages carry with them a very large amount of risk. If for nothing else, it would be good to learn this language to get better at learning languages.


There are some things in Dart that would be nice to have in Javascript, but I don't see why Google wouldn't just try to work them into future ECMAScript revisions. With the exception of banning eval and run-time modification of prototypes, I don't see anything that's completely incompatible with a future revision of Javascript.

I'd even bet that the ES standards committee will eventually give in on the "arrow" lambda style. ES5 has the "function(x) x * x" shorthand, but with C# and Java both settling on "(x) => x * x", I can see it happening in time.




You know what, bringing Dart to android development may be a good idea. Web hobbyists hate java with a passion but may embrace Dart for its resemblance with javascript.


Bringing Go development to Android would be even better, but I doubt either will ever happen, at least not as an officially sanctioned way to create native apps.


Oh I would love for Google to do that!


I like it. Here's what it has got for me:

Isolates: Message passing concurrency which takes away 80% of the problems with threads and locking. I find it intuitive in the way that Unix pipes are intuitive. A few other languages have this also but Dart is one of them and its a plus.

Optional Typing: Its a dynamic language so its very flexible. Some statically typed languages are also flexible but you can still run into some very complex cases with the type system. I want to focus on my application. By having optional types though I can get 80% of what static, strong typing gives me, namely documentation, the ability to quickly reverse engineer someone else's code and runtime type checks. You know all those unit tests that you write in a dynamically typed language just to check the type of some parameter? With Dart you just turn on a switch and those unit tests are built in (I don't think typescript gives you this as the type information is erased at runtime)

Native debugger: I want my apps to run everywhere which means generating javascript. I see the Dart VM as a native debugging environment. Google have built a special VM so that I can debug Dart natively. I don't think source maps will be able to give as rich a debugging experience.

Tree shaking: The size of javascript libraries is a big issue. Have you tried looking at some sites over a slow mobile connection? Tree shaking looks like it will make it possible to only pay for what you use. This is a major plus

A consistent core: How many javascript libraries are there? Which should I pick? I don't even want to pick anymore I just want to get on with the job.

A pretty good experience: Rob Pike had an article a while ago about people complaining about a language without using it. I tried Go and that's why I like it. I also tried Dart with the Dart editor. Its nice, the libraries are good, the language is fluent and concise enough. Everything seems to be in the right place.


Dart + Native Client Modules almost makes me excited about web programming again. Obviously not for general websites, but for specific applications it would not be unreasonable to require Chrome to be installed as the alternative would be installing a native app anyway.


Is it really web programming if you're shipping processor-specific binary bundles that only work in one browser and don't actually interact with the web?

I think I know what you mean, though. It's nice to be able to pick a narrow target that covers most of your customers and code for that.


Not again. We have been through this with ActiveX and it was no fun. Similarly we have been through "works on every OS (if it is Windows)".

Web development today with JS/CoffeeScript + jQuery + Underscore and other libs is not hard. Just accept that different users will use different browsers.


I am more thinking of Dart+Native Client as a nice alternative to native application development rather than an alternative to general web development.

If you wanted to write an application that performed with native speed would you rather write it multiple times for Windows, Linux and OSX, iOS* and Android (and make sure it compiles on multiple architectures) AND force your users to install and update the application on their computer...

OR

Write it once as a mixed Dart/Native Client app targeting the LLVM bytecode and run it securely in the Chrome browser on multiple platforms? All the user needs to do is install Chrome and visit a URL. Updating the app becomes trivial.

I am not saying it is the clear winner, but to me it sounds like a damn interesting alternative with a lot of promise.

It is also possible that Chrome will "win" - either by gaining such majority user-base that targeting specific features of Chrome becomes worth while, or because Dart+Native Client becomes a de facto standard the other browsers adopt.

Also, if you are writing a "web app" to target a niche market that really want to use the application (hard-core gamers?), requiring Chrome really may not be a big deal for the user-base. After all, if people are willing to install native applications on their local system, why would they be unwilling to install Chrome and visit a URL?

* It is unclear if the Chrome browser on iOS will ever be able to download and run native code for both technical and policy reasons.


I haven't read all the comments sorry if this has been posted already. I think you guys would enjoy listing to this discussion about TypeScript, Dart and JavaScript between Anders Hejlsberg and Lars Bak the guy behind V8 and co-creator of Dart.

Link: http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-a...


My problem with Dart is that it's just not that interesting from a language perspective. TypeScript is somewhat interesting in that it has a very low learning curve for JS devs, so that you can go straight to using ES6 maximally minimal classes and type annotations. The ability to jump straight in makes it worth a look. But Dart... Dart is a different (by similar) language that, therefore, has to be learned like any other language. And I simply have no desire to learn another traditional object oriented language that has all of the same features as other object oriented languages but with a "we do this one small thing better" proposition.

You might say that this is the point, but I have to ask why they didn't just fully commit to GWT instead. If the point is to attract Java developers, that seems like the more logical way to go.


I was at this. I was really looking forward since listening to the Javascript Jabber podcast (http://javascriptjabber.com/008-1-v8-and-v8-and-dart-with-la...) about it.

Less than 1/3 through I decided to started to zone out. I don't understand why you need a VM to compile something into Javascript. Also the optional typed language feature is just odd (okay I can see working in groups and wanting to empirically let other developers what type a variable is), but it's just not something I see myself wanting to learn to do what I already know.

I was also interested in the Angular talk, which was good, but it left me thinking Angular is to CakePHP in the MV* javascript world with all the built-in automagic.

Overall some pretty good talks at this.


You don't need a VM to compile something into Javascript but the VM buys you a fast edit/reload cycle and some tooling like a debugger. Also Dart can be used as server-side language and there the VM makes sense. It can also be used as an interpreted language just like Python and here it doesn't hurt if it's fast.

Even if _you_ don't put type annotations in your code, the IDE infers types (locally) and gives you useful warnings and code completion.


Is google really betting dart will take off? Because I don't see microsoft/apple/mozilla supporting it in the future. But of course dart can still be a cofeescript competitor.


They don't need anyone else to support it. Compiling to JS means Dart apps will work in other browsers, and in a Chrome-only world (the world Google wants to exist), everyone will benefit from the native Dart VM.


There is one language to kill JS and Dart. It is TCL and it is here with two decades of development and sane. Why develop these languages when TCL has everything and can run in the browser or even with NaCl.


I have been using dart for a couple of months now and am extremely happy with it. Code completion on the DOM API is a different world to the classic javascript edit-test-fix syntax error cycle.

The language and the vm are a distraction. The huge win with dart is what the IDE will do for your productivity.


Dart, attempt 35.


Could someone throw a good "Beginning Dart" Tutorial here please.Just want play with it.


Why does this video sound like a tv shop program selling body hair removal solutions.




Registration is open for Startup School 2019. Classes start July 22nd.

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

Search: