And as noted, this can already be (and is being) done with JavaScript. The proposal is only to make it native to a browser.
Actually, the proposal is to add specific enhancement to the existing support for paged media in general in CSS. CSS is no more "native" in browsers than JavaScript is, and browsers are already free to (and some, e.g., Opera in full-screen mode for several versions, do) display content as paged, and CSS already has quite a bit of support for paged media.
Opera has been using paged-media features for full-screen display and pushing for better paged-media features in CSS since before the iPad came out, which makes it hard to believe that argument.
Your "Gee, if only there was a set of standards..." comment would make more sense if Opera's proposal didn't consist of two things: 1. Desktop and tablet browsers should allow the use of existing standard CSS paged-media features (which Opera already does in full-screen mode), and 2. Proposals for additions to existing standards-track specifications to make CSS paged-media features more useful, particular for the pages-on-a-screen use case
But, the argument made by many FLOSSers is that everyone SHOULD use FLOSS and if they did, the internet would be a better place
Some supporters of FLOSS make somewhat hyperbolic statements. They aren't the mainstream, and you shouldn't get fixated on them.
And, if someone uses FLOSS and finds problems, FLOSSers say "You have the code. Fix it!"
Some might say that, but that's not my experience. IME, what is usually said that then gets misrepresented by anti-FLOSSers this way is more like: (From a project maintainer) "(That's not at the top of our queue right now/We've got some concerns about how the obvious ways of addressing that concern might impact existing users) but we'd certainly welcome and be willing to evaluate a patch." (Alternatively, also from a project maintainer) "Your request to add mandatory line numbers is inconsistent with the direction we want to take our scripting language. However, you have the source, so you are free to fork it and implement that yourself if you really need it." (From a discussion forum that isn't the main support forum for the product) "Whining about that here isn't going to get you any results. You've got the source, fix it yourself, or, failing that, go to the projects issue tracker at http://www.example.com/mypetproject/tracker and file a bug."
which is suggesting everyone who uses FLOSS is obligated to fix any issue they encounter.
Even if they said what you say, it wouldn't suggest that. It would suggest that people who use FLOSS ought to use their access to the source to correct issues in software that they care about.
It doesn't mean that they need to fix issues in open source software that other people whine to them about, in fact, it is absolutely inconsistent with that attitude.
which is suggesting everyone who uses FLOSS is obligated to fix any issue they encounter.
So, explain again why users should use FLOSS instead closed-source when they have "better things to work on than someone else's code" and can buy something that works?
The thing is, the users of a software package (say, Virtual Box) aren't situated to it in the same way that the developers of some other software package (say, the Linux kernel) are.
The point is, if you care about FLOSS code, then even if the original vendor decides in the future that maintaining that codebase (or even having it continue to exist in use) is contrary to the vendor's larger interests, you can still use it and, if necessary, pay someone else to maintain it.
Whereas with closed-source code, you likely can't do the latter, and under many common license terms may not even be able to do the former.
The argument isn't that everyone who uses open source is obligated to support every open source package that interacts with anything they use or develop, its that anyone who uses open source has the right to address problems in any open source package that is important to their interests.
They have access to the source so instead of just complaining, they could fix it and offer the patch back to Oracle.
They are "Linux Kernel developers". They are (as a class) neither the developers of, nor users of, the Virtual Box driver.
I do believe that people who complain about problems in the Linux kernel and other open source products are often told to do just that.
They aren't complaining. They are saying "this is a known source of problems; if you report bugs that involve it, you either need to fix them yourself or complain to the people responsible for maintaining this piece of code, not the people responsible for maintaining the Linux kernel."
Why expect others to do as you say, if you won't do the same?
Um, what they say is, "if you care about a problem with open source software, you can update the code to address it yourself yourself."
In the case of the Linux kernel (which, one presumes, Linux kernel devs, as a class, do care about), they are doing exactly that.
With regard to the Virtual Box driver, they are saying "while we're willing to deal with issues resulting from foreign code in general, we don't care enough to waste time dealing with the huge number of issues produced because the maintainer isn't going to take the code seriously. If you care about this software (the VBox driver), you either need to get the maintainer to care, or you need to put the effort into dealing with the problems it causes yourself."
Which, you know, isn't inconsistent with what their more general position, either.
Ah! I see the error of my original post. I should have written, "anylanguageInterpreter" or "anylanguageEngine". VM brings to mind bitecode and JIT. I, very poorly, tried to describe an engine/interpreter (Rhino - V8 - SpiderMonkey - Narcissus) capable of interpreting Python, Perl, Lua, Ruby, etc... My apologies
How would you build such a thing? Real multilanguage environments have a common intermediate representation of some form, and some kind compiler/translator/etc. for each language that converts it to the common representation (or separate interpreters for different languages running on the common environment, or a mixture of both approaches for different languages.)
A "multilanguage interpreter" isn't a coherent concept, its multiple interpreters for different languages that happen to share some backend components.
And, still, Google's working on the fundamental groundwork for that with PNaCl and PPAPI, by providing a starting point for the shared target in the browser and integration with the browser environment (e.g., DOM, etc.) in that shared target, in a way that provides an easier path for many existing languages than compile-to (or interpret-in) JavaScript.
There's a long way to go (PNaCl itself isn't in general release yet), but doing Dart doesn't mean Google has stopped doing the work that is needed to underlie what it seems like you are looking for.
What makes you say that? The latest release was a Sept. 07th... about a month ago. Dart may or may not threaten Go at some point, but for now it seems that Dart is more focused on client/GUI code and Go is more focused on server code (e.g., as a systems programming language).
Dart is more than just for clients, one of the big points is that it can also be suitable for server-side applications. But Go is designed for lower-level systems code than what Dart is aimed at, even where Dart would be used on the server side.
(I suspect, thought, that the experimental Go runtime for Google App Engine may never make it out of "experimental" state -- this seems to be an area that Dart is aimed squarely at, and that is outside of the sweet spot for Go as Google is positioning it.)
It's a library thing, even in Dart. It could be a library thing in C# as well.
Creating an isolate is defined in the language spec as being syntactically equivalent to a function call, and passing messages to an isolate is defined in the language spec as being provided by atomic library calls.
Its an essential language feature defined in the spec, though the communication method (but not the spawning method, which looks like a library call) is left to the library.
System.Dynamic.DynamicObject lets you do the same with more verbosity (but that same verbosity lets runtime do some more advanced caching, instead of calling noSuchMethod every time). Of course this only works when the receiver is typed "dynamic".
TryInvoke and friends are somewhat similar, though the calling order of is reversed. OTOH, I can see a case for either order being better, so this is a different-but-not-necessarily-better thing. I don't know that the restriction to DynamicObject descendants in C# is a substantive difference as long as Dart uses closed classes.
I agree that these are useful, but as features they are minor enough that they hardly merit a new and incompatible language. If really desired, they could be made language extensions, and then pushed for standardization in the next version of C#.
Some of them could be, if one wanted to bring in all the baggage of C# that makes it (to my eye, at least) a heavily IDE-dependent, write-mostly language. Being concise has a value, and I don't think C#-without-.NET would be as useful as Dart, as it is, could be as a language for both sides of the web.
Dart -- like JavaScript, Ruby, Python, Lisp/Scheme, and Erlang, but unlike C++, Java, and C# -- looks like it would pass my personal "simple editor test": that is, is all the tool support I really want for editing it (as opposed to SCM and test tooling) syntax highlighting, delimiter matching, and maybe auto-indenting. That's an attractive feature for me (because IDE tooling that eases the pain of writing overly-verbose languages doesn't do as much to ease the pain of reading them), and its probably an attractive feature to Google since they plan on building a cloud-based IDE for it. The less that IDE has to do to satisfy developers, the less work they need to do for that effort to be useful.
The differences between any two Turing-complete languages is always going to boil down to syntactic variations and library features (how big the syntax differences are will, of course, vary).
The fact that those that the differences between [currently popular language] and [new language] boil down to those two things doesn't mean that everyone should use [currently popular language] and that no one should spend effort developing and improving [new language].
As much as developers currently devoted to [currently popular language] will try to convince you that it does (and the argument has, in this thread, been made with C#, Java, JavaScript, and C++ as [currently popular language].)
Google lacks imagination when designing a new language. Even Microsoft can design a bold language like F#, whose design was inspired (or stolen) from OCaml. Microsoft Research has at least two geniuses working for them: Simon Peyton Jones and Erik Meijer. Both came from the Haskell world.
Can Google design an experimental language crazier than Dart (or Go)?
Who wants another Java?
Dart isn't another Java. Unless, at some point where I wasn't looking, Java dropped mandatory strong typing in favor of dynamic typing with option type checking, eliminated the primitive/object distinction, added Erlang-style concurrency and Ruby-style handling of calls to non-existent methods, and added non-allocating constructors (what Dart calls "factory constructors" rather than "generative constructors"), and factory classes to provide default implementations of an interface so that an interface can be instantiated as if it were a class.
I don't want to learn a new language that lacks functional features, or my beloved lambdas. For me, is simply not functional, haha.
Dart has functional features, including a concise notation for lambda expressions (function literals).
Here's a Dart function literal for a function that takes one parameter and returns the result of adding one to it:
(x) => x+1 Here's an alternative notation for the same thing:
(x) { return x+1; } Here's a version that uses explicit typing:
(num x) => x + 1;
I think it is an attempt to combine features of JS and Erlang to get concurrency. Why?
The isolate/sendPort/receivePort setup seems to be pretty much exactly Erlang-style concurrency, but that's not even close to the whole of how Dart differs from (insert any existing language here). Its certainly an important feature, but its not the sole motivation.
One could use it to convert an existing one. My point was, "Why wasn't Google that ONE". They have Native Code. Why not use it for something that frees developers to use any language instead of creating Just Another Language.
Uh, they are doing that. You don't need an "Anylanguage VM" to do that, you need, well, exactly what PNaCl provides as an execution environment (so that you can run LLVM bitcode anywhere, so anything anyone can compile to that can be run anywhere the browser runs), plus what PPAPI provides to interface with the DOM, etc.
Doing that doesn't stop them from designing, implementing, and promoting a new language designed to be useful both on the client side and the server side of web-apps. Google can do more than one thing at a time. In fact, since there are practical limits to the productivity gains they can get by throwing more resources at any single project, they need to do more than one thing at a time.
Well, today, since they only just announced it. JavaScript (born as LiveScript) wasn't an open, widely implemented standard independent of a single vendor when the first information on it was released by Netscape.
Why is that really any different or better?
I would say that the condition of Dart with respect to control compared to C# and Java remains to be seen.
Aside from that, and a few minor deviations such as no method overloading (but named constructors), I really don't see what this brings to the table compared to C# 4.0+ (the one that has "dynamic") - especially given that the stated goal was to have something familiar for Java/C# programmers.
Off the top of my head, the things it seems to have that C# 4.0 doesn't:
Erlang-style shared-nothing actor-model concurrency (via "isolates" which are analogous to Erlang processes).
Ruby-style handling of calls to non-existent methods (via noSuchMethod, analogous to Ruby's method_missing.)
Switch statements without the needless ritual of "breaks" (in C++, which allows fall-through, "break" makes sense -- in C#, which prohibits fall-throug,h "break" is an empty incantation.)
Futures (via "Promise") -- though, to be fair, these are planned for C# 5.0
Factory constructors for classes and factory classes for interfaces
Some Javascript-ish more concise syntax than C# for similar operations (e.g., extraction of methods as functions.)
I was really hoping that they included something like Ruby's mixins.
Interfaces are useful for static checking, since they express an implementation-free contract; this makes them important for Dart.
Mixins might be useful in addition to interfaces, but don't fill the same role. Its also early in the game for Dart, unless there is a philosophical opposition to having mixins, they could well be added in. Maybe you should recommend that on the forum on the dartlang.org website?
Why don't they go back to the source, learn the mistakes that Java made (yes, some were just design decisions, others were due to the limitations of computing back then) and create a language initially based on C++
The only way you could "learn the mistakes that Java made" and then "create a language initially based on C++" is if the purposes of learning Java's mistakes was so that you could repeat them.
Modern C++ is pretty good
Modern C++ may good for some things, but they don't seem to be the things Dart is focussed on doing, which is why C++ isn't the dominant present server-side or client-side languages in the domains Dart addresses.
As it is, I imagine Dart will be just Java in all but name with a javascript compiler.
I think the key word in that sentence is "imagine"; actually reading the spec, its not particularly much like Java.
Writing Dart-only websites is obviously a bad idea. Writing stuff that will work an order of magnitude slower on JS browsers could seem like a sensible lazy solution to many, especially if Chrome continues to gain market-share.
Dart->JS might be slower than Dart, but I don't see any reason to expect that it'll be an order of magnitude slower than just writing it in JS would be, since much of it won't be replacing stuff that would be handcrafted in JS, but stuff that would be built on several abstraction layers in most JS apps.
In the worst case, this could lead to everybody having to implement Dart, and the new de-facto standard scripting language being controlled by Google, who, running several of the world's most popular websites, can hardly be considered neutral.
Many things that became part of the HTML5 and related specs were contributed by Google (and many weren't, and many things that came from Google ended up dying without being standardized, like WebSQL DB.) What makes you think that just because Google created Dart they would control it once it was standardized and other browser vendors implemented it?
The assertion that C# requires an IDE is arbitrary and deserves some kind of supporting evidence. Personally, I find that it is much, much easier to write C# without and IDE than C++.
Comparing C# and C++ as languages to write meaningful code in without an IDE strikes me as very similar to comparing a cantalope and an apple as a tool to drive nails. It might be easier (even much easier) to use one than the other, but either is far from a good choice for the role.
It's becoming obvious that browsers need to support a runtime like LLVM in addition to or instead of javascript. That way, the developer could use their language of choice and just compile to LLVM byte code instead of to javascript
In terms of safe and good for scalable, risk-averse environments, there's pretty much just Java and C#.
If by "risk averse", you mean "will only use what at least 1/4 of the rest of the people doing the same thing are using because it needs to be 'established'", then you'll never have more than a couple of options at best.
If you mean any other sense of "risk averse", well, you can probably add Erlang to that risk, and several other things.
In any case, it'll take quite somet time before any newly-created language is established enough to be attractive to any kind of "risk averse" environment.
First class functions? Dynamic typing with optional static typing? Its not really very much like Java. It is more like the love child of JavaScript and C#.
Looking at the spec, it looks like it has some of the best features of both and I'm looking forward to getting my hands on it.
I wonder if they are trying to position this in any way to distance themselves from Java and provide a new interface for Android apps?
They've made pretty clear what their exit strategy for Android is: move things to the browser, merge with ChromeOS, and do everything as browser-based apps (not necessarily web-apps in the traditional sense, as Chrome supports browser based apps that can be fully offline, and which can include native code.)
So, insofar as this is this intends to replace JavaScript as the main programming language for in-browser apps, and can be expected to fairly quickly be supported as a first-class citizen on Google's browsers even if it may be longer before it is supported elsewhere other than via a JS bridge, its part of that strategy, though not necessarily indispensable in that role.
You know, I could find that answer in probably about as much time as it to took you to ask it. I mean, this is slashdot, you'd think people could use the web. RTFFAQ.
I think this is a good thing, but I'm still baffled by people actually using it. AFAIK there is no escape hatch, no way of getting a little special component to run. Say, your app suddenly needs Stunnel, Varnish or HA-Proxy, what do you do?
It doesn't happen, because Stunnel, Varnish, and HA-Proxy aren't things that an app needs, they are thing that an infrastructure layer might use to support functions that the Google App Engine platform already provides. You use App Engine because you distribution management handled behind the scenes by the platform, so you don't need those kinds of tools.
Admittedly, this sacrifices the flexibility to pick and choose your own solutions for those kind of low-level features, but that's something some people want so that they can focus on the core functionality of their apps.
Slashdot Mirror
Actually, the proposal is to add specific enhancement to the existing support for paged media in general in CSS. CSS is no more "native" in browsers than JavaScript is, and browsers are already free to (and some, e.g., Opera in full-screen mode for several versions, do) display content as paged, and CSS already has quite a bit of support for paged media.
Opera has been using paged-media features for full-screen display and pushing for better paged-media features in CSS since before the iPad came out, which makes it hard to believe that argument.
Your "Gee, if only there was a set of standards..." comment would make more sense if Opera's proposal didn't consist of two things:
1. Desktop and tablet browsers should allow the use of existing standard CSS paged-media features (which Opera already does in full-screen mode), and
2. Proposals for additions to existing standards-track specifications to make CSS paged-media features more useful, particular for the pages-on-a-screen use case
Some supporters of FLOSS make somewhat hyperbolic statements. They aren't the mainstream, and you shouldn't get fixated on them.
Some might say that, but that's not my experience. IME, what is usually said that then gets misrepresented by anti-FLOSSers this way is more like:
(From a project maintainer) "(That's not at the top of our queue right now/We've got some concerns about how the obvious ways of addressing that concern might impact existing users) but we'd certainly welcome and be willing to evaluate a patch."
(Alternatively, also from a project maintainer) "Your request to add mandatory line numbers is inconsistent with the direction we want to take our scripting language. However, you have the source, so you are free to fork it and implement that yourself if you really need it."
(From a discussion forum that isn't the main support forum for the product) "Whining about that here isn't going to get you any results. You've got the source, fix it yourself, or, failing that, go to the projects issue tracker at http://www.example.com/mypetproject/tracker and file a bug."
Even if they said what you say, it wouldn't suggest that. It would suggest that people who use FLOSS ought to use their access to the source to correct issues in software that they care about.
It doesn't mean that they need to fix issues in open source software that other people whine to them about, in fact, it is absolutely inconsistent with that attitude.
which is suggesting everyone who uses FLOSS is obligated to fix any issue they encounter.
The thing is, the users of a software package (say, Virtual Box) aren't situated to it in the same way that the developers of some other software package (say, the Linux kernel) are.
The point is, if you care about FLOSS code, then even if the original vendor decides in the future that maintaining that codebase (or even having it continue to exist in use) is contrary to the vendor's larger interests, you can still use it and, if necessary, pay someone else to maintain it.
Whereas with closed-source code, you likely can't do the latter, and under many common license terms may not even be able to do the former.
The argument isn't that everyone who uses open source is obligated to support every open source package that interacts with anything they use or develop, its that anyone who uses open source has the right to address problems in any open source package that is important to their interests.
They are "Linux Kernel developers". They are (as a class) neither the developers of, nor users of, the Virtual Box driver.
They aren't complaining. They are saying "this is a known source of problems; if you report bugs that involve it, you either need to fix them yourself or complain to the people responsible for maintaining this piece of code, not the people responsible for maintaining the Linux kernel."
Um, what they say is, "if you care about a problem with open source software, you can update the code to address it yourself yourself."
In the case of the Linux kernel (which, one presumes, Linux kernel devs, as a class, do care about), they are doing exactly that.
With regard to the Virtual Box driver, they are saying "while we're willing to deal with issues resulting from foreign code in general, we don't care enough to waste time dealing with the huge number of issues produced because the maintainer isn't going to take the code seriously. If you care about this software (the VBox driver), you either need to get the maintainer to care, or you need to put the effort into dealing with the problems it causes yourself."
Which, you know, isn't inconsistent with what their more general position, either.
How would you build such a thing? Real multilanguage environments have a common intermediate representation of some form, and some kind compiler/translator/etc. for each language that converts it to the common representation (or separate interpreters for different languages running on the common environment, or a mixture of both approaches for different languages.)
A "multilanguage interpreter" isn't a coherent concept, its multiple interpreters for different languages that happen to share some backend components.
And, still, Google's working on the fundamental groundwork for that with PNaCl and PPAPI, by providing a starting point for the shared target in the browser and integration with the browser environment (e.g., DOM, etc.) in that shared target, in a way that provides an easier path for many existing languages than compile-to (or interpret-in) JavaScript.
There's a long way to go (PNaCl itself isn't in general release yet), but doing Dart doesn't mean Google has stopped doing the work that is needed to underlie what it seems like you are looking for.
Dart is more than just for clients, one of the big points is that it can also be suitable for server-side applications. But Go is designed for lower-level systems code than what Dart is aimed at, even where Dart would be used on the server side.
(I suspect, thought, that the experimental Go runtime for Google App Engine may never make it out of "experimental" state -- this seems to be an area that Dart is aimed squarely at, and that is outside of the sweet spot for Go as Google is positioning it.)
Creating an isolate is defined in the language spec as being syntactically equivalent to a function call, and passing messages to an isolate is defined in the language spec as being provided by atomic library calls.
Its an essential language feature defined in the spec, though the communication method (but not the spawning method, which looks like a library call) is left to the library.
TryInvoke and friends are somewhat similar, though the calling order of is reversed. OTOH, I can see a case for either order being better, so this is a different-but-not-necessarily-better thing. I don't know that the restriction to DynamicObject descendants in C# is a substantive difference as long as Dart uses closed classes.
Some of them could be, if one wanted to bring in all the baggage of C# that makes it (to my eye, at least) a heavily IDE-dependent, write-mostly language. Being concise has a value, and I don't think C#-without-.NET would be as useful as Dart, as it is, could be as a language for both sides of the web.
Dart -- like JavaScript, Ruby, Python, Lisp/Scheme, and Erlang, but unlike C++, Java, and C# -- looks like it would pass my personal "simple editor test": that is, is all the tool support I really want for editing it (as opposed to SCM and test tooling) syntax highlighting, delimiter matching, and maybe auto-indenting. That's an attractive feature for me (because IDE tooling that eases the pain of writing overly-verbose languages doesn't do as much to ease the pain of reading them), and its probably an attractive feature to Google since they plan on building a cloud-based IDE for it. The less that IDE has to do to satisfy developers, the less work they need to do for that effort to be useful.
The differences between any two Turing-complete languages is always going to boil down to syntactic variations and library features (how big the syntax differences are will, of course, vary).
The fact that those that the differences between [currently popular language] and [new language] boil down to those two things doesn't mean that everyone should use [currently popular language] and that no one should spend effort developing and improving [new language].
As much as developers currently devoted to [currently popular language] will try to convince you that it does (and the argument has, in this thread, been made with C#, Java, JavaScript, and C++ as [currently popular language].)
Dart isn't another Java. Unless, at some point where I wasn't looking, Java dropped mandatory strong typing in favor of dynamic typing with option type checking, eliminated the primitive/object distinction, added Erlang-style concurrency and Ruby-style handling of calls to non-existent methods, and added non-allocating constructors (what Dart calls "factory constructors" rather than "generative constructors"), and factory classes to provide default implementations of an interface so that an interface can be instantiated as if it were a class.
Dart has functional features, including a concise notation for lambda expressions (function literals).
Here's a Dart function literal for a function that takes one parameter and returns the result of adding one to it:
(x) => x+1
Here's an alternative notation for the same thing:
(x) { return x+1; }
Here's a version that uses explicit typing:
(num x) => x + 1;
The isolate/sendPort/receivePort setup seems to be pretty much exactly Erlang-style concurrency, but that's not even close to the whole of how Dart differs from (insert any existing language here). Its certainly an important feature, but its not the sole motivation.
Uh, they are doing that. You don't need an "Anylanguage VM" to do that, you need, well, exactly what PNaCl provides as an execution environment (so that you can run LLVM bitcode anywhere, so anything anyone can compile to that can be run anywhere the browser runs), plus what PPAPI provides to interface with the DOM, etc.
Doing that doesn't stop them from designing, implementing, and promoting a new language designed to be useful both on the client side and the server side of web-apps. Google can do more than one thing at a time. In fact, since there are practical limits to the productivity gains they can get by throwing more resources at any single project, they need to do more than one thing at a time.
Well, today, since they only just announced it. JavaScript (born as LiveScript) wasn't an open, widely implemented standard independent of a single vendor when the first information on it was released by Netscape.
I would say that the condition of Dart with respect to control compared to C# and Java remains to be seen.
Off the top of my head, the things it seems to have that C# 4.0 doesn't:
Interfaces are useful for static checking, since they express an implementation-free contract; this makes them important for Dart.
Mixins might be useful in addition to interfaces, but don't fill the same role. Its also early in the game for Dart, unless there is a philosophical opposition to having mixins, they could well be added in. Maybe you should recommend that on the forum on the dartlang.org website?
The only way you could "learn the mistakes that Java made" and then "create a language initially based on C++" is if the purposes of learning Java's mistakes was so that you could repeat them.
Modern C++ may good for some things, but they don't seem to be the things Dart is focussed on doing, which is why C++ isn't the dominant present server-side or client-side languages in the domains Dart addresses.
I think the key word in that sentence is "imagine"; actually reading the spec, its not particularly much like Java.
Dart->JS might be slower than Dart, but I don't see any reason to expect that it'll be an order of magnitude slower than just writing it in JS would be, since much of it won't be replacing stuff that would be handcrafted in JS, but stuff that would be built on several abstraction layers in most JS apps.
Many things that became part of the HTML5 and related specs were contributed by Google (and many weren't, and many things that came from Google ended up dying without being standardized, like WebSQL DB.) What makes you think that just because Google created Dart they would control it once it was standardized and other browser vendors implemented it?
Comparing C# and C++ as languages to write meaningful code in without an IDE strikes me as very similar to comparing a cantalope and an apple as a tool to drive nails. It might be easier (even much easier) to use one than the other, but either is far from a good choice for the role.
Yes. It is.
If by "risk averse", you mean "will only use what at least 1/4 of the rest of the people doing the same thing are using because it needs to be 'established'", then you'll never have more than a couple of options at best.
If you mean any other sense of "risk averse", well, you can probably add Erlang to that risk, and several other things.
In any case, it'll take quite somet time before any newly-created language is established enough to be attractive to any kind of "risk averse" environment.
Its designed to run both client-side and server-side.
First class functions? Dynamic typing with optional static typing? Its not really very much like Java. It is more like the love child of JavaScript and C#.
Looking at the spec, it looks like it has some of the best features of both and I'm looking forward to getting my hands on it.
They've made pretty clear what their exit strategy for Android is: move things to the browser, merge with ChromeOS, and do everything as browser-based apps (not necessarily web-apps in the traditional sense, as Chrome supports browser based apps that can be fully offline, and which can include native code.)
So, insofar as this is this intends to replace JavaScript as the main programming language for in-browser apps, and can be expected to fairly quickly be supported as a first-class citizen on Google's browsers even if it may be longer before it is supported elsewhere other than via a JS bridge, its part of that strategy, though not necessarily indispensable in that role.
You know, I could find that answer in probably about as much time as it to took you to ask it. I mean, this is slashdot, you'd think people could use the web. RTFFAQ.
It doesn't happen, because Stunnel, Varnish, and HA-Proxy aren't things that an app needs, they are thing that an infrastructure layer might use to support functions that the Google App Engine platform already provides. You use App Engine because you distribution management handled behind the scenes by the platform, so you don't need those kinds of tools.
Admittedly, this sacrifices the flexibility to pick and choose your own solutions for those kind of low-level features, but that's something some people want so that they can focus on the core functionality of their apps.