> I really like that they are adding things like check, assert, validate into the language itself.
I'm not sure. Contracts are supported in some other languages as a library feature; recent examples I encountered were Elixir, Scala, Clojure, and Haxe; there's also, of course, Racket, but there it's hard to say where the library ends, and language begins... Eiffel, Cobra, Pyret have contracts as a language feature - it may be easier to support it that way instead of first making the language expressive enough and then writing that library.
> What matters more is that it puts them all together in the right way, moves at a good pace, gains traction.
No, out of these only the last one matters: there is no "good" pace (you're either moving too fast or too slow), and there is no "right" way to design a language. The only thing that matters for a language is to gain traction - otherwise, it dies - and that seems to be almost entirely unrelated to the technical features of the language. Luck (e.g., C, Python, PHP) and money (e.g., Java, C#, Go) seem to play a much greater role in making a language successful, along with vendor lock-in (e.g., Objective C, Java, C#).
The lag between an innovative feature conception and its implementation (in the mainstream language(s)) seems to be 10-20 years on average, but it can sometimes take 50+ years while a feature is repeatedly discovered and forgotten in 10-20 years cycle. For example, there are optional static type systems (for otherwise dynamic languages) in languages from the '80s (ie. Common Lisp) and '90s (ie. Dylan), and the more formal gradual typing is IIRC from 2001 (by J. Siek). TypeScript, Flow, Python's mypy, and similar solutions are a mainstream-ish emanation of these ideas - it them took some 15 years to materialize and a few more to appear on the "working programmer" radar. This is a very common pattern: basically, if you want to know how programming will look like in a decade, you can simply look at the experimental features and ideas from 10+ years ago.