There are a lot of unwarranted conclusions drawn here. I think this article is FUD (and I don't really care for Dart).<p>> Dart programs may be statically checked. The static checker will report some violations of the type rules, but such violations do not abort compilation or preclude execution.<p>> In other words the "static checker" is a lint-type development aid, not a language feature.<p>My reading is that the language is optionally typed (similar to SBCL). The type checker will warn you when you have a type declaration that appears to be incorrect, and will optimized based on these declarations, but will not keep you from running code that violates a type-check. This is a remarkably good solution for dynamic languages.<p>> Here's a strange thing: the one and only true value is the boolean literal boolean true. Everything else is false. That means that code in if (1) { ... } will never execute, because 1 is a number, not a boolean, and there is no implicit conversion to boolean. You'll need to write if (1==1) instead.<p>This makes as much sense as 'everything' being true. You would write if (true) {...}, but I can't imagine why you would do that.<p>> There is no implicit type conversion between numeric, string or boolean types.<p>Ok. This is a good thing. Auto conversion is bad.<p>> The distinction between string and numbers allows to re-use the addition operator + both for addition and concatenation. However, without strong typing, this will almost certainly prove to be a bad idea. From the specs, it looks like "2" + 2 will be a concatenation, and 2 + "2" a run-time exception (in the absence of implicit conversion from string to number), but experience infirms this: string concatenation happens in both cases (although with a warning in the second one).<p>This seems to directly contradict the first point. Which is it? It should do a dynamic type check and generate a run time exception in both cases. I don't see anything to convince me that "2" + 2 will be a concatenation... in the spec.<p>>Thus, isolates are a heavyweight thread control model very much like Perl 5's ithreads. That means that they are good for data isolation, but heavy to use and hungry in memory, because spawning a new isolate will imply cloning all the objects and data structures of the running libraries.<p>There is absolutely nothing that implies this. There is a tiny section in the spec about isolates. They could easily be lightweight like Erlang processes.