Smalltalk? meets very few of those points, whilst it has inspired a number of languages it's not a real-world choice itself for developing complex web apps. Dart's closest language is JavaScript (which it also transpiles to) of which it presents a compelling option and holds a number of advantages over - esp. for maintaining large web apps.
I've also used a number of languages in the last 15 years, and I've personally found Dart to be overall be the most productive which has become my go-to language whenever I need to something quick done. It's missing an ecosystem of mature libs which popularity helps most with - but Google has a ton of investment behind Dart which is developing the entire platform (language/libs/toolchain) giving it its best chance to succeed - if it fails to gain any traction it wont be for technical reasons. It looks like it will take over and be the preferred to succeed GWT and Closure Library, with internal usage it should see continued investment for years to come.
> - Provides a familiar language with clean semantics and low ceremony
Smaltalk had it.
> - Provides the fastest dev iteration times (there's no compile step, just edit + run in Dart VM/Dartium)
Smaltalk had it.
> - Provides ~10x faster start-up times than JS with snapshots (Dart VM)
Smaltalk VMs, actually Self, were where the first usuable JIT compilers were developed.
> - Provides faster run-time performance, that's predictable and can take advantage of real integers and SIMD instructions (VM Only)
Self and StrongTalk were quite performant. SIMD was not available back then.
> - Provides a unified object model so all classes from all libraries are interoperable
Smaltalk had it.
> - Providing a rich, well-defined, consistent API, real collections, removing JS WATs, smoothing over browser quirks
Smaltalk had real collections.
> - Provides a unified and composable IO model: Futures and Streams (repeating events)
Smalltalk has streams.
> - Provides a new powerful way to develop client apps with Web UI (Polymer/WebComponents) offering unprecedented levels of encapsulation and reusability
Fare enough regarding WebUI, as the web did not exist back then. However Smaltalk is responsible for the MVC concept.
> - Provides optimal dev and deployment options, you never have to worry about choosing the smallest libs as tree-shaking ensures only code used is compiled and minified
VM pruning in Smaltalk environments for deployment.
> - Providing "full-stack" dev environment, e.g. same language on client and server
This is only true when using Dartium. Transpiling to JavaScript does not count.
Provides a familiar language with clean semantics and low ceremony
> Smaltalk had it.
Smalltalk's syntax is anything but familiar, which for programming languages means C-inspired syntax.
> Smaltalk VMs, actually Self, were where the first usuable JIT compilers were developed.
> Smaltalk had it.
> Self and StrongTalk were quite performant. SIMD was not available back then.
Where are the benchmarks? Alan Kay wanted to kill Smalltalk in the 70's because the way they done things like reflection was done and performed poorly. The computer language shootout shows Dart outperforming Smalltalk by several factors for most things and their still working hard on improving performance with v1.0 of Dart not even released yet: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te... Note: many of the VM team that were originally on the StrongTalk VM team are working on the Dart VM now who have a heavy influenced on how Dart is designed to ensure it retains a great balance of productivity and performance.
> - Provides a unified object model so all classes from all libraries are interoperable
> Smaltalk had it.
Not a coincidence either, Dart's object model was inspired from Smalltalk as many of Dart engineers were from Smalltalk heritage.
> - Providing a rich, well-defined, consistent API, real collections, removing JS WATs, smoothing over browser quirks
> Smaltalk had real collections.
But does nothing to simplify web programming, which was the point of this.
> - Provides a unified and composable IO model: Futures and Streams (repeating events)
> Smalltalk has streams.
Dart is single-threaded and uses Future's for composing async operations for all non-blocking operations which is the default. Like most languages Smalltalk IO is mostly blocking and multi-threading and has poor support for non-blocking operations.
> Fare enough regarding WebUI, as the web did not exist back then. However Smaltalk is responsible for the MVC concept.
Right, but because its effectively non-existent for web programming we'll never see proper support for web technology like Web Components or tooling like TreeShaking, bundling.
> VM pruning in Smaltalk environments for deployment.
Which means nothing for web deployment and is less useful on the server where size is less of a factor.
> This is only true when using Dartium. Transpiling to JavaScript does not count.
Transpiling to JS does count, Dart has great source-maps support letting you debug Dart code from inside browsers running Dart2JS. But in terms of Native VM not running any JS, then yes Dartium now, Chrome in future and possibly Opera by virtue of Blink.
I've also used a number of languages in the last 15 years, and I've personally found Dart to be overall be the most productive which has become my go-to language whenever I need to something quick done. It's missing an ecosystem of mature libs which popularity helps most with - but Google has a ton of investment behind Dart which is developing the entire platform (language/libs/toolchain) giving it its best chance to succeed - if it fails to gain any traction it wont be for technical reasons. It looks like it will take over and be the preferred to succeed GWT and Closure Library, with internal usage it should see continued investment for years to come.