Dart language • Hacker News Board

Re: Dart language

#351

Post by ootachi » Mon, Oct 10, 2011, 4:58 PM UTC

jasonmc wrote: post #348

ootachi wrote: post #324

Earlier quoted context omitted.

"I mean, with Unix, most people are running a single implementation: Linux Kernel, and no one really cares about Open Solaris, or Darwin anymore." Nobody cares about Darwin? Really? I mean, in terms of hacking the kernel, sure, but tons of people are running Darwin. The POSIX standard is more important than ever. "On mobile devices, loading a lot of Javascript is expensive" I keep seeing this assertion that bytecode…

"You realize that Java requires a nontrivial bytecode verifier too, right? IIRC the bytecode verifier, and certainly the compiler, require abstract interpretation to convert the stack-oriented bytecode to a virtual register-based one." It seems like you are talking about Dalvik VM (Android). Java class files (stack bytecode) are actually converted to Dakvik's register bytecode ahead of time. (Before installation on t…

No, I'm talking about the verifier [1]. In particular: "There are no operand stack overflows or underflows." That requires abstract interpretation.

And every performant Java interpreter is required to convert the stack machine to vregs in order to perform register allocation. That requires abstract interpretation too.

[1]: http://java.sun.com/docs/white/langenv/Security.doc3.html

Re: Dart language

#352

Post by breathesalt » Mon, Oct 10, 2011, 4:59 PM UTC

maratd wrote: post #315

cletus wrote: post #293

I don't speak for the team but I believe I can add some perspective. Think of it this way: what is GWT? GWT os compiling Java, a statically typed language, into Javascript. If you've used GWT you'll know that particularly early on there was a lot of friction. What's simple in Javascript with anonymous objects and duck typing doesn't quite gel with Java so you've had to do things like use JSNI for edge cases. Google h…

If Google produced an innovative replacement for JavaScript, the world would listen. Instead, based on what they have released so far and your comments, they have released a language that is primarily designed to enhance their own tool-chain, which the rest of the world doesn't use and isn't interested in. We don't use GWT. Apparently, we won't use Dart either.

I've used GWT. It's no cure all, but it has its place and time. It's too early to judge Dart.

Re: Dart language

#353

Post by cromwellian » Mon, Oct 10, 2011, 5:01 PM UTC

starwed wrote: post #347

georgemcbay wrote: post #198

Earlier quoted context omitted.

I understand the context and still disagree. If Dart is so much better than JavaScript on Chrome and if its Dart->JS engine does a good enough job of creating usable JS on other browsers that developers are willing to commit to using it to write apps then, well, that's too bad for everyone else, isn't it? Why should Google put the brakes on improving client side development just because it puts other browsers in the…

The alternative to google developing Dart isn't doing nothing, but throwing more resources behind javascript. I think you are missing some of the context of Eich's comments. The very same leaked memo declared that Dart was developed b/c js could not be evolved into a suitable language. Obviously Eich thinks it can, but more to the point he's working on the committee that is responsible for guiding such evolution -- t…

If JS can be evolved, why has it taken over a decade, and still nothing much of substance? I think Javascript is much like Java, it is too hampered by concerns of remaining compatible with existing legacy semantics. Whenever you see a language where the only thing they can add is "syntactic sugar" it means they are unwilling to consider functionality that would break the underlying legacy VM assumptions, and that means, ultimately, their evolution is "boxed in" by these concerns.

Java basically is at a dead end because changing the JVM is hard.

Re: Dart language

#354

Post by tomp » Mon, Oct 10, 2011, 5:08 PM UTC

phillmv wrote: post #314

nzonbi wrote: post #156

Earlier quoted context omitted.

Agree with parent comment. My opinion, so far: Overall: uninspired. Below what I was expecting. Probably good for Google goals (tooling, migrating developers, etc) The language is somewhat interesting, but unfortunately saddened by an incredibly boring syntax. At this point, I am thinking that they would have been better off just going with the Go language for this. Looks like something good to migrate fleets of java…

Can someone explain to me what's the point of having syntax like: `var foo = new Bar()`? Why can't a constructor just be a regular method that happens to return a new instance? What's with this new nonsense?

I agree, this syntax makes little sense in dynamic languages where classes/types are first-class values that share the namespace with functions and ordinary values... Even in JavaScript, where it sort-of-kind-of makes sense, it introduces more problems than it solves.

Re: Dart language

#355

Post by jasonmc » Mon, Oct 10, 2011, 5:09 PM UTC

ootachi wrote: post #351

jasonmc wrote: post #348

Earlier quoted context omitted.

"You realize that Java requires a nontrivial bytecode verifier too, right? IIRC the bytecode verifier, and certainly the compiler, require abstract interpretation to convert the stack-oriented bytecode to a virtual register-based one." It seems like you are talking about Dalvik VM (Android). Java class files (stack bytecode) are actually converted to Dakvik's register bytecode ahead of time. (Before installation on t…

No, I'm talking about the verifier [1]. In particular: "There are no operand stack overflows or underflows." That requires abstract interpretation. And every performant Java interpreter is required to convert the stack machine to vregs in order to perform register allocation. That requires abstract interpretation too. [1]: http://java.sun.com/docs/white/langenv/Security.doc3.html

Sure, but I'd be willing to bet that performance impact of the the verifier is insignificant for all but the most trivial of programs.

Re: Dart language

#356

Post by koenigdavidmj » Mon, Oct 10, 2011, 5:12 PM UTC

jeltz wrote: post #299

cubicle67 wrote: post #280

Earlier quoted context omitted.

thanks. I've been writing Ruby for a few years now and I never knew about sort_by. Looks like is works in 1.8 too, but without the &: syntax sort_by{|g|g.irrelevance} source: http://www.ruby-doc.org/core-1.9.2/Enumerable.html#method-i-...

I actually believe the &:symbol syntax was added in 1.8.7 since I am 100% positive we use that in our codebase which still has not been ported to 1.9. $ ruby -e 'puts VERSION; p ["10", "2", "3"].sort_by(&:to_i)' 1.8.7 ["2", "3", "10"]

Rails adds it too, even if your version of Ruby does not support it. Yay monkeypatching!

EDIT: said duck typing first. It's too early for thinking.

Re: Dart language

#357

Post by mikeleeorg » Mon, Oct 10, 2011, 5:14 PM UTC

Jyaif wrote: post #344

maratd wrote: post #315

Earlier quoted context omitted.

If Google produced an innovative replacement for JavaScript, the world would listen. Instead, based on what they have released so far and your comments, they have released a language that is primarily designed to enhance their own tool-chain, which the rest of the world doesn't use and isn't interested in. We don't use GWT. Apparently, we won't use Dart either.

A lot of people use GWT for large web applications instead of JS, precisely for the reasons Dart was created, we just don't go brag about it. The biggest problem with GWT was how slow the toolchain was, and this is adressed with Dart by having a native VM in Chrome.

Out of curiosity, do you know of any notable non-Google sites using GWT? I see a few here, though none seem to be particularly large web apps - that I can tell, at least.

http://gwtgallery.appspot.com/

http://www.gwtsite.com/whos-using-gwt/

http://www.reddit.com/r/programming/comments/aqsxq/does_anyo...

http://www.quora.com/What-web-applications-use-Google-Web-To...

Re: Dart language

#358

Post by Lewisham » Mon, Oct 10, 2011, 5:15 PM UTC

maratd wrote: post #315

cletus wrote: post #293

I don't speak for the team but I believe I can add some perspective. Think of it this way: what is GWT? GWT os compiling Java, a statically typed language, into Javascript. If you've used GWT you'll know that particularly early on there was a lot of friction. What's simple in Javascript with anonymous objects and duck typing doesn't quite gel with Java so you've had to do things like use JSNI for edge cases. Google h…

If Google produced an innovative replacement for JavaScript, the world would listen. Instead, based on what they have released so far and your comments, they have released a language that is primarily designed to enhance their own tool-chain, which the rest of the world doesn't use and isn't interested in. We don't use GWT. Apparently, we won't use Dart either.

they have released a language that is primarily designed to enhance their own tool-chain

You make this sound like its a bad thing, but that's open-source always and forever. Scratch your own itch.

Re: Dart language

#359

Post by cromwellian » Mon, Oct 10, 2011, 5:16 PM UTC

BrendanEich wrote: post #313

cromwellian wrote: post #132

Earlier quoted context omitted.

Browsers already have a wide performance differential. What's the ratio between V8 and IE6? Or between desktop and mobile? As long as the performance isn't pathologically bad, it won't matter. Dart apps will start up quicker and run a percentage faster. Maybe perform much better on mobile. A decent win, but doesn't really change the fragmentation equation much from what it already is. The keyword Brendan used was "de…

I specifically referred to new number types. Dart has bignums (int). See https://twitter.com/#!/maccman/status/123400799756881920 for a clue. Dart-to-JS can't be faster than hand-coded JS if it does not use bignums. If it does use bignums that do not fit in 32-bit ints, then Dart-to-JS will be slower than a native VM with built-in bignum support. IE6 is irrelevant. The topic is modern browser with native Dart VM vs.…

What do you mean Dart-to-JS can't be faster than hand-code JS? That's like saying C can't be faster than hand-coded assembly. Unless you write unmaintainable code or spend efforts counting cycles and scheduling and pipeline harzards, this usually isn't the case, and is not the way most people write large application (all in asm). If you take your average hand-written Javascript and run it through closure compiler, in many cases, it ends up executing faster (at least in V8). If you haven't already, I would recommend investigating the behavior of JS VMs with and without Closure Compiler, you might be surprised.

We're talking averages here, not pathological edge cases. Java has a 64-bit long type which JS doesn't support. GWT supports longs. In theory, GWT code should run slower, in practice, because GWT contains an optimizer, it runs as well, or faster, than hand written JS, simply because very few code bases have hot paths dependent on long arithmetic. For example, I've actually ported popular JS benchmarks to Java, ran them through GWT, and the result was faster.

Sure, would you be able to concoct applications for which Dart and Dart-to-JS have a large divergence? Yes. Will they be the common case? Probably not. I can concoct normal JS applications today which show high divergence between Chrome, Firefox, and IE, because of all of the JS VMs have different weaknesses, different optimizers, different garbage collectors. If you're writing applications that are so CPU bound and performance critical (e.g. games), chances are you're going to run into other portability problems too.

Most of this worry over runtime performance I think is a red herring. The real difference will probably be in startup time.

Re: Dart language

#360

Post by mikeleeorg » Mon, Oct 10, 2011, 5:18 PM UTC

arctangent wrote: post #174

nzonbi wrote: post #156

Earlier quoted context omitted.

Agree with parent comment. My opinion, so far: Overall: uninspired. Below what I was expecting. Probably good for Google goals (tooling, migrating developers, etc) The language is somewhat interesting, but unfortunately saddened by an incredibly boring syntax. At this point, I am thinking that they would have been better off just going with the Go language for this. Looks like something good to migrate fleets of java…

I agree with you about the syntax - I was hoping for something more like Python. Perhaps this is by design, though? Presumably the syntax doesn't look too bad to people who spend all day writing JavaScript (i.e. the target demographic for this language). Presumably some bright spark will eventually write a Python-to-Dart compiler and then we'll all be happy :-)

I interpreted (no pun intended) this all to mean is that Dart is aimed at people who spend all day writing Java.