Dart is ready for the real world • Hacker News Board

Re: Dart is ready for the real world

#41

Post by greggman » Wed, Oct 17, 2012, 9:47 AM UTC

agentultra wrote: post #21

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…

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.

Re: Dart is ready for the real world

#42

Post by polux » Wed, Oct 17, 2012, 10:28 AM UTC

riquito wrote: post #40

ahoge wrote: post #25

Earlier quoted context omitted.

>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…

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/.

Re: Dart is ready for the real world

#43

Post by merdreubu » Wed, Oct 17, 2012, 10:50 AM UTC

jabr wrote: post #10

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…

http://www.dartlang.org/support/faq.html#why-fix-the-languag...

Re: Dart is ready for the real world

#44

Post by polux » Wed, Oct 17, 2012, 12:06 PM UTC

bengillies wrote: post #13

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).

(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.

Re: Dart is ready for the real world

#45

Post by polux » Wed, Oct 17, 2012, 12:10 PM UTC

fourstar wrote: post #26

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…

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.

Re: Dart is ready for the real world

#46

Post by MatthewPhillips » Wed, Oct 17, 2012, 12:52 PM UTC

polux wrote: post #44

bengillies wrote: post #13

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).

(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…

Function hoisting is a good thing.

Re: Dart is ready for the real world

#47

Post by MatthewPhillips » Wed, Oct 17, 2012, 1:09 PM UTC

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.

Re: Dart is ready for the real world

#48

Post by TazeTSchnitzel » Wed, Oct 17, 2012, 1:38 PM UTC

riquito wrote: post #40

ahoge wrote: post #25

Earlier quoted context omitted.

>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…

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

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

Re: Dart is ready for the real world

#49

Post by polux » Wed, Oct 17, 2012, 1:39 PM UTC

MatthewPhillips wrote: post #46

polux wrote: post #44

Earlier quoted context omitted.

(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…

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.

Re: Dart is ready for the real world

#50

Post by ahoge » Wed, Oct 17, 2012, 2:37 PM UTC

riquito wrote: post #40

ahoge wrote: post #25

Earlier quoted context omitted.

>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…

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

> 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.