Tuesday, March 31, 2015

Live analysis results with WebStorm 10 and Dart

Today, JetBrains announced the new WebStorm 10 release, which includes significant enhancements for the Dart developer. The new version adds live analysis feedback, and fixes many reported issues. We highly recommend that all WebStorm users upgrade, and that new Dart developers who want a full-featured IDE try the new WebStorm 10 release.

WebStorm now provides on-the-fly code analysis results for Dart code, powered by the Dart Analysis server. You can quickly look through the list of warnings and errors in your project in a tool window or see them highlighted right in the editor.

WebStorm can now auto-import new libraries into your Dart code. Simply press Control-Space twice, and you will see a list of all libraries that are available. Select the library you want to use, and WebStorm automatically adds the necessary import statement to the top of the file.

You can use Dart's new async/await and generator features in WebStorm 10. Asynchronous code is now easier to write and understand, and the new language features make generating Streams and iterators much easier.

Also included in WebStorm 10 are numerous fixes and enhancements for formatting, code completion, code navigation, documentation, and more.

You can learn more about what's new in WebStorm 10, and download WebStorm 10 to create a new client or server Dart project. We hope you enjoy WebStorm's powerful Dart and web development capabilities.

Thursday, March 26, 2015

Dart 1.9: The release you’ve been await-ing for

Asynchronous programming is everywhere – user interaction, network access, file I/O. Dart simplifies and enhances these scenarios with the 1.9 release.

Today’s release introduces async methods and await expressions built on top of our existing Future API. You can now use familiar control flow features – for/while loops, if blocks, and try/catch – to manage complex asynchronous interactions. These new features are explained thoroughly the Dart Language Asynchrony Support: Phase 1 article.


Dart’s Future API makes it easier to compose asynchronous operations, but handling conditional cases and errors can still be difficult.


async and await make implementing the same functionality straightforward.

We are also introducing generator methods – sync* and async* – that make it easy to lazily generate sequences, eliminating almost all cases where developers need to create custom iterators or manually manage stream creation. For more information, read the Asynchrony Support: Phase 2 article.

For a high-level overview of all of these new features, take a look at the Asynchrony section of the Dart Language Tour.

In addition to async, Dart 1.9 includes a number of other enhancements.

  • enum, a long-requested feature, is now fully supported.
  • The Dart Analyzer has moved to the Dart Analysis Server. This makes it much easier to integrate Dart source analysis into IDE’s beyond the Dart Editor (for instance, IntelliJ and Sublime).
  • We've updated the regular expression engine for the Dart VM. It's up to 150x faster than the previous implementation.
  • The Isolate API has now been fully implemented in the Dart VM, making it much easier to create applications that target multiple CPUs.

For a full list of the changes in this release, take a look at the release notes.

Visit the Dart download page to get started with Dart 1.9. Check out the Dart support page for information on getting help, filing issues, and contributing to the project.

Wednesday, March 25, 2015

Dart for the Entire Web

We work with many teams, inside and outside of Google, that use Dart every day to build business-critical apps. Their feedback is consistent: they love working with the Dart language, libraries, and tools, and they compile Dart to JavaScript when they deploy to the web.  However, they also tell us they need better integration with JavaScript, and they need an easier way to debug and optimize their apps across all modern browsers. We listened, and today we are announcing a more focused strategy for Dart for the web.

In order to do what's best for our users and the web, and not just Google Chrome, we will focus our web efforts on compiling Dart to JavaScript. We have decided not to integrate the Dart VM into Chrome. Our new web strategy puts us on a path to deliver the features our users need to be more productive building web apps with Dart. It also simplifies the testing and deployment scenarios for our developers, because they can focus on a single way to build, test, and deploy their Dart apps for the web.

Google Ads, one of Dart's biggest customers, is committed to Dart and supports this new strategy. Scott Silver, VP of Engineering for Ads, says, “We are committed to building our next-generation web apps with Dart, and a renewed focus on generating optimal JavaScript helps us deliver great apps to everyone with a modern browser. Dart has significantly improved our engineers' productivity and our ability to quickly launch and iterate. We currently have one million lines of Dart code and the number is growing fast.” Many other teams inside of Google, such as Google Fiber, Google Express, and Google's internal sales team, use Dart for business-critical apps.

Dart developers outside of Google are also very supportive of our new focus. When DGLogik, developers of Internet of Things applications, needed to convert their complex visualization software from Flash to HTML5, they chose Dart because “the Dart team's focus on the entire web ensures we continue to deliver great experiences for all our users.” Dennis Khvostionov, CTO of DGLogik, continues: “Without Dart's productivity benefits and tooling, we'd need a team twice our size.”

Many of our developers use Dart for both client and server apps, reducing costs by sharing code. We remain committed to optimizing and improving the Dart VM for developer tools, servers, and mobile apps.

We started the Dart project because we believe that every developer deserves simplicity, productivity, and performance. Our new web strategy makes it easier for developers to build with, and for, the modern web with Dart. With Google Ads' long-term commitment to Dart, and our new focused strategy for the web, we are excited by our path forward.

- Lars Bak & Kasper Lund, Dart co-founders

Monday, March 23, 2015

Create your own REST API with Dart

We created Dart to help make developers as productive as possible. While we were building Dart Pad (a browser-based app to help developers learn Dart), we didn't want to spend a lot of time writing boilerplate code for serialization or routing in the REST API. We built the RPC package to help make building REST APIs easier, and today we're happy to announce that it is open source and ready for you to use.

You can use the RPC package to automate the data serialization and request routing for your REST API. Exposing a REST API is simple. Annotate your classes and methods with the HTTP methods, URL paths, etc. Here is an example of a simple echo service.

After you configure your HTTP server (see README), your API can now be reached at:

GET http://<server url>:<port>/api/echo/v1/identity/<name>
POST http://<server url>:<port>/api/echo/v1/inverse

Calling your new server API from client code (written in Dart, Java, Go, iOS, Android, C#) is also easy. For more details on the specifics, check out the README. You can also find a simple Getting Started example that shows how to hook it all up using either dart:io or shelf.

We currently use the RPC package for Dart Pad and TodoMVC, and we hope you'll find this package as helpful as we do. We look forward to your feedback.

Written by Gustav Wibling, Rapid Productivity Champion

Friday, March 20, 2015

Announcing Dart Developer Summit Sessions and Registration

We invite you to Register Now to connect with Dart engineers and developers at the first Dart Developer Summit, April 28-29 in San Francisco, California.

Join us for two full days of sessions and breakouts, covering everything from client to server, embedded to mobile. You'll hear from a range of speakers from the Dart team, Googlers using Dart, and the Dart community.

Some of the sessions include:
  • Keynotes from Dart's co-founders and Google Ads
  • Deep dives into new features like async/await and reflectable
  • Dart for the Web state of the union
  • Dart for Internet of Things
  • Case studies from Trustwave, instill.io, Google Fiber, and Workiva
  • Not one, but two sessions on Dart for mobile
  • Lots more!
One of the best reasons to attend the summit is the opportunity to meet our engineers and community. Our breakouts and Birds of a Feather sessions ensure we collaborate and help build the future of Dart together.

We look forward to connecting with you at the summit. Register now to secure your ticket, and learn more about the Dart Developer Summit.

Can't make it? No worries, you can watch the live steam and catch the videos on YouTube.

Thursday, March 12, 2015

Highlights from the TC52 meeting on Feb 24, 2015

At the last TC52 meeting on Feb 24, 2015, we discussed a number of additional language features for Dart - including async, tear-offs and null-aware operators.

Update on async

Gilad reported that the implementation had, unsurprisingly, exposed some subtleties in the spec that need to be considered.  Some small adjustments in the language specification may follow from this.

The virtual machine now implements the sync* mechanism.  The async* mechanism is coming along.  The dart2js implementation is complete with respect to the feature set, but it still needs to be debugged.

The development of the async features has given rise to some useful insights.  For instance, sync* creates a synchronous generator, handling all the boilerplate for lazy iteration.  However, the documentation of the library classes need an enhanced level of precision in order for this to work well with the language implementation and specification.  The connection arises because the language specification says that Iterable is implemented by sync* methods.  A conflict arises because Iterator and other classes are allowed to cache some values such as the length, but this is not applicable for sync* functions, and so the spec needs to restrict that.  Consequently, the library documentation has been revised.

An issue arises with “nested” empty iterables for yield*.  The idea is that yield* is used to merge the output from a subiterator into the output of a given iterator.  The wording in the language specification did not specify exactly what to do if that subiterator were empty, but the intention is that the subiterator should be processed normally and iteration should be continued from where it was before that subiterator was inserted.  Adjustments to the specification will be made to clarify this.

Several issues have come up in connection with async primitives:

One issue is whether a construct on the form await (throw x) can throw immediately, or “await always awaits” must prevail.

It was noted that the return type of async uses flatten to avoid nested future types, and also that this should not create any difficulties for the type analysis.

It is not obvious whether await-for loops should require a Stream as the source of the awaited data, or they should allow for non-Stream objects with the required features.  The question arises statically, where a type warning may or may not be given for a non-Stream.  The question arises dynamically where a non-Stream may cause a runtime type error.

Currently, the implementation performs such a check dynamically, even in production mode.  We quickly agreed that it is problematic to have a dynamic check without an accompanying static warning, and also that any such dynamic check should probably only be performed in checked mode.  It is not obvious how to resolve the overall issue, though.

Erik pointed out that there is an underlying principle for this kind of decision:  The language may allow for any object that responds to the requests made by the generated code, or it may enforce a nominal type such that only objects implementing Stream can be used.  The rationale for the former approach (let us call it the “pragmatic” approach) is to run everything that can plausibly be given a semantics, no matter whether or not it is aligned with the associated type structure.  The rationale for the latter approach (let us call it the “typeful” approach) is to support software correctness via explicit contractual obligations and expectations (as expressed by nominal types and supported by dartdoc comments etc.).  It is possible to use both a pragmatic approach and a typeful approach, both statically and dynamically, so all four combinations must be considered.

Dynamically, the pragmatic approach seems to be well aligned with many other decisions in the language design (it’s the “Darty” choice); but as Gilad mentioned, the code that actually implements the features which are used in this context is so subtle that ad-hoc alternative implementations to the ones in the standard library are very likely to be a steady source of stubborn bugs.  For the few highly sophisticated developers who insist on writing their own implementations of “something that works as a stream” it should be easy to add an implements Stream clause to their implementation, such that it works with the stricter, typeful approach.

Statically, the pragmatic approach may be seen as a mistake, especially in the (presumably, vast majority of) cases where a non-Stream is used by accident rather than by intention.  Conversely, if a static warning is given whenever a non-Stream is used in this context, it will cause frustration for the sophisticated developers who have carefully chosen to use a non-Stream.

In summary, we may have implicitly preferred the typeful approach statically and the pragmatic approach dynamically, but no explicit decision was made.

Another matter is that a decision on an underlying principle in this case naturally affects the treatment of similar constructs, including the standard for statement, where changes would obviously be much more difficult.

A quite different issue is the decision about whether yield in async* may suspend.  If a tight loop contains a yield, it may produce a large number of data items which are not being received quickly enough.  These situations create a need for more flexibility than that which is currently granted by the specification.

Finally, Gilad mentioned that there are some missing static warnings in relation to async*/sync*, and a few other small issues.

Update on “Dart Enhancement Proposal”

We are ready to launch the process, and several activities are already taking place.  The process is github-based (see https://github.com/dart-lang/dart_enhancement_proposals).  The idea is that DEP authors file an issue in this github repository which includes a link to the proposal itself, which is stored as a separate github repository.  The proposal repository may also contain other elements such as examples, implementation etc.  The committee will go over incoming proposals according to the flowchart.

TC52 has a royalty-free patent policy. Therefore, when a proposal is accepted by the DEP committee for processing by TC52, the original contributor of the DEP needs to sign the 'ECMA TC52 external contributor form'.

Update on language extensions

Two things are likely to be ready for the next version of the language specification: Generalized tear-offs, and null-aware operators.

For generalized tear-offs, the coverage and discussions at the previous meeting are still valid.  Now there is a complete proposal which is currently getting prepared for markdown presentation etc.  It can be found at https://github.com/gbracha/generalizedTearOffs.  It is done in a way that should be identical to the way that an external contributor could submit a proposal, such that it also serves as a test of the procedure and the associated documents.

For null-aware operators, the information and discussions from the previous meeting are still valid.  In this case it is a very simple proposal, just syntactic sugar, but it comes at a low cost.

We briefly discussed a proposal from Erik to change the class Function to take one type argument which would be the return type of the function represented by the given instance.  This could enable the type Function<T> to be more useful than the current type Function, and it seems to be a benign change because all existing occurrences of Function would be reinterpreted to mean Function<dynamic>, which would have a backward compatible semantics.

We did not discuss configurable imports, union types, generic methods, closure tear-offs, improvements to Type Promotion, nor subtyping for function types.  In most cases this was because there is nothing new.  For function type subtyping it was because we need to consider changes to the runtime semantics of Dart very, very carefully before we commit to them.

Next meeting

The next TC52 meeting is on March 19th, 2015. Main topics expected are finalization of tear-offs and null-aware operators.

Friday, March 6, 2015

Beautiful automated code formatting for Dart

I spend a lot of time reviewing Dart code. At Google, we use the Dart style guide, but we humans are poor at consistently following rules. I end up writing a lot of review comments like "put a newline here" and "remove this space". Although we have an automated formatter, dartfmt, to address this problem, I wasn’t happy with its output.

Over the past few months, I spent a bunch of time adding a sophisticated rule engine to the formatter, helping it choose how best to format a chunk of code. There are still improvements to make, but I believe the formatter is now good enough to be run on all of the world's Dart code.

We've been using this version of the formatter internally for a while, and people really like it. Everyone loves that it ends style debates and makes code reviews easier. Today, I'm happy to announce that the new formatter has landed in the dev channel SDK. Using it is as simple as:

    $ dartfmt -w <file or directory>

I'd love to have you try out the new formatter. Check out the docs, and if you have feedback, throw an issue my way.

– Bob Nystrom, Chief Formatting Officer

Wednesday, March 4, 2015

Evolving the Dart language with Dart Enhancement Proposals

In July 2014, Ecma published the first version of the Dart language specification. Ecma TC52 continues to release updated versions with new features (for example, async/await). Our developers have asked for more insight into the discussion process, and for a formal way to seed the spec process with proposals. Today, we're happy to announce Dart Enhancement Proposals as the primary way for the Dart team and the larger Dart community to work together to evolve the Dart language and libraries.

To make a great language that can be used to write great programs means we need to work together. The DEP process is how we do that. We want to:
  • Create an open, collaborative, and inclusive Dart ecosystem.
  • Be responsive to developer needs.
  • Give the community a sense of shared ownership and stewardship.
  • Be transparent about the work leading to Dart language changes.
  • Ensure rationale for changes (or decisions not to change) is clearly communicated.
  • Close the loop and check if stakeholders are happy before a change is finalized.
Anyone can create and champion a DEP, but this does not mean that Dart is a democracy. The DEP process is a key part of how we decide how Dart should evolve, but it's only one part. DEPs are managed by the DEP committee. The committee meets on a regular basis to review the proposals. Because Dart is an open Ecma specification, TC52 has final say on what changes land in the spec.

We're just getting started with the DEP process. To learn more, check out the GitHub repo for more details, review some of the initial proposals, and review the notes from the first DEP meetings. You can also join our DEP discussion mailing list.