Nothing that I can think of that's particularly insightful. Just the basics that, yes, people want to be involved, and that it takes a good amount of effort—technical, mental, and social—to get a proposal to the state that it needs to be in to land in the language.
> Personally, I like the fact that you have them in Github so it's easy to tag, comment, revise, etc.
Thank you! I have to give credit to a team-member who suggested this, but I really really like this model. It lets each proposal be its own little mini-ecosystem and, I hope, should make it easier for multiple people to collaborate on a proposal.
For a long time Dart community were awaiting when Dart VM will be finally built-in into Chrome, and it was one of the selling points we often heard - Dart will be natively executed by the browsers. However, I personally don't think it's a big deal. Even if tomorrow Chrome... even if all the browsers tomorrow will be shipped with Dart VM inside, we still will have to deploy compiled to JS version for the next 3-5 years (the same with ES6 btw).
Don't get me wrong, I am looking forward to see Chrome with Dart VM onboard, I just don't think it's critical for real business apps.
I also second @jenscow's opinion, compilation to JS is a feature that has some important advantages. For the last 1,5 year I've been working on a business web app written in Dart, it's deployed into production. Most of the time we use dev channel to get access to the latest features. For 1,5 year we never had an issue caused by compilation to JS. Actually 2 times we had issues reproducible only in JS version, but the errors were in our own code, had nothing to do with compilation process, regular race conditions that had higher chances to occur in JS.
I now believe compiling to JS is actually a feature: You're only targeting a single "VM" implementation. All the hard work is done for us, and I'm able to use every feature of the language without worrying if a particular browser supports it. Also, you have an optimising compiler and tree-shaking thrown in for free.
Edit : of course that comment applies to server-side oriented languages. For client-side code running in a browser, this is less of an issue. Actually, dart-to-js on the client + golang for the api could be a good combo...
Async/await is just sugar, it doesn't actually change APIs at all. Note C# also added async/await long after their first release.
Check out https://api.dartlang.org for our core libraries... lots of good stuff in there (collections, async, networking, files, sockets, etc).
And if you don't find what you're looking for, check out https://pub.dartlang.org for third-party packages. Everything from crypto to game loops to graphics to frameworks to database drivers, etc.
As for scripting, you can definitely use Dart for console scripts. You can write really simple scripts with just functions. You can read stdio and stdout. (you can even do it synchronously, which is much easier for console scripts :)
