Dart is ready for the real world
arstechnica.com
Dart is ready for the real world
1–10 of 53 posts
Re: Dart is ready for the real world
#2You know what, bringing Dart to android development may be a good idea. Web hobbyists hate java with a passion but may embrace Dart for its resemblance with javascript.
Re: Dart is ready for the real world
#3I'm not convinced. After Google killed numerous projects this year, I'm a little skittish about jumping into Dart. When it has the traction of Go, I'll be more willing.
Re: Dart is ready for the real world
#4I'm not convinced. After Google killed numerous projects this year, I'm a little skittish about jumping into Dart. When it has the traction of Go, I'll be more willing.
Second time I've seen this today. An account created minutes after the submission apparently just for the purpose of spreading FUD.
Re: Dart is ready for the real world
#5Dart, attempt 35.
Re: Dart is ready for the real world
#6Is google really betting dart will take off? Because I don't see microsoft/apple/mozilla supporting it in the future. But of course dart can still be a cofeescript competitor.
Re: Dart is ready for the real world
#7Honestly 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.
Re: Dart is ready for the real world
#8I'm not convinced. After Google killed numerous projects this year, I'm a little skittish about jumping into Dart. When it has the traction of Go, I'll be more willing.
All new languages carry with them a very large amount of risk. If for nothing else, it would be good to learn this language to get better at learning languages.
Re: Dart is ready for the real world
#9Dart + Native Client Modules almost makes me excited about web programming again. Obviously not for general websites, but for specific applications it would not be unreasonable to require Chrome to be installed as the alternative would be installing a native app anyway.
Re: Dart is ready for the real world
#10There are some things in Dart that would be nice to have in Javascript, but I don't see why Google wouldn't just try to work them into future ECMAScript revisions. With the exception of banning eval and run-time modification of prototypes, I don't see anything that's completely incompatible with a future revision of Javascript.
I'd even bet that the ES standards committee will eventually give in on the "arrow" lambda style. ES5 has the "function(x) x * x" shorthand, but with C# and Java both settling on "(x) => x * x", I can see it happening in time.