A Tour of the Dart Language
dartlang.org
dartlang.org
Lists and arrays are really common though, so I think it makes sense to make it easy to refer to them using short words.
GWT's great when you like static typing, Java development tools, and Java libraries (which I do, so I use GWT), but Dart give you static typing if you want, especially with checked mode, and should support similarly awesome tools because of the typing. Libraries will hopefully come along, and quickly I predict because there won't need to be the equivalent of jQuery and all the classical inheritance implementations.
If you're coming from GWT, just think of Dart as GWT but fast, designed to compile to JS with a native option, and much lighter-weight syntax and language features than Java.
It should be interesting to see whether the safety guarantees of optional typing and the few other restrictions it provides (such as more rigid function signatures) will really entice developers who are planning large web applications. I'm working on a modest-sized (~3kloc) Javascript codebase at the moment and it's somewhat of a mess, but that's really more due to the combined influence of legacy code, time constraints, technical debt, rapidly shifting requirements, and a lack of testing. Other than that last point, it's not immediately obvious how using Dart rather than Javascript would have benefited me. Perhaps someone who's worked with a more substantial Javascript application could provide a better answer.
I agree they're certainly going to have to provide a convincing case for me to switch to Dart in the future but like I said right now it's at least nice to see a second choice being developed.
Dart has more type information, so a Dart compiler has some hints to generate faster code. (And this is why fast JavaScript engines do type inference)
However, in Firefox at least, there are some tentative plans to make debugging transpiled Javascript easier by adding support for identifying the location of the runtime errors in the original source file[1].
I haven't checked, but perhaps there exist addons to allow Firefox's Javascript console to execute CS natively. Other than these two features, I'm not sure what more you could ask for regarding browser support.
Of course, there's no reason a language can't both compete with and compile to Javascript, like CoffeeScript for example.
Really? I got exactly the opposite impression.
All types are nullable (lack of null safety). Why are they using a type (String) for a constant (''final'' variable)? Mixing up lists and arrays. There is a separate string builder class ''StringBuffer'' (which does not share the interface with ''String'', I don't know why not, while ''int'' and ''double'' are unified under the interface ''num'') that doesn't really work. You can't iterate over maps using the ''for...in'' syntax (at least the overview does not mention it).
This document, to me, screams of technical incompetency, or at least of language design from 10 years ago.
There are also some other weird design choices, like optional non-typing (i.e. there are no safety guarantees, types are not enforced), all values but ''true'' are ''false'' (this feature might turn out to actually be useful, but as far as I understand, they want to force people to write proper boolean tests in if statements - why then even allow non-boolean values in boolean contexts?). The ''[x = 1]'' syntax for parameters with default value is really weird, I guess its purpose is to be consistent with the optional argument syntax, but why not just copy what Python does, with all parameters with default values be optional, and you can always set it to ''null'' yourself, if you want...
Julia, for me, is a recent language that is really well designed!
I agree that Dart's features seem sort of "stale" (or perhaps "safe" would be a less inflammatory word). Language design from 10 years ago indeed, although it's still a young language, so I'm willing to give it time to evolve.
In my defense, "reasonably competent" wasn't exactly intended as praise. I do have issues with the things presented in the overview, but at the time I wrote that comment there were no other comments on this article, and I felt that I'd be wasting my time by enumerating them. :P
It's not a constant. Is a variable that contains a value of string type that cannot be assigned to anymore. "String" is an annotation for variable, not for the value.
There is a separate string builder class ''StringBuffer'' (which does not share the interface with ''String'', I don't know why not,
Because string values are immutable, they can't be concatenated without lots of allocations. StringBuffer solves this.
This document, to me, screams of technical incompetency, or at least of language design from 10 years ago.
This is probably because you didn't think out the various trade-offs and design decisions, of which Dart creators thought.
I did, I just didn't want to write too many reasons, just a short rant...
> It's not a constant.
A variable that can only be assigned when it is declared, is not a constant? I think there's a fundamental disagreement in our life philosophies that can not be resolved through debate... ;)
> string values are immutable, they can't be concatenated without lots of allocations
A much more elegant approach that solves most string concatenation problems is string interpolation, which Dart has. There are legitimate uses of StringBuffer, but I'm not sure why they need to mention it in a Language Tutorial.
However, my real complaint is not that. They took the time to put int and double under a common interface, num. So, why not put concrete string and StringBuffer under a common interface, called string, and also have StringBuffer implement a monoid interface (for the + and * operations).
Edit: I hope this doesn't come off as rude. Just tried to clarify my original points.
main() {
final v = [1, 2, 3];
print(v.length); // => 3
v.add(4);
print(v.length); // => 4
}
However, my real complaint is not that. They took the time to put int and double under a common interface, num. So, why not put concrete string and StringBuffer under a common interface, called string, and also have StringBuffer implement a monoid interface (for the + and operations).*
Then what happens when you want it as a key in the map? Really, string buffers and strings are different concepts. Even Ruby, with its mutable strings, has StringIO.
Edit: I hope this doesn't come off as rude. Just tried to clarify my original points.
Of course not, we're having a great discussion.
The second issue, happens everytime you try to put a mutable object into a hashtable. I get bit by this issue quite often in python. In my opinion, there should be a default toMutable method that would make mutable objects immutable, and the map would then store the immutable version. That way, you could store e.g. Python lists in dicts, and have them compared by equality.
There are starting from way behind, because javascript has a wide range of good libraries, several decent frameworks and a few okay tools. Dart has virtually nothing. Google's thousands of really great developers, could build out a first rate, albeit single party, ecosystem. It remains to be seen if they will.
I had a look at Julia and as a result I think that there is some solid value in designing a language whose performance can match C if needed yet use dynamic typing when convenient.
I just don't know what to do next: CoffeeScript or Dart?
Both improve on Javascript. CoffeeScript with a cool syntax. Dart with performance.
How can I have both?
* This is based on most browser vendors not being supportive of it.
Dart is a web friendly optimized SmallTalk with a Javascript like syntax.
It looks like Javascript but feels like SmallTalk.
If that marketing trick works, it will be ironic because Scheme inspired Javascript looked like Java for the same marketing reason...
CoffeeScript might be Javascript's swan song.
As far as native support in other browsers, it appears that Mozilla currently outright refuses to consider it on the principle that Dart is not developed openly and is not standardized, meaning that implementations in other browsers would have to reverse-engineer the Chrome implementation and would be at the mercy of Google with regard to compatibility. Unlike Mozilla, Apple and Microsoft appear to have rejected it out of pragmatism rather than principle. Specifically, Apple's Webkit engineers appear to object to the complexity and overhead a new virtual machine would add[1], and Microsoft has publicly stated that Dart doesn't solve any problems that can't be fixed in future iterations of Javascript[2].
For a more detailed technical and political perspective of why Mozilla won't implement Dart natively, see Brandon Eich's comments on the original Dart announcement[3] (it's actually quite an interesting read).
[1] https://lists.webkit.org/pipermail/webkit-dev/2011-December/...
[2] http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-ecmas...
The overhead of Dart compiled to Javascript will hopefully be very minimal, and in some cases Dart might generated code that runs faster than what a programmer might write.
The reason for the existence Dart VM is not because Dart->JS will be slow, it's because Dart should be able to be faster than Javascript because it's easier to optimise. The creators of V8 are writing the Dart VM, so presumably they have some ideas about how to make it faster than Javascript.
If there does turn out to be significant overhead to the transpilation phase, I'm curious if a pragmatic subset of Dart will emerge that avoids any language features that incur expensive tranformation costs, sort of like how some modern Python projects (e.g. Django) handle 2to3 compatibility by avoiding language features that are incompatible across versions to achieve a more unified codebase[1].
[1] http://groups.google.com/group/django-developers/browse_thre...
My point is that this is not really true. The Dart language itself is designed to compile to efficient Javascript.
This is one reason it's a better solution than GWT in my opinion, because Java does not always compile to efficient Javascript and you do have to skip features like longs, Java regexes, even the java.util collections classes are heavyweight. Dart being designed from the start to compile to Javascript avoids most of these problems.
Like CoffeeScript, I expect Dart performance to be very close to Javascript when compiled, sometimes even faster than what a programmer would normally write.