[dart-announce] A stronger Dart for everyone

['Anders Sandholm' via Dart Announcements]

http://news.dartlang.org/2017/06/a-stronger-dart-for-everyone.html

--

Anders Sandholm | Product Manager Google Product Infrastructure & Ads | Lead PM for Dart

--
For more news and information, visit https://plus.google.com/+dartlang
 
To join the conversation, visit https://groups.google.com/a/dartlang.org/

[Jan Mostert]

At what versions wil these phases kick in and what is the approximate timeline, 3 months, 6 months, 2 years ?

We're currently on 1.23.0 and will be switching to 1.24 later this week, we're already using a `analysis_options.yaml` file which gave us fantastic feedback. Will the strong typing just be the analyzer getting stricter or will this run outside the analyzer directly in the compiler?

Also, I'm assuming, with strong typing comes type inference?

How much type inference can we expect, would it be limited such as in Java where you only get type inference in generics and lambdas or will it be completely type inferred like in Kotlin where you can literally just write var / val for anything and hardly ever have to think about the type?

With regards to Angular2/3/4, I'm guessing this strong typing will be spilling into Angular templates as well?

Exciting news nevertheless, the optional-typing always felt like a double-edged sword. A strict type system that doesn't require boilerplate to specify types everywhere is a huge win if that's the direction Dart is going.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Matan Lurey]

--announce@ to BCC.

On Mon, Jun 26, 2017 at 1:15 PM Jan Mostert <jan.m...@gmail.com> wrote:

At what versions wil these phases kick in and what is the approximate timeline, 3 months, 6 months, 2 years ?

We generally avoid specific dates and timelines and are instead milestone/feature/correctness oriented. In this specific case, the only answer I can give is when:

  (a) Strong-mode dev experience is good as or better than the current experience

  (b) All tooling (Dart VM, dart2js, included) use the new specification

  (c) The old specification is updated, and we've released with little/no bug reports

You can follow along on GitHub for Milestones 1.25 and 2.0.

 

We're currently on 1.23.0 and will be switching to 1.24 later this week, we're already using a `analysis_options.yaml` file which gave us fantastic feedback. Will the strong typing just be the analyzer getting stricter or will this run outside the analyzer directly in the compiler?

These are really good questions!

The first "places" to implement strong-mode are the analyzer (opt-in, via strong-mode: true), and the DartDevCompiler (dartdevc, which only implements strong-mode). Both the standalone Dart VM/Flutter and dart2js will also implement strong-mode for 2.0, which means the compilers will also understand it.

A big part of Dart 2.x is using a common front_end that understands Dart strong-mode semantics (and type inference, etc) and emits an IR format called kernel, which in turn is used by our tools to compile to native code, VM instructions, and JavaScript accordingly.

Some of this is based on prior art on a Dart on LLVM experiment :)

 

Also, I'm assuming, with strong typing comes type inference?

Yup!

 

How much type inference can we expect, would it be limited such as in Java where you only get type inference in generics and lambdas or will it be completely type inferred like in Kotlin where you can literally just write var / val for anything and hardly ever have to think about the type?

In most code I've interacted with, var, const, and final all infer the types correctly. There is a nice overview at the "Sound Mode Dart" (we use Sound/Strong interchangeably, so sorry for the confusion). The tools (analyzer) are pretty good at telling you when you need to manually annotate due to the result being ambiguous or not inferable.

Here are the specific docs around type inference:

https://www.dartlang.org/guides/language/sound-dart#type-inference 

 

With regards to Angular2/3/4, I'm guessing this strong typing will be spilling into Angular templates as well?

Yup! In reality, we've been sort of cheating and slowly making the AngularDart compiler use strong semantics even when inference was not yet supported in your tools, and today AngularDart functions correctly in DDC/Strong mode.

We have a bit more work to do to make everything 100% though (we still fall back to dynamic calls in some situations. There is a project tracking specific issues on github.com/dart-lang/angular2.

[Bob Nystrom]

On Mon, Jun 26, 2017 at 1:15 PM, Jan Mostert <jan.m...@gmail.com> wrote:

At what versions wil these phases kick in and what is the approximate timeline, 3 months, 6 months, 2 years ?

We don't usually comment on timelines, unfortunately. I know it's really valuable to do so, but it can set the wrong expectation when we later need to change the schedule.

We're currently on 1.23.0 and will be switching to 1.24 later this week, we're already using a `analysis_options.yaml` file which gave us fantastic feedback.

Yes, if you've got strong_mode: true in your analysis options, you're getting most of the experience of the new type system already. The main missing pieces are:

• There is a runtime component to strong mode that the VM and dart2js don't implement yet. Checked mode kind of covers some of it, but there are some corners around inference and subtyping where the strong mode runtime behavior is a little different.
  
  
• If you rely on dart2js for generating compile errors, it doesn't report all of the strong mode static errors yet. In practice, most users rely on the analyzer for that anyway.

Will the strong typing just be the analyzer getting stricter

Probably not too much stricter. We are still tweaking strong mode in various ways, but it's pretty mature at this point. The announcement is really about stating that strong mode as it already exists will now become the canonical type system for Dart and not a thing you have to opt into.

or will this run outside the analyzer directly in the compiler?

That too. Once the transition is complete, all of our tools will use this one type system.

 

Also, I'm assuming, with strong typing comes type inference?

Yes, strong mode already does pretty solid type inference and has for quite some time. We're tweaking a few things here and there, but overall it works well. It's what enabled us to move tons of internal Dart code onto using strong mode without too much migration pain.

 

How much type inference can we expect, would it be limited such as in Java where you only get type inference in generics and lambdas or will it be completely type inferred like in Kotlin where you can literally just write var / val for anything and hardly ever have to think about the type?

More the latter. You're probably already using type inference now without realizing it. :)

You do have to think about types sometimes. Things like method signatures aren't inferred. The language still feels like a statically typed one where you have a pretty solid idea of what type of values are stored in what variables. It just doesn't require you to write down the types as often as you have to in Java.

 

With regards to Angular2/3/4, I'm guessing this strong typing will be spilling into Angular templates as well?

Yes.

 

Exciting news nevertheless, the optional-typing always felt like a double-edged sword. A strict type system that doesn't require boilerplate to specify types everywhere is a huge win if that's the direction Dart is going.

I totally agree! I think the main benefit of the previous optional type system was that you didn't have to annotate the types as much, not that you could use tons and tons of dynamism. In practice, most code — even in fully-dynamically typed languages like Python — isn't actually that dynamic, and there are real costs to losing static analyzability.

Strong mode gives you most of the same lightweight feel and brevity of the old type system, but also gives you most of the static safety and tooling you expect from a statically typed language.

Cheers!

– bob

[Michael Francis]

Will Strong mode translate to improved VM performance? Because it makes things more predictable?

['Bob Nystrom' via Dart Announcements]

A sound type system definitely opens the door to optimizations that a compiler or VM could take advantage of, especially in an ahead-of-time setting. For example, dev_compiler relies heavily on strong mode in order to generate smaller, cleaner JavaScript code. If it couldn't rely on types being sound, it would end up generating larger, more pessimistic, likely slower JS since it couldn't rely on the type annotations being correct.

But no promises as to whether our other implementations like the VM will take advantage of the types any time soon.

Cheers!

– bob