[skalkin]

This is awesome - kudos to the Dart team! Dart was a pleasure to work with since the very beginning, and it is getting better with each new release. I absolutely love the recent focus on strong mode support. DDC is an important addition to the platform, hope hot reloading will follow. Also, can't wait to see what Dart 2.0 brings us!

[isoos]

> hope hot reloading will follow

Which hot reload? (1) reloading the web page on change, (2) reloading the Dart source in the VM. For the later there is this: https://github.com/dart-lang/sdk/blob/master/runtime/vm/serv...

[markdog12]

> can't wait to see what Dart 2.0 brings us

What makes you think there will even be a 2.0? I ask because a couple of years ago there was talk of 2.0, but sadly, that has tapered off to silence.

[munificent]

There will be a 2.0.

We've been quieter publicly than I'd prefer, but we've been no less busy for it. Stuff that's going on:

1. We have a giant corpus of internal code at Google that we support and migrating all of that to strong mode while also iterating on strong mode itself is a ton of work. (Very few languages significantly change their type system after launch!)

2. The new dev compiler that generates cleaner modular JS is maturing and getting an increasing number of internal users. There's a lot of features to add, bugs to iron out, etc.

3. We are consolidating our tools onto a shared front end (lexer, parser, static analyzer). Up until now, we've had independently written and maintained front ends for the VM (in C++), dart2js (in Dart), and the analyzer for IDE support (also in Dart, but a separate codebase). Merging those into a single shared front end is a monumental amount of work since each of those targets has very different needs and hard performance requirements.

Hopefully soon we can start saying more about what's coming.

[markdog12]

Thanks for the update, and appreciate your work. I had been keeping an eye on your nnbd prototype here, https://github.com/dart-lang/sdk/tree/prototype-nnbd

Any updates on that? Do you still think it's a go?

[munificent]

No huge updates. The main thing that I learned (well, more precisely confirmed) from the prototype is that we really do needer smarter type promotion to make it easier to work with non-nullable types.

For example, the current promotion rules would handle:

    test(String? string) {
      if (string != null) {
        print(string.length); // Know string is non-null here.
      }
    }

But aren't smart enough to handle:

    test(String? string) {
      if (string == null) return;

      print(string.length); // Don't know it's non-null here.
    }

We've had a proposal and a desire to improve this for quite some time, and it improves promoting in other cases not involving non-nullable types (when doing "is" checks for type tests).

So right now, I'm working on getting that landed because it's a necessary precondition for non-nullable types and also improves the language even if we don't get NNBD.

Aside from that, I'm not working on it directly. Much of the team is very focused on unifying our various parsers and analyzer's so we're trying not to also throw a bunch of language changes at the same time.

I think everyone wants to do non-nullable types, but it's a big, difficult feature and the longer we wait, the harder it gets. I hope it's not too late, but we'll have to see.

[mezoni]

What a problem?

In a second case, after checking value, type of variable does not changed.

// Vraible "string" still have a non-nullble type here // What problem you found here? // Non-nullble type cannot be null even only because analyzed code. print(string.length); // Don't know it's non-null here.

// This is dead code, if you don't know if (string == null) return;

[markdog12]

Makes sense, thanks for taking the time. The inference mentioned here is indeed nice. Hopeful nnbd will get in at some point!

[floitsch]

It's not going to be in Dart 2.0.

However, it's still on the list of features we would like to work on. Adding it later gets harder (because we don't want to break our users), but we hope that we can find a good migration path.

[mfrancis107]

I'm working on using Dart embedded in a VR platform. One thing I would really like to see in 2.0 is the "new" keyword to go away or be optional. Even when working with Flutter it becomes very obvious how unnecessary the new keyword is.

I also would like to see Anonymous classes like in Java if it were possible.

[munificent]

> One thing I would really like to see in 2.0 is the "new" keyword to go away or be optional.

No promises, of course, but that's something we're hoping to do soon.

[dartdartdart]

It seems like firebase for dart is the preferred 'backend'. Do you know when dart will get a native compute engine support on gcloud?

[wstrange]

Not native, but you can use the Flex Environment to run Dart apps on AppEngine:

https://github.com/dart-lang/appengine

[thosakwe]

If you're interested in rolling your own backend with Dart, I've got a project that might interest you: https://angel-dart.github.io

[SureshG]

Thanks for the update Bob! I know you have been working on nullable types in Dart. Is this something we can expect before Dart 2.0?

[floitsch]

It's currently not planned for Dart 2.0.

We intend to work on it at a later point again.

[hajile]

Now that the browser isn't the primary target for dart, is there work going on to make threading possible?

[floitsch]

There are no plans to add multithreading to the platform.

Currently, we are not spending resources on parallel execution (with isolates), either. There are other easier features that have more impact.

Eventually, we will revisit this topic, and see if we can make things easier. Multithreading itself is extremely unlikely, but there are other ways we can make parallel execution better; for example with easier data sharing between isolates.

[markdog12]

> There are other easier features that have more impact

Which features?

[floitsch]

For example:

- better type promotion (`if (x is! A) throw "not A"; useAsA(x);`.

- Optional new/const.

- Allowing named arguments at any position at the call site.

These are all easier to specify and implement, and reach more users.

[isoos]

I have found isolates easy to work with and useful at scale (number of isolates close to the number of CPU cores), with much better experiences than multi-threaded JVM applications (with all of their locking and starvation issues).

I'd be happy to assist if you share details of what you are trying to achieve.

[munificent]

The web is still very much a top-tier target for Dart. Almost all of our current internal users are targeting the browser. So compilation to JS is and will continue to be critical for us.