Google Dart has become easier to try with binary builds of the Dart editor. The SWT/Eclipse-based tool includes the DartC compiler, project management, application wizards, etc. and allows to run Dart applications compiled with DartC.
The editor runs the type checker on all code and annotates code that contains problems; providing type annotations helps the type checker be more useful.
DartC, shipped with the Dart Editor, is a Dart to Javascript compiler written in Java. The question "Why is DartC not written in Dart" can soon be retired thanks to a new project in the Dart repository: Frog is a Dart to Javascript compiler written in Dart. The project is now part of the Dart repository and is improving and evolving very quickly; it can also serve as a growing example Dart codebase.
The Frog project was started by none other than Jim Hugunin, the creator of Jython and IronPython who now works at Google. Jim explains his experience with Dart (from the linked mail):
I've spent most of my career trying to end the battles between the dynamic and static worlds and instead bring them together so that each side can enjoy the benefits of the other. Writing this compiler in dart is the first time that I've really felt the effortless blend of these worlds that I've been seeking.
[..]
Dart is the first time that I have been able to start off writing code in a very dynamic fashion and incrementally add static checks as designs become solid or complexity warrants the effort.
Google announced Dart as "technology preview" to get feedback and comments from the community. The language is far from finished; important details such as reflection are being worked on right now. The community has started providing feedback on the Dart mailing list and on the web.
One example is Bob Nystrom (who is on the Google Dart team) who has provided a proposal to add nullable types to Dart. The basic idea is that all types are non-nullable, but adding a ? to a type annotations allows that type to also accept null as a value.
For details see the proposal text, but here's one of the reasons for nullable types (from the proposal):
Gilad describes Dart as having a "documentary" type system. With nullable and non-nullable types, we can now use type annotations to tell users of our APIs which things accept null and which don't. In other languages you have no choice but to spell that out in the documentation. With this, it's right in the type signature for a method. If you call method(Foo a, Foo? b), it's clear that it can handle a null for the second argument but not the first.
Nullable types and similar ideas are of course not new and are present in other languages, either as part of the type system or, for instance, in the form of Java annotations like @NotNull. Considering the trouble null has been causing, it can be a useful feature to have.
Gilad Bracha, who is on the Dart language team, recently gave a talk on Dart and explained some of the ideas behind the optional type system, citing documentation as the most important contribution. Just like Java's annotations or C# attributes, Dart's type annotations are optional and have no direct impact on the runtime behavior of the system. A video and transcript of Gilad's talk is available. An interview with Gilad about Dart is available at Channel9.
Another resource for Dart news is the DartWatch blog which provides news and also explores various areas of Dart.