Coming from Dart 1, there’s two major developer-facing changes, the largest of which is a stronger type system, including runtime checks to help catch errors that would arise from mismatched or incorrectly labeled types. This type system, originally called “strong mode”, has long been the default in Flutter. The other is an interesting quality-of-life change for Flutter developers, which allows creating an instance of a class without the “new” keyword. The goal of this change is to make Flutter code more readable, less clunky, and easier to type, but the principle applies to all Dart code.
The complete list of changes has all the details.
I recall when Dart was introduced in 2011/2012 I was super skeptical of it. It wasn’t clear what it was really designed to do: address technical deficiencies in Javascript, or as an attempt at vendor lock-in the web.
Taking a closer look recently and modern Dart seems pretty nice, but Javascript has also brought a lot to the table since then. Fuschia’s tight coupling to Flutter/Dart seems… forced? I guess it helps jumpstart UI development, but it’s making a hell of a bet on Dart’s survival. (although, the argument could be that Dart needs Fuschia to survive more than vice versa)
This all reminds me of C#’s introduction. At the time it felt like Microsoft essentially recreating Java, with a bunch of technical issues fixed. But today C# has grown and evolved into a much different language. Maybe Dart will go through a similar evolution.
I’m keeping an open mind, but I have to admit that I’m ambivalent about Dart also.
That said, I like a few of the changes. In particular, I’m generally in favor of moves in the direction of stronger type systems. I realize there are strong opinions on both sides, but IMO the convenience of type inference is not worth the “subtle” bugs that can creep in.
I would not say that type inference is the major problem here. In using languages like F#, I’ve come to see that it is a safe and convenient feature, provided that static typing is enforced.
The issue with Dart and all languages using dynamic typing is that the runtime can’t tell what the value types are until the code is executed. Because this introduces undefined behavior during runtime, devs have to bring in a whole slew of testing methods to try to be sure that the code executes as intended. IMHO, the “strong mode” is just band-aid for a fundamental problem with dynamic languages like Dart. Being burned by Python on many occasions for large projects, I’ve learned that the convenience of dynamic typing isn’t worth the benefits that it brings.
Edited 2018-08-08 00:39 UTC
I completely agree and this seems to be the consensus for compiled (‘programming’) languages, especially after a few revisions (like Dart’s “strong” or ancient Visual Basics “option explicit”). For non-compiled (‘scripting’) languages dynamic typing is strongly favored.
‘Programming’ languages are normally used for programs that are long-running, have many code-paths, lots of input/output and multiple users. This causes a lot of untested situations to eventually appear that require compiler-support to stay manageable.
‘Scripting’ languages are normally used for scripts that are short-lived, have just a few code-paths, limited input/output and mostly 1 user (the coder). Most unexpected situations will cause crashes that will be experienced by the coder and fixed until the script works correctly “for all his uses”. The script will still have a whole bunch of bugs but since the coder knows how the script is meant to be run those will not happen.
Which brings us to JavaScript, which is clearly a scripting language that is used in an environment where you would normally use a compiled language. Lots of users that have no idea how the code should be used and lots of hackers trying to abuse the input/output. Somehow we ended up with this situation though because the web grew so quickly and unguided that there weren’t enough programmers so we needed coders to get all of the work done quickly and cheaply and “good enough”. Now that we have reached the point where we are running our mission-critical software on the web we are luckily seeing more and more JavaScript-“additions” like TypeScript that add programming qualities to this scripting environment
The problem is combinations of weak type systems and type inference. With a strong and strict type system there is no problem. Think “float x := 1” being a type error because 1 is an integer and not a floating point number, and no possibility of type coercion or implicit casts ever.
C# was basically a continuation of J++, Microsoft’s Java with extensions that were not allowed per its contract with Sun. Improved Java with Windows Forms support.
Dart, IMHO, makes a lot of sense for Flutter. Javascript can mean lots of different things due to the crazy browser support that exists/ does not exist. Of course something like Coffee script or Type script might also work. But having something less ambiguous, is a positive. The comparison to early C# makes a lot of sense here, Google is completely free to taylour the language to the usecase of flutter without having to worry about breaking any ECMA stuff.