Dartium: Google’s New Dart Programming Language Comes to Chromium
siliconfilter.com
siliconfilter.com
The VM presumably takes advantage of the slightly less dynamic nature of Dart to make more agressive optimizations than V8.
This also will provide a leverage against Oracle.
If mobile devs started to learn Objective-C en-masse just to be able to write iOS apps, they surely will learn Dart.
A language that does not suck? Check. Is it multi platform? Check. Can it work in other browsers if necessary? Check. Is it open source? check. Can it run in server? Check. Is it fast? Check.
Does it have closures and functions-as-object passing? (amazing feature of js)
Does it support prototypal inheritance? (also great)
I honestly don't know if Dart does these two, but they're pretty important to me. Does anyone know?
Edit: after a little research it looks like the answers are "Yes" and "No". I'd be willing to try it then.
Also, Javascript's version of prototypal inheritance isn't very good. Name me one thing you can do well with Javascript's inheritance that you can't do well in any other dynamic language with some notion of objects having property dictionaries (Perl, Python, Ruby, Lua, etc.).
No. Dart has classical inheritance, which by the large number of classical inheritance libraries for Javascript, is still very popular even when prototypal inheritance is available.
I personally abhor prototypal inheritance. It's aesthetically unappealing, hard to reason about, hard to optimise, and turns what is usually a declarative pattern into an imperative one. When most people are approximating classical inheritance anyway, that's a big sign.
It's sometimes nice that objects can differ structurally from their class, but I've never found it that useful.
"When most people are approximating classical inheritance anyway, that's a big sign."
Two things on that:
1. Most people (vast majority) learned OOP in a classical style, so that's what they're going to be comfortable with and will try to implement. It doesn't automatically mean classical style is superior.
2. You may want to check out the Klass library[1]. It provides a "classical interface to prototypal inheritance." So perhaps classical style is easier to use, but prototypal is better to have in the background.
A language that does not suck?
Can it run in server?
Is it fast?
Perhaps the strongest thing going for Dart is that there's a big company with resources behind it. Unfortunately, this is also the worst thing about it. Google's lack of effort to involve other browser vendors and the community at large in it's development is ultimately the reason why not many are interested, aside from whether or not the language is any good.
languages need to be created as a dictatorship and then ultimately open sourced, imo
So Google's only hope left is for Chrome to gain monopoly-level market share to simply force the remaining browsers into compliance.
I point this out because it's an important difference.
http://www.dartlang.org/docs/technical-overview/index.html#g...
Performance is a design goal, but it is not given as the primary goal.
Of course, a cynical observer might say that the real primary goal of Dart is to give Chrome an artificial performance advantage over competing browsers, since that will be, at the very least, an initial effect if Google succeeds in promoting its adoption.
I think that's rather unlikely.
I'm not sure your caveat is needed -- on a new installation the first thing Chrome does is ask you what search provider you want to use, you're just as free to pick Bing as Google.
That's a rather significant difference, you know.
But control over a given user's browser has incredible potential value for Google. Controlling both client and server means that you no longer have to sacrifice performance in the name of standards compliance (so long as you have a standards-compliant fallback mode for other browsers). What that means if you're Google is that a visitor using Chrome can 1) cost you fewer resources, and 2) walk away with a smoother, more satisfying experience.
Does Google currently take much advantage of this potential? I can't say for sure. But we are talking about a company that omits the </html> on its homepage in the name of performance.
google paid 1 billion dollars for a search deal to Mozilla with ~30% mkt share. If google had never built chrome, Mozilla share might be 50% or more today. The search deal would've been commensurately more expensive.
The point is, google doesn't have to pay for search engine placement for a chrome user.
If Chrome is faster at running Dart it will only really matter if 1) Dart is also faster than Javascript and 2) Dart is better for building complex web apps. That would validate the "clean break" approach as an alternative to the evolution approach. I don't see what makes that "artificial".
If Google successfully gets people to adopt Dart, but other browsers rely on JS cross compilation while Chrome has a dedicated VM, then there will be a period during which Chrome has an artificial advantage. This is a virtual certainty.
Dart might also have real advantages, and those would be enjoyed by all once other browsers provided fast implementations. But initially, Chrome would enjoy an artificial advantage even if Dart was actually worse by design than JavaScript, so long as they could get a significant chunk of web developers to adopt it.
My point is that getting people to adopt a technology that your product pioneers confers on you a market advantage independent of the actual merits of that technology.
What I haven't seen out of the Dart project, so far, is a description of what performance targets they're trying to meet, why they think that no set Javascript extensions (e.g., the "freeze" proposals for Harmony) would suffice to meet those targets, and why they think that any of this is relevant to people whose needs _are_ adequately met by Javascript as it stands.
Don't you think that building V8 (the engine inside Node) may have given them some very good insight into the upper bounds of Javascript performance and insight into ways to fix them?
Other people might have different tradeoffs, of course. Which is fine. But nothing I've seen the Dart crew say yet explains in plain English who those people might be, and why the particular set of tradeoffs in Dart is better for them than either v8 or, say, some other language reduced to strongly typed bytecode for PNaCl.
Of those five, the only one that CoffeeScript doesn't emphasize is "high performance/fast startup", which basically can't be a goal for a language without its own VM or JIT.
It seems to me that focusing on adding this one emphasis to CoffeeScript would make a lot more sense than making yet another not-exactly-Java.
Right. I think Dart's general goals are good, but I think they're wrong about how to go about it. I don't think most of the "problems" they enumerate are actually the obstacles that prevent their listed goals from being achieved. I think they are things that bother programmers whose thinking has been infected by too much Java.