4 ms·
Honestly I still don't see the point of Dart. It's made some strange choices (IMHO) like optional typing. The idea that code can be shared between client and s
by cletus 14y ago
Honestly I still don't see the point of Dart. It's made some strange choices (IMHO) like optional typing.
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.
- halefx 14y agoDart was actually created by the guys who created V8. They gave a great interview about it in episodes 8[1] and 8.1[2] of Javascript Jabber. 1: http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-bak-and-kaspar-lund/ http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-ba... 2: http://javascriptjabber.com/008-1-v8-and-v8-and-dart-with-lars-bak-and-kasper-lund-bonus-content/ http://javascriptjabber.com/008-1-v8-and-v8-and-dart-with-la...
- orangethirty 14y agoI agree. Even though I'm not a JS fanboy, can't really be against the language at this point. It has evolved a very good community around it, and libraries like Jquery make it very simple to pick up. That just makes adoption of Dart less likely.
- pcwalton 14y agoThere are middle grounds between unsafe manual memory management and full garbage collection other than atomic reference counting. Region systems (like in Cyclone and Rust), for example.
- kevingadd 14y agoYou can also integrate unsafe manual memory management with a full garbage collector in environments like .NET. Use the GC for 99% of your code, manually malloc/free/pin the other 1%.
- bigdubs 14y agoOne of the more elegant ways of handling this, .net does a great job of integrating with unmanaged (COM, i'm looking at you) resources.
- ahoge 14y ago>It's made some strange choices (IMHO) like optional typing. 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) { ... } vs /// Foos the bar. String foo (int x, int y) { ... } Much better, isn't it? 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.
- riquito 14y agoYou made an example of how not to write documentation and then you shown that the code was better without. That is not the point. Try to add content to the documentation, as "what is expected to be x?", then you can't remove it so easily anymore
- polux 14y agoThe point is right now JS developers of big apps write this kind of comments because they are understood by tools like https://developers.google.com/closure/ https://developers.google.com/closure/.
- TazeTSchnitzel 14y agoUm, I think that's a type annotation for closure compiler, not a documentation comment.
- ahoge 14y agoThe closure compiler uses doc comments. YUIDoc or JSDoc comments look pretty similar, for example. However, since this stuff isn't standardized, there are some differences between different flavors.
- 14y ago