Yes, this may look a bit weird, but it actually makes perfect sense. Those types are annotations. If you use them at the "API boundaries" (parameters and return values), you already get most of the benefits you may know from Java or C#.
Compare the doc comments you usually have to write with those baked-in type annotations:
/**
* Foos the bar.
* @param {int} x
* @param {int} y
* @returns {String}
*/
function foo (x, y) {
...
}
/// Foos the bar.
String foo (int x, int y) {
...
}
Additionally, adding those type annotations is useful right off the bat. The IDE will make use of them right away.
>Go on the other hand [...]
Well, Go is very different. It has a completely different focus. It's more like Rust, for example.
Try to add content to the documentation, as "what is expected to be x?", then you can't remove it so easily anymore
Both code snippets are equally documented. That triple slash thing is a doc comment and the type annotations will be also used by dart doc.
Furthermore, those type annotations will be used by the IDE right away. It will tell me if I pass something of the wrong type or if I do something silly with the return value. That type information will be also shown in call tips. I can also run my stuff in checked mode during development, which will make sure that everything is used correctly.
That's the advantage of having this kind of annotations baked into the language itself. It's a lot less annoying to write and, since it's standardized, every tool can use this information, too.
Since this stuff is optional, you can gradually add them as you go. You can quickly prototype something and if it worked as intended, you can add some types while you clean it up.
YUIDoc or JSDoc comments look pretty similar, for example. However, since this stuff isn't standardized, there are some differences between different flavors.
1: http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-ba...
2: http://javascriptjabber.com/008-1-v8-and-v8-and-dart-with-la...
The idea that code can be shared between client and server is the panacea touted by GWT, which (IMHO) failed to eventuate (eg some classes weren't "GWT compatible" and this included protocol buffers generated classes). Dart seems like the next throw of the dice. I am not optimistic about its successes.
Go on the other hand, seems to have an incredibly bright future (IMHO) and it has lots of things in it that I like.
The only issue with Go, as a low-level (C++ replacement) language at least, is that it is a GC language. I used to think that you could implement some kind of ARC (automatic reference counting) system a la Obj-C/iOS 5+ as a middle ground between manual memory management and GC but I now have doubts about this, largely due to reference counting being an issue with locking on highly concurrent systems (something not an issue on phones with Obj-C/iOS).
More to the point, I think Javascript is like the email of programming languages: its ubiquitous and a whole bunch of people are convinced it needs fixing but I'm not exactly sure why. More to the point, those fixes seem to be incredibly complicated to the point of being a questionable value proposition.
I've been using AngularJS of late and to me it's a bit like the Lisp of Javascript frameworks in the sense that it is actually incredibly expressive but can have a steep learning curve. There is a lot that's simple about Angular but once you start delving into custom directives that support ngModel and the like you start requiring a deeper understanding of what's actually happening.
Anyway, back to Dart: I wish them the best but the complexity of language cross-compilation I think diminishes most if not all of the benefits of client and server language-sharing.